静态集合必须配套显式清理方法、容量限制与淘汰机制，优先用ThreadLocal替代，并通过工具扫描和规范管控防止内存泄漏。
关键在于让静态集合“有始有终”——它被创建，就必须被清理；否则对象一直强引用着，GC永远无法回收，内存只会单向增长。
静态集合必须配套可调用的清空方法
不能只声明一个 private static List<Object> cache = new ArrayList<>(); 就完事。必须同步提供显式清理入口：
- 定义公共清除方法，如 public static void clearCache() { cache.clear(); }
- 在业务逻辑结束点（如请求完成、任务退出、模块卸载时）主动调用该方法
- 避免依赖“应用关闭时自动释放”——JVM 不保证 static 字段一定被回收，尤其在容器环境或热部署场景下
加容量上限与淘汰机制
即使能清空，也防不住突发写入或忘记调用。更稳妥的做法是限制其“生长能力”：
- 用 ConcurrentHashMap 替代 HashMap，配合 LRU 策略（例如基于 LinkedHashMap 的自定义缓存，或引入 Caffeine/Guava Cache）
- 设置最大条目数（maximumSize(1000)）和过期时间（expireAfterWrite(10, TimeUnit.MINUTES)）
- 禁用无约束的 add() 或 put()，改用带校验的封装方法，超限时先淘汰再插入
用 ThreadLocal 替代全局静态集合（多数场景更安全）
如果集合用途是“每个线程一份缓存”，static 集合反而是陷阱。应优先转向线程局部存储：
立即学习“Java免费学习笔记（深入）”；
- 声明 private static final ThreadLocal<List<Object>> THREAD_CACHE = ThreadLocal.withInitial(ArrayList::new);
- 使用后务必调用 THREAD_CACHE.remove();（尤其在线程池复用场景下，不 remove 会导致内存泄漏）
- 相比 static 集合，ThreadLocal 天然隔离、生命周期可控，且 GC 可正常回收线程终止后的数据
上线前用工具扫描并建立静态字段管控规范
靠人工 review 容易漏掉隐藏的 static 集合。需形成工程化卡点：
- 接入 SpotBugs 或 SonarQube，配置规则检测 static + Collection/Map 组合
- CI 流水线中增加字节码扫描步骤，识别未配套清理方法的静态集合字段
- 团队约定：所有 static 集合类必须标注 @CleanupRequired 注释，并在 PR 中说明清理触发时机
