★ FEATURED ARTICLE 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是同步的方法加了synchronizedStringBuilder没有。单线程下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提供了码点相关的APIString 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)在业务代码里往往也是多余的如果参数是字面量或已经存在的Stringnew只会额外创建一个对象。现代JDK里几乎没有手动new String的必要。当然字节数组转字符串时肯定要new String(bytes, charset)那是另一个正确用途。优化不是炫技是让程序尽量少干活。记住这一点字符串相关的大部分性能问题都能避开。最后再分享一点个人体会处理字符串问题时先问自己三个问题——这个字符串是哪里来的我要比较的是值还是引用这段拼接会不会发生在循环里把这三个问题想清楚至少能避开一半的常见坑。字符串虽然基础但真正能把它用明白的人写出来的代码往往更稳也更省内存。
阅读完成 · 觉得有帮助？
