运行时常量池在类加载后不可修改，因其是只读结构，设计目标为存储编译期已知的字面量和符号引用，JVM规范要求其固化以保障安全性、内存一致性及JIT优化正确性。
Java中方法区的运行时常量池（Runtime Constant Pool）在类加载时由class文件中的常量池内容初始化，**默认情况下无法在运行期直接向其中添加新常量**。这是JVM规范明确限定的行为：常量池是只读结构，其内容在类加载、验证、准备阶段完成初始化后即固化，不支持动态增删。
为什么不能直接添加？
运行时常量池属于方法区（JDK 8+ 后为元空间）的一部分，其设计目标是存储编译期已知的字面量和符号引用（如类名、字段名、方法名、字符串字面量等）。JVM规范要求常量池在类加载完成后保持不可变，以保障安全性、内存模型一致性以及即时编译器（JIT）优化的正确性。
试图通过反射或Unsafe操作强行修改常量池，会导致：
- JVM崩溃或抛出InternalError、VerifyError
- 不同JVM实现行为不一致（如HotSpot会直接拒绝非法修改）
- 破坏类的不可变语义，引发难以排查的并发或链接错误
替代方案：模拟“动态常量”效果
若业务需要类似“运行期注册常量”的能力（如动态生成类名、方法描述符、字符串标识），应绕过常量池，改用以下安全、标准的方式：
立即学习“Java免费学习笔记（深入）”；
-
使用String.intern()：对运行期构造的字符串调用
intern()，可将其加入字符串常量池（注意：该池与运行时常量池逻辑隔离，但共享底层字符串表）。例如：String s = new StringBuilder("dynamic").toString().intern(); - 借助MethodHandles或VarHandle（JDK 9+）：动态构建方法/字段访问句柄，避免硬编码符号引用
-
生成新类（字节码增强）：用ASM、ByteBuddy或Javassist在运行期生成含所需常量的新class，并通过
ClassLoader.defineClass()加载。此时新类的常量池在定义时静态确定，符合规范 - 用Map缓存运行期“常量”：将需复用的动态值（如枚举式ID、配置键）存在ConcurrentHashMap中，以空间换灵活性
特殊场景：Instrumentation + retransformClasses（仅限Agent）
在JVM启动时挂载Java Agent，可通过Instrumentation API 对已加载类进行retransform。虽然仍不能直接写入常量池，但可以：
- 注入静态字段并预设值（相当于把“常量”转为类的静态变量）
- 修改字节码，在方法中插入
LDC指令加载已知常量（前提是该常量已在目标类的常量池中存在，或通过新增字段间接引入）
这本质是“替换类定义”，而非修改原常量池，且需满足严格的字节码验证规则。
不复杂但容易忽略：常量池不是通用缓存，它的角色是支撑JVM链接与解析机制。真有动态元数据需求，优先考虑应用层抽象，而非挑战JVM底层契约。
