静态集合类未清理是Java最典型内存泄漏场景——对象被长期强引用导致GC无法回收；需用jmap+MAT查Dominator Tree定位静态字段持有路径，结合代码审查add/remove逻辑，并用Caffeine等带驱逐策略的缓存替代手写静态集合。
静态集合类（如 static List）未清理是Java中最典型、最易复现的内存泄漏场景之一。它不依赖复杂框架或异步逻辑，只要对象被加入静态集合后长期不移除，就会持续强引用，GC完全无法回收——排查关键在于“确认谁在往里塞、谁该负责清、现在堆里还剩多少”。
看堆转储，锁定静态集合实例和持有对象
这是最直接有效的手段。用 jmap 生成堆快照后，用 MAT（Eclipse Memory Analyzer）打开：
- 执行
jmap -dump:live,format=b,file=heap.hprof <pid></pid>获取当前存活对象的完整堆镜像 - 在 MAT 中打开“Dominator Tree”，按“Retained Heap”排序，找到占用内存最大的
ArrayList或HashMap实例 - 右键 → “Merge Shortest Paths to GC Roots”，勾选“exclude weak/soft references”，查看哪些静态字段持有了它——大概率会指向类似
com.example.CacheManager.cache这样的路径 - 点开该集合，查看其
elementData数组内容，就能看到里面存了哪些业务对象（比如几千个Order、UserSession），验证是否已失效但未清除
查代码，定位 add 和 missing remove 的位置
光知道“有集合”不够，得确认逻辑断点：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 全局搜索
private static.*List、public static.*Map等模式，列出所有可疑静态集合声明 - 对每个集合，检查是否有配套的
clear()、remove(key)或过期淘汰逻辑；特别注意：没有remove调用，或者remove只在异常分支里、从未被执行过 - 重点审查缓存类、监听器注册中心、任务队列管理器等高频使用静态集合的模块；例如
TaskManager.TASK_CACHE.put(taskId, task)后，是否对应存在TASK_CACHE.remove(taskId)（尤其在任务失败或超时场景下）
加监控，验证泄漏是否持续发生
避免“一次排查、反复复发”，需要建立可观测性：
立即学习“Java免费学习笔记（深入）”；
- 在集合的
add方法里打日志，记录时间、线程名、对象类型和数量，观察是否只增不减 - 用 JMX 暴露集合 size 属性（如通过
@ManagedResource注册），接入 Prometheus + Grafana，画出cache.size随时间变化曲线——若持续上升且无回落，基本坐实泄漏 - 结合 JVM GC 日志（开启
-Xlog:gc*:file=gc.log），观察老年代使用率是否缓慢爬升、Full GC 频次是否降低但每次回收量变少——这是静态集合泄漏的典型 GC 行为特征
改代码，从设计上切断强引用链
修复不是简单加一行 clear()，而是按场景选择安全方案：
- 如果必须用静态缓存，改用
ConcurrentHashMap+computeIfAbsent，并配合WeakReference或SoftReference包装 value，让 GC 可介入 - 优先替换为带自动驱逐的缓存库，如 Caffeine：
Caffeine.newBuilder().maximumSize(1000).expireAfterWrite(10, TimeUnit.MINUTES).build() - 若业务逻辑确实需要长期持有，明确生命周期边界：比如绑定到 Spring 的
@Scope("singleton")Bean 上，利用@PreDestroy清理；或在应用 shutdown hook 中统一释放
