静态集合类是Java中最常见、最隐蔽的内存泄漏源头，因其生命周期与JVM同寿，且易因缓存无淘汰、监听器未注销、Key可变失联、清理逻辑失效等导致对象长期驻留堆内存。
静态集合类（比如 static Map、static List）是Java中最常见、最隐蔽的内存泄漏源头之一。根本原因在于：静态变量的生命周期与JVM同寿，只要类没被卸载，它持有的所有对象就一直无法被GC回收——哪怕这些对象业务上早已“死亡”。
缓存未设上限也无淘汰机制
很多开发者用 public static Map<Long, User> cache = new HashMap<>(); 做简易缓存，只加不删。用户登录信息、订单快照等不断写入，却从不清理。随着时间推移，Map里对象越积越多，堆内存持续上涨，最终触发 OutOfMemoryError。
- 避免直接用
HashMap或ArrayList作全局缓存容器 - 改用
LinkedHashMap并重写removeEldestEntry()实现LRU自动淘汰 - 或引入成熟缓存库（如 Caffeine），它内置容量控制、过期策略和弱引用支持
监听器/回调注册后未注销
在工具类中定义静态集合存放监听器，例如：private static List<EventListener> listeners = new ArrayList<>();，业务模块注册后忘记反注册。即使该模块实例已销毁，监听器仍被静态列表强引用，连带其所属对象一并“钉”在内存里。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 提供配套的
unregister()方法，并确保调用时机（如Spring中用@PreDestroy） - 考虑用
WeakReference<EventListener>包装监听器，避免强引用拖住整个对象图 - 若监听器本身是匿名内部类，需注意它隐式持有外部类引用，可能引发连锁泄漏
Key可变导致Map条目永久滞留
把一个普通POJO（字段可修改）作为 static Map 的key，后续又更改了影响 hashCode() 或 equals() 的字段。这时 map.get(key) 查不到，map.remove(key) 也删不掉——条目实际还在，但彻底“失联”，Value对象永远无法释放。
立即学习“Java免费学习笔记（深入）”；
- 用作Map Key的对象必须是不可变的（immutable），推荐使用
String、Long或自定义final类 - 若必须用可变对象，应在放入Map前深拷贝为不可变副本
- 定期用MAT分析堆转储，检查是否存在大量“无法访问却未回收”的Value对象
缺乏清理入口或清理逻辑失效
有些代码写了 clear() 或 remove() 方法，但调用点缺失、条件判断错误，或清理动作被异常中断而未执行。比如定时任务配置失败、服务启停时未触发清理钩子、多线程并发下remove操作被覆盖等。
- 静态集合的增删操作尽量封装成原子方法，避免裸露集合引用
- 关键清理逻辑加上日志或监控埋点，确认是否真正执行
- 对高频写入场景，增加容量水位告警（如size() > 10000时发通知）
