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。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 加数据前检查 size 或时间戳，超限时主动 clear() 或 remove 旧项
- 优先用 LinkedHashMap 并重写 removeEldestEntry() 实现 LRU 自动淘汰
- 对大缓存对象（如 Bitmap、大 DTO），用 WeakReference
包装 value，允许 GC 在内存紧张时回收 - 禁止裸写 public static Map
cache = new HashMap();
单例 + Context 是 Android 典型陷阱
static 单例若持有 Activity、Fragment 或 View 的强引用，整个界面视图树将被钉在堆中，GC 彻底失效。
- 单例内部一律使用 getApplicationContext()，绝不保存 Activity/View 的 this
- 注册回调或监听器时，用 WeakReference
封装，切断强引用链 - 避免在 Activity 的 onCreate() 中传参初始化单例，防止隐式绑定生命周期
清理必须工程化，不能靠人记
每个 public static 缓存字段都应配套提供 clearCache() 或 reset() 方法，并在系统关键节点自动调用。
- 在 Application 的 onTrimMemory(int level) 中响应 TRIM_MEMORY_UI_HIDDEN 或 TRIM_MEMORY_RUNNING
- 结合 MAT 或 VisualVM 定期扫描静态引用链，确认无意外长生命周期对象滞留
- 上线前做内存压力测试，验证缓存淘汰逻辑是否真正生效
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
