static变量本身不被GC回收，但会因长期持有堆对象引用而阻碍GC，导致内存泄漏；静态集合、单例持Activity引用、缺乏清理机制是三大风险点，需用弱引用、LRU、自动淘汰和工程化清理应对。
static 关键字本身不触发垃圾回收，也不会被 GC 回收——但它会显著影响 GC 的效率和行为，核心在于它长期持有堆中对象的引用。
static 变量不参与 GC，但会“锁住”其他对象
static 变量随类加载而初始化，存于元空间（JDK 8+），其生命周期与类一致，直到程序结束或类卸载。它本身不会被回收，但若它引用了堆中的对象（比如 new ArrayList()），这个引用会一直有效，导致被引用的对象无法被判定为“不可达”，从而无法被 GC 回收。
- ✅ 安全写法：public static final String CONFIG = "prod";（字符串常量池或编译期常量，无堆对象）
- ❌ 危险写法：public static List cache = new ArrayList();（持续 add 后不清理，对象永远可达）
静态集合是内存泄漏高发区
Map、List、Set 等静态容器若无清理机制，会不断累积对象，推高堆内存水位，最终诱发频繁 Young GC，甚至 Full GC。
- 加数据前检查 size 或时间戳，超限时主动 clear() 或 remove 旧项
- 优先用 LinkedHashMap 并重写 removeEldestEntry() 实现 LRU 自动淘汰
- 对大缓存对象（如 Bitmap、大 DTO），用 WeakReference<T> 包装 value，允许 GC 在内存紧张时回收
- 禁止裸写 public static Map<String, Object> cache = new HashMap<>();
单例 + Context 是 Android 典型陷阱
static 单例若持有 Activity、Fragment 或 View 的强引用，整个界面视图树将被钉在堆中，GC 彻底失效。
立即学习“Java免费学习笔记（深入）”；
- 单例内部一律使用 getApplicationContext()，绝不保存 Activity/View 的 this
- 注册回调或监听器时，用 WeakReference<Listener> 封装，切断强引用链
- 避免在 Activity 的 onCreate() 中传参初始化单例，防止隐式绑定生命周期
清理必须工程化，不能靠人记
每个 public static 缓存字段都应配套提供 clearCache() 或 reset() 方法，并在系统关键节点自动调用。
- 在 Application 的 onTrimMemory(int level) 中响应 TRIM_MEMORY_UI_HIDDEN 或 TRIM_MEMORY_RUNNING
- 结合 MAT 或 VisualVM 定期扫描静态引用链，确认无意外长生命周期对象滞留
- 上线前做内存压力测试，验证缓存淘汰逻辑是否真正生效
