运行时常量池依附方法区随其实现变迁，字符串常量池自jdk7起独立迁移至堆中；二者同源但职责分离：前者存类结构符号引用，后者管字符串实例唯一性，分离源于内存治理逻辑差异。
运行时常量池和字符串常量池虽然都源于 class 文件的常量池，但它们在 JVM 内存中的归属、演进动因和实际行为完全不同。理解它们的关键，不是背版本号，而是抓住“方法区实现方式变化 → 常量池内容拆分 → intern 行为与 GC 特性同步调整”这条主线。
运行时常量池：始终依附于方法区，随载体迁移
运行时常量池是方法区（Method Area）的逻辑组成部分，它的物理位置完全取决于方法区在 HotSpot 中的实现：
- JDK 6 及之前：方法区由永久代（PermGen）实现，运行时常量池就在永久代中，包含类名、字段描述符、方法签名等符号引用，也包含字符串字面量的完整拷贝
- JDK 7：方法区仍用永久代，但运行时常量池开始“瘦身”——符号引用保留在永久代，而字符串字面量被剥离出去，不再存入其中
- JDK 8 及之后：永久代被移除，方法区改由元空间（Metaspace）实现（使用本地内存），运行时常量池的结构信息（如类全限定名、字段类型描述）随之进入元空间
字符串常量池：从永久代出走，坚定扎根堆中
字符串常量池（StringTable）专用于字符串字面量（如 "abc"）和 intern() 结果的复用管理，它的迁移是主动解耦的结果：
- JDK 6 及之前：位于永久代，intern() 会把堆中字符串完整复制一份到永久代，极易触发 OutOfMemoryError: PermGen space
- JDK 7：整体迁入 Java 堆，只存储对堆中已有 String 对象的引用（8 字节指针），不再复制内容；从此可被 Young GC / Full GC 回收，扩容也更灵活
- JDK 8+：继续保留在堆中，与元空间彻底分离；此时运行时常量池（元空间）和字符串常量池（堆）各管一摊——前者管类结构，后者管字符串实例唯一性
两个池的关系：同源不同域，运行期已完全独立
它们都源自 class 文件常量池，但加载后职责分明：
- 编译期的 "hello" 同时写入 class 常量池 → 类加载时，该字面量作为符号引用进入运行时常量池（JDK 7+ 仅留引用标记），同时触发字符串常量池查重与登记
- 运行时常量池不存字符串本体，只存符号信息；字符串对象本体（包括 new 出来的和字面量生成的）始终在堆中，从未进入过元空间
- 调用 String.intern() 本质是向堆中的 StringTable 插入或查找引用，与元空间无直接交互
为什么必须分开？核心是内存治理逻辑不同
永久代设计初衷是承载类元数据这类生命周期长、变动少的数据，而字符串复用具有高频创建、短生命周期、数量不可控等特点：
- 永久代 GC 效率低，字符串堆积后难以释放，OOM 风险高
- 堆内存更大、GC 更成熟（尤其 G1/ZGC），适合动态字符串管理
- 分离后，类加载器卸载、字符串回收互不影响，系统更稳定
