1. 从一个诡异的现象说起为什么两个相等的字符串却不相等刚入行那会儿我写过一段至今想起来都脸红的代码。当时在做一个用户标签匹配的功能逻辑很简单从数据库里读出一个标签字符串跟代码里写死的常量做比较相等就走某个分支。本地测试一切正常上了测试环境也没问题结果到了预发布环境同样的数据、同样的代码判断结果却反了。我盯着屏幕看了两个小时打印出来的两个字符串肉眼看上去一模一样长度一样字符一样连编码都查了。最后用换成equals才恢复正常。那一刻我才真正意识到Java 里那个看似简单的背后藏着一整套关于内存布局的学问而这一切的起点就是今天要聊的主角——常量池。这篇文章不是那种把常量池分为 Class 常量池、运行时常量池、字符串常量池三句话讲完就收工的八股文。我想做的是把常量池放回到栈、堆、方法区这三大内存区域的大背景下讲清楚它到底住在哪、什么时候被创建、什么时候被回收、为什么和equals会打架、intern()到底干了什么、以及那些面试里常被追问但很少有人讲透的细节。不管你是刚学 Java 的新手还是写了几年代码但对内存模型一直模模糊糊的老手看完应该都能有点收获。我尽量不堆术语遇到绕的地方就用生活化的类比拆开讲同时把能动手验证的代码都给你备好你可以直接复制到本地跑一遍眼见为实。2. 先把地图画出来栈、堆、方法区到底各管什么在聊常量池之前必须先把 JVM 的内存地图铺开。很多人学常量池学得痛苦根本原因不是常量池本身难而是脑子里没有一张清晰的内存分区图导致常量池像悬在半空中不知道它跟谁有关系。所以我们先花点篇幅把这张图建立起来。2.1 用一家公司来类比 JVM 内存你可以把整个 JVM 想象成一家公司公司里有几个不同的部门各司其职栈Stack相当于每个员工的私人办公桌。每个线程都有自己的栈线程私有的。你在方法里定义的局部变量、方法调用的现场信息都放在这张桌子上。桌子很小用完就清速度极快。方法一执行完对应的栈帧就弹出桌上的东西立刻消失。堆Heap相当于公司的公共仓库。所有线程共享你new出来的对象、数组全都堆在这里。仓库很大但东西多了要清理垃圾回收清理是有成本的。方法区Method Area相当于公司的档案室。存放类的结构信息、字段描述、方法描述、常量、静态变量等。它是线程共享的生命周期跟 JVM 差不多长。在 JDK 8 之前这块区域的具体实现叫永久代PermGenJDK 8 之后换成了元空间Metaspace从堆内存挪到了本地内存。这三者里常量池主要跟方法区打交道但字符串常量池又跟堆有着千丝万缕的联系这正是它让人头晕的地方。2.2 栈的细节为什么局部变量活得那么短栈里最基本的单位叫栈帧Stack Frame每调用一个方法就压入一个栈帧方法返回就弹出。一个栈帧里通常包含四块内容局部变量表、操作数栈、动态链接、方法返回地址。局部变量表里存的是方法参数和方法内定义的局部变量。这里有个关键点基本类型int、long、boolean 等直接存值引用类型存的是指向堆或方法区的引用可以理解为一个地址。所以当你在方法里写String s abc;时局部变量表里的s存的是一个引用真正的abc这个字符串对象并不在栈上。栈的空间通常很小默认也就几百 KB 到 1 MB 左右可以用-Xss调整。这也是为什么递归太深会抛StackOverflowError——桌子就那么大你非要往上堆几百层盘子肯定塌。2.3 堆的细节对象都住在这里但字符串有点特殊堆是 GC 的主战场几乎所有对象实例都在这里分配。堆内部又分新生代和老年代新生代再分 Eden、Survivor 区这套分代模型是为了提高 GC 效率这里不展开。对于字符串来说情况稍微特殊一点。字符串对象本身是存在堆里的但字符串常量池String Pool在 JDK 7 之后也被挪到了堆里。也就是说字符串相关的常量和对象其实都住在堆这个公共仓库里只是分属不同的货架。2.4 方法区的细节常量池的老家方法区里最核心的内容之一就是运行时常量池Runtime Constant Pool。每个类被加载时它的 Class 文件里的常量池Constant Pool会被解析并放入方法区的运行时常量池。这里面存的东西包括字面量文本字符串、final 常量值等和符号引用类和接口的全限定名、字段名、方法名等。这里要区分两个概念很多人会混概念位置产生时机内容Class 常量池Class 文件中编译期字面量 符号引用运行时常量池方法区类加载后Class 常量池的内容 动态添加的常量字符串常量池堆JDK 7运行期字符串字面量的引用看到没常量池这个词其实指代了三个不同的东西它们位置不同、时机不同、职责不同。面试里如果只答常量池在方法区那基本是要被追问到露馅的。3. 常量池三兄弟Class 常量池、运行时常量池、字符串常量池把地图铺好之后我们逐个拆解这三个常量池搞清楚它们各自是什么、住在哪、什么时候登场。3.1 Class 常量池编译期就写死在字节码里的清单你写一个.java文件编译成.class文件后用javap -verbose反编译一下会看到一大段Constant pool的输出。这就是 Class 常量池它是 Class 文件结构的一部分在编译期就已经确定。它里面主要放两类东西字面量Literal比如文本字符串、声明为 final 的常量值。符号引用Symbolic Reference比如类和接口的全限定名、字段的名称和描述符、方法的名称和描述符。为什么要有符号引用因为编译的时候你引用的其他类可能还没加载编译器没法知道它们真实的内存地址只能用名字先占个位。等到运行期类加载的时候再把这些符号引用解析成真正的直接引用内存地址。你可以自己动手验证一下。写一个最简单的类public class Demo { public static void main(String[] args) { String s hello; int a 100; } }编译后执行javap -verbose Demo你会看到常量池里出现了hello这个字符串字面量以及java/lang/String、main、([Ljava/lang/String;)V这些符号引用。这些就是 Class 常量池的内容。3.2 运行时常量池类加载后搬到方法区的活版本Class 常量池是静态的、躺在文件里的。当类被 JVM 加载时Class 常量池的内容会被原封不动地搬进方法区形成运行时常量池。但运行时常量池比 Class 常量池多了一个能力它支持动态添加。最典型的就是String.intern()方法运行时可以把新的字符串常量加进去。这一点是 Class 常量池做不到的因为文件已经编译完了改不了。注意运行时常量池是每个类一份的。你加载 100 个类方法区里就有 100 个运行时常量池。它们彼此独立各自对应自己的 Class 文件。3.3 字符串常量池最特殊、最容易踩坑的一个字符串常量池String Pool也叫 String Table是三个里面最特殊的一个原因有三第一它的位置变过。JDK 6 及之前字符串常量池在方法区永久代里JDK 7 开始被挪到了堆里JDK 8 之后方法区变成元空间字符串常量池依然留在堆里。这个变化直接影响了intern()的行为后面会细讲。第二它的设计目的是复用。字符串是程序里用得最频繁的类型之一如果每次写abc都创建一个新对象内存会被迅速撑爆。所以 JVM 维护了一个哈希表StringTable相同的字面量只存一份大家共享引用。第三它和堆里的字符串对象是两回事。字符串常量池里存的是引用真正的字符串对象在堆里。这个区分非常关键很多人搞混就栽在这。用一个类比字符串常量池就像图书馆的索引卡片柜卡片上写着《Java 编程思想》在 3 楼 A 区。真正的书字符串对象在书架上堆卡片柜里只有索引引用。你查卡片柜拿到的是书的位置而不是书本身。4. 字符串创建的两条路字面量 vs new差别到底在哪理解了字符串常量池的定位我们就能解释那个经典问题了String s1 abc和String s2 new String(abc)到底有什么区别为什么s1 s2是 false4.1 字面量方式先查池子有就复用当你写String s1 abc;时JVM 的执行流程是这样的去字符串常量池里查有没有内容为abc的字符串。如果有直接把池子里的引用返回给s1。如果没有在堆里创建一个abc对象把它的引用登记到字符串常量池然后返回这个引用。所以字面量方式最多只会创建一个对象池子里没有时或者一个都不创建池子里已有时。这就是复用的威力。4.2 new 方式至少创建一个新对象当你写String s2 new String(abc);时流程复杂一些先看abc这个字面量在不在字符串常量池里不在就先创建并登记这一步跟字面量方式一样。然后在堆里再 new 一个全新的 String 对象把abc的内容复制进去。返回这个新对象的引用给s2。所以new String(abc)至少创建一个对象最多创建两个池子里没有时池子一个 堆里一个。4.3 用代码验证眼见为实光说没用跑一遍代码最清楚public class StringDemo { public static void main(String[] args) { String s1 abc; String s2 abc; String s3 new String(abc); String s4 new String(abc); System.out.println(s1 s2); // true都指向池子里同一个对象 System.out.println(s1 s3); // falses3 是堆里新对象 System.out.println(s3 s4); // false两个不同的堆对象 System.out.println(s1.equals(s3)); // true内容相同 } }运行结果跟我注释里写的一致。s1 s2为 true是因为它们都指向字符串常量池里那唯一一份abc。s1 s3为 false是因为s3指向堆里一个全新的对象地址不同。实操心得判断字符串相等永远用equals()不要用。比的是引用地址equals()比的是内容。这个坑我踩过你也别踩。4.4 编译期优化那些你以为会创建对象其实没创建的情况有个细节值得单独拎出来说。下面这段代码s3是几个对象String s1 a; String s2 b; String s3 a b; String s4 s1 s2;答案是s3在编译期就被优化成了ab直接去常量池找不会创建新对象。而s4因为涉及变量编译期无法确定会在运行期通过StringBuilder拼接后toString()创建一个新的堆对象。所以System.out.println(s3 ab); // true System.out.println(s4 ab); // false这个差异在面试里被问到的频率极高很多人只知道字符串拼接用 StringBuilder但不知道纯字面量拼接编译器会直接优化只有涉及变量时才会走 StringBuilder。5. intern() 方法字符串常量池的手动挡如果说字面量方式是自动挡那intern()就是手动挡。它允许你在运行时手动把一个字符串塞进常量池或者从池子里取引用。这个方法的行为在 JDK 6 和 JDK 7 之间发生了变化是面试的重灾区。5.1 intern() 到底做了什么intern()的逻辑可以概括为如果字符串常量池里已经有一个内容相等的字符串直接返回池子里那个的引用。如果没有把当前字符串的引用登记到池子里然后返回这个引用。注意 JDK 6 和 JDK 7 的区别就在第二步JDK 6字符串常量池在永久代。如果池子里没有会把当前字符串复制一份到永久代返回永久代里那个副本的引用。JDK 7字符串常量池在堆里。如果池子里没有直接把当前堆对象的引用登记到池子里返回的就是这个堆对象的引用不再复制。这个区别导致同一段代码在两个版本上结果不同我们来看经典例子。5.2 经典面试题这段代码在 JDK 6 和 JDK 7 结果不同public class InternDemo { public static void main(String[] args) { String s new String(1); s.intern(); String s2 1; System.out.println(s s2); // JDK 6: false, JDK 7: false String s3 new String(1) new String(1); s3.intern(); String s4 11; System.out.println(s3 s4); // JDK 6: false, JDK 7: true } }第一组s s2在两个版本都是 false因为s是new出来的堆对象s2是池子里的引用两者地址不同。第二组就有意思了。s3是通过拼接得到的堆对象内容为11。此时字符串常量池里并没有11因为11不是字面量是拼出来的。调用s3.intern()后JDK 6把11复制到永久代池子里存的是副本。之后s4 11拿到的是副本的引用跟s3不是同一个所以 false。JDK 7直接把s3这个堆对象的引用登记到池子里。之后s4 11拿到的就是这个引用跟s3相同所以 true。注意这个差异的根源就是字符串常量池的位置变化。理解了池子在堆里还是方法区这个结果就顺理成章了。5.3 intern() 的实际用途省内存intern()不只是面试题它在实际项目里是有用的。假设你要处理海量日志里面有很多重复的字符串比如状态码、地区名、设备型号如果每个都独立存一份内存会爆。这时候可以用intern()把它们收敛到常量池相同的字符串只留一份。不过要小心常量池本身也是要占内存的而且 JDK 7 之后它在堆里受 GC 管理。如果 intern 的字符串太多太杂反而会拖慢 GC。所以这个技巧适合重复率高、种类有限的场景不适合每个字符串都独一无二的场景。6. 常量池与 GC谁会被回收谁不会聊完创建和复用我们来说说回收。常量池里的东西是不是永远不回收答案是否定的但回收条件比较苛刻。6.1 字符串常量池的回收字符串常量池里的字符串如果没有任何引用指向它是可以被回收的。但注意这里的引用包括池子本身的登记。也就是说一个字符串要被回收得满足堆里没有任何地方引用它包括栈上的局部变量、其他对象里的字段等。它没有被字符串常量池登记或者虽然登记了但可以被清理。实际上字符串常量池的回收依赖于 GC 对 StringTable 的扫描。如果某个字符串已经无人问津GC 会把它从池子里移除释放内存。这也是为什么 JDK 7 把池子挪到堆里——堆里的东西才能被 GC 高效管理永久代的回收效率低得多。6.2 运行时常量池的回收运行时常量池属于方法区它的回收主要针对不再使用的类和常量。类的卸载条件非常严格该类的所有实例都被回收、加载该类的 ClassLoader 被回收、该类的 Class 对象没有被引用。三个条件同时满足类才会被卸载对应的运行时常量池才会被清理。在实际应用里类卸载很少发生因为大部分类都是系统类加载器加载的生命周期跟 JVM 一样长。所以运行时常量池基本可以认为是常驻的。6.3 一个容易忽略的点常量池也会 OOM很多人以为只有堆会 OOM其实常量池也会。JDK 6 时代如果疯狂intern()大量字符串会抛PermGen space的 OOM。JDK 7 之后字符串常量池在堆里疯狂 intern 会导致堆 OOM错误信息变成Java heap space。这个变化也提醒我们常量池不是无限大的用intern()优化内存时要有节制最好配合监控观察 StringTable 的大小。7. 常见问题与排查技巧实录理论讲完了最后来点实战的。下面这些问题是这些年我在项目里、在帮同事排查时反复遇到的整理成速查表方便你对号入座。7.1 常见问题速查表现象可能原因排查思路解决方式判断字符串相等时结果不稳定一个来自常量池一个来自 new 或拼接打印System.identityHashCode()看地址统一用equals()大量字符串导致内存飙升重复字符串未复用用 MAT 或 JProfiler 看 String 对象数量考虑intern()或改用枚举intern()后内存反而更高字符串种类太多池子膨胀观察 StringTable 大小和 GC 频率限制 intern 的使用范围拼接字符串性能差循环里用拼接看是否有大量临时 String 对象改用StringBuilder类加载后常量池异常Class 文件损坏或版本不匹配javap -verbose检查常量池重新编译确认 JDK 版本7.2 几个独家避坑技巧技巧一判断字符串来源用identityHashCode。当你怀疑两个字符串是不是同一个对象时System.out.println(System.identityHashCode(s))比更直观因为它打印的是对象的原始哈希基于地址能直接看出是不是同一个。技巧二循环拼接一定用 StringBuilder。下面这段代码是性能杀手String result ; for (int i 0; i 10000; i) { result i; }每次都会创建一个新的 String 对象10000 次循环就是 10000 个临时对象。改成StringBuilder后只在最后toString()时创建一个对象性能差距是数量级的。技巧三常量池的字符串比较编译期能确定的尽量用字面量。比如配置里的固定值直接写成字面量让编译器帮你复用比运行时拼接再 intern 更省事。技巧四JDK 版本升级时重点回归 intern 相关逻辑。如果你的代码里用了intern()从 JDK 6 升到 JDK 8 时一定要重新测试因为行为变了原来 false 的判断可能变成 true逻辑分支可能走错。7.3 一个真实的排查案例之前有个同事反馈说他们的缓存 key 偶尔匹配不上导致缓存击穿。我帮他看代码发现 key 是用new String(...)拼出来的然后跟配置里的字面量 key 用比较。大部分时候能匹配上是因为某些路径下 JVM 恰好复用了池子里的对象但一旦走new的路径就匹配失败。这个问题隐蔽就隐蔽在它不是每次都错而是看运气。修复方式很简单把改成equals()问题立刻消失。所以我现在写代码只要涉及字符串比较条件反射就是equals()绝不给自己留隐患。8. 把常量池放回内存模型里再看一遍写到这里我想把整篇文章的逻辑再串一下帮你形成一个完整的认知闭环。常量池不是一个孤立的概念它是JVM 内存模型的一个横切面。Class 常量池是编译期的产物躺在字节码文件里类加载后它变成运行时常量池住进方法区而字符串常量池作为其中最活跃的部分在 JDK 7 之后搬进了堆接受 GC 的管理。栈上的局部变量持有引用堆里存放真正的对象方法区保存类的元信息和常量——这三者通过引用这条线连在一起。理解了这条线你就能解释为什么和equals结果不同为什么intern()在不同 JDK 版本行为不同为什么字符串拼接有时创建对象有时不创建为什么常量池也会 OOM。这些问题表面上是字符串的坑本质上是内存布局的坑。我个人在实际项目里的体会是大部分字符串相关的 bug根源都不是字符串本身而是对内存模型理解不到位。一旦你把栈、堆、方法区、常量池的关系理顺了很多看似玄学的问题都会变得理所当然。所以与其死记硬背面试题答案不如花点时间把这张内存地图真正画进脑子里后面遇到任何变体都能自己推出来。最后再分享一个小习惯每次写完涉及字符串比较、拼接、缓存的代码我都会下意识问自己一句——这里比的是地址还是内容这个对象是在池子里还是堆里养成这个习惯之后我踩的坑明显少了很多。