什么是内存泄漏？在Java中如何排查内存泄漏问题？

紅蓮之龍

发布时间：2025-09-03 19:18:01

480人浏览过

来源于php中文网

原创

内存泄漏的常见迹象包括应用性能下降、频繁Full GC、OutOfMemoryError异常、系统资源占用飙升及部分功能异常。当Java程序中存在未释放的内存引用时，对象无法被垃圾回收，导致内存使用持续增长。典型表现有：响应变慢、GC日志显示Old区内存居高不下、堆内存使用率接近上限。结合jstat、jmap等JDK工具可初步排查，通过观察GC频率与堆内存变化，定位可疑对象，进一步分析Heap Dump以确定泄漏源头。

什么是内存泄漏？在java中如何排查内存泄漏问题？

内存泄漏，简单来说，就是程序在申请内存后，却忘记或者无法释放这部分内存，导致这些内存一直被占用，直到程序耗尽所有可用内存，最终崩溃。在Java里，这通常意味着一些对象本该被垃圾回收器（GC）回收，但由于某些引用链的存在，它们仍然被GC视为“可达”，从而无法被清理。这就像你租了个房间，用完了却忘了退租，房间费还在一直扣，直到你破产。

解决方案

排查Java内存泄漏，我个人觉得，更像是一场侦探游戏，需要耐心和一些趁手的工具。

第一步，也是最直观的，是观察系统表现。如果你的应用开始变得越来越慢，响应时间延长，或者时不时地抛出

OutOfMemoryError

，那基本可以确定，内存泄漏就在不远处等着你。这时候，我会先用一些基础的命令行工具，比如

jstat -gc <pid> 1000

来观察GC的活动情况。如果发现Full GC变得异常频繁，或者堆内存使用率持续高企不下，那这就是一个很强的信号。

接下来，真正的“武器”就派上用场了：内存分析工具。我最常用的，也是我个人觉得上手最快的，是VisualVM。你可以用它连接到你的Java进程，实时监控堆内存、GC活动。更关键的是，它可以方便地触发Heap Dump。一个Heap Dump，就好比是程序在某一刻的内存快照，里面记录了所有对象的详细信息。

立即学习“Java免费学习笔记（深入）”；

拿到Heap Dump后，无论是用VisualVM自带的分析器，还是更专业的MAT (Eclipse Memory Analyzer Tool)，甚至是JProfiler或YourKit，分析的思路都是相似的。我们主要关注以下几点：

大对象（Dominator Tree）：找到那些占据了大量内存的对象，或者说，那些“支配”了其他大量对象的对象。它们往往是泄漏的源头。
GC Roots路径：对于那些被怀疑泄漏的对象，查看它们到GC Roots的引用路径。只要存在一条到GC Roots的强引用路径，对象就不会被回收。我们需要找到这条路径，并理解为什么它不应该存在。
对象数量和类型：看看是否有某个类的实例数量异常增多，或者一些本该是短生命周期的对象却存活了很长时间。
浅层大小（Shallow Size）和保留大小（Retained Size）：浅层大小是对象自身占用内存，保留大小是对象自身加上它所持有的、且只被它持有的所有对象的内存总和。保留大小大的对象，往往是泄漏的“元凶”。

分析出可疑对象和引用路径后，就需要回溯代码了。这通常是最烧脑的一步。我一般会根据Heap Dump中显示的对象类型和引用链，在代码中搜索相关的类和逻辑。常见的泄漏模式包括：

云从科技AI开放平台

云从AI开放平台

下载

静态集合：比如一个静态的
```
HashMap
```
或
```
ArrayList
```
，不断地往里面添加对象，但从不移除。
未注销的监听器或回调：如果你注册了一个监听器，但没有在合适的时机取消注册，那么被监听的对象可能会一直持有监听器的引用，导致监听器对象无法被回收。
内部类引用外部类：非静态的内部类会隐式持有外部类的引用。如果内部类的实例生命周期比外部类长，就可能导致外部类无法被回收。
ThreadLocal未清理：
```
ThreadLocal
```
在线程池中尤其容易出问题，如果线程复用而没有手动调用
```
remove()
```
，旧值可能会一直存在。
资源未关闭：虽然不是严格意义上的Java堆内存泄漏，但像文件句柄、数据库连接等外部资源未关闭，也会导致系统资源耗尽，表现类似内存泄漏。

通过工具定位问题，再结合代码分析，通常就能找到内存泄漏的根源并加以修复。这过程可能需要反复几次，才能彻底解决。

内存泄漏的常见迹象有哪些？

说实话，内存泄漏这东西，它不会直接告诉你“我泄漏了！”。它更多的是通过一些“症状”来暗示你。最直接的，当然是你的应用突然抛出

java.lang.OutOfMemoryError: Java heap space

异常，这基本上就是内存耗尽的铁证了。但在此之前，通常会有一些预兆：

