字符串常量池（stringtable）自jdk 7起固定位于堆内存，非元空间或永久代；openjdk 17/21中仍如此，由堆内哈希表实现，存储字符串引用，受gc管理，且可通过-xx:stringtablesize调优。
OpenJDK 的字符串常量池（StringTable）在堆内存中，不是元空间，也不是永久代 —— 这点从 JDK 7 开始就已固定，且在 OpenJDK 17/21 等主流版本中完全一致。
字符串常量池的物理位置：堆内存中的 StringTable
OpenJDK 中的字符串常量池由 StringTable 类实现，本质是一个全局哈希表（Hashtable），它被分配在 Java 堆（Heap）里，而非方法区或元空间。你可以在 OpenJDK 源码中直接定位到：src/hotspot/share/classfile/stringTable.hpp 和 stringTable.cpp，其中 the_table() 返回的就是堆上分配的哈希表实例。
这意味着：
- 所有通过字面量创建的字符串（如
"hello"）首次加载时，其引用（JDK 7+）或对象本身（JDK 6）会被写入这个堆内的StringTable -
String.intern()的行为直接操作该表：查表、插入、返回堆中已有字符串的引用 - 它受 GC 管理 —— 表中存储的引用若指向的字符串对象不可达，该引用条目可能被清理（取决于具体实现和 GC 策略）
为什么不是元空间？元空间里存什么
元空间（Metaspace）只存放类的元数据：如 InstanceKlass 对象、方法签名、字段描述、注解、运行时常量池（ConstantPool）等 —— 但注意，这里的「运行时常量池」是每个类独有的、从 class 文件解析来的结构，和全局的字符串常量池（StringTable）是两回事。
关键区别：
-
ConstantPool是每个类实例一份，存在元空间，包含JVM_CONSTANT_String这类符号引用（指向字符串字面量索引） -
StringTable是整个 JVM 进程唯一一份，存在堆，负责实际管理字符串内容的去重与引用分发 - 当类加载器解析
JVM_CONSTANT_String时，会触发对StringTable的查找或插入，完成符号引用到实际字符串引用的绑定
常见误判场景：-XX:MetaspaceSize 调大没用
如果你遇到 java.lang.OutOfMemoryError: Metaspace，调大 -XX:MetaspaceSize 可能缓解；但如果是字符串大量 intern() 导致内存飙升或 GC 频繁，问题根源在堆 —— 此时增大元空间毫无意义，反而可能掩盖真实压力点。
需要关注的指标和参数：
- 堆内存使用率（尤其老年代）、GC 日志中是否频繁出现
StringTable相关清理动作 -
-XX:StringTableSize：可显式设置StringTable哈希桶数量，默认值在 OpenJDK 17+ 是 60013；若 intern 字符串极多且散列集中，桶太少会导致链表过长，intern()性能线性下降 - JFR 或 JMC 中可监控
jdk.StringTableStatistics事件，查看命中率、条目数、平均链长
验证方式：用 jmap + jhsdb 直接观察
最直接的确认方式不是看文档，而是运行时观测：
- 启动一个大量调用
new String("key").intern()的程序 - 用
jmap -histo:live <pid></pid>查看堆中java.lang.String实例数变化趋势 - 用
jhsdb jmap --heap --binaryheap <pid></pid>导出堆快照后，搜索StringTable相关结构（在 OpenJDK 17+ 的 jhsdb 中支持符号解析） - 对比
jstat -gc <pid></pid>中堆内存增长与intern调用次数的关系，排除元空间干扰
字符串常量池的位置看似简单，但真正容易被忽略的是它的“全局单例+堆内驻留+哈希结构可调”三重特性 —— 很多线上 intern 引发的性能毛刺，其实都卡在默认 StringTableSize 不足以承载业务字符串熵值上。
