静态集合类因强引用且生命周期与应用一致，导致所持对象无法被GC回收，从而引发内存泄漏；典型如无清除机制的static HashMap会持续累积对象直至OOM。
静态集合类为什么会导致内存泄漏
静态集合类（如 static List、static Map）的生命周期与类加载器一致，贯穿整个应用运行期。只要集合本身不被销毁，它所持有的所有对象都会被强引用持续“拴住”，即使这些对象在业务逻辑中早已无用，GC 也无法回收它们。
关键点在于：强引用 + 长生命周期容器 = 对象无法释放。比如一个 static HashMap<Long, User> 不断 put 用户对象，但没提供 remove 或 clear 机制，User 实例就会越积越多，最终耗尽堆内存，触发 OutOfMemoryError。
典型错误写法示例
以下代码看似简单，实则危险：
public class CacheUtil {
private static final Map
public static void put(String key, Object value) { cache.put(key, value); }
public static Object get(String key) { return cache.get(key); }
}
问题在于：没有清除入口、没有容量限制、没有过期机制。缓存只会单向增长，对象永远驻留。
实用且可落地的解决方案
不是禁用静态集合，而是让它的行为可控、可回收：
-
优先用弱引用容器：改用
WeakHashMap（键为弱引用），当 key 不再被其他地方强引用时，对应 entry 会在 GC 时自动清理；适用于“缓存键本身可被回收”的场景 -
内置淘汰策略：继承
LinkedHashMap并重写removeEldestEntry()，实现 LRU 或固定容量上限，避免无限堆积 -
显式管理生命周期：提供
evictByKey()、clearExpired()等方法，并在业务关键路径（如用户登出、请求完成）中主动调用 -
改用局部变量或作用域受限的集合：多数临时缓存无需全局静态，用方法内局部
new ArrayList()更安全，随栈帧自然消亡
辅助手段：监控与验证
光靠编码规范不够，要建立可观测性：
- 定期导出 heap dump，用 MAT 或 JProfiler 检查静态集合大小及其中对象的存活时间
- 在测试环境中模拟长时间运行+高频缓存操作，监控
cache.size()是否线性增长 - 对关键静态集合添加 JMX 指标暴露（如当前 size、put 次数、最近一次清理时间），便于运维介入
