做了这么多年Java开发又带过不少新人面试过一堆候选人我有一个感受越来越强烈很多人写业务代码手到擒来一聊到字符串算法就开始露怯。字符串看起来不过就是一堆字符拼在一起可真到了比较、反转、统计、匹配、截取、排序的时候边界条件能把人整得怀疑人生。尤其近几年面试题越来越爱往字符串底层和算法上钻从length()和codePointCount()的区别到substring()到底会不会内存泄漏再到手写KMP、字符串排序——没点真功夫确实扛不住。这篇内容不打算给你堆概念而是从Java字符串的底层真相出发把我在实际项目和面试复盘里用到、踩到、考到的东西一次性讲透。包含可直接抄走的代码、每个关键选择背后的理由以及普通文档里不会写的坑。适合准备Java后端面试的同学也适合写业务代码时想避免低级性能问题的在职开发。1. 字符串在Java里的底层真相为什么char[]时代已经翻篇了1.1 不可变性不是设计洁癖是安全契约Java的String是不可变对象这个结论人人都背得出来但真正理解它为什么不可变的人没那么多。我在项目里见过不少人试图用反射去改String内部的值最后换来一堆诡异的并发问题和越权数据这就是典型的知道结论、不知道原因。String被设计成不可变首要原因是安全。它被广泛用作HashMap的key、网络连接地址、类名、文件路径如果字符串可变那么一个对象存进HashMap之后另一个线程悄悄改了它的hashCode所依赖的内容整个Map的查找逻辑就直接崩塌。同样一个带有权限信息的字符串变量被传进框架层框架层假设它不会在执行途中被篡改这种信任是建立在不可变性之上的。其次才是性能。不可变让字符串可以被安全地缓存和复用Java里那套字符串常量池体系依赖的就是同一个String对象永远不会变这个前提。如果可变池化之后随便改一下所有引用到它的地方全部遭殃。所以理解不可变性理解的重点不是改不了值而是正因为改不了值Java才敢做池化、做缓存、做安全假设。这个认知是后续理解字符串算法和性能优化的大前提。1.2 字符串常量池到底缓存了什么面试里最常问的那个问题String s1 abc; String s2 new String(abc); 两者相等吗这题的答案很简单一个true一个false但背后的池化机制值得展开。String s1 abc这行代码JVM会先看常量池里有没有值为abc的对象没有就在池里创建并返回引用。new String(abc)则是在堆里额外new一个对象哪怕常量池里已经有一个abc它也会重新创建。所以s1 s3比较的是引用s1指向池里的对象s3指向堆里的新对象结果必然是false。但要注意new String(abc)这个构造过程本身并不会把abc立即放进常量池它只是在堆上建了一个值相同的新对象。真正决定要不要进池的是intern()方法或者编译期的字面量。这引出一个我在代码评审里经常强调的点除非业务确实需要强制去重海量动态字符串否则不要主动调用intern()因为常量池是全局的池子塞满了会影响整个JVM运行时的性能。1.3 从JDK 8到JDK 17compact strings到底改了什么很多还在用JDK 8的老项目对字符串底层的认知停留在char[]数组存UTF-16编码。这个说法在JDK 9以后就不准确了。JDK 9引入了JEP 254叫Compact Strings。简单说String内部不再总是用两个字节的char来存而是根据实际内容选择存储编码如果字符串里的所有字符都能用Latin-1编码一个字节就能表示就用byte[]只占一个字节如果包含中文、emoji、其他非Latin-1字符才回退到两个字节的UTF-16表示。我记得刚升JDK 11那会儿线上有个业务缓存了大量纯英文短字符串平均长度不到20个字符改版之后内存占用肉眼可见地降了将近一半。这是因为每个字符从2字节变成1字节字符串对象本身的空间开销大幅缩水。这个细节在做内存调优或者回答JDK版本对字符串有什么影响这类问题时非常加分。不过也要注意Compact Strings带来的一个副作用是String.charAt(int index)这种老式按索引访问的方式在底层可能需要先判断当前字符串用的是哪种编码。好在JVM做了优化实际性能下降没那么夸张但我们在算法题里如果追求极致性能还是优先用原生的charAt不要为了优化而先把字符串toCharArray再操作——那反而会白拷一份数组。2. 高频字符串算法实务从比较、反转到字符统计2.1 判断相等、equals、Objects.equals到底差在哪字符串比较是我在评审时看到新人出错最多的地方。同一个接口里上游传下来的参数和数据库查出来的值明明肉眼看着一模一样用判断就是false。原因就是前面讲的池化和对象创建路径不同。三个手段的差异比较引用两个对象只要不是同一个一律false适合比较枚举、null、基本类型equals()比较内容但调用时如果左边对象为null会抛NullPointerExceptionObjects.equals(a, b)是JDK 7以后提供的安全比较先做null判断再做equals适合两个对象都可能为null的场景。我自己在写业务判断时的习惯是确定两边都非null用str1.equals(str2)不确定又有可能为null直接上Objects.equals代码更稳。如果要忽略大小写用equalsIgnoreCase但要注意它对locale敏感的场景会有边界问题比如土耳其语里的I和i转换规则和我们预期不同这种情况老老实实先转成小写再比较或者明确指定Locale。还有一个偏向底层的冷知识两个字符串内容完全一致hashCode()也一致但hashCode()相等不代表字符串相等。因为哈希必然会碰撞这个点在做字符串去重和布隆过滤器方案时需要想清楚。2.2 反转字符串从一行API到双指针原地逆序字符串反转是笔试里的常客。最简单的解法是用StringBuilder.reverse()一行代码String reversed new StringBuilder(input).reverse().toString();这个答案能过大多数场景但面试官往往紧接着会问如果要求不借助额外空间你怎么办这里就需要手写双指针交换public static String reverseByPointer(String s) { char[] chars s.toCharArray(); int left 0; int right chars.length - 1; while (left right) { char temp chars[left]; chars[left] chars[right]; chars[right] temp; left; right--; } return new String(chars); }注意一个现实问题toCharArray()和new String(chars)其实是拷贝了两次数组所以严格来说不借助额外空间在Java里做不到百分之百。面试官问这个问题考察的是算法思路而不是真的纠结于那两次拷贝你把复杂度分析说清楚就好。另外一个反转场景是I love Java反转成Java love I也就是单词级反转。正确做法是先整体反转变成avaJ evol I再把每个单词内部反转回来。我见过很多人直接按空格split再倒序遍历这在单词之间存在多个连续空格时会丢信息所以先整体反转再逐词反转的处理方式更稳。2.3 字符统计与判断字符串包含中文的标准写法字符统计是字符串算法的基础款统计每个字符出现次数。主流做法有两种用HashMapCharacter, Integer记录或者用int[128]/int[65536]数组计数。字符串长度短、字符范围可控时数组计数性能远好于HashMap字符集不确定时HashMap更通用。public static MapCharacter, Integer countChars(String s) { MapCharacter, Integer map new HashMap(); for (char c : s.toCharArray()) { map.merge(c, 1, Integer::sum); } return map; }热搜词里有判断字符串含有汉字这个需求实际场景中比如用户昵称校验、日志清洗都需要判断是否包含中文字符。最直接的方式是正则public static boolean containsChinese(String s) { return s.matches(.*[\\u4e00-\\u9fa5].*); }\u4e00-\u9fa5是Unicode里CJK统一汉字区间的常用写法。但要注意这个范围不包含扩展B区甚至C区的生僻字如果业务涉及生僻人名可能需要扩大范围到\u20000-\u2A6DF等区段那就不能靠一个简单的正则片段解决了得引入专门的Unicode判断工具库。另外正则里的matches()要求整个字符串匹配所以我在前后加了.*表示只要中间有汉字就算这个细节容易漏。字符串转数字也是高频操作具体到代码上要区分Integer.parseInt和Integer.valueOfparseInt(123)返回int基本类型valueOf(123)返回Integer对象并且在-128到127之间会走缓存同一个对象反复valueOf时引用相等。做转换前先想清楚边界空字符串、非法格式、超出Integer范围这些都要提前处理。我个人更推荐先写一个封装方法内部用正则白名单校验再加try-catch兜底避免业务代码里到处散落try-catch。3. 字符串匹配与排序笔试和业务里都绕不开的两类问题3.1 从暴力匹配到KMP手写indexOf的完整思路字符串匹配在Java里最常用的其实是String.indexOf()源码就是比较朴素的暴力匹配只是做了一些首字符快速筛选的优化。但面试为了考算法功底经常让人手写匹配逻辑甚至直接上KMP。暴力匹配的思路很直白主串从第i个位置开始模式串从第0个位置开始逐一比对不匹配就主串回到i1、模式串清零再比。时间复杂度最坏O(n*m)。KMP的核心优化是当某一轮比较失败时模式串不一定从头再来而是利用已经算好的next数组跳到前面某个合理的位置。next数组的意义是模式串当前失配位置之前最长的相同前后缀长度。比如模式串ababc当匹配到最后一个c失配时前面的abab里最长相同前后缀是ab长度为2那么模式串下次可以直接从下标2继续匹配主串指针不回退。下面是我手写过的KMP参考实现public static int kmpIndexOf(String text, String pattern) { if (pattern.isEmpty()) return 0; int[] next buildNext(pattern); int i 0, j 0; while (i text.length() j pattern.length()) { if (j -1 || text.charAt(i) pattern.charAt(j)) { i; j; } else { j next[j]; } } return j pattern.length() ? i - j : -1; } private static int[] buildNext(String pattern) { int[] next new int[pattern.length()]; next[0] -1; int i 0, j -1; while (i pattern.length() - 1) { if (j -1 || pattern.charAt(i) pattern.charAt(j)) { i; j; next[i] j; } else { j next[j]; } } return next; }这里有个我当初学习时卡了很久的点next数组里为什么会有-1因为当第一个字符就失配时我们要让主串指针前进同时模式串仍在开头用-1作为特殊标志让循环里的j -1分支生效。这个细节不写代码很难体会理解了它KMP才算真的吃透。不过要提醒一句KMP不是万能的。在实际工程里短文本匹配、频繁构造next数组的场景下KMP的预处理成本反而可能超过暴力匹配。Java源码在indexOf里选择朴素匹配是有道理的因为绝大多数业务字符串很短简单实现的局部性好、开销低。算法选型永远要结合实际数据规模这是我在代码评审里反复强调的原则。3.2 字符串排序字典序、长度排序与多关键字排序热搜词里出现了字符串排序这词看着简单实际有很多层。第一层是字典序也就是Unicode码点顺序。Java的String.compareTo()实现的就是这个逻辑两个字符串从头开始逐字符比较char值遇到第一个不相等的字符就返回差值短的字符串在长的字符串之前。可以用Arrays.sort(String[])直接获得字典序排序。第二层是自定义规则的排序。比如按长度排序短的在前长度相等再按字典序Arrays.sort(array, Comparator.comparingInt(String::length) .thenComparing(String::compareTo));第三层是更真实业务里会遇到的场景多关键字排序。比如一组文件名要求先按前缀数字排再按后缀版本排。这时候string自身字典序不满足需求得把每个部分拆出来用Comparator组合多个比较器。拆分时如果用split要注意正则里.和|这类字符要转义。我在实际做日志文件聚合时遇到过这样一个案例文件名是20241101_001.log20241101_002.log直接用字典序排序结果完全正确因为日期和序号都是定长零填充的但后来业务加了不带零填充的序号后字典序就排错了10会排在9前面。这就引出一个很多人没注意的原则字符串排序的结果强烈依赖数据格式。如果你能控制数据格式最好把数值部分做零填充否则就得拆字段用数值比较器。4. 面试与实际开发里最常踩的字符串陷阱4.1 截取子串的内存故事substring到底还泄不泄漏这是个老生常谈但依然很多人答不透的问题。JDK 6及以前String内部除了char数组还有个offset和count字段substring()不会复制字符而是直接复用原字符串内部的char数组只是把偏移和长度改一下。好处是快坏处是只要子串还在被引用整个父串的大数组就永远无法回收。典型的线上事故场景你从一个几MB的大日志字符串里截取了前面20个字符的token然后把这20个字符往缓存里一放底层那几MB的char数组就被一起托底了。一次两次无所谓量大了内存直接被拖垮。JDK 7以后这个问题被修复substring()会真正复制出一个新数组截取出来的子串不再持有父串的引用。所以现在面试如果问Java的substring会不会内存泄漏答案要分版本说清楚。但在实际开发里另一个问题又冒出来了频繁调用substring()产生大量短生命周期对象对GC压力很大。我的建议是如果循环里大量截取字符串且能明确截取位置尽量用slicing思路一次性截取并复用或者直接操作原始char数组范围读取避免反复生成新对象。4.2 split、replaceAll与正则表达式方便背后的隐性成本很多人在项目里把split当万能工具用但没意识到它参数是正则表达式。最容易翻车的是按点号分割IP字符串192.168.1.1.split(.)结果返回空数组。因为.在正则里匹配任意字符要写成split(\\.)。类似的还有按竖线分割a|b|c.split(|)竖线在正则里是或运算符结果被拆成单个字符按美元符号分割price$100.split(\\$)也需要转义。这些坑我几乎每隔一段时间就能在代码评审里碰到一次。比转义更要命的是性能问题。String.split()内部每次调用都会编译正则表达式如果这段代码在循环里执行开销会被放大。replaceAll同理第一参数也是正则。高频路径上我会优先用indexOf加substring手写分割或者用StringTokenizer处理简单分隔符。朴素字符串处理的性能通常会好很多。另外一个常用但容易误解的是String.format和模板字符串。很多人觉得format就是做字符串拼装的用起来方便但它在内部走的是Formatter对性能敏感的热点路径来说并不友好。如果只是简单拼接直接字符串加法或者StringBuilder更可控。4.3 字符串长度不是你想的那个长度字符串长度这个热搜词背后藏着一道很经典的面试题.length()到底等于多少答案不是1是2。因为emoji字符在Java里是以代理对形式存在的两个char才能表示一个完整Unicode码点。String.length()返回的是char数量也就是UTF-16编码单元数量。真正表示用户感知的字符个数要用codePointCount()String s ab; System.out.println(s.length()); // 4 System.out.println(s.codePointCount(0, s.length())); // 3做文本截断校验、数据库字段长度校验时这个问题非常现实。我做过一个短信模板系统用户输入内容里带emoji后端限制140个字符用的length()算结果一条短信内容显示被截了一半剩下半个emoji变成乱码。后来统一改成codePointCount问题才解决。类似的还有反转字符串时普通char数组反转会把代理对拆开。要做完整字符反转需要先按码点拆分再逆序拼接public static String reverseUnicode(String input) { return input.codePoints() .mapToObj(c - new String(Character.toChars(c))) .collect(Collectors.collectingAndThen( Collectors.toList(), list - { Collections.reverse(list); return String.join(, list); })); }这个细节可能日常用不上但一旦接触国际化和emoji场景就能体现你到底有没有真正理解字符串的编码模型。5. 性能优化与工程落地一万次拼接背后的取舍5.1 字符串拼接工具到底该怎么选拼字符串是Java开发里最频繁的操作之一。常规做法三种、StringBuilder、StringBuffer。选型的逻辑并不复杂StringBuffer是线程安全的但内部方法加了synchronized单线程下没必要用StringBuilder单线程首选性能最好在JDK 8以后编译器会优化成StringBuilder.append但是有前提的如果在同一个表达式里拼接编译器会生成一次StringBuilder创建和多次append很合理如果在循环里反复str item每次循环都会new一个StringBuilder性能就崩了。我写过一段很典型的反例代码循环10000次拼接SQL values结果接口耗时从50ms飙到800ms。改成循环外创建StringBuilder循环内只append耗时直接回落。代码评审的标准项之一就是循环内不得做字符串拼接宁可多写几行也不要图省事。还有一个小技巧预估长度时给StringBuilder初始容量。默认容量16拼接超过后会触发数组扩容和拷贝。如果知道最终字符串大概长度直接new StringBuilder(256)能减少无谓扩容。细节看起来微小在高频调用场景里积少成多。5.2 intern的正确打开方式与滥用代价前文提过intern()这里展开说一下什么时候该用、什么时候别碰。合理场景系统里有大量重复出现的有限集合字符串比如状态码枚举值、成功失败这样的固定文案、或者从配置文件里反复读取的固定key。用intern()让所有相同字符串共享同一份常量池对象可以显著减少内存占用。滥用场景对用户输入、随机生成内容、各种动态报文做intern()。这些字符串的值集合无限大intern()会把每一个都塞进常量池。常量池在JDK 7以后移到了堆里塞满了会触发GC压力甚至造成堆内存无法回收——因为intern的字符串是强引用在池里。我见过有同学对日志内容做intern去重跑了一天频繁FullGC最后排查出来就是池子被日志塞爆了。所以结论很清晰数据值域有限、重复率极高才考虑intern数据值域不可控千万别碰。5.3 真实业务里的字符串算法落地思路最后聊点实际的把上面这些知识串起来。做敏感信息脱敏时比如手机号只保留前3后4很多人用substring截三截再拼其实StringBuilderreplace更高效。做关键词过滤时如果用contains逐个关键词轮询关键词多了性能线性增长更好的方案是先把所有关键词构造成Trie树或者Aho-Corasick自动机一次扫描完成多模式匹配。这个思路和KMP一脉相承都是尽量复用已经做过的比较只是多模式场景把单模式串换成了字典树。做CSV解析时字段里可能带逗号和引号split(,)分分钟解析错。正确做法是手写一个状态机解析器逐字符遍历区分引号内和引号外的逗号。这个场景我碰过不止一次每次都庆幸自己当年认真研究过字符串状态机的处理逻辑不然线上数据分分钟错位。字符串算法看着基础但在底层性能优化、数据清洗、协议解析、敏感信息处理等场景里它才是真正的主角。这也是为什么我一直建议团队里的年轻开发别只顾着学各种框架把字符串这一层的知识打扎实很多疑难问题会豁然开朗。我个人在实际项目里最大的体会是字符串操作没有银弹任何一门技术选型都要回到数据特征和调用频率上做判断。掌握底层原理的好处是看到一行代码你能马上想到它的内存开销和时间复杂度而不是等线上出了问题再去优化。建议你把自己项目里所有用split、substring、拼接的地方翻出来过一遍很可能会有意外的性能收益。
