java内存泄漏本质是本该不可达的对象因静态集合、未注销监听器、threadlocal未清理或缓存无上限等误连gc roots而持续可达，导致gc无法回收。

Java 有 GC 并不等于不会内存泄漏。关键在于：GC 只回收「不可达」对象，而内存泄漏的本质是「本该不可达的对象，却因意外保留了可达路径」——两者看似矛盾，实则紧密关联。

内存泄漏的根源在 GC Roots 的误连

JVM 判定一个对象是否可回收，只看它是否能从 GC Roots 沿引用链到达。只要有一条强引用路径存在，哪怕逻辑上这个对象早已不用，GC 就永远无法回收它。

常见误连场景包括：

• 静态集合类（如 static Map、static List）持续添加对象却不清理
• 未注销的监听器或回调（如 GUI 事件、Netty ChannelHandler）
• ThreadLocal 变量未调用 remove()，导致线程复用时对象长期滞留
• 缓存未设上限或失效策略，对象被强引用锁死

GC 行为异常是内存泄漏的早期信号

内存泄漏不会立刻崩溃，但会逐步改变 GC 的运行特征：

• Minor GC 频率升高，但每次回收后老年代占用持续上涨
• Full GC 越来越频繁，且每次回收释放的内存越来越少
• 堆内存使用曲线呈现「阶梯式上升」，停顿时间逐渐拉长

这些现象说明：新生代对象不断晋升到老年代，而老年代中大量对象本该死亡却因引用残留而存活——这正是泄漏对象堆积的表现。

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

定位泄漏要从堆快照反查 GC Roots

光看 GC 日志只能发现问题，确认泄漏点必须分析堆内存快照（heap dump）：

• 用 jmap -dump:format=b,file=heap.hprof 抓取快照
• 用 Eclipse MAT 或 VisualVM 打开，按「dominator tree」查看大对象及其支配关系
• 对可疑对象右键 → 「Path to GC Roots」→ 勾选「exclude weak/soft references」，找出强引用链起点

真正起作用的，往往不是那个大对象本身，而是它上方某个静态字段、线程局部变量或未关闭资源持有的强引用。

修复核心是切断非必要强引用

找到 GC Roots 路径后，修复方向很明确：

• 把静态集合换成弱引用容器（如 WeakHashMap），或加主动清理逻辑
• 注册监听器时记录引用，业务结束前显式 unregister
• ThreadLocal 使用后务必调用 remove()，尤其在线程池场景下
• 缓存改用 SoftReference 或带 LRU 和过期机制的工具类（如 Caffeine）

不是所有引用都要删，而是让“本该结束生命周期”的对象，真正脱离 GC Roots 的可达范围。