运行时常量池是JVM方法区（JDK 8+为元空间）中动态管理类字面量和符号引用的核心结构，支撑动态链接与跨类引用解析；其核心作用非单纯存储常量，而是实现符号引用到直接引用的解析、字符串驻留共享及反射等动态特性。
运行时常量池是JVM方法区（JDK 8+为元空间）中用于动态管理类字面量和符号引用的核心内存结构，它的核心作用不是“存常量”，而是支撑Java的动态链接与跨类引用解析。
为什么String == "abc"有时true、有时false？——字符串常量池的实际影响
这背后不是简单的相等判断，而是字符串对象是否指向运行时常量池中同一份字面量引用：
-
"abc"字面量在编译期进入Class文件常量池，类加载时被载入运行时常量池；执行时直接复用该引用 -
new String("abc")一定在堆新建对象，即使内容相同，==比较也返回false -
"abc".intern()强制将字符串注册进运行时常量池（若不存在则添加），之后再用字面量或intern()获取，就能共享引用
String a = "hello";
String b = "hello";
String c = new String("hello");
System.out.println(a == b); // true —— 同指运行时常量池中唯一实例
System.out.println(a == c); // false —— c在堆，a在常量池
System.out.println(a == c.intern()); // true —— intern后指向池中已有项
运行时常量池如何参与类加载？——符号引用转直接引用的关键环节
Java不靠硬编码地址调用方法，而靠符号引用（如"java/lang/String.toString:()Ljava/lang/String;"）在运行时查表定位。这个“查表”就发生在运行时常量池：
- 类加载的“解析阶段”，JVM遍历运行时常量池，把符号引用（类名、方法名、字段名等）翻译成内存中的直接引用（比如方法入口地址、字段偏移量）
- 若解析失败（如类未加载、方法不存在），抛出
NoSuchMethodError或NoClassDefFoundError - 反射调用（
Class.getMethod()）、动态代理、Lambda生成，都依赖运行时常量池中已解析或可延迟解析的符号信息
常量池溢出（OutOfMemoryError: Metaspace / Compressed Class Space）怎么排查？
这不是“字符串太多”的简单问题，而是元空间或类元数据承载能力不足的表现，常见于：
立即学习“Java免费学习笔记（深入）”；
- 大量动态生成类（如反复使用
ASM、CGLIB、Spring AOP代理未清理） - 热部署频繁（旧类卸载失败，常量池残留未回收）
- JDK 7+ 字符串常量池虽在堆，但
StringTableSize过小（默认1009）会导致哈希冲突加剧，intern()性能暴跌甚至卡顿
关键排查命令：
jstat -gc# 查看元空间使用量 jmap -histo:live | grep String # 看堆中String实例数（非池内引用数） jinfo -flag StringTableSize # 查当前字符串表大小
调优建议：-XX:StringTableSize=65536（质数，减少哈希冲突），配合监控String.intern()调用频次。
真正容易被忽略的是：运行时常量池不是只读的——它支持运行时新增（如intern()、MethodHandle解析结果缓存），这意味着多线程并发修改可能引发竞争，尤其在高并发驻留字符串场景下，intern() 是同步方法，会成为瓶颈。
