Java字符串，谁没写过几行？可面试题里最刁钻的角落，往往也藏在String里。你也许被问过“new String("abc")到底创建了几个对象”，也许被split(".")坑到怀疑人生，或者在线上看到过莫名奇妙的内存飙升。字符串背后不是简单的字符数组，而是一整套常量池、不可变性、编码和正则的规则。这篇总结不聊空洞八股，只聊我在真实代码里遇到过、验证过、并且能直接用在生产环境的知识。
如果你刚开始学Java，建议从头看，常量池和比较这两节一定要吃透；如果你已经写了几年，重点看substring和split那两节，它们能解释不少平时说不清的诡异Bug。下面进入正题。
1. String为什么设计成final：常量池、缓存与安全
不少人觉得String设计成final只是为了“安全”，但这个安全具体指什么，很多人说不清楚。final修饰类，真正防的是有人写出String的子类，然后偷偷改变equals、hashCode这些核心行为。String一旦可被继承，常量池的引用复用就会变成灾难：你拿到的“abc”可能是一个子类实例，equals逻辑变了，hashCode也变了，HashMap直接乱套。这种风险不是理论上的，而是Java设计者明确要规避的路径。
1.1 字面量与常量池的实际流程
当JVM加载包含字符串字面量的类时，会去字符串常量池（StringTable）里找有没有相同内容的字符串。常见的JVM实现里，StringTable本质是一个哈希表。如果找到了相同Unicode序列的字符串，就直接复用这个引用；如果没找到，就在堆里创建一个新的String对象，再把它的引用放进StringTable。注意，放进常量池的字符串对象本身在堆上，池里保存的是引用。很多人以为字符串常量池里的对象都在“方法区”，这其实是个过时的误会。
而new String("abc")这条语句更复杂。参数"abc"本身是字面量，在编译期已经入池；new关键字则无论如何都再创建一个新的堆对象。所以一句话概括：一个来自池，一个是堆上新对象。这也是“创建了几个对象”的经典答案为什么通常是两个——池里的字面量对象，以及new出来的堆对象。
1.2 不可变带来的三件免费礼物
第一件礼物是hashCode缓存。String内部有一个private int hash字段，第一次调用hashCode()时才会计算并赋值，之后直接返回缓存，不需要每次都遍历字符数组。HashMap敢把String当默认key，就是因为它的hashCode稳定，equals也被严格定义。如果String可变，key一旦被修改，桶的位置就错了，hashCode缓存也要跟着失效，整个散列结构都会失去可靠性。
第二件礼物是线程安全。不可变对象天然可以共享，多个线程同时读同一个String，不存在一个线程写坏另一个线程数据的可能。日志系统、参数传递、全局配置里到处是String，这个特性帮了大忙。
第三件礼物是安全审查。类名、文件路径、远程地址这些敏感场景经常用String传递，一个方法拿到String之后只能读不能改，调用者可以放心把它交给不可信的代码。当然，这种安全感还要排除反射暴力修改的极端情况，但正常代码里它就是成立的。不可变也有代价：每次修改内容都会产生新对象，后面讲拼接性能时你会看到这个代价有多明显。
1.3 JDK 9之后String的内存布局变化
JDK 8及以前，String内部是char[] value，每个char占2字节。如果你大量使用只有英文字母和数字的字符串，每个字符的高字节都是0，内存白白浪费一半。JDK 9引入了Compact Strings，默认开启，内部改用byte[] value，并增加一个coder字段，用0表示LATIN1编码（每字符1字节），用1表示UTF16编码（每字符2字节）。这是一个完全透明的优化：业务代码不用改，内存占用却可能明显下降。
了解这个变化有什么用处？排查堆内存时，如果看到String对象的字符数组类型和旧版本对不上，不要慌，这是版本特性。如果你用反射直接读取String.value字段，也一定要根据JDK版本调整处理逻辑，JDK 9之后拿到的是byte[]不是char[]。另外，substring之类操作的底层复制量也会受coder影响，不同版本的表现差异，恰恰说明为什么分析问题时要先确认JDK版本。
2. 字符串比较：==、equals与intern的真实边界
字符串比较是Java里翻车率最高的操作之一。很多人知道要用equals，但说不清为什么，更说不清==偶尔对、偶尔错的原因。这一章把边界拆开讲透。
2.1 业务值比较永远用equals
铁律只有一条：如果比较的是业务内容，一律用equals，不要用==。String.equals()的逻辑并不复杂：先比较引用，引用相同直接返回true；然后判断对方是不是String，不是就返回false；最后逐字符比较内容。它不要求两个引用来自同一个池，只要求字符序列一致。
那为什么有人会掉进==的坑？因为字面量场景下==恰好是true，产生“这样也能用”的错觉。比如：
String a = "hello"; String b = "hello"; System.out.println(a == b); // true，两个变量指向常量池同一个对象但同一套代码换到new String("hello")、从数据库读取、从配置文件加载的数据，==就可能变成false。这种Bug最坑的是本地跑得好好的，一到生产环境就偶发，因为数据来源变了。
2.2 编译期折叠与运行期创建
字符串字面量的拼接会被编译器在编译期直接折叠。比如String s = "a" + "b" + "c";，javac会直接把它优化成"abc"，这个结果依然进入常量池。但一旦表达式里有变量，折叠就失效了：
String s1 = "a"; String s2 = "ab"; // 常量池中的"ab" String s3 = s1 + "b"; // 运行期新对象 System.out.println(s2 == s3); // falses3在运行期是new StringBuilder(s1).append("b")拼出来的新对象，和常量池里的"ab"没有任何引用关系。这个特性曾经在日志比较里坑过我：两个变量打印出来都是同一个值，if (x == y)却走进else分支，查了半天才发现一处来自配置、一处来自字面量。从那以后，我只要看到字符串用==比较，第一反应就是先改成equals。
2.3 intern方法：什么时候该用，什么时候别碰
String.intern()的作用是：如果常量池里已经有相同内容的字符串，就返回池里的引用；如果没有，就把当前字符串内容放入池中并返回池里的引用。它给了你一个主动“回归常量池”的机会：
String direct = new String("java").intern(); String literal = "java"; System.out.println(direct == literal); // true但intern的代价不是零。字符串池是一个哈希表，插入可能触发扩容，哈希冲突多的时候性能会明显下降。此外，池里的字符串被StringTable强引用，GC回收条件比普通对象苛刻得多。JDK 7之后interned字符串虽然跟随堆GC，但大量intern仍然可能导致堆内存上涨。
至于什么时候用？数量可控、重复度极高的固定值，比如枚举类状态名、错误码，用intern可以省内存。什么时候别碰？用户输入、随机生成、大文本，这些内容几乎不会重复，intern只会把StringTable越撑越大。
2.4 不同JDK版本下intern的行为差异
JDK 6及之前，interned字符串放在永久代，永久代有大小限制，intern太多会直接抛出OutOfMemoryError: PermGen space。JDK 7开始，字符串常量池被移到堆，interned字符串可以被GC回收，永久代OOM风险消失了，但堆内存压力还在。JDK 8彻底移除永久代，Metaspace不再保存字符串池，行为与JDK 7基本一致。
这些差异不是考古知识。如果你在维护老项目，从JDK 6往上升级时，原本常见的字符串类OOM可能自动消失；反过来，如果在JDK 8上无节制intern，堆里会出现大量重复的byte[]，用堆转储一看便知。理解版本演进，排查线上问题会快很多。
3. 字符串拼接：+、StringBuilder与StringBuffer的真正取舍
“别用+拼接字符串，要用StringBuilder”，这句话在网上被传了太多年，以至于很多人产生了条件反射。但真相是：编译器早就对+做了局部优化，一棍子打死并不公平。
3.1 编译器的局部优化不是免死金牌
对于单表达式里的字符串相加，javac通常会把代码改写成StringBuilder的连续append。例如：
String a = "A"; String b = "B"; String result = a + b + "C";编译后大致等价于：
String result = new StringBuilder(a).append(b).append("C").toString();所以如果只是书写上的一次性拼接，用+和手写StringBuilder差异很小，使用+反而更清晰。注意这里的“一次性”，说的是一个表达式内部。一旦拼接发生在循环里，情况就完全不同了。
3.2 循环拼接的O(n²)是怎么来的
String不可变的本质决定了，每次result += item都必须创建一个新字符串对象，再把旧内容和新内容都复制进去。循环到第n次时，已经复制了近n个字符，累计复制量大约是n²/2，所以整体复杂度是二次方级。
我自己测试过：循环10万次向一个初始空字符串追加短字符，用+=耗时能到几百毫秒甚至更多，改成StringBuilder后只有几毫秒到十几毫秒。字符串越长，差距越恐怖，几十倍很常见。
所以建议很明确：能在一行里写完毕的拼接待用+，没有关系；循环里的拼接一定先new StringBuilder()，然后append。不要拿“编译器会优化”当借口在循环里肆无忌惮地用+=，编译器救不了跨迭代的累积复制。
3.3 StringBuffer在真实多线程场景中的地位
StringBuffer是同步的，方法加了synchronized，StringBuilder没有。单线程下StringBuffer有锁开销，性能不如StringBuilder。那多线程下是不是就应该用StringBuffer？
答案没这么简单。多个线程同时向同一个StringBuffer追加，得到的只是“内部数组不会坏”的结果，追加顺序完全不可控。如果业务对顺序有要求，比如你想让线程A的日志先写入、线程B的日志后写入，StringBuffer解决不了，需要自行加锁或用其他并发结构。如果顺序无所谓，StringBuffer确能避免并发写坏数据。但在绝大多数业务代码里，拼接用的都是方法内的局部变量，天然线程私有，直接用StringBuilder即可，完全没必要为“可能的并发”付出锁开销。
4. 高频API的隐藏行为：substring、split、replaceAll中的历史坑
这些API每个业务项目都会用到，但它们的“隐藏规则”总能在不经意间坑你一下。我把实战里最常见的几个坑集中讲一下。
4.1 substring在JDK 6里的内存泄漏与JDK 7的改版
JDK 6及以前，String内部由char[] value、offset和count三个字段组成。substring不会复制字符数组，而是直接复用原始字符串的char[]，只是把offset和count调整到截取位置。这样截出来的子串很小，但它会一直持有父字符串的整个char[]引用。如果你从一个几十MB的日志文本里截取出几KB内容并长期保存，那几十MB的char[]就始终无法被GC回收。
JDK 7之后改了设计，substring会复制出一份新的字符数组，不再持有原始数组，以空间换时间，杜绝了这类内存泄漏。这也意味着每次substring都伴随一次数组复制。如果对同一个大字符串做几千次截取，复制成本也不能忽略。现在的代码基本不用担心substring内存泄漏，但看老项目的内存问题时要能联想到这个版本差异。
4.2 split的正则参数：点号为什么总让人翻车
split接收的是正则表达式，不是普通分隔符。最经典的坑就是：
"a.b.c".split("."); // 结果不是["a","b","c"]，而是空数组因为正则里的.是通配符，匹配任意字符，整个字符串被切得面目全非。正确写法是split("\\.")或split(Pattern.quote("."))。
竖线|同理，它是正则里的“或”运算符，直接split("|")会把每个字符都拆开，要用split("\\|")。$、^、方括号等元字符都需要转义。我的习惯是：如果分隔符是固定字符，直接写转义后的字面量；如果分隔符来自用户输入，就用Pattern.quote()包一层，否则用户输入一个点或竖线，整个拆分就炸了。
另外split还有一个容易被忽略的行为：默认情况下末尾的空字符串会被丢弃。比如"a,b,".split(",")返回的是["a","b"]，如果你希望保留末尾空串，要使用split(",", -1)。
4.3 replace与replaceAll：一个正则引发的意外
replaceAll(String regex, String replacement)的两个参数，一个按正则解析，一个按替换模板解析。它和replace(CharSequence, CharSequence)有本质区别，后者完全是字面量替换。看这个例子：
"a.b.c".replace(".", "_"); // "a_b_c" "a.b.c".replaceAll(".", "_"); // "_______"，每个字符都被替换所以如果只是替换固定字符，优先用replace。如果确定要用replaceAll，正则里的元字符务必转义。
更隐蔽的是replacement参数里的$和\。在replaceAll或replaceFirst中，replacement里的$1会被当成捕获组引用，如果用户输入的内容里恰好有$5，替换时可能直接抛出IllegalArgumentException，或者结果完全不是预期。最稳妥的做法是用Matcher.quoteReplacement()包装一下替换内容，让所有特殊字符都变成普通文本。
5. 编码视角下的字符串长度：length()不等于字符数
中文场景下，字符串长度问题比英文世界更容易踩坑。不是编码变复杂了，而是很多人根本没意识到Java的String内部存的是UTF-16。
5.1 String内部到底存的是什么
Java的char是一个16位无符号整数，String内部按UTF-16编码保存字符序列。Unicode字符集远不止65535个字符，基本多语言平面（BMP）之外的字符，比如emoji和大量生僻汉字，需要用两个char组成一个“代理对”来表示。因此"😀".length()返回的是2，不是1。
这个现象在截断、校验、数据库字段长度控制时特别容易出问题。用户输入一个包含emoji的字符串，按length()判断是否超过20个字符，可能他明明只输入了18个“字”，却被判成超长。反过来，如果按照length()去数据库里截字段，很可能把一个完整emoji劈成两半，存进去变成乱码。
5.2 按用户感知的字符数处理字符串
如果业务上需要统计或截取“用户看到的字符”，就不能直接用length()和substring()，因为它们都按UTF-16代码单元操作。Java提供了码点相关的API：
String s = "Hello😀"; System.out.println(s.length()); // 6，最后两个char是代理对 System.out.println(s.codePointCount(0, s.length())); // 5，按码点计如果要按码点截取，可以先offsetByCodePoints(0, n)得到对应的char下标，再substring，这样就不会劈开代理对。对包含emoji和生僻字的字符串，这招能避免很多乱码。
不过严谨地说，码点还不是用户感知的“字素数”。像带音调的字母，可能由基础字母和组合变音标记组成，Java标准库没有直接提供按字素簇（grapheme cluster）切分的能力。普通业务用codePointCount基本够用，至少不会把emoji劈开；如果要做文本编辑器那种级别的处理，就需要引入第三方断字库了。
5.3 文件读取与编码乱码的常见来源
字符串的本质是char序列，而与外部交互时都是字节序列，中间的桥梁必须指定字符集。常见错误是用FileReader直接读文本却不指定编码，它默认使用平台编码。开发机和服务器系统不同，同样的代码读同一个文件，一个正常一个乱码。
建议用Files.readAllBytes配合new String(bytes, StandardCharsets.UTF_8)，或者直接Files.readString(Path, StandardCharsets.UTF_8)。写文件同理。如果历史数据是GBK编码，不能硬按UTF-8解码，否则要么乱码要么抛异常。项目里最好统一约定“读写字符串必须显式指定字符集”，这条规矩能省下大量排查乱码的时间。
6. 字符串性能优化：池、复用与内存观测
聊完特征和API，最后落到性能。字符串优化不是炫技，核心是让JVM少创建对象、少复制数据。但具体怎么做，不能拍脑袋。
6.1 先量化再优化，别被直觉带偏
很多性能建议听起来头头是道，实际收益可能很小。与其凭感觉用intern或疯狂换API，不如先用数据定位问题。遇到内存或GC压力大，我会用JFR的分配分析或堆转储工具看对象占据Top，字符串相关的异常占用通常表现为char[]或byte[]数量巨大，来源不外乎HashMap的key、日志消息、HTTP报文、JSON序列化等。
一个非常常见的优化是日志拼接：logger.debug("user " + userId + " login")，即使在debug级别关闭时也会执行字符串拼接，产生临时对象。正确做法是使用日志框架的占位符，比如logger.debug("user {} login", userId)，由框架决定是否格式化。这个优化效果立竿见影，而且基本不用动业务逻辑。
6.2 固定值复用与序列化缓存
状态码、错误消息模板这类固定字符串，能定义成常量就定义成常量，避免同一个字面量在代码里被重复创建。这里要特别提醒：常量池只对字面量和intern生效，如果你从配置文件读入一批固定文本，JVM不会自动帮你复用，需要自己设计容器缓存。
JSON序列化场景也值得注意：同一个对象反复序列化，每次toJSONString都可能产生大量新的字符串对象。如果数据更新不频繁，可以缓存序列化结果，或者使用带缓存机制的序列化方案。优化前最好用堆转储确认这部分确实是瓶颈，否则可能折腾半天，GC曲线纹丝不动。
6.3 少做无意义的包装和转换
有一种反模式很常见：在循环里把基本类型先转成String，拼到缓冲区里，最后又解析回数值。比如用Integer.toString(i)拼日志，再Integer.parseInt读回来。每一步都产生新对象，纯属浪费。遇到这种情况，应该直接在数值层面处理，或者把数值存到专门的集合里。
另外，new String("xxx")在业务代码里往往也是多余的：如果参数是字面量或已经存在的String，new只会额外创建一个对象。现代JDK里几乎没有手动new String的必要。当然，字节数组转字符串时肯定要new String(bytes, charset)，那是另一个正确用途。优化不是炫技，是让程序尽量少干活。记住这一点，字符串相关的大部分性能问题都能避开。
最后再分享一点个人体会：处理字符串问题时，先问自己三个问题——这个字符串是哪里来的？我要比较的是值还是引用？这段拼接会不会发生在循环里？把这三个问题想清楚，至少能避开一半的常见坑。字符串虽然基础，但真正能把它用明白的人，写出来的代码往往更稳，也更省内存。
