静态集合导致内存泄漏的本质是对象被长期强引用而无法回收——只要集合不清理、不置空、不设限，对象就永远活在堆里；其根本原因是static变量作为gc root使所持对象不可被gc回收。
静态集合导致的内存泄漏，本质是对象被长期强引用而无法回收——只要集合不清理、不置空、不设限，对象就永远活在堆里。
为什么 static List/Map 会卡死 GC
静态变量生命周期与 JVM 一致，它持有的每个 Object 都算作 GC Root 的直接或间接引用。哪怕业务逻辑早已不用这些对象，只要它们还在 staticList 或 staticMap 里，GC 就绝不会碰。
- 常见错误写法：
private static List<user> cache = new ArrayList();</user>—— 没上限、没清理、没超时 - 更隐蔽的是：
static Map<string object></string>用作缓存，但 key 不是弱引用，value 也不可回收 - 注意
ThreadLocal的 value 如果是静态持有对象（比如static ThreadLocal<map></map>），也会等效于静态集合
用 jmap + MAT 快速定位泄漏源头
别猜，直接看谁在撑大堆——重点不是“有多少对象”，而是“谁一直留着它们”。
- 先确认现象：
jstat -gc <pid></pid>显示老年代（OU）持续上涨，且FGC后不下降 - 立刻导出快照：
jmap -dump:format=b,file=heap.hprof <pid></pid>（注意：生产环境慎用，可能暂停应用数秒） - 用 Eclipse MAT 打开后，点 Leak Suspects Report → 看 “Problem Suspect 1” 是否指向某个静态集合类
- 再进 Dominator Tree，按包名排序，找
java.util.ArrayList或java.util.HashMap实例，右键 → Path to GC Roots → exclude weak/soft references
如果路径终点是 java.lang.Class → static field，基本就是它了。
修复时最容易踩的三个坑
改代码不难，但改错方向会让问题更隐蔽。
- 只清空集合内容（
list.clear()）但没重置引用本身？——如果其他地方还持有着这个list实例，下次照样加新对象 - 换成
WeakHashMap就以为万事大吉？——key 是弱引用，但 value 仍是强引用；value 本身又引用了别的长生命周期对象，照样泄漏 - 加了定时清理逻辑，但没考虑并发：多个线程同时
add和clear，可能漏数据或抛ConcurrentModificationException
真正稳妥的做法是：用 ConcurrentHashMap + 过期策略（如 expireAfterWrite(10, TimeUnit.MINUTES)），或者直接上 Caffeine，别手写静态缓存。
上线前必须验证的细节
修复完不等于结束——得证明它真不涨了。
- 不能只跑一次单元测试；要在和生产相似的负载下，连续压测 30 分钟以上，监控
jstat -gc <pid></pid>的OU值是否平稳 - 如果用了
WeakReference或SoftReference，注意 JVM 参数影响：-XX:SoftRefLRUPolicyMSPerMB会改变软引用回收时机，测试环境默认值可能和线上不同 - 静态集合如果被多个模块共用，要检查所有调用方是否都遵循了新增/删除/过期的约定，一个漏掉就前功尽弃
最常被忽略的一点：静态集合本身可能只是“中转站”，真正泄漏的其实是它里面存的那些对象所持有的子对象（比如 User 里有个 static Config 字段）。所以 MAT 里一定要顺着引用链往下钻两层，别停在第一级。
