应使用WeakReference封装静态缓存中的实际数据，以实现全局可访问且自动回收：静态变量仅作索引，WeakReference交由JVM管理对象生命周期，get时需判空并清理失效项。
静态变量本身生命周期长，容易造成内存泄漏，尤其当它强引用 Activity、Context 或大对象时。要实现“全局可访问 + 自动回收”的缓存，关键不是放弃静态变量，而是用弱引用包裹实际数据，让 JVM 在内存紧张时能安全回收，同时保留缓存结构的长期存在。
为什么必须用 WeakReference 包一层？
静态变量直接持有 Context、View 或业务对象（如 User、Bitmap），会阻止 GC 回收这些对象——哪怕 Activity 已 finish，只要静态 Map 还强引用着它，就一直留在内存里。WeakReference 不计入 GC 引用链，对象仅被弱引用时，下一次 GC 就会被清理，避免泄漏。
- 静态变量（如 HashMap）只负责“索引”，不负责“保命”
- 真正存储的对象用
WeakReference<T>封装，交由 JVM 管理生命周期 - 读取时需判空：取出 WeakReference 后调用
.get()，可能返回 null
实战写法：带自动清理的静态弱引用缓存
下面是一个线程安全、支持泛型、自动处理 null 的通用缓存模板：
public class WeakGlobalCache<K, V> {
private static final Map<String, WeakReference<Object>> CACHE = new ConcurrentHashMap<>();
public static <T> void put(String key, T value) {
if (value != null) {
CACHE.put(key, new WeakReference<>(value));
} else {
CACHE.remove(key);
}
}
@SuppressWarnings("unchecked")
public static <T> T get(String key, Class<T> type) {
WeakReference<Object> ref = CACHE.get(key);
if (ref != null) {
Object obj = ref.get();
if (obj != null && type.isInstance(obj)) {
return (T) obj;
}
}
CACHE.remove(key); // 清理失效引用，防内存碎片
return null;
}
}
- 用
ConcurrentHashMap替代普通 HashMap，天然支持多线程读写 - 每次
get()后主动remove()失效项，避免 WeakReference 对象堆积 - 传入
Class<T>做类型校验，比 raw cast 更安全
典型使用场景与注意事项
比如缓存某个页面的配置对象，或复用解析后的 JSON 数据：
- 缓存 Context？不推荐。改用 Application Context（本身是单例且生命周期长），或彻底避免缓存 Context
- 缓存 Bitmap？适合。WeakReference 能在内存不足时释放，下次需要再加载
- 缓存 Retrofit Service 实例？可以。但更推荐用 Dagger/Hilt 管理作用域，弱引用只是兜底
- 缓存 List<User>？注意：WeakReference 只弱引用整个 List 对象，不递归弱引用每个 User —— 若 User 本身含强引用资源，仍需单独设计
和普通静态缓存对比的关键差异
普通静态缓存（如 static Map<String, User>）是“全有或全无”：要么一直占内存，要么手动清空。而弱引用缓存是“按需存活”：
- 不增加 GC 压力：WeakReference 对象本身很小，GC 清理的是它指向的目标，不是它自己
- 无需手动维护生命周期：不用监听 Activity onDestroy() 去 remove，JVM 自动处理
- 适合中低频、非强一致性要求的数据：比如用户头像 URL 映射、页面配置元数据、临时计算结果
