静态集合类持续添加对象却不清理是Java最典型内存泄漏源；表现为老年代内存单向上涨、Full GC后不下降、YGC频次升高，需用jstat观察、jmap+MAT定位、重点排查裸集合、伪缓存及隐式引用，并以专业缓存或弱引用替代。
静态集合类（如 static List、static Map）持续添加对象却不清理，是 Java 中最典型、最隐蔽的内存泄漏源头。它不报错、不崩溃，只让老年代内存缓慢但坚定地上升，最终触发频繁 Full GC 甚至 OutOfMemoryError。排查关键不是看集合本身，而是盯住“谁在往里加、加完清没清、有没有其他隐式引用”。
看现象：用 jstat 快速确认是否为静态集合泄漏
别急着翻代码，先观察 JVM 行为是否符合典型泄漏特征：
- 执行
jstat -gc <pid> 2000</pid>每两秒刷新一次，重点关注：
OU（Old Used）是否单向缓慢上涨，且每次 Full GC 后几乎不下降（比如 FGC 后 OU 仅降 1–2MB） - 对比 OC（Old Capacity）与 OU 比值，若长期 >85% 并持续爬升，说明老年代对象堆积严重
- 观察 YGC 频次是否异常升高——大量对象从年轻代“逃逸”到老年代，常见原因就是被静态集合长期强引用
- 检查业务请求量是否平稳；若流量无明显增长但堆持续上涨，基本可排除外部压力，指向内部对象滞留
抓快照：用 jmap + MAT 定位具体是哪个静态集合
确认异常后，导出堆快照进行根因分析（建议选低峰期操作）：
- 执行
jmap -dump:format=b,file=heap.hprof <pid></pid>获取堆镜像 - 用 Eclipse MAT 打开，直接点击 Leak Suspects Report，通常第一个嫌疑就是
java.util.ArrayList或java.util.HashMap - 进入 Dominator Tree，按你项目包名（如
com.example.util）排序，快速定位可疑工具类或缓存类中的静态集合 - 右键该集合实例 → Path to GC Roots → exclude all weak/soft references；若路径终点显示
java.lang.Class → static field，就坐实了：这个静态字段就是泄漏根因
查代码：重点扫描三类高危写法
在工程中全局搜索 private static.*List、static.*Map、static.*cache 等关键词，尤其注意以下模式：
立即学习“Java免费学习笔记（深入）”；
-
裸静态集合无上限无清理：例如
private static List<user> cache = new ArrayList();</user>—— 只有add()，没有clear()、remove()或过期逻辑 -
伪缓存滥用：Spring
@Service类里声明static Map，误当轻量缓存使用，实际生命周期与类加载器一致，永不释放 -
subList 或内部类引入隐式强引用：如
staticList.add(list.subList(0, 1))（视图持整个底层数组），或staticList.add(() -> doSomething())（Lambda 隐式持有外部类this，可能钉住 Controller、Activity 等大对象）
修方案：断引用链，而非仅清内容
修复不是简单加一行 list.clear()，必须确保 GC Root 引用链真正断裂：
- 在 MAT 中验证修复后，该
ArrayList实例是否已不在任何 GC Roots 路径上 -
优先替换为专业缓存库：选用 Caffeine，配置
maximumSize(1000)和expireAfterWrite(10, TimeUnit.MINUTES)，让淘汰自动发生 - 必须手写时，避免
static List，改用ConcurrentHashMap<key weakreference>></key>，或至少配合容量检查 + 主动驱逐逻辑 - 对已存在的静态集合，补全清理入口（如 Spring
@PreDestroy方法），并加入监控告警（如定期上报集合 size）
