静态变量导致内存泄漏的本质是强引用滞留而非状态传递，其典型表现是Activity等对象无法被GC回收；应避免用static存储UI对象，改用ViewModel、LruCache或WeakReference，并在生命周期回调中主动清理。
静态变量本身不存于堆中，但会持续持有堆内对象的引用，导致本该被回收的对象无法释放——对象状态看似“传递”了，实则被悄悄锁死在内存里。这不是状态共享，而是状态滞留。
静态变量让对象状态“粘住”而不是传递
静态字段（如 public static Map<String, Object> cache）一旦引用了某个 Activity、Fragment 或自定义业务对象，就等于给它加了一道强锁。哪怕该 Activity 已 finish，只要静态 Map 还持有它的引用，整个视图树、Context、Bitmap 等资源就全卡在堆里。
- 不是“传过去”，而是“拖不走”：对象没被复制或转移，只是被静态变量长期拽住
- 典型症状：反复打开关闭同一页面后内存占用只升不降，Dump 后发现大量重复的 Activity 实例
- Android 场景尤其危险：Activity 的 Context 被静态持有时，会连带泄漏其关联的所有 View 和 Drawable
避免静态变量误作状态容器
把 static 当成“全局暂存区”是常见误区。状态传递应有明确生命周期边界，而 static 没有。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 用 Intent、Bundle 或 ViewModel 代替 static 字段传递页面间数据
- 跨组件通信优先选 EventBus、LiveData、Flow 或接口回调，而非 public static Listener
- 若真需缓存，用 LruCache 或 WeakHashMap，前者自动淘汰，后者允许 GC 回收键/值
- 绝不将 Activity、Fragment、View、Adapter 等 UI 相关对象塞进 static 集合
必须用 static 时的防御性写法
当静态缓存、计数器、配置等确实必要，就默认承担起它的清理责任。
立即学习“Java免费学习笔记（深入）”；
- 静态集合清空时机要明确：Application.onTrimMemory()、Activity.onDestroy()、Fragment.onDestroyView() 中调用
map.clear() - 对可能大对象（如 Bitmap、InputStream、大型 List）使用
WeakReference或SoftReference包装 - 单例内部一律用
getApplicationContext()，禁止保存 Activity.this 或 this（非静态内部类） - 静态工具类方法接收对象参数时，不保存引用；如需缓存，由调用方控制生命周期
多线程下静态状态更易失控
多个线程同时读写同一 static 变量，不仅引发数据错乱，还会让“谁该释放谁”的责任模糊化。
- 避免用 static int 计数器做业务逻辑判断，改用 AtomicInteger 或 synchronized 块保护
- 静态集合类优先选 ConcurrentHashMap、CopyOnWriteArrayList，而非 HashMap + 手动同步
- 不要依赖 static 标志位（如
static boolean isReady）协调线程，改用 CountDownLatch 或 CompletableFuture - ThreadLocal 是替代方案之一：它为每个线程提供独立副本，本质是“伪静态”，规避共享风险
