静态变量自JDK7起移至堆中，随Class对象存储；JDK8取消永久代，静态变量仍存于堆，元空间仅存类元数据。
静态变量的存储位置，不取决于你写的是 static int x = 1 这行代码本身，而取决于你运行的 JDK 版本和 JVM 实现。关键分水岭在 JDK 7 和 JDK 8：从 JDK 7 起，静态变量就已**不再存于永久代（PermGen）**；到 JDK 8，随着永久代被彻底移除，静态变量明确归属堆（Heap），与普通对象共享 GC 策略和内存管理机制。
静态变量在哪？看 JDK 版本说话
不同 JDK 版本下，静态变量的物理存放位置有明确演进路径：
- JDK 6 及之前：静态变量和类元数据一起放在永久代（PermGen）中，属于方法区的实现之一
- JDK 7：永久代开始“瘦身”，类的静态变量（class statics）已迁移至 Java 堆；但类元数据、运行时常量池等仍保留在永久代
- JDK 8 及之后：永久代被元空间（Metaspace）取代；静态变量继续留在堆中，元空间只存类结构、方法信息、符号引用等元数据，不包含任何静态变量
为什么把静态变量挪到堆里？
这不是随意调整，而是为了解决实际问题：
- 永久代垃圾回收效率低，仅在 Full GC 时才清理，而静态变量生命周期常与 ClassLoader 绑定，容易长期驻留导致 PermGen OOM
- 堆内存有成熟的分代 GC 机制（如 G1、ZGC），能更及时回收失效的静态引用（尤其配合弱/软引用或显式置 null）
- 统一内存视图：静态变量本质是“类级别对象状态”，和 new 出来的实例对象逻辑一致，放堆里更符合语义直觉
怎么验证静态变量真在堆里？
可通过 JVM 参数 + 工具观察行为，无需改代码：
- 启动参数加
-XX:+PrintGCDetails -Xlog:gc+heap=debug（JDK 10+）或-XX:+PrintGCDetails（旧版），触发 GC 后查看日志中“PSYoungGen”“ParOldGen”等堆区域回收记录，静态变量所属对象若被回收，会体现在老年代（Old Gen）统计中 - 用
jmap -histo <pid></pid>查看堆中对象分布，定义了大量静态集合（如static Map<string object> CACHE = new HashMap()</string>）时，该 Map 实例及其内容必然出现在堆 histogram 结果里，而非元空间 dump 中 - 对比
jstat -gc <pid></pid>输出：Metaspace 的 used / committed 值不会随静态集合扩容而增长；但堆的 used 值会明显上升
开发中要注意的迁移影响
虽然迁移对大多数代码透明，但以下场景需特别留意：
- 内存监控告警策略要更新：别再紧盯
PermGen usage，应关注堆内存（尤其是老年代）中由静态缓存引发的持续增长 - ClassLoader 泄漏问题更隐蔽：静态变量持有 ClassLoader 引用（如
static Logger logger = LoggerFactory.getLogger(MyClass.class)），会导致整个类加载器及其加载的所有类无法卸载——这类泄漏现在表现为堆内存泄漏，而非 Metaspace OOM - 调优参数变化：不用再配
-XX:MaxPermSize，但需合理设置堆大小（-Xmx）和老年代比例，避免静态缓存撑爆堆
