Java内存泄漏最常见原因是静态集合类长期持有短生命周期对象引用，如static List/Map未及时清理，导致对象无法被GC回收，持续占用堆内存。
集合变量持有长寿命对象是 Java 堆内存泄漏最常见、最隐蔽的根源之一。问题不在于集合本身，而在于它“不该长期存着却一直存着”的对象引用——这些对象本该随业务逻辑结束就被回收，却因被静态或长生命周期容器强持有，变成 GC Root 不可达路径上的“活死人”。
重点看静态/单例集合是否失控
静态集合（static List/Map/Set）生命周期与类加载器一致，只要类没卸载，里面所有元素就永远无法被 GC 回收。哪怕只是缓存一个用户会话对象，若没配容量限制、过期策略或清理入口，1000 个请求就积累 1000 个对象，堆内存只增不减。
- 检查所有 private static final Map, ?>、static List> 声明，确认是否有 put/putAll/add 等写入操作但无对应 remove/clear
- 特别注意工具类、配置管理器、全局事件总线中的集合字段，它们常被误认为“只读”，实则悄悄在后台添加监听器或上下文数据
- 用 MAT 打开 heap dump 后，在 Dominator Tree 中搜索类名含 “Cache”、“Manager”、“Holder” 的静态集合实例，点开看其 value 或 element 数量是否异常高（如 >10k）
警惕非静态但被长生命周期对象持有的集合
不是 static 的集合也可能酿成泄漏——只要它属于一个长期存活的对象（如 Spring 单例 Bean、Servlet、Connection Pool）。例如：
- 一个 @Service 类中定义了 private List
pendingTasks ，但处理完后未清空；下次请求复用该实例，列表越积越多 - 数据库连接池里的 Connection 对象内部持有 PreparedStatement 缓存，若 SQL 拼接不当生成大量唯一语句，缓存键不断膨胀
- 自定义线程池中 Worker 线程持有 ThreadLocal
快速验证与修复方向
不用等 OOM，现在就能动手验证：
- 用 jstat -gc
2000 观察 2 秒一次的 GC 日志：若 Old Gen 使用率持续上升、Full GC 后回落极少（如只降 5%），高度可疑 - 执行 jmap -dump:format=b,file=leak.hprof
抓快照，用 Eclipse MAT 打开 → Run Report → “Leak Suspects” → 查看 “Problem Suspect 1” 是否指向某个集合及其内部对象 - 修复优先级：加容量上限（new LinkedHashMap(1000, 0.75f, true) 实现 LRU）＞ 改用 WeakHashMap（键为弱引用）＞ 补充 clear() 调用点 ＞ 改用软引用包装值（SoftReference
）
别忽略引用类型本身的设计缺陷
有些集合看似“合理”，实则暗藏陷阱：
- ConcurrentHashMap 不是万能的——它线程安全，但不解决“该删不删”的逻辑问题；put 进去的 key 若是未重写 equals/hashCode 的自定义对象，会导致重复插入无法命中，最终堆积
- ArrayList 在反复 add/remove 后可能保留大量 null 元素（尤其调用过 remove(i) 但未 trimToSize），占用空间却不显眼
- 用字符串拼接作 Map key（如 "user_" + id + "_cache"）易产生不可复用的临时对象，建议统一转为 Long 或 UUID 作为 key
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
