静态Map缓存未设过期淘汰是Java内存泄漏最隐蔽高发隐患，表现为老年代内存持续增长、FGC后不回落、OOM前YGC频次升高；需用jstat定位OU异常、jmap+MAT分析根因、排查三类高危写法并用Caffeine等专业方案修复。
静态 Map 缓存未设过期淘汰，是 Java 内存泄漏最隐蔽也最高发的隐患之一。它不抛异常、不中断业务，只让老年代内存缓慢爬升，直到某次 Full GC 后仍居高不下，最终触发 OOM。
看现象：用 jstat 锁定老年代单向增长
先别翻代码，快速验证是否是它在作怪：
- 执行 jstat -gc <pid> 2000，每两秒刷新一次，重点关注 OU（Old Used） 列——若持续上升、每次 FGC 后几乎不回落，就是典型信号
- 同时观察 OC（Old Capacity） 与 OU 的比值，长期高于 85% 且趋势向上，基本可判定有长生命周期对象堆积
- YGC 频次明显升高？说明大量对象“躲过”年轻代回收，逃逸到老年代——而它们很可能正被静态 Map 强引用着
抓快照：用 jmap 导出堆并定位根因
确认异常后，立即导出堆快照（建议选业务低峰期）：
- 运行 jmap -dump:format=b,file=heap.hprof <pid> 生成二进制快照
- 用 Eclipse MAT 打开，点 Leak Suspects Report，第一嫌疑往往就是某个 java.util.HashMap 实例
- 进入 Dominator Tree，按包名排序，找到你项目里的工具类或缓存类；右键该 Map → Path to GC Roots → 勾选 exclude all weak/soft references
- 如果路径终点是 java.lang.Class → static field，就坐实了：这个静态字段就是泄漏源头
查代码：三类高危写法必须立刻扫描
在工程中全局搜索 private static.*Map、static.*cache 等关键词，重点盯：
立即学习“Java免费学习笔记（深入）”；
-
无上限无清理的裸 Map：比如
private static Map<String, User> cache = new HashMap<>();，只有 put，从不 remove - 伪缓存逻辑：尤其 Spring @Service 类里写的 static Map，被当成“轻量缓存”用，但没配淘汰策略、也没业务侧清理入口
-
ThreadLocal + static 组合：如
private static final ThreadLocal<Map> holder = new ThreadLocal<>();，等效于每个线程持有一个永不释放的强引用集合
修方案：断引用链，不是清内容
修复的关键不是调 list.clear()，而是切断 GC Root 引用链并防复发：
-
优先替换为专业缓存库：用 Caffeine，配置
maximumSize(1000)和expireAfterWrite(10, TimeUnit.MINUTES)，自动淘汰 -
若必须手写：用 ConcurrentHashMap 替代 HashMap，配合定时任务调用
computeIfPresent清理过期项（注意加锁或 CAS，避免并发问题） - 慎用 WeakHashMap：它只在 key 不再被其他强引用持有时才自动清理，若业务中 key 是 Long/String 等常量池对象，可能根本不会被回收
不复杂但容易忽略。真正卡住系统的，往往不是大对象，而是成千上万个被静态 Map 死死拽住的小对象。
