创建几个对象？JVM常量池与堆内存深度解析)
1. 这道题为什么成了面试分水岭new String()创建几个对象这个问题几乎成了Java面试里的一道分水岭。初级开发者背个答案就过去了但真正做过几年项目、读过JVM源码的人能从这一道题里讲出字符串常量池、堆内存分配、编译期优化、类加载机制等一连串知识点。我自己在带团队的时候也喜欢用这道题来试探候选人对Java内存模型的理解深度因为它的答案不是固定的1个或2个而是取决于具体的代码写法和运行环境。先把结论摆在前面new String(abc)这行代码在大多数常规场景下会创建2个对象一个在字符串常量池一个在堆里但如果常量池里已经存在abc这个字面量那就只创建1个对象。而new String(abc)和直接写String s abc之间的区别才是这道题真正想考察的核心。这篇文章我会从字节码层面、JVM内存结构、常量池机制三个维度把这个问题彻底拆开不光告诉你答案还要让你明白为什么是这个答案以及在什么情况下答案会变。看完之后你不仅能从容应对面试更能在实际编码中避开字符串相关的一些性能陷阱。适合阅读这篇文章的人准备Java面试的开发者、想深入理解JVM内存模型的工程师、以及平时写代码时对字符串处理有疑惑的朋友。哪怕你刚学Java不久我也会用生活化的类比把复杂概念讲清楚。2. 字符串常量池与堆内存的核心机制2.1 字符串常量池到底是个什么东西要搞清楚创建了几个对象首先得弄明白字符串常量池String Constant Pool是什么。你可以把它想象成一个公共仓库——JVM在加载类的时候会把代码里出现的字符串字面量就是用双引号直接写出来的那些比如abc、hello提前放进这个仓库里。下次再有人需要同样的字符串直接从这个仓库拿就行了不用重新造一个。这个仓库在JDK 1.7之前位于方法区永久代中JDK 1.7及以后被移到了堆内存里。这个变化很关键因为它直接影响了intern()方法的行为和字符串对象的分配策略。很多面试官会追问这一点就是想看看你有没有关注过JDK版本差异带来的底层变化。常量池的核心价值在于复用。字符串在Java程序里出现的频率极高如果每次声明一个字符串都创建新对象内存早就爆了。常量池的设计思路和日常生活中的共享单车很像——大家共用一批车而不是每人买一辆。2.2 堆内存中的字符串对象当你在代码里写new String(abc)的时候new这个关键字就明确告诉JVM我要在堆上开辟一块新空间创建一个全新的对象。这个对象和常量池里的那个abc是完全独立的两个实例虽然它们的内容一样但内存地址不同。用生活类比来说常量池里的abc像是图书馆里的一本公共藏书而new String(abc)则是你把这本藏书复印了一份放在自己家里。内容一模一样但一个是公共资源一个是你的私有副本。这里有个容易混淆的点new String(abc)中的abc本身也是一个字符串字面量它也会触发常量池的检查机制。如果常量池里没有abc就先在池子里创建一个然后再在堆里创建一个新的String对象把池子里那个abc的内容复制过去。这就是为什么大多数情况下答案是2个对象。2.3 字节码层面看对象创建过程光说理论不够直观我们直接看字节码。假设有这样一段代码public class StringTest { public static void main(String[] args) { String s new String(abc); } }编译后用javap -c StringTest查看字节码核心指令大概是这样0: new #2 // class java/lang/String 3: dup 4: ldc #3 // String abc 6: invokespecial #4 // Method java/lang/String.init:(Ljava/lang/String;)V 9: astore_1逐条解读一下new #2在堆中分配内存创建一个String对象此时对象里的字段还是默认值。dup复制栈顶的引用因为后面要调用构造方法需要保留一份引用给变量赋值。ldc #3从常量池中加载字符串abc。注意如果常量池里没有abc这一步会触发常量池的创建。invokespecial #4调用String的构造方法把abc的内容传给新创建的对象。astore_1把对象的引用存到局部变量表里。从字节码可以清楚看到ldc指令负责常量池的部分new指令负责堆的部分两者配合完成了整个对象的创建。这也从底层印证了两个对象的说法。3. 不同写法下的对象数量差异3.1 经典场景new String(abc)创建几个回到最经典的场景。当JVM执行new String(abc)时会经历以下步骤检查字符串常量池中是否存在abc。如果不存在在常量池中创建一个abc对象。无论常量池中是否已存在都在堆中创建一个新的String对象。将常量池中abc的内容复制到堆中的新对象里。返回堆中对象的引用。所以常量池没有abc时创建2个对象常量池1个 堆1个。常量池已有abc时创建1个对象只在堆中创建。那什么时候常量池里会已经有abc呢比如同一个类中前面已经写过String a abc;或者同一个类加载器加载的其他类里已经用过这个字面量。这种情况下new String(abc)就只创建1个堆对象了。3.2 对比场景直接赋值与new的区别很多人会把String s abc和String s new String(abc)搞混。前者只涉及常量池后者才涉及堆。看下面的对比String s1 abc; // 常量池 String s2 new String(abc); // 堆 常量池 String s3 abc; // 复用常量池 System.out.println(s1 s2); // false System.out.println(s1 s3); // true System.out.println(s1.equals(s2)); // trues1 s3为true是因为它们指向常量池里同一个对象。s1 s2为false是因为s2指向堆里那个新对象地址不同。而equals比较的是内容所以为true。这个对比是面试高频考点也是实际开发中容易踩坑的地方。我见过不少项目里用比较字符串导致bug的案例尤其是在处理用户输入、配置读取这类场景时。3.3 编译期优化带来的意外结果有一种情况会让对象数量变得更少那就是编译期优化。看这段代码String s a b c;你可能以为这里创建了多个对象但实际上编译器会把它优化成String s abc;只创建1个常量池对象。因为a、b、c都是编译期常量编译器在编译阶段就能算出结果。但如果是这样String a a; String b b; String s a b;这就不同了。a和b是变量编译器无法在编译期确定它们的值所以会使用StringBuilder来拼接最终通过toString()创建一个新的String对象。这种情况下对象数量就变成了常量池a、b各1个StringBuilder对象1个最终String对象1个。注意从JDK 9开始字符串拼接的底层实现从StringBuilder改成了invokedynamic指令配合StringConcatFactory但本质上仍然会创建新的String对象只是优化了拼接性能。3.4 intern方法对对象数量的影响intern()方法是这道题的进阶考点。它的作用是检查字符串常量池中是否有当前字符串内容的等价对象如果有就返回池中那个如果没有就把当前字符串的引用放入池中JDK 1.7或复制一份放入池中JDK 1.6。String s1 new String(abc); String s2 s1.intern(); String s3 abc; System.out.println(s2 s3); // true System.out.println(s1 s2); // false这里s1是堆对象s2通过intern拿到了常量池里的abcs3直接指向常量池所以s2和s3相等s1和s2不等。JDK 1.6和1.7在intern的实现上有细微差别1.6会把字符串复制到常量池1.7则直接把堆中的引用记录到常量池。这个差异在极端场景下会影响对象数量和内存占用面试时如果被问到能答出来绝对是加分项。4. 完整实操验证与内存分析4.1 用代码实测对象创建数量理论说了这么多我们来实际验证一下。虽然不能直接数对象个数但可以通过一些间接手段来观察。下面这段代码可以帮你直观感受常量池和堆的区别public class StringObjectDemo { public static void main(String[] args) { String s1 abc; String s2 new String(abc); String s3 s2.intern(); System.out.println(s1 s2: (s1 s2)); // false System.out.println(s1 s3: (s1 s3)); // true System.out.println(s2 s3: (s2 s3)); // false // 验证常量池复用 String s4 abc; System.out.println(s1 s4: (s1 s4)); // true } }运行结果和我们分析的一致。如果你想更精确地观察对象数量可以借助JOLJava Object Layout工具或者JVM的-verbose:gc参数来观察内存变化不过对于日常理解来说上面的代码已经足够了。4.2 用JOL工具查看对象内存布局JOL是OpenJDK提供的一个轻量级工具可以打印出对象在内存中的布局。引入依赖后这里不写具体坐标避免版本问题可以这样用import org.openjdk.jol.info.ClassLayout; public class JOLDemo { public static void main(String[] args) { String s new String(abc); System.out.println(ClassLayout.parseInstance(s).toPrintable()); } }输出会显示对象头mark word klass pointer、字段value数组引用、hash等以及对齐填充。通过这个工具你能直观看到String对象在堆里到底占了多少字节也能理解为什么说每个String对象都有额外的内存开销。一个空的String对象在64位JVM上大约占24字节对象头12字节 引用4字节 对齐8字节加上字符数组本身的开销实际占用远大于你看到的字符数。这也是为什么在大数据量场景下字符串处理要格外注意内存问题。4.3 不同JDK版本的差异实测前面提到JDK 1.7把常量池从方法区移到了堆里这个变化对intern()的行为有影响。我分别在JDK 8和JDK 17上跑过类似的测试代码结论是JDK版本常量池位置intern行为new String(abc)对象数JDK 1.6方法区永久代复制字符串到常量池2个池中无时JDK 1.7堆内存记录引用到常量池2个池中无时JDK 1.8堆内存元空间替代永久代同1.72个池中无时JDK 17堆内存同1.72个池中无时对象数量本身没有变化但内存分布和intern的底层实现变了。如果你在面试中被问到JDK 1.7前后有什么区别这就是标准答案。4.4 参数计算一个String对象到底占多少内存我们来算一笔账。假设是64位JVM开启指针压缩默认开启一个new String(abc)的对象内存占用如下String对象本身对象头12字节 value引用4字节 hash字段4字节 对齐填充0字节 20字节对齐到24字节。底层byte数组JDK 9用byte[]存字符对象头16字节 长度4字节 3个字符3字节 对齐填充1字节 24字节。合计约48字节。而如果直接用String s abc只占用常量池里那一份堆上不额外分配。所以在循环里频繁new String()是非常浪费内存的操作。实操心得在需要大量拼接字符串的场景优先用StringBuilder在需要比较字符串内容的场景永远用equals而不是在需要复用字符串的场景考虑用intern但要评估常量池膨胀的风险。5. 常见问题与排查技巧实录5.1 面试中常见的追问与应对这道题之所以经典是因为它可以无限延伸。下面整理几个高频追问和应对思路追问核心考点回答要点new String(abc)创建几个对象常量池堆池中无则2个有则1个String s abc创建几个常量池池中无则1个有则0个intern()的作用常量池复用返回池中引用1.7记录堆引用和equals的区别引用vs内容比地址equals比内容字符串拼接的底层编译优化常量折叠或StringBuilder常量池在哪个区域内存模型1.7前方法区1.7堆回答这类问题时不要只给结论要把推理过程讲出来。面试官更看重你的分析能力而不是背诵能力。5.2 实际开发中的字符串陷阱面试题归面试题实际开发中字符串相关的坑更多。我踩过的几个典型坑坑一用比较字符串。这个不用多说新手常犯。尤其是从配置文件读取的值和代码里写死的字面量比较时因为配置读取走的是堆对象字面量在常量池必然为false。坑二循环里拼接字符串。每次循环都str x底层每次都会创建新的StringBuilder和String对象循环一万次就是几万个对象。改成在循环外创建StringBuilder性能能提升几十倍。坑三intern滥用导致常量池膨胀。intern确实能节省内存但如果intern的字符串是动态生成的、数量不可控的比如用户ID常量池会无限膨胀最终导致OOM。用之前一定要评估字符串的基数。坑四substring内存泄漏JDK 1.6。JDK 1.6的substring会共享原字符串的char数组如果原字符串很大而substring很小会导致大数组无法被回收。JDK 1.7已经修复了这个问题会创建新的数组。5.3 排查字符串内存问题的思路如果你怀疑项目里有字符串导致的内存问题可以按这个思路排查用jmap -histo:live pid查看堆中对象数量排名看String和char[]/byte[]的占比。用jstack配合MATMemory Analyzer Tool分析堆转储找到占用内存最多的字符串。检查代码中是否有大量字符串拼接、是否有不必要的new String、是否有intern滥用。对于高频字符串操作考虑用StringBuilder、StringBuffer或字符数组替代。注意排查内存问题时一定要在测试环境复现不要直接在生产环境dump堆因为dump过程会暂停应用STW影响线上服务。5.4 避坑速查表最后整理一份字符串使用的避坑速查表贴在工位上随时看比较内容用equals比较地址才用。循环拼接用StringBuilder不要用。频繁复用的字符串考虑intern但要注意基数。大量字符串处理考虑用byte[]或char[]减少对象开销。从外部读取的字符串和字面量比较时把字面量放前面避免NPE。字符串常量池在JDK 1.7位于堆中调优时要考虑这部分内存。我个人在实际项目中的体会是字符串问题往往不是性能瓶颈的第一来源但一旦成为瓶颈排查起来特别费劲因为它涉及的内存区域多、对象数量大。所以与其事后排查不如在编码阶段就养成好习惯。比如我们团队现在代码review时看到循环里的字符串拼接、看到用比较字符串都会直接打回去重写。这些规范看起来琐碎但积累下来能省掉很多线上问题。另外分享一个小技巧如果你在面试中被问到这道题不要急着回答2个先反问一句您是指常量池中已有还是未有该字符串的情况这一问面试官就知道你是真懂而不是背答案的。这个反问技巧在很多Java基础题里都适用比如问HashMap扩容、问GC算法先确认前提条件再回答既显得严谨也能给自己争取思考时间。 
长河君 · 2026/10/15 16:35:20 · 阅读 1.2k Java面试分水岭：new String()创建几个对象？JVM常量池与堆内存深度解析
1. 这道题为什么成了面试分水岭new String()创建几个对象这个问题几乎成了Java面试里的一道分水岭。初级开发者背个答案就过去了但真正做过几年项目、读过JVM源码的人能从这一道题里讲出字符串常量池、堆内存分配、编译期优化、类加载机制等一连串知识点。我自己在带团队的时候也喜欢用这道题来试探候选人对Java内存模型的理解深度因为它的答案不是固定的1个或2个而是取决于具体的代码写法和运行环境。先把结论摆在前面new String(abc)这行代码在大多数常规场景下会创建2个对象一个在字符串常量池一个在堆里但如果常量池里已经存在abc这个字面量那就只创建1个对象。而new String(abc)和直接写String s abc之间的区别才是这道题真正想考察的核心。这篇文章我会从字节码层面、JVM内存结构、常量池机制三个维度把这个问题彻底拆开不光告诉你答案还要让你明白为什么是这个答案以及在什么情况下答案会变。看完之后你不仅能从容应对面试更能在实际编码中避开字符串相关的一些性能陷阱。适合阅读这篇文章的人准备Java面试的开发者、想深入理解JVM内存模型的工程师、以及平时写代码时对字符串处理有疑惑的朋友。哪怕你刚学Java不久我也会用生活化的类比把复杂概念讲清楚。2. 字符串常量池与堆内存的核心机制2.1 字符串常量池到底是个什么东西要搞清楚创建了几个对象首先得弄明白字符串常量池String Constant Pool是什么。你可以把它想象成一个公共仓库——JVM在加载类的时候会把代码里出现的字符串字面量就是用双引号直接写出来的那些比如abc、hello提前放进这个仓库里。下次再有人需要同样的字符串直接从这个仓库拿就行了不用重新造一个。这个仓库在JDK 1.7之前位于方法区永久代中JDK 1.7及以后被移到了堆内存里。这个变化很关键因为它直接影响了intern()方法的行为和字符串对象的分配策略。很多面试官会追问这一点就是想看看你有没有关注过JDK版本差异带来的底层变化。常量池的核心价值在于复用。字符串在Java程序里出现的频率极高如果每次声明一个字符串都创建新对象内存早就爆了。常量池的设计思路和日常生活中的共享单车很像——大家共用一批车而不是每人买一辆。2.2 堆内存中的字符串对象当你在代码里写new String(abc)的时候new这个关键字就明确告诉JVM我要在堆上开辟一块新空间创建一个全新的对象。这个对象和常量池里的那个abc是完全独立的两个实例虽然它们的内容一样但内存地址不同。用生活类比来说常量池里的abc像是图书馆里的一本公共藏书而new String(abc)则是你把这本藏书复印了一份放在自己家里。内容一模一样但一个是公共资源一个是你的私有副本。这里有个容易混淆的点new String(abc)中的abc本身也是一个字符串字面量它也会触发常量池的检查机制。如果常量池里没有abc就先在池子里创建一个然后再在堆里创建一个新的String对象把池子里那个abc的内容复制过去。这就是为什么大多数情况下答案是2个对象。2.3 字节码层面看对象创建过程光说理论不够直观我们直接看字节码。假设有这样一段代码public class StringTest { public static void main(String[] args) { String s new String(abc); } }编译后用javap -c StringTest查看字节码核心指令大概是这样0: new #2 // class java/lang/String 3: dup 4: ldc #3 // String abc 6: invokespecial #4 // Method java/lang/String.init:(Ljava/lang/String;)V 9: astore_1逐条解读一下new #2在堆中分配内存创建一个String对象此时对象里的字段还是默认值。dup复制栈顶的引用因为后面要调用构造方法需要保留一份引用给变量赋值。ldc #3从常量池中加载字符串abc。注意如果常量池里没有abc这一步会触发常量池的创建。invokespecial #4调用String的构造方法把abc的内容传给新创建的对象。astore_1把对象的引用存到局部变量表里。从字节码可以清楚看到ldc指令负责常量池的部分new指令负责堆的部分两者配合完成了整个对象的创建。这也从底层印证了两个对象的说法。3. 不同写法下的对象数量差异3.1 经典场景new String(abc)创建几个回到最经典的场景。当JVM执行new String(abc)时会经历以下步骤检查字符串常量池中是否存在abc。如果不存在在常量池中创建一个abc对象。无论常量池中是否已存在都在堆中创建一个新的String对象。将常量池中abc的内容复制到堆中的新对象里。返回堆中对象的引用。所以常量池没有abc时创建2个对象常量池1个 堆1个。常量池已有abc时创建1个对象只在堆中创建。那什么时候常量池里会已经有abc呢比如同一个类中前面已经写过String a abc;或者同一个类加载器加载的其他类里已经用过这个字面量。这种情况下new String(abc)就只创建1个堆对象了。3.2 对比场景直接赋值与new的区别很多人会把String s abc和String s new String(abc)搞混。前者只涉及常量池后者才涉及堆。看下面的对比String s1 abc; // 常量池 String s2 new String(abc); // 堆 常量池 String s3 abc; // 复用常量池 System.out.println(s1 s2); // false System.out.println(s1 s3); // true System.out.println(s1.equals(s2)); // trues1 s3为true是因为它们指向常量池里同一个对象。s1 s2为false是因为s2指向堆里那个新对象地址不同。而equals比较的是内容所以为true。这个对比是面试高频考点也是实际开发中容易踩坑的地方。我见过不少项目里用比较字符串导致bug的案例尤其是在处理用户输入、配置读取这类场景时。3.3 编译期优化带来的意外结果有一种情况会让对象数量变得更少那就是编译期优化。看这段代码String s a b c;你可能以为这里创建了多个对象但实际上编译器会把它优化成String s abc;只创建1个常量池对象。因为a、b、c都是编译期常量编译器在编译阶段就能算出结果。但如果是这样String a a; String b b; String s a b;这就不同了。a和b是变量编译器无法在编译期确定它们的值所以会使用StringBuilder来拼接最终通过toString()创建一个新的String对象。这种情况下对象数量就变成了常量池a、b各1个StringBuilder对象1个最终String对象1个。注意从JDK 9开始字符串拼接的底层实现从StringBuilder改成了invokedynamic指令配合StringConcatFactory但本质上仍然会创建新的String对象只是优化了拼接性能。3.4 intern方法对对象数量的影响intern()方法是这道题的进阶考点。它的作用是检查字符串常量池中是否有当前字符串内容的等价对象如果有就返回池中那个如果没有就把当前字符串的引用放入池中JDK 1.7或复制一份放入池中JDK 1.6。String s1 new String(abc); String s2 s1.intern(); String s3 abc; System.out.println(s2 s3); // true System.out.println(s1 s2); // false这里s1是堆对象s2通过intern拿到了常量池里的abcs3直接指向常量池所以s2和s3相等s1和s2不等。JDK 1.6和1.7在intern的实现上有细微差别1.6会把字符串复制到常量池1.7则直接把堆中的引用记录到常量池。这个差异在极端场景下会影响对象数量和内存占用面试时如果被问到能答出来绝对是加分项。4. 完整实操验证与内存分析4.1 用代码实测对象创建数量理论说了这么多我们来实际验证一下。虽然不能直接数对象个数但可以通过一些间接手段来观察。下面这段代码可以帮你直观感受常量池和堆的区别public class StringObjectDemo { public static void main(String[] args) { String s1 abc; String s2 new String(abc); String s3 s2.intern(); System.out.println(s1 s2: (s1 s2)); // false System.out.println(s1 s3: (s1 s3)); // true System.out.println(s2 s3: (s2 s3)); // false // 验证常量池复用 String s4 abc; System.out.println(s1 s4: (s1 s4)); // true } }运行结果和我们分析的一致。如果你想更精确地观察对象数量可以借助JOLJava Object Layout工具或者JVM的-verbose:gc参数来观察内存变化不过对于日常理解来说上面的代码已经足够了。4.2 用JOL工具查看对象内存布局JOL是OpenJDK提供的一个轻量级工具可以打印出对象在内存中的布局。引入依赖后这里不写具体坐标避免版本问题可以这样用import org.openjdk.jol.info.ClassLayout; public class JOLDemo { public static void main(String[] args) { String s new String(abc); System.out.println(ClassLayout.parseInstance(s).toPrintable()); } }输出会显示对象头mark word klass pointer、字段value数组引用、hash等以及对齐填充。通过这个工具你能直观看到String对象在堆里到底占了多少字节也能理解为什么说每个String对象都有额外的内存开销。一个空的String对象在64位JVM上大约占24字节对象头12字节 引用4字节 对齐8字节加上字符数组本身的开销实际占用远大于你看到的字符数。这也是为什么在大数据量场景下字符串处理要格外注意内存问题。4.3 不同JDK版本的差异实测前面提到JDK 1.7把常量池从方法区移到了堆里这个变化对intern()的行为有影响。我分别在JDK 8和JDK 17上跑过类似的测试代码结论是JDK版本常量池位置intern行为new String(abc)对象数JDK 1.6方法区永久代复制字符串到常量池2个池中无时JDK 1.7堆内存记录引用到常量池2个池中无时JDK 1.8堆内存元空间替代永久代同1.72个池中无时JDK 17堆内存同1.72个池中无时对象数量本身没有变化但内存分布和intern的底层实现变了。如果你在面试中被问到JDK 1.7前后有什么区别这就是标准答案。4.4 参数计算一个String对象到底占多少内存我们来算一笔账。假设是64位JVM开启指针压缩默认开启一个new String(abc)的对象内存占用如下String对象本身对象头12字节 value引用4字节 hash字段4字节 对齐填充0字节 20字节对齐到24字节。底层byte数组JDK 9用byte[]存字符对象头16字节 长度4字节 3个字符3字节 对齐填充1字节 24字节。合计约48字节。而如果直接用String s abc只占用常量池里那一份堆上不额外分配。所以在循环里频繁new String()是非常浪费内存的操作。实操心得在需要大量拼接字符串的场景优先用StringBuilder在需要比较字符串内容的场景永远用equals而不是在需要复用字符串的场景考虑用intern但要评估常量池膨胀的风险。5. 常见问题与排查技巧实录5.1 面试中常见的追问与应对这道题之所以经典是因为它可以无限延伸。下面整理几个高频追问和应对思路追问核心考点回答要点new String(abc)创建几个对象常量池堆池中无则2个有则1个String s abc创建几个常量池池中无则1个有则0个intern()的作用常量池复用返回池中引用1.7记录堆引用和equals的区别引用vs内容比地址equals比内容字符串拼接的底层编译优化常量折叠或StringBuilder常量池在哪个区域内存模型1.7前方法区1.7堆回答这类问题时不要只给结论要把推理过程讲出来。面试官更看重你的分析能力而不是背诵能力。5.2 实际开发中的字符串陷阱面试题归面试题实际开发中字符串相关的坑更多。我踩过的几个典型坑坑一用比较字符串。这个不用多说新手常犯。尤其是从配置文件读取的值和代码里写死的字面量比较时因为配置读取走的是堆对象字面量在常量池必然为false。坑二循环里拼接字符串。每次循环都str x底层每次都会创建新的StringBuilder和String对象循环一万次就是几万个对象。改成在循环外创建StringBuilder性能能提升几十倍。坑三intern滥用导致常量池膨胀。intern确实能节省内存但如果intern的字符串是动态生成的、数量不可控的比如用户ID常量池会无限膨胀最终导致OOM。用之前一定要评估字符串的基数。坑四substring内存泄漏JDK 1.6。JDK 1.6的substring会共享原字符串的char数组如果原字符串很大而substring很小会导致大数组无法被回收。JDK 1.7已经修复了这个问题会创建新的数组。5.3 排查字符串内存问题的思路如果你怀疑项目里有字符串导致的内存问题可以按这个思路排查用jmap -histo:live pid查看堆中对象数量排名看String和char[]/byte[]的占比。用jstack配合MATMemory Analyzer Tool分析堆转储找到占用内存最多的字符串。检查代码中是否有大量字符串拼接、是否有不必要的new String、是否有intern滥用。对于高频字符串操作考虑用StringBuilder、StringBuffer或字符数组替代。注意排查内存问题时一定要在测试环境复现不要直接在生产环境dump堆因为dump过程会暂停应用STW影响线上服务。5.4 避坑速查表最后整理一份字符串使用的避坑速查表贴在工位上随时看比较内容用equals比较地址才用。循环拼接用StringBuilder不要用。频繁复用的字符串考虑intern但要注意基数。大量字符串处理考虑用byte[]或char[]减少对象开销。从外部读取的字符串和字面量比较时把字面量放前面避免NPE。字符串常量池在JDK 1.7位于堆中调优时要考虑这部分内存。我个人在实际项目中的体会是字符串问题往往不是性能瓶颈的第一来源但一旦成为瓶颈排查起来特别费劲因为它涉及的内存区域多、对象数量大。所以与其事后排查不如在编码阶段就养成好习惯。比如我们团队现在代码review时看到循环里的字符串拼接、看到用比较字符串都会直接打回去重写。这些规范看起来琐碎但积累下来能省掉很多线上问题。另外分享一个小技巧如果你在面试中被问到这道题不要急着回答2个先反问一句您是指常量池中已有还是未有该字符串的情况这一问面试官就知道你是真懂而不是背答案的。这个反问技巧在很多Java基础题里都适用比如问HashMap扩容、问GC算法先确认前提条件再回答既显得严谨也能给自己争取思考时间。