内存溢出、内存泄露、GC的基本概念-Java面试题-PHP中文网

内存溢出是程序申请内存失败时的崩溃信号，内存泄露是无用对象因被引用无法回收导致的内存浪费，GC通过标记-清除机制自动回收不可达对象，但无法解决逻辑上的内存泄露；二者需结合工具分析和代码优化来预防与排查。

内存溢出、内存泄露、gc的基本概念

内存溢出、内存泄露和垃圾回收（GC）是Java（或其他托管语言）开发中绕不开的几个核心概念。简单来说，内存溢出是程序试图申请超过可用内存时发生的错误；内存泄露则是指程序中不再需要的内存未能被及时释放，导致内存逐渐耗尽；而GC，就是系统自动清理那些不再被使用的内存的机制。理解它们，是写出稳定、高性能应用的基础。

解决方案

谈到这些概念，我常常觉得它们像是一场围绕着“内存”展开的持续博弈。

内存溢出（Out Of Memory, OOM） 这就像你家里有个水箱，容量是固定的。当你不断往里灌水，直到水箱满了，水就溢出来了。在程序里，内存溢出就是JVM（Java虚拟机）或者你的应用尝试分配新的内存，但发现堆（Heap）上已经没有足够的空间了。它是一个事件，一个程序崩溃的信号。常见的内存溢出类型有很多，比如：

java.lang.OutOfMemoryError: Java heap space：这是最常见的，堆内存不够用了。可能你创建了太多对象，或者对象太大，或者集合类里装了太多东西没及时清理。
java.lang.OutOfMemoryError: Metaspace (JDK8及以后) / PermGen space (JDK7及以前)：这块区域主要存放类的元数据信息。如果加载了太多类，或者动态生成了大量类，就可能在这里溢出。
java.lang.OutOfMemoryError: GC overhead limit exceeded：当GC在回收内存上花费了超过98%的时间，并且回收的内存少于2%时，JVM就会抛这个错误。这通常意味着你的应用内存极度紧张，GC已经快忙不过来了。

内存泄露（Memory Leak） 如果说内存溢出是水箱满了溢出来，那内存泄露就是水箱底部有个小洞，水一直在往外渗，但你没察觉，或者察觉了但修不好。在程序里，内存泄露指的是那些你已经不再需要使用的对象，但由于某种原因（比如还有强引用指向它们），垃圾回收器无法识别它们为“垃圾”并回收其占用的内存。于是，这些“僵尸”对象就一直霸占着内存，随着程序的运行，可用内存会越来越少，最终往往会导致内存溢出。内存泄露往往比内存溢出更隐蔽，因为它不是一个即时错误，而是一个缓慢积累的过程。常见的泄露场景包括：

静态集合类引用： static List<Object> cache = new ArrayList<>(); 如果你往这个静态列表里不断添加对象，但从不移除，那么这些对象将永远不会被GC回收。
未关闭的资源： 数据库连接、文件流、网络连接等，如果使用完后没有显式关闭，它们占用的内存可能不会被释放。
监听器或回调未注销： 当一个对象注册了某个监听器，但在其生命周期结束时没有取消注册，那么监听器持有对该对象的引用，导致对象无法被回收。
内部类或匿名类引用外部类： 如果内部类（尤其是非静态内部类）的实例生命周期比外部类长，它可能会隐式持有外部类的引用，阻止外部类被回收。

垃圾回收（Garbage Collection, GC） GC是Java等语言的一大特色，它自动管理内存，省去了开发者手动分配和释放内存的繁琐与易错。GC的核心任务就是找出那些“死”了的对象（即不再被任何活跃引用指向的对象），然后回收它们占用的内存空间。 GC的工作流程大致可以概括为：

标记（Marking）： 从一组“GC Roots”（如线程栈中的局部变量、静态变量、JNI引用等）开始，遍历所有可达的对象。所有能被GC Roots直接或间接访问到的对象都被标记为“存活”对象。
清除（Sweeping）： 遍历堆中所有对象，将未被标记的对象（即“垃圾”对象）所占用的内存空间进行回收。
压缩（Compacting）： （可选步骤）为了避免内存碎片化，有些GC算法会在回收后将存活对象移动到一起，形成连续的内存空间。 Java的GC机制基于“分代假设”：大多数对象都是朝生夕死的；熬过越多次GC的对象，越可能活得久。因此，堆被划分为年轻代（Young Generation）和老年代（Old Generation），并针对不同代采用不同的GC算法，以提高效率。

内存溢出与内存泄露：它们究竟有何不同？

我个人觉得，理解这两者的差异，是解决内存问题的第一步。内存溢出（OOM）是一个结果，是系统内存耗尽时抛出的一个错误，它告诉你“没地儿了！”。而内存泄露（Memory Leak）则是一个过程，是导致内存逐渐减少，最终引发OOM的根本原因之一。你可以把OOM想象成你汽车油箱空了，熄火了；而内存泄露，则像是油箱底部有个小孔，油一直在滴，你没发现，最后导致油箱空了。

