字符串常量池从JDK 6永久代→JDK 7堆中（存引用）→JDK 8堆中稳定存在，核心动因是解决永久代OOM、提升GC效率，并适配方法区重构为元空间。
Java 中常量池的演进，本质上不是常量池“自己搬家”，而是它所依附的内存区域——方法区（Method Area）的实现方式发生了根本性变化。这个变化牵动了常量池的存储位置、管理逻辑和生命周期，核心驱动力是解决永久代的设计缺陷。
常量池在不同 JDK 版本中的归属变化
- JDK 6 及之前：运行时常量池（Runtime Constant Pool）和字符串常量池（StringTable）都存放在永久代（PermGen）中。
- JDK 7：字符串常量池被提前迁出永久代，移入 Java 堆（Heap）；但运行时常量池（含类名、字段/方法符号引用等）仍保留在永久代。
-
JDK 8 及之后：永久代被彻底移除，取而代之的是元空间（Metaspace）。此时：
- 运行时常量池中符号引用部分（如类全限定名、字段名、方法签名等）随类元数据一起进入元空间；
- 字符串常量池（即 interned strings 的引用表）仍保留在堆中；
- 而字符串对象本身（如
"hello"实例）始终在堆中，从未进过永久代或元空间。
为什么要把字符串常量池先挪到堆？
- 字符串是应用中最常 intern 和复用的对象，生命周期差异大：有的长期驻留，有的短期创建即弃。
- 永久代大小固定、GC 低效，把高频变动的字符串表放进去，极易成为 OOM 的导火索（尤其 Web 应用大量
String.intern()）。 - 堆内存有成熟的分代 GC（如 G1、ZGC），能更精细地回收短命字符串，提升整体内存利用率。
为什么运行时常量池要跟着类元数据进元空间？
- 运行时常量池是类加载过程的产物，与
.class文件结构强绑定，属于类的“静态蓝图”一部分。 - 它的生命周期天然与类、类加载器一致：类卸载时，其常量池也应一并释放。
- 元空间的设计正是以“类加载器为单位”进行元数据管理，把常量池放进去，能实现批量、原子、及时的回收，避免永久代中因类卸载失败导致的常量池残留和内存泄漏。
迁移背后的统一目标
- 解耦内存压力：堆管对象实例，元空间管类结构，各司其职，不再互相挤占；
- 避免硬上限：字符串常量池在堆里可随堆策略伸缩；运行时常量池在元空间里可动态扩容；
- 提升 GC 效率：堆 GC 不再扫描类符号信息，元空间 GC 不再拖累 Full GC，停顿更可控；
- 支持现代特性：模块化（JPMS）、动态语言（Groovy/JSR-292）、热重载（HotSwap）等都需要更灵活、更健壮的元数据管理机制。
简言之，常量池的迁移不是孤立调整，而是 JVM 内存架构升级的一环——从“一刀切塞进固定盒子”走向“按语义分区、按需生长、按生命周期精准回收”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
