运行时常量池是jvm类加载时将.class静态常量池“活化”形成的内存结构，位于方法区（jdk 8+为元空间）并协同堆中字符串池，核心作用是支撑动态链接与符号引用解析为直接引用，并管理字面量共享、影响类加载稳定性及间接依赖gc。
运行时常量池是JVM在类加载过程中，将.class文件里的静态常量池“活化”后形成的内存结构，它存在于方法区（JDK 8+为元空间 + 堆中字符串池协同），核心作用不是单纯存数据，而是支撑类的动态链接与快速解析。
它是类加载时符号引用转直接引用的关键桥梁
编译后的.class文件里，方法调用、字段访问、类名等都以符号形式存在（比如#5 = Methodref "java/io/PrintStream.println"），这些只是编号和名字，没有真实内存地址。类加载到JVM后，运行时常量池把这些符号“翻译”成可执行的直接引用——例如指向堆中Class对象、方法区中的方法入口、或字符串常量池中的具体String实例。这个过程叫“解析”，是动态链接的前提。
它支持字面量共享与运行期优化
运行时常量池本身不直接存储字符串对象或数值对象，但它管理着对这些资源的统一访问入口：
- 整数-128～127、true/false/null等基础字面量，在类加载时就自动加入运行时常量池，后续使用直接复用，避免重复包装
- 字符串字面量（如"abc"）首次被加载时，会检查字符串常量池（位于堆中），若已存在则复用其引用；否则创建并登记——这正是
==能比较字符串字面量相等的底层依据 -
String.intern()操作本质就是把堆中字符串“登记”进运行时常量池所关联的字符串池，实现跨对象引用共享
它影响类加载成败与内存稳定性
运行时常量池大小受限于方法区（或元空间）容量。如果类定义了超大数量的常量（如巨量字符串、大量反射用的类名/方法名），或存在恶意构造的超长UTF-8字符串常量，可能在加载阶段触发OutOfMemoryError: Metaspace或OutOfMemoryError: Compressed class space。JDK 7起将字符串常量池移至堆，缓解了永久代压力，但堆内存不足仍会导致串池GC频繁甚至OOM。
立即学习“Java免费学习笔记（深入）”；
它不参与垃圾回收，但间接依赖GC机制
运行时常量池本身所在的结构（方法区/元空间）不直接进行对象级GC，但其中引用的字符串对象（通过字符串常量池）在堆中，受常规GC管理。也就是说：常量池条目不会被回收，但其所指向的String实例若无强引用，会被堆GC清理——这时再调用intern()可能重新创建新实例。
基本上就这些。理解它，关键抓住两点：一是“符号→地址”的翻译器角色，二是它与字符串池、基础缓存、方法区容量的实际联动关系。
