static变量不参与GC但会长期持有堆对象引用，导致内存泄漏和Full GC；应避免静态集合无清理、单例强引Context，并配套自动清理机制。
Java 中 static 变量本身不参与垃圾回收，也不会导致“频繁 GC”，但它们会长期持有堆中对象的引用，间接阻碍 GC 回收这些对象——这才是影响性能的真正源头。关键不是 static 变量被回收（它根本不会被回收），而是它“抓着”的对象一直活在堆里，拖慢 GC 效率、抬高内存水位、甚至触发 Full GC。
下面从实际编码角度讲清楚怎么管住 static 的“手”，避免它拖垮性能：
明确 static 的生命周期边界
static 变量随类加载而初始化，存于元空间（JDK 8+），其值（比如 new 出来的 ArrayList）却实实在在在堆里。只要这个 static 引用不为 null，它指向的所有对象就无法被 GC 判定为垃圾。
- ✅ 合理场景：
public static final String API_URL = "https://api.example.com";（常量，无堆对象） - ❌ 高危写法：
public static List<User> cache = new ArrayList<>();（持续 add，永不清理）
静态集合必须带“刹车”机制
List、Map、Set 这类静态容器是 OOM 最常见温床——只进不出，越积越多。
- 加数据前检查容量或时间戳，超限时主动
clear()或remove旧项 - 优先用
LinkedHashMap并重写removeEldestEntry()实现 LRU 自动淘汰 - 大缓存场景改用
WeakReference<T>包装 value，让 GC 在内存紧张时可回收 - 禁止无约束写法，如
public static Map<String, Bitmap> imageCache = new HashMap<>();
单例与 Context 引用务必“去 Activity 化”
尤其在 Android 场景，static 单例若持有了 Activity 的强引用，整个界面树就锁死在堆里，GC 彻底失效。
- 单例内部一律使用
getApplicationContext()，绝不保存 Activity/Fragment/View 的 this - 如需注册监听器或回调，用
WeakReference<Listener>包一层，断开强引用链 - 初始化单例不要放在 Activity 的
onCreate()中传参，避免隐式绑定生命周期
配套清理动作要工程化落地
靠人脑记住哪个 static 该清、何时清，不可靠。
- 每个 public static 缓存字段都配套提供
clearCache()或reset()方法 - 在 Application 生命周期关键点（如
onTrimMemory(TRIM_MEMORY_UI_HIDDEN)）调用清理 - 上线前用 MAT 或 VisualVM 扫描堆转储，过滤
java.util.*和android.*下的静态引用链 - CI 流程接入 SpotBugs，对
static + Collection / Context / Bitmap组合自动告警
不复杂但容易忽略：static 不是省内存的开关，而是延长生命周期的杠杆。用得好，省对象；用得莽，锁内存。
