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 <pid> 抓取快照
- 用 Eclipse MAT 或 VisualVM 打开，按「dominator tree」查看大对象及其支配关系
- 对可疑对象右键 → 「Path to GC Roots」→ 勾选「exclude weak/soft references」，找出强引用链起点
真正起作用的，往往不是那个大对象本身，而是它上方某个静态字段、线程局部变量或未关闭资源持有的强引用。
修复核心是切断非必要强引用
找到 GC Roots 路径后，修复方向很明确：
- 把静态集合换成弱引用容器（如 WeakHashMap），或加主动清理逻辑
- 注册监听器时记录引用，业务结束前显式 unregister
- ThreadLocal 使用后务必调用 remove()，尤其在线程池场景下
- 缓存改用 SoftReference 或带 LRU 和过期机制的工具类（如 Caffeine）
不是所有引用都要删，而是让“本该结束生命周期”的对象，真正脱离 GC Roots 的可达范围。
