静态变量存储在方法区（JDK 8+为元空间），由类加载的准备阶段分配内存、初始化阶段赋值，仅首次主动使用时线程安全地初始化，其生命周期依附于所属类——类卸载需满足实例全回收、ClassLoader被回收、Class对象无强引用三个苛刻条件，故通常驻留至JVM结束。
Java 静态变量的内存管理不是“写完就放那儿”，而是有明确的加载时机、存储位置、共享机制和回收边界。理解它，才能避免内存泄漏、误判生命周期、滥用缓存。
静态变量存在哪儿？不是堆，也不是栈
静态变量不随对象创建而分配在堆上，也不随方法调用压入栈帧。它的归属地是 JVM 的方法区（JDK 8+ 称为元空间）——这是专属于类元数据的区域。
- 类加载的「准备阶段」：JVM 为所有静态变量分配内存，并设默认值（
int → 0，Object → null） - 类加载的「初始化阶段」：执行
static int x = 5;或静态代码块，完成显式赋值 -
final static字面量常量（如"abc"、123）例外：在准备阶段就直接写入常量池并绑定变量 - 数组类静态变量（如
static byte[] buf = new byte[1024*1024];）：引用存于元空间，实际字节数组对象分配在堆上
静态变量什么时候被初始化？只一次，且可延迟
静态变量初始化不是在程序启动时统一执行，而是由类的首次主动使用触发，且整个过程线程安全、仅执行一次。
- 触发场景包括：访问非
final static字段、调用静态方法、new实例、Class.forName()、子类初始化（此时父类先初始化） - 多个线程同时触发？JVM 用该类的
Class对象内置锁保证只有一个线程执行初始化，其余阻塞等待 - 未被主动使用的类，其静态变量永远不会初始化（例如某个工具类只在特定配置下才加载）
静态变量能被回收吗？条件苛刻，几乎等于“活到 JVM 结束”
静态变量本身不单独回收，它的存续完全依附于所属类。而一个类要被卸载，必须同时满足三个极难达成的条件：
立即学习“Java免费学习笔记（深入）”；
- 该类的所有实例已被 GC 回收
- 加载它的
ClassLoader实例本身也被 GC 回收（常见于 Web 容器热部署、OSGi、自定义 ClassLoader 场景） - 该类的
java.lang.Class对象没有任何强引用（包括静态字段、栈中局部变量、其他对象字段等）
绝大多数应用中，由系统类加载器（Bootstrap/Extension/AppClassLoader）加载的类不会被卸载，所以你写的 public static Map<String, Object> cache = new HashMap<>(); 就会一直驻留内存，直到 JVM 退出。
实战中怎么管好静态变量？防泄漏比省内存更重要
静态变量节省内存是优点，但更常成为内存泄漏的入口，尤其当它持有 Activity、Context、View、大集合或未关闭资源时。
- 避免持有 Activity/Context：改用
ApplicationContext，或用弱引用（WeakReference<Context>）包装 - 集合类静态变量务必设界：如
static final Map<String, byte[]> IMAGE_CACHE = Collections.synchronizedMap(new LRUMap(100)); - 大对象或流式数据不全量缓存：静态变量只存索引或句柄，真实数据走磁盘/DB/外部缓存
- 提供显式清理方法：比如
public static void clearCache() { CACHE.clear(); }，并在合适时机（如 Activity onDestroy、模块卸载）调用 - 慎用静态监听器/回调：注册后必须配对反注册，否则目标对象无法被回收
