静态集合类是Java内存泄漏最常见诱因，因其生命周期与类加载器绑定，长期持有对象导致OOM；需通过工具定位、控制生命周期、显式清理及预防性编码规范来防范。
Java内存泄漏中，长生命周期集合类（如静态Map、缓存容器、监听器列表等）是最常见诱因之一：对象被意外长期持有，无法被GC回收，导致堆内存持续增长，最终OOM。
为什么静态集合最容易引发泄漏
静态变量生命周期与类加载器一致，只要类不卸载，其引用的集合就一直存在。若往其中不断添加对象（尤其未及时清理），这些对象及其引用链上的所有对象都会“活”在老年代。
- 典型场景：用static Map<String, Object>做全局缓存，但忘记失效机制或未移除过期项
- 常见陷阱：将Activity、Fragment、Context、Runnable、内部类实例放入静态集合——它们隐式持有所在类的引用，直接拖垮整个页面对象图
- 注意：WeakHashMap虽能缓解，但仅对key弱引用，value仍强引用；若value又反向引用key或其他大对象，照样泄漏
如何快速定位这类泄漏
不依赖猜测，用工具看真实引用链：
- 用jstat观察老年代使用率是否单向上升（jstat -gc <pid> 5s）
- 触发Full GC后dump堆（jmap -dump:format=b,file=heap.hprof <pid>），用Eclipse MAT打开，按“Leak Suspects”报告优先查看
- 在MAT中用“Merge Shortest Paths to GC Roots”分析可疑集合里的对象，重点看是否有不该存在的业务对象（如已finish的Activity）被静态Map强引用
修复关键点：控制生命周期 + 显式清理
核心原则是让集合的生命周期与业务逻辑对齐，而非“一建永驻”：
立即学习“Java免费学习笔记（深入）”；
- 避免静态集合存储业务对象；改用局部变量、作用域明确的Bean（如Spring @Scope("prototype")）或依赖注入容器管理
- 必须用静态缓存时，加自动淘汰策略：用Caffeine替代手写Map，配置maximumSize、expireAfterWrite等
- 注册型集合（如事件监听器、回调队列）务必配套remove逻辑：在onDestroy、unregister、close等钩子中显式清理，建议用WeakReference包装listener防止强引用滞留
- 检查日志中是否有“java.lang.OutOfMemoryError: Java heap space”伴随大量相同类实例，结合代码搜索add/put操作点
预防比诊断更重要
从编码习惯入手降低风险：
- 所有静态集合声明旁加注释，说明“谁负责清理”“何时清空”“最大容量限制”
- Code Review时重点检查static字段、单例类、Application级别容器的增删操作是否成对
- 单元测试中模拟长时间运行，用jcmd或Arthas监控堆内指定类实例数是否异常增长
