企业官网建设流程全解析

String类可能是Java里最被低估的一个类。很多同学写了好几年代码，能熟练使用substring、split、replace，但被问到"new String("abc")到底创建了几个对象"，或者"为什么String要设计成不可变"的时候，还是会卡壳。这篇东西不是教科书式的知识点罗列，而是我从实际项目、面试官视角和线上问题排查里沉淀下来的String类完整复盘——哪些原理必须懂，哪些API有坑，哪些性能问题真的会出现在生产环境，一次讲透。无论你是准备Java基础面试、刚入门Java，还是工作几年想补一下底层功底，这篇都值得存下来反复看。

1. 不可变性设计：String为什么打死都不让你改

1.1 从源码看"不可变"到底是怎么实现的

先说结论：String对象一旦创建，它的值就永远无法被修改。这里说的"无法修改"，指的是对象内部用来存储字符数据的那个数组被final修饰，而且这个数组在构造时被完整拷贝了一份，外部拿不到引用。

在JDK 8及以前，String内部是这么存的：

public final class String implements java.io.Serializable, Comparable<String>, CharSequence { private final char value[]; // ... }

JDK 9开始，为了节省内存，内部存储从char[]换成了byte[]，同时引入了一个coder字段来标记当前字符串是LATIN1编码（单字节）还是UTF16编码（双字节）：

private final byte[] value; private final byte coder;

这一步改动非常关键。因为大多数业务字符串都是英文字母、数字、符号，用LATIN1编码的话，一个字符只占一个字节，存储密度直接翻倍，堆内存里海量String对象的总占用能下降不少。我当年做过一次全链路压测，升级JDK 9之后，光字符串这块的堆占用就降了大概百分之十几，效果相当明显。

但无论存储结构怎么变，核心设计没变：类被final修饰，不能被继承；所有构造方法里都会把传入的字符数组Arrays.copyOf拷一份；对外暴露的所有"修改"方法——比如replace、substring、concat——根本不是原地改，而是new一个新对象返回。所以你在任何情况下拿到的String对象，都不可能被外部代码偷偷改动内部数据。

1.2 为什么Java团队宁可牺牲性能也要锁死它

很多人都想过一个问题：如果String是可变的，很多字符串拼接操作就能原地修改，省掉大量新对象创建的开销，为什么不这么做？这个问题在面试里被问到的频率极高，我把几个关键原因拆开说。

第一，线程安全。不可变对象天然是线程安全的，多个线程同时读一个String对象，不需要加锁，也不需要拷贝副本。这一点在并发场景下的价值是巨大的。如果String可变，HashMap的key如果是String，并发读写时哈希桶里的链表结构可能直接被破坏。正因为不可变，String才能放心地作为HashMap的key、作为锁对象、作为网络传输的载体。

第二，字符串常量池能成立的前提就是不可变。JVM里有一块区域专门缓存字符串字面量，让相同的字符串复用同一个对象。如果String可变，常量池里缓存的那个对象一旦被某个线程修改，所有引用它的地方全部遭殃，整个复用机制就崩了。不可变保证了"同一个字符串一定相同"，这是常量池存在的根基。

第三，hashCode可以安全缓存。打开String源码，你会发现有个private int hash字段，默认是0，第一次调用hashCode()的时候计算一次，之后就一直复用。这个缓存之所以安全，就是因为值不会变。这个优化对HashMap、HashSet这类依赖哈希的集合影响巨大——String是使用最频繁的key类型，hashCode缓存让每次get操作少了一次字符串遍历计算。

第四，安全性。类加载机制里，Class.forName的类名、ClassLoader加载的路径、网络连接的host和port，大量这些敏感参数都是以String形式传入的。如果String可变，一个恶意的引用共享就可能篡改类名或地址，把加载逻辑引到别的地方去，安全模型直接被人从根上撬开。

所以不可变性这个设计，本质上是牺牲了一部分拼串性能，换来了安全性、并发稳定性、缓存可行性和整个JVM内存体系的简洁。这是一笔长期收益远大于短期成本的买卖。

1.3 反射真的能修改String吗？能，但别这么干

虽然String内部数组是final的，但final只是Java编译器层面的约束，反射可以把private final字段的accessible标记打开，然后直接改数组内容。网上流传的这段代码是真实可行的：

String s = "Hello World"; Field valueField = String.class.getDeclaredField("value"); valueField.setAccessible(true); char[] value = (char[]) valueField.get(s); value[0] = 'J'; System.out.println(s); // 输出 Jello World

在JDK 8上，这段代码真的能把s的内容改成"Jello World"。但我要严肃说一句：这是极其危险的破坏性操作。因为如果这个String对象恰好是常量池里的字面量，你修改它会影响所有引用同一字面量的代码，甚至连JVM内部一些缓存字符串都会被污染，可能引发无法预料的崩溃。JDK 9之后value变成了byte[]，反射修改的代码写法要调整，但原理类似。这只能作为理解"不可变"边界的实验，线上代码碰都不要碰。

1.4 不可变带来的隐藏坑：substring的内存泄漏历史

不可变虽然好，但早期实现里有个著名的内存问题。JDK 6及以前，substring并不会复制字符数据，而是新创建一个String对象，内部value直接指向原字符串的同一个char[]，只是用offset和count标记区间。这么做的本意是省一次拷贝，但后果是：如果你从一个很大的字符串（比如几十MB的日志文本）里截取一小段（比如几个字符），只要这个小对象还活着，整个大char[]就无法被GC回收，内存被白占。

JDK 7之后官方改了实现，substring会真正复制一份数组，小对象不再拖着大数组陪葬。这个问题现在基本不存在了，但如果你在维护老项目或者面试被问到"JDK 6和JDK 7的substring有什么区别"，这个历史背景就是标准答案。它同时也是理解"不可变不等于没有内存代价"的一个好案例。

2. 字符串常量池与 intern()：高频面试点的完整认知

2.1 常量池的位置与演进过程

字符串常量池（String Table）是一个专门存放字符串字面量的区域，JVM保证内容相同的字符串字面量在池里只有一份。但"池子到底在哪"这个问题，经历了三个阶段：

• JDK 6及以前：常量池在方法区（PermGen永久代）里。永久代有大小限制，字符串一多就容易OutOfMemoryError: PermGen space。
• JDK 7：常量池挪到了堆内存里。这一挪意义很大，因为堆是GC的主要管理区域，字符串对象用完了可以被正常回收，PermGen空间压力大降。
• JDK 8：永久代被元空间（Metaspace）取代，但字符串常量池依然在堆中，位置没有再变。

为什么要挪到堆？永久代的空间小、回收效率低，字符串这种高创建量的对象放在那里，很容易就把PermGen打满。挪到堆之后，String对象能享受新生代的快速回收，池子本身也可以用堆内存的大小来弹性扩容。现在你看到一个StringTableSize相关的JVM参数，调的就是这个池子的哈希桶数量，默认大概六万个左右，可以通过-XX:StringTableSize调整，这在字符串数量极大的应用里是实打实的调优点。

2.2 "new String("abc")"到底创建了几个对象？这是一个陷阱题

这道题在面试里出现的频率高得离谱，但很多人背了答案却不懂原理。拆解如下：

String s = new String("abc");

这行代码涉及两个对象：一个是编译期间就被放入常量池的字面量"abc"，一个是运行期在堆里new出来的String对象。注意，new String("abc")的构造参数本身引用的是常量池里的那个"abc"，构造时再把内容复制一份到新的堆对象里。所以结果是：如果常量池里还没有"abc"，那就创建2个对象；如果常量池里已经有"abc"了，那只有堆里这1个是新建的。

String s1 = "abc"; // 只在常量池创建或复用 String s2 = new String("abc"); // 堆里新对象，但内容指向常量池的"abc" s1 == s2 // false，因为一个在池里一个在堆里 s1.equals(s2) // true，比较的是内容

这个题的深层考点是：==比较的是引用地址，equals比较的是内容。很多人把这两句话背得滚瓜烂熟，但一拿到这道题就懵，其实是因为对常量池和堆的对象分布没有一个直观的画面。你在心里画一张图——常量池在下面，堆对象在上面，两个不同位置的引用怎么==都是false——就永远不会错了。

2.3 intern()的机制与JDK版本差异

intern()方法的作用是：如果常量池里有内容相同的字符串，直接返回池中对象的引用；如果没有，把当前String的内容放入池中，返回池中对象的引用。调用它能让堆里的字符串与常量池建立关联，从而让后续相同内容的字符串能复用同一个对象。

但这里有个非常隐蔽的版本差异。JDK 6里，intern()是把这个字符串复制一份放进PermGen，返回的是PermGen里那个对象，堆里的原对象和池里的对象不是同一个。JDK 7以后，常量池挪到了堆里，intern()第一次调用时，如果池里没有，它不会复制一个新对象，而是把当前这个堆对象的引用记录到池里。看这个经典例子：

String a = new String("ab") + new String("cd"); // 创建了"abcd"，但"abcd"不在常量池 a.intern(); // JDK7: 池里没有"abcd"，把a的引用存进去 String b = "abcd"; // 常量池里已经有"abcd"，直接返回池中引用，也就是a a == b; // true（JDK7+）；JDK6下为false

把这个例子讲清楚，面试官基本就能确认你是不是真的理解常量池机制，而不只是背了八股。不过我要提醒一句：intern()是把双刃剑。在高并发或海量字符串场景下，intern()会导致字符串驻留在常量池里，如果池中对象一直有人引用，GC就无法回收，最后堆里出现大量无法回收的字符串，可能引发OutOfMemoryError。后面我会单独讲这个坑。

2.4 一个真实案例：滥用intern()引发的线上OOM

曾经有个项目用intern()来去重大量重复的设备上报消息。思路很简单：每条消息里有一个设备ID，理论上就几百个，用intern()把这些ID变成共享对象，能省内存。上线初期效果很好，堆占用降了一半。但运行三天后，GC日志出现异常，老年代涨得飞快，最终OOM。

排查发现，问题出在消息里除了设备ID，还有一个请求追踪ID——这个字段每次请求都随机生成，几乎没有重复。代码里把所有字符串字段都无脑intern()了一遍，导致每个随机ID都永久驻留在常量池里，堆被无限膨胀的池子撑爆。重启之后去掉对追踪ID的intern()，只保留设备ID等有限枚举型字段的驻留，问题立刻消失。

这个案例给我的教训是：intern()只适合用在值域有限且可枚举的字符串上，比如状态码、地区编码、枚举名。对于日志内容、请求ID、错误信息这类高基数字符串，用intern()就是在给堆内存埋炸弹。

3. 常用API分类拆解：不是罗列方法，是讲清每个方法背后的坑

3.1 创建与判空：isEmpty、isBlank与length()的边界

字符串判空，很多老手都会随手写一个s.length() == 0，功能上没问题，但语义上不够清晰。官方提供了两个方法：

• isEmpty()：判断length()是否为0，也就是内部数组长度是否为0。注意，""这种长度为0的字符串是isEmpty的，但一个只有空格的字符串" "不是isEmpty。
• isBlank()：JDK 11新增，判断字符串是否为空白。它内部会调用indexOfNonWhitespace，只要所有字符都是空白字符（空格、制表符、换行等），就返回true。

"".isEmpty(); // true " ".isEmpty(); // false " ".isBlank(); // true

实际业务里，校验用户输入时用isBlank()通常更合理，因为用户敲几个空格和什么都没敲，处理逻辑是一样的。不过要注意，isBlank()不是JDK 8自带的方法，如果项目还在JDK 8，需要自己封装或者用commons-lang3的StringUtils.isBlank()。还有一个高频坑：null字符串调用isEmpty()或isBlank()会直接抛NullPointerException，所以判空前一定要先判断是否为null，或者直接用StringUtils系列工具类。

3.2 比较：equals、equalsIgnoreCase、contentEquals与compareTo的差异

equals是字符串比较的基础操作，去比较两个字符串内容是否相同。equalsIgnoreCase忽略大小写，但注意它是基于Character.toUpperCase和Character.toLowerCase的双向忽略，不是只转一次。

contentEquals(CharSequence)是容易被忽略但很有用的方法——它可以直接和StringBuilder、StringBuffer比较内容，不用先调toString()再equals。和equals相比，contentEquals多了个链路优化：如果参数也是String，内部直接equals；如果是StringBuilder，它会加锁后逐字符比对，避免生成中间String对象。

compareTo按字典序比较字符串，返回负数、零、正数。它在排序场景中是主力：Arrays.sort、Collections.sort、TreeMap的排序规则，默认都是调compareTo。有个细节：compareTo是区分大小写的，忽略大小写的版本是compareToIgnoreCase。排序时如果你希望"ABC"和"abc"相邻，就得用后者。

3.3 查找与截取：indexOf、substring、split的组合使用技巧

indexOf系列是我最常用的API之一。它有多种重载：indexOf(int ch)找单个字符、indexOf(String str)找子串、带fromIndex的版本从指定位置开始找；对应的还有lastIndexOf从后往前找。处理日志解析、协议解析时，"用indexOf定位标记位，再用substring截取"是比直接split更高效的做法，因为split底层走正则，性能开销大得多。

String log = "timestamp=1699999999 level=INFO msg=hello"; int levelIdx = log.indexOf("level="); int msgIdx = log.indexOf("msg="); String level = log.substring(levelIdx + 6, msgIdx).trim();

这段代码比log.split(" ")效率高很多，尤其当日志行很长、分隔符很多的时候。substring方法本身有个注意点：它的参数区间是[beginIndex, endIndex)，左闭右开。很多新手写成substring(0, length)去取整个字符串，结果发现最后一位丢了，其实要取到末尾应该传substring(0)或者省略endIndex。

split方法最大的坑是：它是按正则表达式分割的。字符串里的.、|、*、$这些符号都有正则含义，直接传进去会得到匪夷所思的结果。比如"a.b.c".split(".")返回的是一个空数组，因为.在正则里匹配任意字符。正确的写法是split("\\.")或者split(Pattern.quote("."))。还有一个坑：split默认会丢弃末尾的空字符串，如果你需要保留空串，要用带limit参数的重载，比如split(",", -1)。

3.4 替换与转换：replace、replaceAll、replaceFirst的区分

很多人分不清replace和replaceAll，面试里翻车率也很高。replace(CharSequence target, CharSequence replacement)处理的是字面量，不做正则解析，所以"a.b".replace(".", "#")结果是a#b。replaceAll(String regex, String replacement)第一个参数是正则表达式，"a.b".replaceAll(".", "#")会把所有字符都替换成#。

replaceFirst和replaceAll类似，也只替换第一个匹配项。此外，replaceAll的第二个参数replacement里，$和\还有特殊含义，$1代表第一个捕获组。如果你想把文本里的$符号原样替换掉，直接写replaceAll("\\$", "USD")没问题，但如果替换的内容本身含$，需要写成Matcher.quoteReplacement(replacement)来规避解析。这个细节在写动态语句、模板渲染类代码时经常会踩到。

3.5 字符与字节：charAt、toCharArray、getBytes与编码陷阱

charAt(int index)按索引拿字符，注意索引越界会抛StringIndexOutOfBoundsException。toCharArray()返回一个全新的char[]，修改这个数组不会影响原String，这也是不可变设计的一部分——它宁可复制一份再给你，也不让你拿到内部引用。

getBytes()在面试里的考点集中在编码上。无参版本getBytes()使用平台默认字符集，这在部署环境之间迁移时是个隐患——开发环境Windows默认GBK，生产环境Linux默认UTF-8，同样的代码在两个环境可能产出不同字节。规范写法是明确指定字符集：getBytes(StandardCharsets.UTF_8)，构造String时同样用new String(bytes, StandardCharsets.UTF_8)。一次编码混乱导致的中文乱码，排查成本远超你写那行代码的时间，这个教训我是在处理一个跨语言接口时深刻体会到的。

3.6 JDK 8新增的join与JDK 11新增的repeat、lines

String.join是拼接集合元素非常方便的方法，它内部用StringJoiner实现，可以指定分隔符。比如把UUID列表拼成逗号分隔的字符串，一行搞定：

List<String> ids = Arrays.asList("a", "b", "c"); String joined = String.join(",", ids); // a,b,c

JDK 11加入的repeat(int count)用于重复字符串，生成缩进、分隔线这种场景很实用：

String line = "-".repeat(80);

lines()方法把一个多行字符串按\n、\r\n等换行符拆成Stream<String>流，处理多行文本、日志分析非常顺手。这些都是小而美的API，但如果你还在用老版本JDK，就得自己写循环或者找工具类替代。

4. 字符串拼接的性能真相：+号、StringBuilder与StringBuffer

4.1 "+"号拼接的底层真相与循环陷阱

很多人以为"a" + "b"就是简单的字符串连接，其实JVM在编译期做了两件不同的事。先看字面量拼接：

String s = "a" + "b" + "c";

编译阶段，"a" + "b" + "c"会被直接优化成"abc"——因为这三个都是编译期常量，编译器可以在编译时就算出结果。这是JVM的编译期常量折叠优化。

再看变量拼接：

String x = "a"; String s = x + "b";

这种情况下，编译后的字节码等价于：

String s = new StringBuilder().append(x).append("b").toString();

也就是说，单个+表达式其实不慢，JVM已经帮你建了StringBuilder。但问题出在循环里：

String s = ""; for (int i = 0; i < 10000; i++) { s += i; // 每次都new一个StringBuilder }

这段代码的隐性逻辑是：每次循环都新建一个StringBuilder、append、toString生成新字符串、再丢弃上一轮的结果。10000次循环就意味着10000次StringBuilder创建和10000个中间String对象产生，时间复杂度退化到O(n^2)。我做过简单压测，10万次循环，用+拼接耗时是StringBuilder的几十倍，GC压力更是天差地别。这还没算上中间字符串对象对新生代的冲击。

所以结论是：循环体内拼字符串，永远不要用+；循环体外单次拼接，怎么用都行。反过来的教训是——别为了性能，在单次拼接场景强行用StringBuilder，把代码可读性搞坏，收益微乎其微。

4.2 StringBuilder的扩容机制与初始化容量

StringBuilder内部维护一个byte[]（JDK 9之前是char[]），初始容量默认是16。如果append的内容超过容量，它会按旧容量的2倍加2来扩容，并把旧数据Arrays.copyOf到新数组。扩容本身是一个数组拷贝操作，频繁扩容的成本不低。

所以对于能够预估长度的拼接场景，最好提前指定容量：

StringBuilder sb = new StringBuilder(1024); for (String item : items) { sb.append(item); }

特别是循环拼接、构建大JSON字符串、生成文件内容时，提前给一个合理容量可以省掉大量扩容拷贝。这个经验在写高吞吐的日志组装代码时尤其重要——日志框架在异步线程里拼消息，StringBuilder容量给对了，整体QPS都能上去一点。

4.3 StringBuffer：线程安全背后的性能代价

StringBuffer是JDK 1.0就有的老类，它的关键方法都加了synchronized，所以线程安全。但"线程安全"是有代价的——每个append方法都要经历锁竞争。在单线程场景下，StringBuffer比StringBuilder慢不少；在多线程场景下，除非你真的需要让多个线程共享同一个拼接缓冲区，否则大部分情况下StringBuffer的同步也是浪费——你完全可以在每个线程里用独立的StringBuilder，最后合并结果。

我的实际建议是：99%的字符串拼接场景用StringBuilder就够了。StringBuffer的适用场景非常窄，基本是你需要把一个StringBuffer实例传给多个线程去append时才会用。JDK源码里StringBuffer的toString方法每次都会new String，不会复用缓存，这也是它开销高的一个点。面试如果问到"三者的区别"，标准答法是：运行速度快慢排序StringBuilder > StringBuffer > String + 拼接（循环场景），安全性上StringBuffer唯一线程安全。

4.4 JDK 9之后的拼接优化：invokedynamic与StringConcatFactory

JDK 9做了一个很多人没注意到的优化：+号拼接不再固定翻译成new StringBuilder().append()，而是改用invokedynamic指令，运行时通过StringConcatFactory来决定具体的拼接策略。默认策略在简单场景下会直接预分配一个足够大的数组，把各段内容拷进去，避免StringBuilder的中间态对象。这意味着，单次+拼接的性能得到了进一步提升，但循环拼接的低效本质并没有改变——每次循环还是会生成新字符串。

这个优化的意义在于：JDK在告诉你，"用+号拼接不用有心理负担，JVM自己会优化"。所以我的实践原则是：业务代码里的可读性优先，该用+就用+；只有在循环体、大字符串高频拼接、对GC敏感的代码路径上，才显式使用StringBuilder并指定容量。

5. equals、hashCode与字符串比较：细节里藏着一堆雷

5.1 为什么重写equals必须重写hashCode

这个问题的标准答案是：两个对象如果equals相等，它们的hashCode必须相等。反过来不成立——hashCode相等的两个对象，equals不一定相等（哈希碰撞）。如果你只重写equals不重写hashCode，HashMap、HashSet这类依赖hashCode定位的集合就会出问题：两个equals相等的对象被散列到不同的桶里，就会出现"同一个逻辑key在集合里存在两份"的怪象。

String的实现是教科书级别的：equals逐个字符比较，hashCode用31作为乘数做多项式计算：

public int hashCode() { int h = hash; if (h == 0 && value.length > 0) { for (byte v : value) { h = 31 * h + (v & 0xff); } hash = h; } return h; }

为什么选31？因为31是奇素数，乘法可以优化成(i << 5) - i，既减少哈希碰撞又兼顾计算性能，这是Joshua Bloch在《Effective Java》里解释过的经典设计。字符串hashCode的计算结果被缓存后，HashMap的get操作才能在O(1)时间复杂度内完成——否则每次都要重新遍历字符串算一遍哈希，性能会差一个数量级。

5.2 equals的隐藏坑：类型判断、长度检查与性能

String的equals方法实现里，第一步是this == anObject，先用引用相等做快速判断；第二步是判断对方是不是String类型；第三步才比较长度，长度不同直接返回false；最后逐字符比较。这个顺序不是随意的——引用相等命中是O(1)，类型判断是防止ClassCastException，长度检查能快速排除不相等的情况。

实际开发中有一个常见误区：把String.equals(Object)用反了。有些人写str.equals("abc")，如果str是null，直接NPE。凡是可能为null的字符串，比较时应该写成：

"abc".equals(str);

这样即使str为null，也只是返回false，不会抛异常。这个习惯在写接口校验、参数判等时能帮你省下不少NullPointerException的报错。类似地，Objects.equals(str1, str2)也是更好的选择，它会先做null判断。

5.3 String与StringBuilder为什么不"相等"？

一个容易被忽略的细节："abc".equals(new StringBuilder("abc"))返回false。因为equals里有两个条件，一个是类型判断，另一个是字符比较。String的对象和StringBuilder的对象类型不同，即使内容一样，String永远不认为StringBuilder和它相等。如果要比内容，前面说的contentEquals方法就是干这个的。

这个设计其实是有意为之——如果String把toString和StringBuilder的equals耦合在一起，那HashMap使用String做key时的语义就乱了。但实际项目中，调用第三方接口时对方返回StringBuilder类型，你直接equals发现不等，一定要记得先调toString()再比较。

5.4 大量字符串比较时的性能优化思路

如果你需要在一批字符串中频繁查找是否存在某个值，直接List.contains是O(n)逐一equals，数据量一大就慢。这时候就该用到HashSet：

Set<String> blackSet = new HashSet<>(blacklist); if (blackSet.contains(target)) { ... }

HashSet查找是O(1)级别，依赖的正是String的hashCode缓存。不过要小心，如果黑名单是动态变化的，频繁创建HashSet本身也有开销。另外一个相关优化思路是：对于很长的字符串，可以先比较hashCode再比较equals——因为如果hashCode不同，字符串一定不同。但注意不要依赖这个判断，因为hashCode可能碰撞，最终还是要equals兜底。

6. 字符串在JVM内存模型中的分布与线上排查经验

6.1 一个String对象到底占多少内存

很多人对"String对象多大"没有概念。以JDK 8为例，一个String对象内部有char[]的引用、int hash，对象头占12字节（开启压缩指针时），引用占4字节，int占4字节，加起来对象本身约24字节；char[]对象还有额外10字节左右的对象头和长度字段。存储一个英文字符串"hello"（5个字符），char[]占12（数组头）+ 5 * 2 = 22字节，对齐后24字节，加上String对象本身，总计接近48字节。对比存放这5个字符的原始数据只要5字节，可以看出String对象的内存放大效应很严重。这也是为什么大量String驻留在堆里时，内存会涨得飞快。

这里引出一个实际优化方案：如果内存特别紧张，而且字符串长度很短（比如IMEI、订单号、状态码），可以考虑用char[]或自定义轻量结构替代String，或者直接用String.intern()把重复值收敛。但如果字符串内容本身高度随机（如日志、traceID），intern反而会让内存更糟。

6.2 用MAT分析重复字符串导致的内存飙升

生产环境遇到堆内存居高不下，一个常见的元凶就是集合里堆积了大量内容相同但引用不同的String对象。排查工具我常用Eclipse MAT（Memory Analyzer）。具体步骤：

1. 导出堆转储文件jmap -dump:format=b,file=heap.bin <pid>。
2. 用MAT打开，进入"Java Basics" -> "String"视图，可以看到所有String对象的内容、个数和总大小。
3. 排序后如果发现某几个相同内容的字符串出现成千上万份，基本可以断定是缓存或集合没有去重。

这时候有两种解法，一是改代码用HashSet或Map替代List，二是对确有必要的重复字符串用intern()去重。但如果字符串基数本身就大，就要考虑数据是否分页加载合理、缓存是否设置了过期策略。我见过一个案例，网关把每台设备上报的完整报文都存到内存列表里，重复率极高，改成按设备ID聚合存储后，内存直接降了70%。

6.3 StringBuilder与String在JVM层面对GC的影响

String是典型的"创建快、消亡也快"的对象。大量短生命周期String对象会迅速填满新生代，触发频繁Minor GC。如果此时还有大量String被长生命周期对象引用（比如缓存、静态集合），它们会晋升到老年代，老年代占满就会Full GC，GC停顿时间陡增。

要想减少String对GC的压力，核心思路是降低创建量。高频路径上：优先使用StringBuilder而不是+；不要用split做高频解析，改为手写indexOf+substring；接收网络数据时直接解析字节流，避免new String再拆分。这些事情单看都是小优化，但在高并发系统里，每一毫秒的GC暂停都可能在峰值流量下被放大成雪崩。

6.4 不可变字符串在分布式锁与缓存Key设计中的应用

String不可变在分布式系统里也有实打实的价值。最典型的就是缓存Key。用StringBuilder拼出来的Key必须调用toString()生成一个不可变快照，才能安全地放入Redis客户端或本地缓存Map中。如果直接用StringBuilder当Key，后续任何append操作都会改变hashCode和equals的判定，缓存命中率立崩。所以很多框架的API设计里，缓存Key都强制要求String类型。

同理，synchronized锁对象如果是一个会变的内容，锁的意义就没了。实践中我见过有人把StringBuilder.toString()的结果当锁，但没有意识到每次toString都是新对象，导致锁完全不生效——不同线程拿的是不同锁对象。正确的做法是定义一个private static final String LOCK_KEY = "lock-xxx";这种常量，才能保证所有线程拿到的是同一个对象。

7. 高频面试题与常见八股文速查：这些题目背后考的是什么

7.1 字符串面试高频题清单与核心答案要点

面试官问String类相关的问题，通常不是考记忆，而是考你有没有真正理解底层机制。我整理了一份高频问题清单，附带核心答案要点，大家可以自己对照检测一下：

7.2 容易被追问的深水区：从答案到原理

面试官经常会顺着一个答案追问下去，考察你是不是真的懂。比如你说"String是不可变的"，他接着问"那StringBuilder为什么是可变的？你从源码层面说说它怎么实现可变"。这时候要能说出StringBuilder内部数组不final，append直接在数组上操作，容量不够再扩容。再比如你说"intern()能省内存"，他追问"什么时候用intern()会导致OOM"，这就是我在前面讲的高基数字符串滥用驻留的反面案例。

另一个高频追问是："为什么HashMap的key推荐用String？"这要从三个层面回答：String不可变保证hashCode稳定；String重写了equals和hashCode，语义正确；String的hashCode有缓存，性能好。如果换成可变对象当key，对象内容一变，hashCode就变，HashMap就找不到原来的value了——这是非常经典的坑。

7.3 从八股文到实战：面试题在生产环境的映射

背八股文最大的问题，是面试过了但代码还是写不好。实际上每一个String知识点都能映射到具体的代码场景：

• 理解了split("\\.")才知道解析配置文件时为什么IP地址切分要转义。
• 理解了不可变性才知道为什么方法参数传String，方法内怎么改都不会影响外部变量，但传StringBuilder就会——这个特性在写工具类、设计接口时非常关键。
• 理解了常量池才知道为什么==比较字符串在某些情况下是true、某些情况下是false，也才不会写出依赖==判断字符串相等的bug。
• 理解了StringBuilder的扩容机制，才明白为什么日志框架在初始化时要预估一个较大的容量。

我面试人的时候，最喜欢问的其实是："线上有一段日志解析代码，出现了内存持续增长，你怀疑是String相关的，排查思路是什么？"这个问题没有标准答案，考的就是你对字符串内存模型的理解深度。能答出"先看是不是有大量相同内容String在集合里累积，再看是不是intern()被滥用，然后用MAT看String对象分布"的人，基本能确认是有实战经验的。

7.4 再补充两道有意思的排列题

最后分享两道我收藏的题目，能顺便测出你对"字符串+常量池"的理解是不是成体系的。

第一道：

String s1 = "hello"; String s2 = "hello"; String s3 = new String("hello"); System.out.println(s1 == s2); // true，都是常量池同一个对象 System.out.println(s1 == s3); // false，s3是堆对象 System.out.println(s1.equals(s3)); // true，内容相同

第二道：

final String a = "a"; final String b = "b"; String c = "ab"; String d = a + b; // 编译期常量折叠，等价于"ab" String e = new String("a") + new String("b"); // 运行期生成新对象"ab" System.out.println(c == d); // true System.out.println(c == e); // false

注意第二道里a和b必须是final修饰的编译期常量，a + b才会在编译期直接算出"ab"。如果去掉final，它是两个变量，运行时就会走StringBuilder路径，c == d就变成false了。这个题目很能检验你对编译期、运行期两个阶段的理解是否清晰。

写在最后

我在实际项目中反复体会最深的一点是——String类绝不是"会用API就行"的基础设施，它的不可变性设计、常量池机制、编码与内存模型，直接影响着你写的每一行代码的性能和稳定性。很多线上诡异的问题，最后追根溯源都会落到"字符串的不当使用"上：可能是循环里用+拼接导致GC压力飙升，可能是split正则处理错了分隔符，也可能是错误地用intern()去重了不该驻留的随机字符串。建议你把这篇里提到的代码片段都自己跑一遍，遇到"为什么"的时候，打开IDEA点进String源码逐行看——源码是最好的老师，比任何博客都准确。下次再有人说String类很简单，你可以微笑着问他：那你说说new String("abc")到底创建了几个对象？