应用性能逐渐下降：随着运行时间的增长，应用的响应速度越来越慢，操作卡顿。这往往是因为GC为了清理内存，不得不频繁暂停应用线程，导致吞吐量下降。
频繁的Full GC：如果你观察到GC日志中Full GC的频率异常高，并且每次GC后内存使用率并没有显著下降，或者很快又涨了上去，那很可能就是有大量“垃圾”对象无法被回收。
系统资源占用飙升：不仅仅是Java堆内存，有时你会发现整个服务器的内存使用率都在不断攀升，即使Java进程本身没有直接占用那么多，也可能是因为GC频繁，导致CPU使用率过高，间接影响系统。
部分功能出现异常或不可用：比如一个缓存功能，本该有淘汰策略，结果缓存越来越大，导致查询变慢甚至崩溃。或者某个服务接口开始返回错误，因为内部某个集合已经塞满了对象。这些迹象单独出现可能不一定是内存泄漏，但如果组合出现，那排查内存泄漏就应该提上日程了。

Java中导致内存泄漏的常见陷阱和代码模式是什么？

在我多年的开发经验里，Java的内存泄漏，很多时候都和一些“想当然”或者“图方便”的代码习惯有关。以下是一些我经常遇到的陷阱：

静态集合的滥用与遗忘：这是最经典的。比如一个
```
static List<Object> cache = new ArrayList<>();
```
，你不断往里面加对象，却从不清理。这些对象因为被静态引用，永远不会被GC回收。即使你认为它们是“缓存”，也应该有明确的淘汰策略，或者考虑使用
```
WeakHashMap
```
等。
未注销的监听器和回调：当你为一个UI组件、一个事件源或者一个服务注册了监听器（Listener）或回调（Callback）时，如果这个事件源的生命周期比监听器长，而你又忘记在合适的时机（比如组件销毁时）取消注册，那么事件源就会一直持有监听器的强引用，导致监听器对象无法被回收。这在Android开发中尤为常见。
内部类对外部类的隐式引用：非静态的内部类（包括匿名内部类）会隐式地持有其外部类的引用。如果一个非静态内部类的实例被传递给了一个生命周期更长的对象，那么外部类的实例也可能因此无法被回收。一个常见的例子是，在Activity中创建了一个非静态的Handler，而Handler的消息队列中又持有Activity的引用，导致Activity无法被回收。
ThreadLocal
的“陷阱”：
```
ThreadLocal
```
本身是为了解决线程安全问题，但如果在使用线程池时，没有在任务结束后显式调用
```
ThreadLocal.remove()
```
来清理线程局部变量，那么当线程被回收并复用时，上一个任务设置的值可能仍然存在，并且如果这个值是一个大对象，就可能导致内存泄漏。
资源未关闭：虽然Java的垃圾回收机制处理了堆内存，但对于文件流（
```
FileInputStream
```
,
```
FileOutputStream
```
）、网络连接（
```
Socket
```
,
```
Connection
```
）、数据库连接（
```
Connection
```
,
```
Statement
```
,
```
ResultSet
```
）等系统资源，你需要手动关闭。如果忘记关闭，这些资源会一直被操作系统占用，最终导致资源耗尽。Java 7引入的
```
try-with-resources
```
语句就是为了解决这个问题，强烈推荐使用。
缓存机制的过度自信：自己实现缓存时，如果只考虑了“加”而没有考虑“淘汰”或“过期”，或者淘汰策略设计不当，很容易让缓存变成一个无限膨胀的黑洞。

这些模式，一旦不注意，就可能成为内存泄漏的温床。所以，在写代码的时候，多思考一下对象的生命周期和引用关系，很有必要。

如何利用JDK自带工具进行初步的内存泄漏排查？

JDK自带的工具，虽然可能没有JProfiler或YourKit那么华丽和功能强大，但它们在初步排查和定位问题上，绝对是够用的，而且还不用额外安装，非常方便。

jps
(Java Virtual Machine Process Status Tool)：这是你排查的第一步，用来查看当前系统上运行的所有Java进程的PID。知道了PID，才能对症下药。
```
jps -l
```
jstat
(JVM Statistics Monitoring Tool)：这个工具可以用来监控JVM的GC活动和堆内存使用情况。
```
jstat -gcutil <pid> 1000
```
：每秒打印一次GC统计信息，包括Young/Old/Metaspace代的利用率、GC次数和时间。如果你看到Old区（或Metaspace）利用率持续走高，或者Full GC频率异常，那就是个很强的信号。
```
jstat -gc <pid> 1000
```
：更详细的GC信息。
jmap
(Memory Map for Java)：这是获取堆内存信息的利器。
```
jmap -heap <pid>
```
：打印堆内存的概要信息，包括GC算法、堆配置参数以及各代的内存使用情况。
```
jmap -histo:live <pid>
```
：打印堆中对象的直方图，显示每个类的实例数量和内存占用。
```
live
```
参数表示只统计存活对象。如果你发现某个类的实例数量异常多，或者占用了大量内存，那它就可能是泄漏的嫌疑犯。
```
jmap -dump:format=b,file=heapdump.hprof <pid>
```
：这是最关键的，它会生成一个二进制格式的堆转储文件（Heap Dump）。这个文件包含了JVM某一时刻所有对象的详细信息，是后续使用MAT、VisualVM等工具进行深度分析的原始数据。
jstack
(Stack Trace for Java)：虽然
```
jstack
```
主要是用来查看线程堆栈，排查死锁或线程阻塞问题，但有时也能间接帮助我们。如果某个线程因为持有大量资源而长时间阻塞，或者大量线程都处于等待状态，可能也暗示着资源未释放或处理不当，虽然不是