我刚刚接受了一次面试，我被要求用 Java 创建一个内存泄漏。
不用说，我什至不知道如何开始创建一个，感觉很愚蠢。
有什么例子？
【问题讨论】：
标签： java memory memory-leaks
这是在纯 Java 中创建真正的内存泄漏（运行代码无法访问但仍存储在内存中的对象）的好方法：
ClassLoader 加载类。new byte[1000000]），在静态字段中存储对它的强引用，然后在ThreadLocal 中存储对自身的引用。分配额外的内存是可选的（泄漏类实例就足够了），但它会使泄漏工作得更快。ClassLoader 的引用。由于 ThreadLocal 在 Oracle 的 JDK 中的实现方式，这会造成内存泄漏：
Thread 都有一个私有字段threadLocals，它实际上存储了线程局部值。ThreadLocal 对象的弱引用，因此在对 ThreadLocal 对象进行垃圾回收后，其条目将从映射中删除。ThreadLocal对象时，该对象既不会只要线程存在，就会被垃圾收集或从地图中删除。在本例中，强引用链如下所示：
Thread对象→threadLocals映射→示例类的实例→示例类→静态ThreadLocal字段→ThreadLocal对象。
(ClassLoader 并没有真正起到造成泄漏的作用，它只是因为这个额外的引用链而使泄漏变得更糟：示例类 → ClassLoader → 它已加载的所有类。甚至在许多 JVM 实现中更糟糕，尤其是在 Java 7 之前，因为类和 ClassLoaders 被直接分配到 permgen 中，根本没有被垃圾回收。）
这种模式的一个变体是，如果您经常重新部署碰巧使用ThreadLocals 的应用程序，应用程序容器（如Tomcat）可能会像筛子一样泄漏内存，而这些应用程序在某种程度上又指向了它们自己。发生这种情况的原因有很多，而且通常很难调试和/或修复。
更新：由于很多人一直在要求它，here's some example code that shows this behavior in action。
【讨论】：
包含对象引用的静态字段[尤其是 final field]
class MemorableClass {
static final ArrayList list = new ArrayList(100);
}
在长字符串上调用String.intern()
String str = readString(); // read lengthy string any source db,textbox/jsp etc..
// This will place the string in memory pool from which you can't remove
str.intern();
（未关闭）打开的流（文件、网络等）
try {
BufferedReader br = new BufferedReader(new FileReader(inputFile));
...
...
} catch (Exception e) {
e.printStacktrace();
}
未关闭的连接
try {
Connection conn = ConnectionFactory.getConnection();
...
...
} catch (Exception e) {
e.printStacktrace();
}
JVM 垃圾收集器无法访问的区域，例如通过本机方法分配的内存。
在 Web 应用程序中，一些对象存储在应用程序范围内，直到应用程序被显式停止或删除。
getServletContext().setAttribute("SOME_MAP", map);
不正确或不合适的 JVM 选项，例如 IBM JDK 上的 noclassgc 选项可防止未使用的类垃圾回收
【讨论】：
close() 通常不会在终结器线程中调用，因为可能是阻塞操作）。不关闭是不好的做法，但不会导致泄漏。未关闭的java.sql.Connection也是一样的。
intern 哈希表内容上仅具有弱引用。因此，它是正确收集垃圾而不是泄漏。 （但 IANAJP）mindprod.com/jgloss/interned.html#GC
一个简单的做法是使用不正确（或不存在）hashCode() 或equals() 的 HashSet，然后继续添加“重复项”。集合不会像它应该忽略的那样忽略重复项，而是只会增长并且您将无法删除它们。
如果你想让这些坏键/元素到处乱跑，你可以使用像
这样的静态字段class BadKey {
// no hashCode or equals();
public final String key;
public BadKey(String key) { this.key = key; }
}
Map map = System.getProperties();
map.put(new BadKey("key"), "value"); // Memory leak even if your threads die.
【讨论】：
BadKey myKey = new BadKey("key"); map.put(key,"value");，你才能把它弄出来。你是对的，你可以使用迭代器来删除它，但你不能总是对所有数据结构都这样做。例如，如果您不取消@meriton 答案中的引用，那将永远丢失。你无权访问后备数组，迭代器将停止它。
下面会出现一个不明显的 Java 泄漏案例，除了标准案例被遗忘的侦听器、静态引用、hashmap 中的虚假/可修改键，或者只是线程卡住而没有任何机会结束其生命周期。
File.deleteOnExit() - 总是泄漏字符串，我将集中在线程上，主要展示非托管线程的危险，甚至不想碰摇摆。
Runtime.addShutdownHook 并且不删除...，然后即使使用 removeShutdownHook 由于 ThreadGroup 类中关于未启动线程的错误，它可能不会被收集，有效地泄漏 ThreadGroup。 JGroup 在 GossipRouter 中有漏洞。
创建但未启动 Thread 属于与上述相同的类别。
创建线程会继承ContextClassLoader 和AccessControlContext，加上ThreadGroup 和任何InheritedThreadLocal，所有这些引用以及类加载器加载的整个类和所有静态引用都是潜在的泄漏, 和 ja-ja。整个 j.u.c.Executor 框架的效果尤其明显，该框架具有超级简单的ThreadFactory 接口，但大多数开发人员对潜伏的危险一无所知。还有很多库会根据请求启动线程（行业流行的库太多了）。
ThreadLocal 缓存；在许多情况下，这些都是邪恶的。我相信每个人都看过很多基于 ThreadLocal 的简单缓存，但坏消息是：如果线程持续运行超过预期的上下文 ClassLoader 的生命周期，这纯粹是一个不错的小泄漏。除非确实需要，否则不要使用 ThreadLocal 缓存。
当线程组本身没有线程时调用ThreadGroup.destroy()，但它仍然保留子线程组。严重的泄漏会阻止 ThreadGroup 从其父级中删除，但所有子级都变得不可枚举。
使用 WeakHashMap 和值 (in) 直接引用键。如果没有堆转储，这很难找到。这适用于所有可能保留对受保护对象的硬引用的扩展 Weak/SoftReference。
将 java.net.URL 与 HTTP(S) 协议一起使用并从 (!) 加载资源。这个很特别，KeepAliveCache 在系统 ThreadGroup 中创建了一个新线程，它会泄露当前线程的上下文类加载器。当没有活动线程存在时，该线程是在第一次请求时创建的，因此您可能会幸运或只是泄漏。 泄漏已经在 Java 7 中得到修复，创建线程的代码会正确删除上下文类加载器。还有少数情况（像 ImageFetcher，也已修复 em>) 创建类似的线程。
使用InflaterInputStream 在构造函数中传递new java.util.zip.Inflater()（例如PNGImageDecoder）而不是调用充气器的end()。好吧，如果你只用new 传入构造函数，就没有机会......而且是的，如果它作为构造函数参数手动传递，则在流上调用close() 不会关闭充气器。这不是真正的泄漏，因为它会被终结器释放......当它认为有必要时。直到那一刻，它严重地吃掉了本机内存，它可能导致 Linux oom_killer 杀死进程而不受惩罚。主要问题是 Java 中的最终确定非常不可靠，G1 使情况变得更糟，直到 7.0.2。故事的寓意：尽快释放原生资源；终结器太差了。
与java.util.zip.Deflater 的情况相同。这要糟糕得多，因为 Deflater 在 Java 中很耗内存，即总是使用 15 位（最大）和 8 级内存（最大 9 级）来分配数百 KB 的本机内存。幸运的是，Deflater 并没有被广泛使用，据我所知，JDK 没有滥用。如果您手动创建Deflater 或Inflater，请始终调用end()。最后两个中最好的部分：您无法通过可用的常规分析工具找到它们。
（我可以根据要求添加更多我遇到的浪费时间。）
祝你好运，保持安全；泄漏是邪恶的！
【讨论】：
Creating but not starting a Thread... 哎呀，几个世纪前我被这个咬得很厉害！ (Java 1.3)
unstarted 计数，而且防止线程组被破坏（较小的邪恶但仍然是泄漏）
ThreadGroup.destroy()...” 是一个非常微妙的错误；我已经追了几个小时了，误入歧途，因为在我的控制 GUI 中枚举线程没有显示任何内容，但是线程组和大概至少一个子组不会消失。
这里的大多数示例“太复杂”。它们是边缘情况。在这些例子中，程序员犯了一个错误（比如不要重新定义equals/hashcode），或者被JVM/JAVA的极端情况所困扰（静态类的加载......）。我认为这不是面试官想要的示例类型，甚至不是最常见的情况。
但是内存泄漏确实有更简单的情况。垃圾收集器只释放不再引用的内容。作为 Java 开发人员，我们并不关心内存。我们在需要时分配它并让它自动释放。很好。
但任何长期存在的应用程序都倾向于具有共享状态。它可以是任何东西，静态的，单例的......通常不平凡的应用程序倾向于制作复杂的对象图。只是忘记设置对 null 的引用或更经常忘记从集合中删除一个对象就足以造成内存泄漏。
当然，如果处理不当，所有类型的侦听器（如 UI 侦听器）、缓存或任何长期存在的共享状态都会产生内存泄漏。应该理解的是，这不是 Java 的极端情况，也不是垃圾收集器的问题。这是一个设计问题。我们设计为向长寿命对象添加监听器，但在不再需要时不会删除监听器。我们缓存对象，但我们没有将它们从缓存中删除的策略。
我们可能有一个复杂的图来存储计算所需的先前状态。但之前的状态本身与之前的状态相关联，以此类推。
就像我们必须关闭 SQL 连接或文件一样。我们需要设置对 null 的正确引用并从集合中删除元素。我们应该有适当的缓存策略（最大内存大小、元素数量或计时器）。允许通知侦听器的所有对象都必须提供 addListener 和 removeListener 方法。而当这些通知器不再使用时，它们必须清除它们的监听器列表。
内存泄漏确实是可能的，并且完全可以预测。不需要特殊的语言功能或极端情况。内存泄漏要么表明可能缺少某些东西，要么表明存在设计问题。
【讨论】：
答案完全取决于面试官认为他们在问什么。
在实践中是否有可能使 Java 泄漏？当然是这样，其他答案中有很多例子。
但是可能已经提出了多个元问题？
我将您的元问题解读为“在这种面试情况下我可以使用什么答案”。因此，我将专注于面试技巧而不是 Java。我相信你更有可能在面试中重复不知道问题答案的情况，而不是你需要知道如何让 Java 泄漏的情况。所以，希望这会有所帮助。
您可以为面试培养的一项最重要的技能是学会积极倾听问题并与面试官合作以提取他们的意图。这不仅可以让您以他们想要的方式回答他们的问题，而且还表明您具有一些重要的沟通技巧。当要在众多同样才华横溢的开发人员之间进行选择时，我会雇佣那些在每次回应之前都会倾听、思考和理解的人。
【讨论】：
如果您不了解JDBC，以下是一个毫无意义的示例。或者至少 JDBC 期望开发人员在丢弃它们或丢失对它们的引用之前关闭 Connection、Statement 和 ResultSet 实例，而不是依赖于 finalize 的实现。
void doWork() {
try {
Connection conn = ConnectionFactory.getConnection();
PreparedStatement stmt = conn.preparedStatement("some query");
// executes a valid query
ResultSet rs = stmt.executeQuery();
while(rs.hasNext()) {
// ... process the result set
}
} catch(SQLException sqlEx) {
log(sqlEx);
}
}
上面的问题是Connection 对象没有关闭，因此物理连接将保持打开状态，直到垃圾收集器发现它无法访问。 GC 会调用finalize 方法，但是有些JDBC 驱动程序没有实现finalize，至少与实现Connection.close 的方式不同。由此产生的行为是，虽然由于收集了无法访问的对象而回收了内存，但与 Connection 对象关联的资源（包括内存）可能根本不会被回收。
在Connection 的finalize 方法无法清理所有内容的情况下，实际上可能会发现与数据库服务器的物理连接将持续几个垃圾回收周期，直到数据库服务器最终弄清楚连接不存在（如果存在），应该关闭。
即使 JDBC 驱动程序要实现 finalize，也有可能在终结期间引发异常。结果行为是任何与现在“休眠”对象关联的内存都不会被回收，因为finalize 保证只会被调用一次。
上述在对象终结期间遇到异常的场景与另一个可能导致内存泄漏的场景有关 - 对象复活。对象复活通常是通过从另一个对象创建对对象的强引用来有意完成的。当对象复活被滥用时，它会导致内存泄漏与其他内存泄漏源相结合。
还有很多你可以想出的例子——比如
List 实例，您只添加到列表中而不是从中删除（尽管您应该删除不再需要的元素），或者Sockets 或Files，但在不再需要它们时不关闭它们（类似于上面涉及Connection 类的示例）。【讨论】：
ArrayList.remove(int) 的实现可能是潜在内存泄漏的最简单示例之一，以及如何避免它：
public E remove(int index) {
RangeCheck(index);
modCount++;
E oldValue = (E) elementData[index];
int numMoved = size - index - 1;
if (numMoved > 0)
System.arraycopy(elementData, index + 1, elementData, index,
numMoved);
elementData[--size] = null; // (!) Let gc do its work
return oldValue;
}
如果你自己实现的话，你会不会想过清除不再使用的数组元素（elementData[--size] = null）？该引用可能会使一个巨大的对象保持活力......
【讨论】：
任何时候，如果您保留对不再需要的对象的引用，就会发生内存泄漏。请参阅Handling memory leaks in Java programs，了解内存泄漏在 Java 中的表现方式以及您可以采取的措施。
【讨论】：
您可以使用 sun.misc.Unsafe 类造成内存泄漏。事实上，这个服务类在不同的标准类中使用（例如在 java.nio 类中）。 您不能直接创建此类的实例，但您可以使用反射来做到这一点。
代码无法在 Eclipse IDE 中编译 - 使用命令 javac 编译它（编译期间您会收到警告）
import java.lang.reflect.Constructor;
import java.lang.reflect.Field;
import sun.misc.Unsafe;
public class TestUnsafe {
public static void main(String[] args) throws Exception{
Class unsafeClass = Class.forName("sun.misc.Unsafe");
Field f = unsafeClass.getDeclaredField("theUnsafe");
f.setAccessible(true);
Unsafe unsafe = (Unsafe) f.get(null);
System.out.print("4..3..2..1...");
try
{
for(;;)
unsafe.allocateMemory(1024*1024);
} catch(Error e) {
System.out.println("Boom :)");
e.printStackTrace();
}
}
}
【讨论】：
我可以从这里复制我的答案： Easiest way to cause memory leak in Java
“计算机科学中的内存泄漏（或在此上下文中的泄漏）发生在计算机程序消耗内存但无法将其释放回操作系统时。” （维基百科）
简单的答案是：你不能。 Java 会自动进行内存管理，并会释放您不需要的资源。你无法阻止这种情况发生。它将总是能够释放资源。在具有手动内存管理的程序中，这是不同的。您可以使用 malloc() 在 C 中获取一些内存。要释放内存，您需要 malloc 返回的指针并在其上调用 free()。但是，如果您不再拥有该指针（被覆盖，或者超出了生命周期），那么很遗憾，您将无法释放此内存，从而导致内存泄漏。
到目前为止，所有其他答案都在我的定义中，并不是真正的内存泄漏。他们都旨在快速用毫无意义的东西填充记忆。但是在任何时候你仍然可以取消引用你创建的对象，从而释放内存 --> 没有泄漏。 acconrad's answer 非常接近，尽管我不得不承认，因为他的解决方案是通过强制垃圾收集器进入无限循环来有效地“崩溃”垃圾收集器）。
长答案是：您可以通过使用 JNI 为 Java 编写一个库来获得内存泄漏，该库可以进行手动内存管理，因此存在内存泄漏。如果你调用这个库，你的 Java 进程会泄漏内存。或者，您可能在 JVM 中存在错误，从而导致 JVM 丢失内存。 JVM 中可能存在错误，甚至可能有一些已知的错误，因为垃圾收集并不是那么微不足道，但它仍然是一个错误。按照设计，这是不可能的。您可能会要求一些受此类错误影响的 Java 代码。抱歉，我不知道，在下一个 Java 版本中它可能不再是一个错误。
【讨论】：
通过http://wiki.eclipse.org/Performance_Bloopers#String.substring.28.29，这是一个简单/险恶的。
public class StringLeaker
{
private final String muchSmallerString;
public StringLeaker()
{
// Imagine the whole Declaration of Independence here
String veryLongString = "We hold these truths to be self-evident...";
// The substring here maintains a reference to the internal char[]
// representation of the original string.
this.muchSmallerString = veryLongString.substring(0, 1);
}
}
因为子字符串是指原始字符串的内部表示，更长的字符串，原始字符串保留在内存中。因此，只要你有一个 StringLeaker 在运行，你就会在内存中拥有整个原始字符串，即使你可能认为你只是在保留一个单个字符的字符串。
避免存储对原始字符串的不需要的引用的方法是执行以下操作：
...
this.muchSmallerString = new String(veryLongString.substring(0, 1));
...
为了增加坏处，你也可以.intern()子字符串：
...
this.muchSmallerString = veryLongString.substring(0, 1).intern();
...
即使在 StringLeaker 实例被丢弃后，这样做也会将原始长字符串和派生子字符串保留在内存中。
【讨论】：
GUI 代码中的一个常见示例是创建小部件/组件并向某些静态/应用程序范围的对象添加侦听器，然后在销毁小部件时不移除侦听器。您不仅会遇到内存泄漏，还会影响性能，因为当您正在监听的任何事件触发事件时，所有旧监听器也会被调用。
【讨论】：
也许通过 JNI 使用外部本机代码？
使用纯 Java 几乎是不可能的。
但这是关于“标准”类型的内存泄漏，当您无法再访问内存时，它仍然归应用程序所有。您可以改为保留对未使用对象的引用，或者打开流而不在之后关闭它们。
【讨论】：
使用在任何 servlet 容器中运行的任何 Web 应用程序（Tomcat、Jetty、GlassFish 等等……）。连续重新部署应用程序 10 或 20 次（只需触摸服务器自动部署目录中的 WAR 就足够了。
除非有人实际对此进行了测试，否则在几次重新部署后您很可能会收到 OutOfMemoryError，因为应用程序没有注意自行清理。通过此测试，您甚至可能会在您的服务器中发现一个错误。
问题是，容器的生命周期比应用程序的生命周期长。您必须确保容器可能对应用程序的对象或类的所有引用都可以被垃圾回收。
如果只有一个引用在您的 Web 应用程序的取消部署中幸存下来，则相应的类加载器以及因此您的 Web 应用程序的所有类都不能被垃圾回收。
您的应用程序启动的线程、ThreadLocal 变量、日志附加程序是导致类加载器泄漏的常见原因。
【讨论】：
关于 PermGen 和 XML 解析，我曾经有过一次很好的“内存泄漏”。 我们使用的 XML 解析器（我不记得是哪一个了）对标签名称执行了 String.intern()，以便更快地进行比较。 我们的一位客户提出了一个绝妙的想法，即不将数据值存储在 XML 属性或文本中，而是作为标记名存储，因此我们的文档如下：
<data>
<1>bla</1>
<2>foo</>
...
</data>
事实上，他们没有使用数字，而是使用更长的文本 ID（大约 20 个字符），这些 ID 是独一无二的，每天以 10-15 百万的速度出现。这使得每天产生 200 MB 的垃圾，这不再需要，也永远不会被 GC（因为它在 PermGen 中）。我们将 permgen 设置为 512 MB，因此内存不足异常 (OOME) 大约需要两天时间才能到达...
【讨论】：
什么是内存泄漏：
典型例子：
对象缓存是一个很好的起点。
private static final Map<String, Info> myCache = new HashMap<>();
public void getInfo(String key)
{
// uses cache
Info info = myCache.get(key);
if (info != null) return info;
// if it's not in cache, then fetch it from the database
info = Database.fetch(key);
if (info == null) return null;
// and store it in the cache
myCache.put(key, info);
return info;
}
您的缓存会不断增长。很快整个数据库就被吸进了内存。更好的设计使用 LRUMap（仅在缓存中保留最近使用的对象）。
当然，你可以让事情变得更复杂：
经常发生的事情：
如果此 Info 对象引用了其他对象，则该对象又引用了其他对象。在某种程度上，您也可以认为这是某种内存泄漏（由糟糕的设计引起）。
【讨论】：
面试官可能正在寻找类似下面的代码的循环引用（顺便说一下，它只会在使用引用计数的非常旧的 JVM 中泄漏内存，现在已经不是这种情况了）。但这是一个非常模糊的问题，因此这是展示您对 JVM 内存管理的理解的绝佳机会。
class A {
B bRef;
}
class B {
A aRef;
}
public class Main {
public static void main(String args[]) {
A myA = new A();
B myB = new B();
myA.bRef = myB;
myB.aRef = myA;
myA=null;
myB=null;
/* at this point, there is no access to the myA and myB objects, */
/* even though both objects still have active references. */
} /* main */
}
那么你可以解释一下，使用引用计数，上面的代码会泄漏内存。但是大多数现代 JVM 不再使用引用计数。大多数使用清扫垃圾收集器，它实际上会收集这些内存。
接下来您可能会解释如何创建一个具有底层原生资源的对象，如下所示：
public class Main {
public static void main(String args[]) {
Socket s = new Socket(InetAddress.getByName("google.com"),80);
s=null;
/* at this point, because you didn't close the socket properly, */
/* you have a leak of a native descriptor, which uses memory. */
}
}
然后你可以解释这是技术上的内存泄漏，但实际上泄漏是由 JVM 中的本机代码分配底层本机资源引起的，这些资源没有被你的 Java 代码释放。
归根结底，对于现代 JVM，您需要编写一些 Java 代码来分配超出 JVM 感知范围的本机资源。
【讨论】：
我认为没有人使用内部类示例很有趣。如果你有一个内部类；它固有地维护对包含类的引用。当然，从技术上讲，这不是内存泄漏，因为 Java 最终会清理它；但这可能会导致课程停留的时间比预期的要长。
public class Example1 {
public Example2 getNewExample2() {
return this.new Example2();
}
public class Example2 {
public Example2() {}
}
}
现在，如果您调用 Example1 并得到一个 Example2 丢弃 Example1，那么您本质上仍然有一个指向 Example1 对象的链接。
public class Referencer {
public static Example2 GetAnExample2() {
Example1 ex = new Example1();
return ex.getNewExample2();
}
public static void main(String[] args) {
Example2 ex = Referencer.GetAnExample2();
// As long as ex is reachable; Example1 will always remain in memory.
}
}
我还听说过一个传言，如果你有一个变量存在的时间超过了特定的时间； Java 假定它永远存在，并且如果代码中无法再访问它，实际上将永远不会尝试清理它。但这是完全未经证实的。
【讨论】：
我最近遇到了一个由 log4j 引起的内存泄漏情况。
Log4j 有这种称为Nested Diagnostic Context(NDC) 的机制，它是一种用于区分来自不同来源的交错日志输出的工具。 NDC工作的粒度是线程，所以它会分别区分不同线程的日志输出。
为了存储线程特定的标签，log4j 的 NDC 类使用一个 Hashtable，它由 Thread 对象本身作为键（而不是线程 id），因此直到 NDC 标签留在内存中，所有挂起的对象线程对象也留在内存中。在我们的 Web 应用程序中，我们使用 NDC 使用请求 id 标记日志输出，以将日志与单个请求分开。将 NDC 标记与线程相关联的容器也在从请求返回响应时将其删除。问题发生在处理请求的过程中，产生了一个子线程，类似于以下代码：
pubclic class RequestProcessor {
private static final Logger logger = Logger.getLogger(RequestProcessor.class);
public void doSomething() {
....
final List<String> hugeList = new ArrayList<String>(10000);
new Thread() {
public void run() {
logger.info("Child thread spawned")
for(String s:hugeList) {
....
}
}
}.start();
}
}
因此，NDC 上下文与生成的内联线程相关联。作为这个 NDC 上下文的关键的线程对象是内联线程，它有一个巨大的列表对象。因此，即使在线程完成它正在做的事情之后，对 hugeList 的引用仍然被 NDC 上下文 Hastable 保持活动状态，从而导致内存泄漏。
【讨论】：
创建一个静态 Map 并不断添加硬引用。这些永远不会被垃圾收集。
public class Leaker {
private static final Map<String, Object> CACHE = new HashMap<String, Object>();
// Keep adding until failure.
public static void addToCache(String key, Object value) { Leaker.CACHE.put(key, value); }
}
【讨论】：
每个人总是忘记原生代码路由。这是一个简单的泄漏公式：
malloc。不要打电话给free。请记住，本机代码中的内存分配来自 JVM 堆。
【讨论】：
您可以通过在该类的 finalize 方法中创建一个类的新实例来创建移动内存泄漏。如果终结器创建多个实例，则加分。这是一个简单的程序，它会根据您的堆大小在几秒到几分钟之间泄漏整个堆：
class Leakee {
public void check() {
if (depth > 2) {
Leaker.done();
}
}
private int depth;
public Leakee(int d) {
depth = d;
}
protected void finalize() {
new Leakee(depth + 1).check();
new Leakee(depth + 1).check();
}
}
public class Leaker {
private static boolean makeMore = true;
public static void done() {
makeMore = false;
}
public static void main(String[] args) throws InterruptedException {
// make a bunch of them until the garbage collector gets active
while (makeMore) {
new Leakee(0).check();
}
// sit back and watch the finalizers chew through memory
while (true) {
Thread.sleep(1000);
System.out.println("memory=" +
Runtime.getRuntime().freeMemory() + " / " +
Runtime.getRuntime().totalMemory());
}
}
}
【讨论】：
我想还没有人说过：你可以通过重写 finalize() 方法来复活一个对象，这样 finalize() 就会在某处存储 this 的引用。垃圾收集器只会在对象上调用一次，因此之后该对象将永远不会被销毁。
【讨论】：
finalize() 不会被调用，但是一旦没有更多的引用，对象就会被收集。垃圾收集器也没有被“调用”。
finalize()方法只能被JVM调用一次，但这并不意味着如果对象复活然后再次取消引用它就不能被重新垃圾收集。如果finalize()方法中有资源关闭代码，那么这段代码将不会再次运行，这可能会导致内存泄漏。
我最近遇到了一种更微妙的资源泄漏。 我们通过类加载器的getResourceAsStream打开资源，碰巧输入流句柄没有关闭。
嗯，你可能会说，真是个白痴。
嗯，有趣的是：通过这种方式，您可以泄漏底层进程的堆内存，而不是从 JVM 的堆中泄漏。
您只需要一个 jar 文件，其中包含一个文件，该文件将从 Java 代码中引用。 jar 文件越大，分配的内存就越快。
您可以使用以下类轻松创建这样的 jar：
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.util.zip.ZipEntry;
import java.util.zip.ZipOutputStream;
public class BigJarCreator {
public static void main(String[] args) throws IOException {
ZipOutputStream zos = new ZipOutputStream(new FileOutputStream(new File("big.jar")));
zos.putNextEntry(new ZipEntry("resource.txt"));
zos.write("not too much in here".getBytes());
zos.closeEntry();
zos.putNextEntry(new ZipEntry("largeFile.out"));
for (int i=0 ; i<10000000 ; i++) {
zos.write((int) (Math.round(Math.random()*100)+20));
}
zos.closeEntry();
zos.close();
}
}
只需粘贴到名为 BigJarCreator.java 的文件中，从命令行编译并运行它：
javac BigJarCreator.java
java -cp . BigJarCreator
等等：您在当前工作目录中找到一个 jar 存档，其中包含两个文件。
让我们创建第二个类：
public class MemLeak {
public static void main(String[] args) throws InterruptedException {
int ITERATIONS=100000;
for (int i=0 ; i<ITERATIONS ; i++) {
MemLeak.class.getClassLoader().getResourceAsStream("resource.txt");
}
System.out.println("finished creation of streams, now waiting to be killed");
Thread.sleep(Long.MAX_VALUE);
}
}
这个类基本上什么都不做，只是创建未引用的 InputStream 对象。这些对象将立即被垃圾收集，因此不会增加堆大小。 对于我们的示例来说，从 jar 文件加载现有资源很重要，而且大小在这里很重要！
如果您有疑问，请尝试编译并启动上面的类，但请确保选择合适的堆大小（2 MB）：
javac MemLeak.java
java -Xmx2m -classpath .:big.jar MemLeak
您不会在此处遇到 OOM 错误，因为没有保留任何引用，所以无论您在上面的示例中选择了多大的 ITERATIONS，应用程序都会继续运行。 除非应用程序进入等待命令，否则进程的内存消耗（在顶部 (RES/RSS) 或进程资源管理器中可见）会增长。在上面的设置中，它将分配大约 150 MB 的内存。
如果您希望应用程序安全运行，请在其创建位置关闭输入流：
MemLeak.class.getClassLoader().getResourceAsStream("resource.txt").close();
并且您的进程不会超过 35 MB，与迭代次数无关。
相当简单和令人惊讶。
【讨论】：
另一种可能造成巨大内存泄漏的方法是保存对 Map.Entry<K,V> 的引用，而不是 TreeMap。
很难评估为什么这仅适用于TreeMaps，但通过查看实现，原因可能是：TreeMap.Entry 存储对其兄弟的引用，因此如果 TreeMap 准备好已收集，但其他一些类持有对其任何 Map.Entry 的引用，则 整个 Map 将被保留到内存中。
真实场景：
想象一下，有一个 db 查询返回一个大的 TreeMap 数据结构。人们通常使用TreeMaps 作为保留元素插入顺序。
public static Map<String, Integer> pseudoQueryDatabase();
如果查询被多次调用，并且对于每个查询（因此，对于每个返回的 Map），您在某处保存一个 Entry，内存将不断增长。
考虑以下包装类：
class EntryHolder {
Map.Entry<String, Integer> entry;
EntryHolder(Map.Entry<String, Integer> entry) {
this.entry = entry;
}
}
应用：
public class LeakTest {
private final List<EntryHolder> holdersCache = new ArrayList<>();
private static final int MAP_SIZE = 100_000;
public void run() {
// create 500 entries each holding a reference to an Entry of a TreeMap
IntStream.range(0, 500).forEach(value -> {
// create map
final Map<String, Integer> map = pseudoQueryDatabase();
final int index = new Random().nextInt(MAP_SIZE);
// get random entry from map
for (Map.Entry<String, Integer> entry : map.entrySet()) {
if (entry.getValue().equals(index)) {
holdersCache.add(new EntryHolder(entry));
break;
}
}
// to observe behavior in visualvm
try {
Thread.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
}
});
}
public static Map<String, Integer> pseudoQueryDatabase() {
final Map<String, Integer> map = new TreeMap<>();
IntStream.range(0, MAP_SIZE).forEach(i -> map.put(String.valueOf(i), i));
return map;
}
public static void main(String[] args) throws Exception {
new LeakTest().run();
}
}
在每次pseudoQueryDatabase() 调用之后，map 实例应该准备好收集，但不会发生，因为至少有一个 Entry 存储在其他地方。
根据您的jvm 设置，应用程序可能会在早期由于OutOfMemoryError 而崩溃。
您可以从这张visualvm 图表中看到内存是如何不断增长的。
哈希数据结构 (HashMap) 不会发生同样的情况。
这是使用HashMap时的图表。
解决方案？直接保存键/值（您可能已经这样做了）而不是保存Map.Entry。
我写了一个更广泛的基准here。
【讨论】：
正如很多人所建议的那样，资源泄漏相当容易导致 - 就像 JDBC 示例一样。实际的 memory 泄漏要困难一些 - 特别是如果您不依赖 JVM 的残缺部分来为您做这件事...
创建占用空间非常大的对象然后无法访问它们的想法也不是真正的内存泄漏。如果没有东西可以访问它，那么它将被垃圾收集，如果有东西可以访问它，那么它就不是泄漏......
使用的一种方法——我不知道它是否仍然有效——是有一个三深的循环链。就像对象 A 引用了对象 B，对象 B 引用了对象 C，而对象 C 引用了对象 A。GC 足够聪明地知道两个深链 - 如 A B - 如果 A 和 B 不能被其他任何东西访问，可以安全地收集，但无法处理三向链......
【讨论】：
面试官可能一直在寻找循环参考解决方案：
public static void main(String[] args) {
while (true) {
Element first = new Element();
first.next = new Element();
first.next.next = first;
}
}
这是引用计数垃圾收集器的经典问题。然后你会礼貌地解释说 JVM 使用了一种更复杂的算法，没有这个限制。
【讨论】：
first 没有用处，应该被垃圾回收。在引用计数垃圾收集器中，对象不会被释放，因为它（本身）有一个活动引用。无限循环是为了证明泄漏：当你运行程序时，内存会无限增加。
线程在终止之前不会被收集。它们充当垃圾收集的roots。它们是少数不会仅仅通过忘记它们或清除对它们的引用而不会被回收的对象之一。
考虑：终止工作线程的基本模式是设置线程看到的一些条件变量。线程可以定期检查变量并将其用作终止信号。如果变量没有声明volatile，那么线程可能看不到对变量的更改，因此它不会知道终止。或者想象一下，如果某些线程想要更新共享对象，但在尝试锁定它时出现死锁。
如果您只有少数线程，这些错误可能会很明显，因为您的程序将停止正常工作。如果您有一个线程池可以根据需要创建更多线程，那么过时/卡住的线程可能不会被注意到，并且会无限期地累积，从而导致内存泄漏。线程可能会在您的应用程序中使用其他数据，因此也会阻止收集它们直接引用的任何数据。
作为一个玩具示例：
static void leakMe(final Object object) {
new Thread() {
public void run() {
Object o = object;
for (;;) {
try {
sleep(Long.MAX_VALUE);
} catch (InterruptedException e) {}
}
}
}.start();
}
随便调用System.gc()，但是传递给leakMe的对象永远不会死。
【讨论】：
我认为一个有效的示例可能是在线程池化的环境中使用 ThreadLocal 变量。
例如，使用 Servlet 中的 ThreadLocal 变量与其他 Web 组件进行通信，让线程由容器创建并在池中维护空闲的线程。 ThreadLocal 变量，如果没有正确清理，将一直存在，直到同一个 Web 组件可能覆盖它们的值。
当然，一旦确定，问题就很容易解决了。
【讨论】：