内存泄漏排查：分析集合变量持有长寿命对象导致的 Java Heap Space

Ja va内存泄漏的祸根，往往藏在最不起眼的角落——那些看似无害的集合变量，一旦持有了不该长期持有的对象，就会变成堆内存的黑洞。问题不在于集合本身，而在于它“不该长期存着却一直存着”的对象引用。这些对象本该随业务逻辑结束就被回收，却因被静态或长生命周期容器强持有，成了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 观察两秒一次的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