运行时常量池是jvm方法区（jdk8+为元空间）中类粒度的动态数据区域，源自class文件常量池，类加载时解析符号引用为直接引用并存入，支持string.intern()等运行时动态添加，与堆中的字符串常量池协作但物理分离，是编译期到运行期的关键桥梁。

运行时常量池是 JVM 方法区（JDK 8+ 对应元空间）中一个动态的、类粒度的数据区域，它不是一块独立内存，而是方法区逻辑结构的一部分，承载着类在运行期所需的常量信息和符号解析结果。

运行时常量池从哪来

它源自每个 class 文件里的“Class 常量池”（静态常量池）。编译时，javac 把字符串字面量、final 基本类型值、类/方法/字段的符号引用等，写入 class 文件的 Constant Pool Table。类加载过程中，在“解析阶段”，JVM 将这些符号引用逐步转换为直接引用（如内存地址、Klass 指针、方法入口偏移），并把这些解析后的数据结构存入运行时常量池。

• 每个已加载的类都有自己独立的一份运行时常量池
• 内容可变：不像 class 文件常量池是只读的，运行时常量池支持动态添加，比如 String.intern() 就会把新字符串对象的引用加入其中
• 位置归属：JDK 7 起，字符串常量池被移到堆中；但运行时常量池本身仍属于方法区（元空间）管理范畴

它和字符串常量池什么关系

字符串常量池（String Pool）在逻辑上是运行时常量池的“子集”或“协作组件”，但物理存储位置不同：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 运行时常量池里可能存有对字符串对象的引用（例如 class 文件中定义的 "hello" 字面量，解析后指向堆中某个 String 实例）
• 字符串常量池是 HotSpot VM 中一个名为 StringTable 的哈希表，位于堆内存（JDK 7+），专门用于驻留（intern）字符串——即保证相同内容的字符串字面量只有一份实例，且所有引用都指向它
• 调用 String.intern() 时，JVM 先查 StringTable，命中则返回已有引用；未命中则将该字符串对象引用加入 StringTable，并返回该引用——这个动作不修改运行时常量池本身，但会影响其后续对同一字面量的解析行为

为什么说它“动态”又“关键”

运行时常量池是连接编译期与运行期的关键桥梁：

• 字节码指令（如 ldc、ldc_w）不直接操作原始数据，而是通过索引查运行时常量池获取实际值或引用
• 反射、动态代理、Lambda 表达式底层都依赖运行时常量池中解析好的类名、方法签名等信息
• 若运行时常量池所在的方法区/元空间不足（如大量动态生成类未卸载），会抛出 java.lang.OutOfMemoryError: Metaspace
• 可通过 javap -v 查看 class 文件常量池；用 jmap -histo 或 JVMTI 工具观察运行时内容，但无法直接 dump 运行时常量池全貌

理解它，重点不在背定义，而在看清“编译→加载→解析→运行”这条链路上，常量如何从静态描述变成可执行的内存引用——运行时常量池，就是那个正在被 JVM 活着使用的“常量中枢”。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南