Java常量池与String内存详解

本文深入剖析了Java字符串常量池的核心机制与常见误区，揭示了字面量如"abc"如何在编译期进入class常量池、类加载时载入运行时常量池（JDK 7+位于堆中），以及String s = "abc"与new String("abc")在内存分配上的本质差异；详解了intern()方法“查表+注册”的真实语义、适用场景与高危误用，并指出其在JDK版本演进中的行为变迁；同时澄清了==与equals()的本质区别——前者依赖偶然的引用复用，后者才是安全可靠的判等方式；最后警示常量池滥用（尤其无差别调用intern()）可能导致Metaspace OOM，并强调常量池并非缓存，而是JVM规范定义的符号引用存储区，其强引用特性直接影响字符串对象的GC生命周期。

String字面量直接赋值时，到底进没进常量池？

进了，但仅限于编译期能确定的字符串字面量。Java在编译阶段就把"abc"这类字面量收集到class文件的常量池里，类加载时再把它们“搬运”到运行时常量池（属于方法区）。这不是String对象创建过程，而是元数据加载。

• String s = "abc"; → 从运行时常量池中查找，有则复用，无则新建并放入
• String s = new String("abc"); → 一定在堆上新建对象，常量池里的"abc"只是构造参数，不改变引用指向
• 拼接表达式如"ab" + "c"在编译期被优化为"abc"，同样走常量池；但含变量的拼接（如"ab" + x）不会优化，结果在堆上

intern()到底干了什么？什么时候该调用？

intern()不是“把字符串塞进常量池”，而是“查表+注册”：先检查运行时常量池中是否存在内容相同的字符串，存在就返回其引用；不存在则把当前字符串对象的引用存入池中，并返回该引用。注意：JDK 7+后，常量池移到堆中，所以intern()可能返回堆上已有对象的引用，而非新对象。

• 适用于大量重复字符串（如解析CSV中的列名、HTTP头字段），可显著降低内存占用
• 不要对短生命周期或唯一性高的字符串调用，徒增哈希查找开销
• 常见误用：new String("abc").intern() == "abc"为true，但new String("abc").intern() == new String("abc")为false——后者是堆上两个不同对象

为什么String.equals()比==更安全？和常量池有关吗？

有关，但不是根本原因。==比较的是引用地址，而常量池的存在让字面量复用成为可能，所以"a" == "a"为true；但这只是巧合。一旦涉及运行期构造（StringBuilder.toString()、new String(...)等），==就不可靠。而equals()始终比较字符序列内容，与内存布局无关。

• 所有字符串判等，无条件优先用equals()
• 只有明确知道两边都是字面量或已调用intern()，且性能极端敏感时，才考虑==
• 反模式：s == "abc" —— 如果s来自用户输入或IO，必然失败

常量池大小不够会OOM吗？怎么调？

会，但不是因为“存不下字符串”，而是因为运行时常量池是方法区（JDK 8+为元空间）的一部分，受-XX:MaxMetaspaceSize限制。当大量调用intern()且字符串内容不重复时，每个都会在元空间中占一块结构体，最终触发java.lang.OutOfMemoryError: Metaspace。

• 默认元空间大小无硬上限（只受本地内存限制），但生产环境必须设-XX:MaxMetaspaceSize
• 监控指标看java.lang:type=MemoryPool,name=Metaspace的使用率
• 别盲目加大，先确认是不是滥用intern()——比如把UUID、时间戳、JSON片段都intern()，纯属自找麻烦

常量池不是缓存，也不负责对象生命周期管理；它只是JVM规范里一个存放符号引用的地方。真正容易被忽略的，是intern()行为在JDK 6/7/8之间的语义迁移，以及它和GC的微妙关系：常量池里的引用是强引用，只要池子活着，里面的字符串就不会被回收。

今天关于《Java常量池与String内存详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！