一个程序可能因为瞬间需要大量内存而直接发生OOM，这不一定是内存泄露导致的，比如你尝试一次性读取一个几GB的大文件到内存中。但很多时候，内存泄露才是那个“慢性病”，它慢慢侵蚀着系统的可用内存，直到有一天，内存池被耗尽，OOM就爆发了。所以，当看到OOM时，我们首先要思考的，往往是：这是不是一个内存泄露的信号？是不是有某些对象被不合理地持有了？

垃圾回收（GC）如何工作，它能解决所有内存问题吗？

GC的工作原理，核心在于“可达性分析”。它不像C++那样需要你手动delete对象，而是通过判断对象是否还有“根”（GC Roots）引用来决定其“生死”。比如，一个局部变量在方法执行结束后，如果它引用的对象没有其他地方再引用，那么这个对象就变得不可达了，GC就会把它标记为垃圾。

那么，GC能解决所有内存问题吗？答案是不能，而且这是很多初学者容易误解的地方。GC确实能自动回收那些不再被引用的对象，极大地简化了内存管理。但它无法解决“逻辑上的内存泄露”。什么叫“逻辑上的内存泄露”？就是那些对象在代码逻辑上已经不再需要了，但因为某种原因，它们仍然被GC Roots强引用着，所以GC认为它们是“活”的，不会去回收它们。

存了个图

视频图片解析/字幕/剪辑，视频高清保存/图片源图提取

查看详情

举个例子，你有一个缓存Map，往里面放了1000个用户对象，但你只在业务上需要其中100个。剩下的900个在逻辑上是“废弃”的，但由于它们还在Map里被引用着，GC就无能为力。这就是典型的内存泄露，GC无法解决。它只能清理那些你真正“丢弃”了的对象。所以，GC是内存管理的强大助手，但它不是万能药，我们仍然需要编写合理的代码来避免不必要的对象引用，尤其是那些生命周期过长的引用。

如何诊断和避免内存溢出与内存泄露？

诊断和避免这些问题，是一门实践性很强的学问。我这些年处理过不少这类问题，总结下来，通常是“预防为主，诊断为辅”。

诊断： 当OOM发生时，JVM会打印出详细的错误信息和堆栈跟踪，这是第一手资料。例如，java.lang.OutOfMemoryError: Java heap space会告诉你堆内存不够。更深入的诊断，需要借助工具：

JVisualVM/JConsole： 这些是JDK自带的监控工具，可以实时查看JVM的内存使用情况、GC活动、线程状态等。如果发现堆内存持续上涨，并且在Full GC后也无法下降到正常水平，那很可能就是内存泄露。
内存分析工具（如Eclipse MAT, JProfiler, YourKit）： 当OOM发生时，JVM可以配置生成一个堆转储文件（Heap Dump，通常是.hprof格式）。这些工具可以加载.hprof文件，分析内存中的对象分布、对象引用链、支配者树（Dominator Tree），从而找出是哪些对象占用了大量内存，以及它们为什么没有被回收。比如，MAT可以很方便地找出“泄露嫌疑”最大的对象，并显示其到GC Roots的引用路径。

避免：

及时释放资源： 任何打开的I/O流、数据库连接、网络连接等，都要确保在finally块中关闭，或者使用Java 7引入的try-with-resources语句，它能自动关闭实现了AutoCloseable接口的资源。
注销监听器/回调： 如果你注册了某个事件监听器，在其生命周期结束时，一定要记得取消注册，否则监听器对象会一直持有对被监听对象的引用。
谨慎使用静态集合： 静态集合的生命周期与应用程序相同。如果往static Map或List中添加对象，但从不移除，就可能导致内存泄露。如果需要缓存，考虑使用WeakHashMap（键被GC回收时，对应的值也会被移除）或设置合理的缓存淘汰策略（如LRU）。
避免不必要的强引用： 特别是在内部类和匿名类中，它们默认持有外部类的引用。如果内部类的生命周期比外部类长，可能导致外部类无法被回收。必要时，考虑使用静态内部类。
优化数据结构和算法： 有时，内存溢出不是泄露，而是你的算法本身需要处理的数据量过大，或者数据结构选择不当。例如，处理超大文件时，不要一次性读入内存，而是分块读取或使用流式处理。
合理配置JVM内存参数： 根据应用的实际需求，调整-Xmx（最大堆内存）和-Xms（初始堆内存）等参数。但这不是解决内存泄露的办法，只是延缓OOM的发生。
代码审查： 定期进行代码审查，关注对象生命周期、资源管理和集合使用模式，这些地方常常是内存问题的温床。