静态集合导致内存泄漏的本质是对象被长期强引用而无法回收——只要集合不清理、不置空、不设限，对象就永远活在堆里；其根本原因是static变量作为gc root使所持对象不可被gc回收。
Java类变量（即静态变量）本身不占堆内存，但它持有的对象引用全部落在堆中。一旦这些引用没被及时释放，对象就无法被GC回收——不是因为还在用，而是被“钉”在了内存里。
静态集合是最常见的泄漏源头
像 public static List<User> cache = new ArrayList<>() 这类写法，表面是缓存，实则是长期持有。每次 add() 都会建立一条从 Class → static field → List → element 的强引用链。哪怕 User 实例业务逻辑早已结束，只要没手动 remove() 或清空集合，它就永远可达。
- Web 场景中，若在 Filter 初始化时创建却无定时清理，几小时后可能堆积数万无效 DTO
- 日志类、监控统计类也常犯此错：
public static List<String> logs = new ArrayList<>()，只增不删 - 优先用
LinkedHashMap并重写removeEldestEntry()实现 LRU，或加容量/过期时间判断
单例内部状态容易变成内存放大器
饿汉式单例本身安全，但若它内部维护了未受控的成员变量，风险立刻浮现。比如：
- 一个
private Map<String, byte[]> buffers，每次处理文件都put大数组，却从不淘汰 - 注册了监听器回调，而回调闭包捕获了 Activity 或 ServletRequest，导致整个上下文被锁死
- Android 中尤其危险：单例持有了 Activity 的强引用，连带泄漏 View、Drawable、Context 等整套资源
对策是：单例内只用 getApplicationContext()，监听器一律用 WeakReference 包裹，避免隐式绑定生命周期。
立即学习“Java免费学习笔记（深入）”；
工具类里的“临时”缓存往往不临时
为图方便在 static 方法里缓存中间结果，是隐蔽的高危操作。例如：
-
public static void process(JsonNode node) { CACHE.put(node.hashCode(), node); }—— node 是解析树根，引用整棵子树及其所有字段（含大字符串、字节数组） - JSON 库常复用 Node 对象，若缓存 key 仅依赖
hashCode，相同结构的不同实例可能重复加入 - 大对象坚决禁用硬编码缓存：
private static byte[] buffer = new byte[100MB]等同于埋雷
替代方案：用 ThreadLocal 隔离线程级实例，或交由 Glide、LruCache 等专业组件管理。
识别与清理的关键动作
别只盯着“有没有 new”，要查“谁在长期 hold”。实际排查建议：
- 用
jmap -dump:format=b,file=heap.hprof <pid>抓堆快照，MAT 中按 “Merge Shortest Paths to GC Roots” 查路径，重点过滤static字段 - 每个
public static字段都配套提供clearCache()或reset()方法，并在 Application 生命周期末尾调用 - CI 流程接入 SpotBugs，对
static + Collection / Context / Bitmap组合自动告警
