运行时常量池始终属于方法区，jdk 6在永久代、jdk 7符号引用留永久代而剥离字符串字面量、jdk 8起随方法区迁入元空间；字符串常量池jdk 6在永久代，jdk 7起移至堆中存引用，jdk 8仍驻堆，实现解耦、gc回收与动态扩容。
运行时常量池和字符串常量池的位置变化，不是版本升级的附带调整，而是JVM为解决真实内存瓶颈做出的针对性重构。关键要抓住一点：它们同源（都来自.class文件的常量池），但职责不同，因此演进路径也不同。
运行时常量池：始终锚定方法区，随方法区实现迁移
它逻辑上永远属于方法区，物理位置则取决于方法区怎么实现：
- JDK 6及以前：方法区用永久代（PermGen）实现 → 运行时常量池就在PermGen里
- JDK 7：方法区仍用PermGen，但开始“瘦身” → 符号引用保留在PermGen，字符串字面量被剥离出去
- JDK 8起：永久代被移除，方法区改由元空间（Metaspace）实现 → 运行时常量池随之进入元空间（本地内存）
字符串常量池：从PermGen出走，扎根堆中
它的迁移更彻底，核心动因是“复用+回收”需求倒逼架构调整：
- JDK 6及以前：和运行时常量池挤在PermGen → 存的是字符串对象实例本身 → 容量小（默认仅4MB）、GC基本不清理 → intern()滥用极易触发OutOfMemoryError: PermGen space
- JDK 7：整体迁入Java堆 → 存的是堆中字符串对象的引用 → 可参与Minor GC和Full GC → 生命周期短的字符串能及时释放
- JDK 8及以后：继续留在堆中，与元空间解耦 → 运行时常量池在元空间，字符串常量池在堆 → 物理分离、各司其职
为什么JDK 7是分水岭？三个底层考量直击痛点
这次迁移不是微调，而是为应对现代应用规模做的关键解耦：
- 解耦内存压力：PermGen原本要承载类元数据、静态变量、符号引用，再塞大量字符串，极易撑爆；堆空间更灵活，可通过-Xmx统一调控
- 支持真正GC回收：PermGen几乎不参与常规GC，字符串一旦进去就“长驻”；堆中字符串可被标准GC策略识别并回收
- 适配动态增长场景：微服务、海量配置、JSON解析等场景下，字符串数量波动剧烈，堆比固定大小的PermGen更适合承载这类数据
两个池现在的关系：同源不同域，运行期完全独立
编译期的一个"hello"字面量，在运行期会走两条路：
- 作为符号引用 → 类加载时进入运行时常量池（元空间）→ 用于方法解析、字段定位等类结构操作
- 作为字符串值 → 触发字符串常量池检查（堆中StringTable）→ 若不存在，则在堆中创建String对象，并将引用存入StringTable
两者不再共享内存区域，也不共用GC策略。实验证据很直接：JDK 8下持续调用String.intern()最终抛出的是OutOfMemoryError: Java heap space，而不是PermGen错误——这直接印证了它就在堆里。
