运行时常量池是每个类独有的编译期快照，位于方法区（JDK 8+为元空间），存储字面量和符号引用，支持有限动态扩充，与字符串常量池协同工作但不等同。
运行时常量池是每个类独有的“编译期快照”
运行时常量池不是全局共享的内存池，而是每个类在加载进JVM后，在方法区（JDK 8+ 是元空间）中生成的一份独立副本——它本质是 class 文件常量池内容的运行时映射。你写一个 MyClass，JVM 就为它建一个专属的运行时常量池；再写个 YourClass，又建另一个。它们互不干扰。
- 它存的是编译期确定的字面量（如
"abc"、123、true、final int x = 42）和符号引用（如java/lang/String、"toString()Ljava/lang/String;"） - 这些内容在类加载的「解析阶段」才被逐步转成直接引用（比如把类名字符串变成指向
Class对象的指针） - 它支持动态扩充：调用
String.intern()、反射生成的类名等，都可能往当前类的运行时常量池里塞新项（注意：不是所有 JVM 实现都允许任意扩充，HotSpot 对非字符串类的动态添加限制较严）
字符串常量池 ≠ 运行时常量池，但两者深度联动
字符串常量池（StringTable）是全局唯一的哈希表，位于堆内存（JDK 7+），而运行时常量池是每个类一份、位于元空间。但二者在字符串处理上紧密协作：
- 当你写
String s = "hello"，JVM 先查字符串常量池是否有"hello"的引用；若有，直接返回；若无，先在堆中创建对象，再将该对象引用存入字符串常量池 - 这个过程会**触发对当前类运行时常量池中对应
CONSTANT_String_info项的解析**：它原本只存着一个指向CONSTANT_Utf8_info的索引，此时才真正关联到堆里的字符串实例 - 所以
s == "hello"为true，靠的不是运行时常量池本身存储对象，而是它驱动了字符串常量池的复用逻辑
别误以为 final static 就一定进运行时常量池
只有**编译期可确定值的 static final 基本类型或字符串**才会被“内联”进运行时常量池，并在字节码中被直接替换为常量值；其他情况只是普通静态字段。
public class PoolTest {
public static final int A = 100; // ✅ 编译期常量，字节码中直接出现 100
public static final Integer B = 200; // ❌ 包装类，不内联，运行时从静态变量取值
public static final String C = "ok"; // ✅ 字符串字面量，进字符串常量池，也关联运行时常量池
public static final String D = new String("no"); // ❌ new 出来，不进字符串常量池，也不触发运行时常量池内联
}
- 反编译看
javap -v PoolTest.class，你会发现只有A和C出现在常量池表中，且A的使用位置直接是bipush 100 -
B和D虽然也是final，但因无法在编译期确定（后者甚至涉及运行时对象创建），不会进入运行时常量池，也不会带来复用收益
运行时常量池溢出的真实风险点
运行时常量池本身不常爆内存，但它的膨胀往往暴露底层问题：大量动态生成类（如反复 ASM 或 CGLIB 代理）、滥用 intern() 处理长生命周期字符串、或反射频繁注册新符号，都可能导致元空间（Metaspace）耗尽，抛出 java.lang.OutOfMemoryError: Metaspace。
立即学习“Java免费学习笔记（深入）”；
- 监控建议：加 JVM 参数
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，观察Metaspace使用趋势 - 调优重点不是扩大
-XX:MaxMetaspaceSize，而是检查是否在循环中调用String.intern()处理未去重的用户输入（比如日志字段、HTTP header 值） - JDK 8+ 中，
StringTable默认大小仅1009个桶，高并发 intern 可能引发哈希冲突激增，必要时用-XX:StringTableSize=65536扩容
最易被忽略的是：运行时常量池的“懒解析”特性——某些符号引用直到第一次被调用才解析，这意味着 OOM 可能延迟出现在看似无关的代码路径上，而非类加载瞬间。
