1. 从一个诡异的空指针说起为什么String值得单独拎出来讲刚入行那会儿我遇到过一个至今印象深刻的Bug。一个看似简单的字符串比较代码逻辑上完全说得通但运行结果就是不对。排查了大半天最后发现问题出在和equals的区别上。那一刻我才意识到String这个类远没有表面看起来那么简单。String是Java中使用频率最高的类没有之一。你写下的每一行代码几乎都离不开它。但恰恰因为它太常见、太基础很多人对它的理解停留在“能声明字符串、能拼接、能比较”这个层面。一旦遇到性能问题、内存问题、编码问题就抓瞎了。这篇文章想做的事情很明确把String这个类从里到外讲透。不管你是刚学Java的新手还是写了几年代码但没系统梳理过String的老手都能从中找到有价值的东西。我会从底层实现讲起把常量池、不可变性、字符串拼接的真相、常见API的坑、性能优化手段这些内容全部串起来。读完你至少能搞清楚三件事String对象到底怎么存的、为什么有些写法性能差得离谱、以及在实际项目里怎么用对String。先抛一个结论String是Java里被设计得最精巧的类之一但也是最容易被误用的类之一。精巧在于它用不可变性和常量池解决了大量问题容易被误用则是因为它的API太“顺手”了顺手到很多人根本不去想背后的代价。2. String的底层结构从char数组到字节数组的演进2.1 不可变性到底意味着什么String被设计成不可变类这是理解一切String行为的起点。所谓不可变就是一旦一个String对象被创建它内部存储的字符序列就再也不能被修改。你调用的所有看似“修改”字符串的方法比如substring、replace、toUpperCase实际上都是返回了一个全新的String对象原来的对象纹丝不动。为什么Java要把String设计成不可变的这个问题值得认真想一想。我总结下来主要有这么几个原因第一线程安全。不可变对象天然就是线程安全的多个线程同时读取一个String对象不需要任何同步措施。这在并发场景下省了太多事。第二支持常量池。只有不可变的对象才能安全地被多个引用共享。如果String可变那常量池里同一个字符串被两个变量引用一个改了另一个也跟着变整个语言体系就乱套了。第三缓存哈希值。String的hashCode可以被缓存因为内容永远不会变。这让String作为HashMap的键时效率极高。第四安全性。字符串经常被用来传递敏感信息比如文件路径、网络连接地址、类名等。如果可变就可能被恶意篡改。理解不可变性的一个关键是不可变的是String对象本身而不是引用它的变量。下面这段代码经常让新手困惑String s hello; s s world;看起来像是把hello改成了hello world但实际上内存里现在有两个String对象原来的hello和新的hello world。变量s只是重新指向了新的对象而已。原来的hello如果没有任何其他引用就会被垃圾回收。2.2 从char[]到byte[]JDK 9的压缩字符串优化在JDK 8及之前String内部是用char[]来存储字符的。Java的char是16位的也就是说每个字符不管实际需要几个字节都占2个字节。对于大量使用拉丁字母的场景这造成了严重的内存浪费——一个只包含ASCII字符的字符串一半的空间都白占了。JDK 9引入了Compact Strings压缩字符串特性把底层存储从char[]改成了byte[]同时增加了一个coder字段来标识编码方式。如果字符串内容全部是Latin-1范围内的字符也就是每个字符用一个字节就能表示就用单字节存储否则用UTF-16双字节存储。这个改动带来的内存节省非常可观。根据官方数据在实际应用中String对象的内存占用平均减少了约20%到30%。对于堆内存紧张的应用来说这个优化是实打实的。不过要注意这个变化对开发者是透明的。你写代码的方式不需要任何改变charAt、length这些方法的语义也完全一致。但如果你用反射去直接操作String内部的value字段那就要注意类型已经从char[]变成byte[]了。2.3 字符串常量池同一个字符串为什么只存一份字符串常量池是JVM为了提升性能和减少内存开销专门设计的一块区域。它的核心思想很简单相同的字符串字面量只存一份。当你写下String a hello时JVM会先去常量池里找有没有hello这个字符串。有的话直接把引用给你没有就创建一个放进去。所以下面这段代码的结果是trueString a hello; String b hello; System.out.println(a b); // true但如果你用new String(hello)情况就不一样了。new关键字强制在堆上创建一个新的对象不管常量池里有没有。所以String a hello; String b new String(hello); System.out.println(a b); // false System.out.println(a.equals(b)); // true这里就引出了一个经典问题比较的是引用地址equals比较的是内容。对于String来说几乎永远应该用equals来比较内容。我见过太多人在这上面栽跟头。关于常量池的位置JDK 7是一个分水岭。JDK 7之前常量池在方法区永久代里JDK 7及之后常量池被移到了堆内存中。这个变化带来的直接影响是常量池里的字符串也可以被垃圾回收了。在JDK 7之前如果大量使用intern()方法很容易导致永久代溢出。intern()方法值得单独说一下。它的作用是如果常量池里已经有内容相同的字符串就返回池中那个对象的引用如果没有就把当前字符串放入池中再返回引用。这个方法在特定场景下可以大幅减少重复字符串的内存占用但滥用的话反而会增加常量池的负担。3. 字符串拼接的真相为什么你的代码慢得离谱3.1 用“”拼接在循环里发生了什么字符串拼接是日常开发中最常见的操作之一。很多人习惯直接用号拼接简单直观。但如果在循环里用拼接性能会差到让你怀疑人生。先看一段典型的“反面教材”String result ; for (int i 0; i 10000; i) { result i; }这段代码看起来没什么问题但实际执行时每次循环都会创建一个新的StringBuilder对象编译器会把优化成StringBuilder的append和toString然后调用toString生成一个新的String对象。10000次循环就是10000个StringBuilder和10000个String对象。内存分配和垃圾回收的压力非常大。编译器对字符串拼接的优化其实比很多人想象的要聪明。对于简单的a b c这种字面量拼接编译器会直接在编译期合并成abc运行时没有任何额外开销。但对于包含变量的拼接编译器会转换成StringBuilder的链式调用。问题在于这个优化只在单条语句内有效。一旦拼接跨越了循环的边界每次循环都会重新创建StringBuilder。3.2 StringBuilder和StringBuffer怎么选StringBuilder和StringBuffer都是可变的字符序列区别在于StringBuffer的方法是线程安全的加了synchronized而StringBuilder不是。选择逻辑很简单单线程环境下用StringBuilder多线程共享同一个可变字符串时才考虑StringBuffer。实际项目中绝大多数字符串拼接场景都是单线程的所以StringBuilder是更常见的选择。StringBuffer因为同步开销性能比StringBuilder差不少。用StringBuilder改写上面的循环StringBuilder sb new StringBuilder(); for (int i 0; i 10000; i) { sb.append(i); } String result sb.toString();这段代码只创建了一个StringBuilder对象和一个最终的String对象性能提升是数量级的。我实测过在百万级循环下StringBuilder比直接用拼接快几十倍甚至上百倍。3.3 预分配容量一个容易被忽略的优化点StringBuilder的底层也是一个数组默认初始容量是16个字符。当append的内容超过容量时它会自动扩容扩容策略是“新容量 旧容量 * 2 2”。扩容意味着创建新数组、复制旧数据这个开销在频繁扩容时不可忽视。如果你能预估最终字符串的大致长度最好在创建StringBuilder时就指定容量StringBuilder sb new StringBuilder(1024);这样就能避免中间多次扩容。这个优化在拼接大量字符串时效果明显尤其是最终长度在几千甚至几万字符的场景。3.4 字符串拼接的编译期优化边界有一个细节很多人不知道编译器对字符串拼接的优化是有边界的。对于final修饰的字符串变量编译器会把它当作常量来处理在编译期就完成拼接final String a hello; final String b world; String c a b; // 编译期直接变成 helloworld但如果变量不是final的即使它在运行时的值确定编译器也不会在编译期拼接。这个区别在某些对性能极度敏感的场景下值得注意。另外JDK 9之后字符串拼接的底层实现从StringBuilder改成了invokedynamic指令配合StringConcatFactory。这个改动让拼接的性能进一步优化尤其是在拼接少量字符串时。不过对于开发者来说使用方式没有变化了解这个背景即可。4. String核心API的深水区那些文档没告诉你的细节4.1 equals和hashCode的契约关系equals和hashCode是Object类定义的两个方法它们之间有一个必须遵守的契约如果两个对象equals返回true那么它们的hashCode必须相等反之则不要求。这个契约对于String来说尤其重要因为String是HashMap中最常用的键类型。String的equals方法比较的是字符序列是否完全一致hashCode则是根据字符内容计算出来的。String的hashCode计算方式是这样的int h 0; for (int i 0; i value.length; i) { h 31 * h value[i]; }为什么选31因为31是一个奇素数用31做乘数可以让哈希值分布更均匀减少碰撞。而且31可以被JVM优化成位运算31 * i (i 5) - i计算效率高。这个选择是经过大量实践验证的不是随便定的。有一个坑需要注意String的hashCode是可能重复的。不同的字符串算出相同的hashCode是完全可能的这叫哈希碰撞。所以HashMap在比较键的时候会先用hashCode定位桶再用equals确认是否真的相等。这也是为什么重写equals时必须重写hashCode的原因。4.2 substring在JDK 6和JDK 7的行为差异substring方法有一个著名的历史遗留问题。在JDK 6中substring返回的新String对象会共享原字符串的底层char数组只是通过offset和count来标识自己截取的范围。这个设计本意是节省内存但实际使用中经常导致内存泄漏——如果你从一个很长的字符串中截取一小段但一直持有这个小字符串的引用那么整个大字符串的char数组都无法被回收。JDK 7修复了这个问题substring会创建一个新的char数组只包含截取的部分。虽然牺牲了一点性能需要复制数组但避免了潜在的内存泄漏。如果你现在用的是JDK 7及以上版本这个问题已经不存在了。但如果你维护的是老系统或者面试时被问到这个问题知道这段历史还是很有价值的。4.3 split方法的正则陷阱split方法接受一个正则表达式作为分隔符这既是它的强大之处也是它的陷阱所在。很多人习惯用split(.)来按点号分割字符串结果发现返回的是空数组。原因是点号在正则表达式里是特殊字符表示“任意字符”。正确的写法是split(\\.)。类似的还有split(|)竖线在正则里表示“或”也需要转义成split(\\|)。这些坑几乎每个Java开发者都踩过至少一次。另外split方法的第二个参数limit也值得注意。当limit为0时默认值末尾的空字符串会被丢弃当limit为正数时最多分割成limit个部分当limit为负数时末尾的空字符串会被保留。这个行为差异在处理CSV等格式时特别重要。4.4 字符串比较的多种方式及其适用场景String提供了多个比较方法各有各的用途方法比较内容大小写敏感返回值典型场景equals内容是boolean精确匹配equalsIgnoreCase内容否boolean忽略大小写匹配compareTo字典序是int排序compareToIgnoreCase字典序否int忽略大小写排序contentEquals内容是boolean与CharSequence比较regionMatches部分内容可配置boolean子串匹配compareTo的返回值含义需要记清楚负数表示当前字符串在参数字符串之前0表示相等正数表示在之后。这个方法是Comparable接口的实现决定了String在排序时的默认行为。contentEquals可以接受StringBuffer或StringBuilder作为参数这在需要比较String和可变字符序列时很有用。regionMatches则适合做前缀或子串的精确匹配可以指定是否忽略大小写。5. 内存视角下的String常量池、堆和intern的博弈5.1 不同创建方式的内存分布String对象的创建方式直接影响它在内存中的位置和数量。下面这张表总结了常见创建方式的行为差异创建方式常量池堆说明String s abc有则复用无则创建不创建直接引用常量池String s new String(abc)有则复用无则创建必定创建堆上新对象String s ab c编译期合并为abc不创建等同于字面量String s a b不涉及创建运行时拼接s.intern()有则返回池中引用可能创建手动入池理解这张表的关键在于区分“编译期常量”和“运行期变量”。编译期能确定值的字符串会直接进入常量池运行期才能确定值的字符串则在堆上创建。5.2 intern方法的正确使用姿势intern()方法的作用是手动将字符串放入常量池。在JDK 7之后常量池移到了堆中intern()的行为也有所变化如果池中已有相同内容的字符串返回池中对象的引用如果没有将当前对象的引用放入池中并返回。intern()的典型使用场景是当你需要处理大量重复字符串时用intern()可以让相同内容的字符串共享同一份内存。比如解析日志文件时很多字段的值是重复的用intern()可以显著减少内存占用。但intern()不是银弹。在JDK 6及之前常量池在永久代中大量使用intern()会导致永久代溢出。JDK 7之后虽然移到了堆中但常量池的回收效率不如普通堆对象滥用仍然可能导致内存问题。我的建议是只在确实存在大量重复字符串且内存压力大的场景下使用intern()并且要做好监控。5.3 字符串与编码getBytes和new String的编码陷阱字符串和字节数组之间的转换是另一个容易出问题的地方。getBytes()方法如果不指定字符集会使用平台默认字符集这在跨平台场景下是灾难性的。同样的代码在Windows上跑出来是GBK编码在Linux上跑出来是UTF-8编码结果完全不一样。正确的做法是始终显式指定字符集byte[] bytes str.getBytes(StandardCharsets.UTF_8); String str new String(bytes, StandardCharsets.UTF_8);StandardCharsets类提供了常用的字符集常量比用字符串字面量更安全因为拼写错误会在编译期就被发现。还有一个常见的乱码场景用错误的字符集解码字节数组。比如用UTF-8编码的字节用GBK解码得到的字符串就是乱码。这种问题在读取文件、处理网络数据时经常遇到。排查思路是确认编码端和解码端使用的是同一个字符集。6. 实战中的String优化从代码规范到JVM调优6.1 循环拼接、频繁创建和大字符串的规避策略在实际项目中String相关的性能问题主要集中在三个方面循环内拼接、频繁创建临时字符串、以及处理超大字符串。循环内拼接的解决方案前面已经讲过了用StringBuilder替代。这里补充一个细节如果循环体内有多个拼接操作应该把StringBuilder的创建提到循环外面而不是每次循环都new一个。频繁创建临时字符串的场景很隐蔽。比如在日志打印时很多人会这样写logger.debug(Processing user: user.getName() , age: user.getAge());即使日志级别是INFO这行代码的字符串拼接仍然会执行白白浪费性能。正确的做法是使用占位符logger.debug(Processing user: {}, age: {}, user.getName(), user.getAge());这样只有在需要输出日志时才会进行字符串格式化。处理超大字符串时要特别注意内存占用。一个包含百万字符的String对象在JDK 9之前占用约2MB内存每个char 2字节JDK 9之后如果全是Latin-1字符则占用约1MB。如果同时存在多个大字符串很容易触发Full GC。处理大文本时考虑用流式处理或者分块处理避免一次性加载整个字符串。6.2 用String做HashMap键的注意事项String作为HashMap的键是最常见的用法但有几个细节需要注意。首先String的hashCode是缓存的第一次调用时计算并保存后续调用直接返回缓存值。这意味着用String做键时哈希计算的开销只在第一次发生后续查找效率很高。其次要避免使用可变内容的字符串作为键。虽然String本身不可变但如果你用new String(...)创建了多个内容相同的键它们在HashMap中会被视为不同的键因为equals虽然相等但如果你重写了hashCode或者用了IdentityHashMap就另当别论。实际上HashMap用的是equals和hashCode所以内容相同的String会被视为同一个键不管它们是常量池里的还是堆上的。最后如果键的集合很大要注意hashCode的分布。虽然String的hashCode算法已经足够好但在极端情况下仍然可能出现大量碰撞。如果发现HashMap的性能异常可以用工具分析一下键的哈希分布。6.3 字符串去重与G1 GC的String DeduplicationG1垃圾回收器提供了一个叫String Deduplication字符串去重的特性可以在GC过程中自动识别内容相同的String对象让它们共享同一个底层byte数组。这个特性对于大量使用String的应用非常有用可以显著减少堆内存占用。开启方式是通过JVM参数-XX:UseG1GC -XX:UseStringDeduplication需要注意的是String Deduplication只对堆上的String对象生效常量池里的字符串本来就不会重复。另外这个特性会带来额外的CPU开销因为GC需要遍历和比较字符串内容。是否开启要根据实际的内存压力和CPU情况来权衡。6.4 常见String性能问题的排查思路遇到String相关的性能问题时排查思路可以按照这个顺序来第一步确认问题现象。是CPU高、内存高、还是GC频繁不同的现象指向不同的原因。第二步定位热点代码。用JProfiler、Async Profiler等工具找到消耗最大的方法调用。String相关的问题通常集中在StringBuilder.append、String.substring、String.split这些方法上。第三步分析具体原因。如果是循环拼接改用StringBuilder如果是频繁创建临时字符串考虑用占位符或缓存如果是大字符串导致的内存压力考虑流式处理或分块。第四步验证优化效果。优化后要重新测量确认问题确实得到了改善。有时候优化了一个地方问题转移到了另一个地方需要持续观察。7. 那些年我踩过的String坑真实案例复盘7.1 用比较字符串导致的生产事故前面提过和equals的区别但真正让我记住这个教训的是一次生产事故。当时有一个权限校验的逻辑用比较用户输入的角色名和系统预设的角色名。测试环境一直没问题因为测试时用的字符串都是字面量指向常量池中的同一个对象。但生产环境的角色名是从数据库读出来的每次都是新的String对象比较永远返回false导致所有用户都无法通过权限校验。这个问题的根因是字面量字符串在常量池中共享而运行时创建的字符串在堆上独立存在。测试环境和生产环境的数据来源不同导致了行为差异。修复方案很简单把改成equals就行但排查过程花了几个小时。从那以后我养成了一个习惯只要是比较字符串内容一律用equals绝不用。如果确实需要比较引用那一定是有特殊意图并且要加注释说明。7.2 大字符串substring引发的内存泄漏这个坑发生在JDK 7之前的项目上。当时有一个功能是从一个很大的JSON字符串中截取某个字段的值用的是substring。功能本身没问题但运行一段时间后应用的内存占用越来越高最终OOM。排查后发现substring返回的小字符串一直持有原大字符串的char数组引用。虽然小字符串本身很短但它背后的char数组是整个JSON字符串的大小。只要小字符串不被回收大数组就无法释放。解决方案有两个一是升级到JDK 7substring会自动复制数组二是在JDK 6环境下用new String(str.substring(...))的方式强制创建新的char数组。这个案例让我深刻理解了“看似无害的API背后可能隐藏着巨大的代价”。7.3 编码不一致导致的乱码问题编码问题几乎每个后端开发者都遇到过。我印象最深的一次是本地开发环境一切正常部署到服务器后中文全部变成乱码。排查后发现本地JVM的默认字符集是UTF-8而服务器的默认字符集是GBK。代码里用了getBytes()没有指定字符集导致编码行为不一致。这个问题的教训是任何涉及字符集转换的地方都必须显式指定字符集。不要依赖平台默认值因为不同环境的默认值可能不同。StandardCharsets.UTF_8应该成为你的默认选择除非有明确的理由使用其他字符集。7.4 字符串拼接在日志中的性能陷阱日志打印是字符串拼接的重灾区。我见过一个项目在DEBUG级别打印了大量详细的请求和响应信息用的是字符串拼接。虽然生产环境的日志级别是INFO但拼接操作仍然执行了因为字符串拼接是在方法调用之前完成的。这个问题在流量大的接口上尤其明显。每次请求都要拼接几个甚至几十个字符串累积起来就是可观的性能损耗。改用占位符后CPU使用率下降了将近10%。这个案例说明了一个道理性能优化不一定要做什么高深的事情把基础的东西用对效果就很明显。8. 从String看Java设计哲学不可变、缓存与权衡String这个类身上体现了Java语言设计的很多核心思想。不可变性带来了线程安全和缓存友好但也带来了每次修改都要创建新对象的代价。常量池优化了内存使用和比较效率但也引入了和equals的混淆。Compact Strings节省了内存但增加了实现的复杂度。这些设计没有绝对的好坏都是在特定约束下做出的权衡。理解这些权衡比记住API的用法更重要。因为API会变JDK版本会升级但设计思想是相对稳定的。我在实际工作中有一个体会当你真正理解了一个东西为什么这样设计你就很难再用错它了。比如理解了不可变性你就不会在循环里用拼接字符串理解了常量池你就不会用比较字符串内容理解了编码的本质你就不会在字符集转换上栽跟头。String的学习不会止步于这篇文章。JDK还在演进String的实现也可能继续变化。但只要你掌握了底层原理和设计思路不管API怎么变你都能快速适应。最后分享一个我个人的小习惯每次遇到String相关的奇怪问题先问自己三个问题——这个字符串是在常量池还是堆上这个操作创建了几个对象字符集是什么想清楚这三个问题大部分问题都能迎刃而解。 
长河君 · 2026/10/9 11:05:57 · 阅读 1.2k Java String深度剖析：从底层原理到性能优化实战
1. 从一个诡异的空指针说起为什么String值得单独拎出来讲刚入行那会儿我遇到过一个至今印象深刻的Bug。一个看似简单的字符串比较代码逻辑上完全说得通但运行结果就是不对。排查了大半天最后发现问题出在和equals的区别上。那一刻我才意识到String这个类远没有表面看起来那么简单。String是Java中使用频率最高的类没有之一。你写下的每一行代码几乎都离不开它。但恰恰因为它太常见、太基础很多人对它的理解停留在“能声明字符串、能拼接、能比较”这个层面。一旦遇到性能问题、内存问题、编码问题就抓瞎了。这篇文章想做的事情很明确把String这个类从里到外讲透。不管你是刚学Java的新手还是写了几年代码但没系统梳理过String的老手都能从中找到有价值的东西。我会从底层实现讲起把常量池、不可变性、字符串拼接的真相、常见API的坑、性能优化手段这些内容全部串起来。读完你至少能搞清楚三件事String对象到底怎么存的、为什么有些写法性能差得离谱、以及在实际项目里怎么用对String。先抛一个结论String是Java里被设计得最精巧的类之一但也是最容易被误用的类之一。精巧在于它用不可变性和常量池解决了大量问题容易被误用则是因为它的API太“顺手”了顺手到很多人根本不去想背后的代价。2. String的底层结构从char数组到字节数组的演进2.1 不可变性到底意味着什么String被设计成不可变类这是理解一切String行为的起点。所谓不可变就是一旦一个String对象被创建它内部存储的字符序列就再也不能被修改。你调用的所有看似“修改”字符串的方法比如substring、replace、toUpperCase实际上都是返回了一个全新的String对象原来的对象纹丝不动。为什么Java要把String设计成不可变的这个问题值得认真想一想。我总结下来主要有这么几个原因第一线程安全。不可变对象天然就是线程安全的多个线程同时读取一个String对象不需要任何同步措施。这在并发场景下省了太多事。第二支持常量池。只有不可变的对象才能安全地被多个引用共享。如果String可变那常量池里同一个字符串被两个变量引用一个改了另一个也跟着变整个语言体系就乱套了。第三缓存哈希值。String的hashCode可以被缓存因为内容永远不会变。这让String作为HashMap的键时效率极高。第四安全性。字符串经常被用来传递敏感信息比如文件路径、网络连接地址、类名等。如果可变就可能被恶意篡改。理解不可变性的一个关键是不可变的是String对象本身而不是引用它的变量。下面这段代码经常让新手困惑String s hello; s s world;看起来像是把hello改成了hello world但实际上内存里现在有两个String对象原来的hello和新的hello world。变量s只是重新指向了新的对象而已。原来的hello如果没有任何其他引用就会被垃圾回收。2.2 从char[]到byte[]JDK 9的压缩字符串优化在JDK 8及之前String内部是用char[]来存储字符的。Java的char是16位的也就是说每个字符不管实际需要几个字节都占2个字节。对于大量使用拉丁字母的场景这造成了严重的内存浪费——一个只包含ASCII字符的字符串一半的空间都白占了。JDK 9引入了Compact Strings压缩字符串特性把底层存储从char[]改成了byte[]同时增加了一个coder字段来标识编码方式。如果字符串内容全部是Latin-1范围内的字符也就是每个字符用一个字节就能表示就用单字节存储否则用UTF-16双字节存储。这个改动带来的内存节省非常可观。根据官方数据在实际应用中String对象的内存占用平均减少了约20%到30%。对于堆内存紧张的应用来说这个优化是实打实的。不过要注意这个变化对开发者是透明的。你写代码的方式不需要任何改变charAt、length这些方法的语义也完全一致。但如果你用反射去直接操作String内部的value字段那就要注意类型已经从char[]变成byte[]了。2.3 字符串常量池同一个字符串为什么只存一份字符串常量池是JVM为了提升性能和减少内存开销专门设计的一块区域。它的核心思想很简单相同的字符串字面量只存一份。当你写下String a hello时JVM会先去常量池里找有没有hello这个字符串。有的话直接把引用给你没有就创建一个放进去。所以下面这段代码的结果是trueString a hello; String b hello; System.out.println(a b); // true但如果你用new String(hello)情况就不一样了。new关键字强制在堆上创建一个新的对象不管常量池里有没有。所以String a hello; String b new String(hello); System.out.println(a b); // false System.out.println(a.equals(b)); // true这里就引出了一个经典问题比较的是引用地址equals比较的是内容。对于String来说几乎永远应该用equals来比较内容。我见过太多人在这上面栽跟头。关于常量池的位置JDK 7是一个分水岭。JDK 7之前常量池在方法区永久代里JDK 7及之后常量池被移到了堆内存中。这个变化带来的直接影响是常量池里的字符串也可以被垃圾回收了。在JDK 7之前如果大量使用intern()方法很容易导致永久代溢出。intern()方法值得单独说一下。它的作用是如果常量池里已经有内容相同的字符串就返回池中那个对象的引用如果没有就把当前字符串放入池中再返回引用。这个方法在特定场景下可以大幅减少重复字符串的内存占用但滥用的话反而会增加常量池的负担。3. 字符串拼接的真相为什么你的代码慢得离谱3.1 用“”拼接在循环里发生了什么字符串拼接是日常开发中最常见的操作之一。很多人习惯直接用号拼接简单直观。但如果在循环里用拼接性能会差到让你怀疑人生。先看一段典型的“反面教材”String result ; for (int i 0; i 10000; i) { result i; }这段代码看起来没什么问题但实际执行时每次循环都会创建一个新的StringBuilder对象编译器会把优化成StringBuilder的append和toString然后调用toString生成一个新的String对象。10000次循环就是10000个StringBuilder和10000个String对象。内存分配和垃圾回收的压力非常大。编译器对字符串拼接的优化其实比很多人想象的要聪明。对于简单的a b c这种字面量拼接编译器会直接在编译期合并成abc运行时没有任何额外开销。但对于包含变量的拼接编译器会转换成StringBuilder的链式调用。问题在于这个优化只在单条语句内有效。一旦拼接跨越了循环的边界每次循环都会重新创建StringBuilder。3.2 StringBuilder和StringBuffer怎么选StringBuilder和StringBuffer都是可变的字符序列区别在于StringBuffer的方法是线程安全的加了synchronized而StringBuilder不是。选择逻辑很简单单线程环境下用StringBuilder多线程共享同一个可变字符串时才考虑StringBuffer。实际项目中绝大多数字符串拼接场景都是单线程的所以StringBuilder是更常见的选择。StringBuffer因为同步开销性能比StringBuilder差不少。用StringBuilder改写上面的循环StringBuilder sb new StringBuilder(); for (int i 0; i 10000; i) { sb.append(i); } String result sb.toString();这段代码只创建了一个StringBuilder对象和一个最终的String对象性能提升是数量级的。我实测过在百万级循环下StringBuilder比直接用拼接快几十倍甚至上百倍。3.3 预分配容量一个容易被忽略的优化点StringBuilder的底层也是一个数组默认初始容量是16个字符。当append的内容超过容量时它会自动扩容扩容策略是“新容量 旧容量 * 2 2”。扩容意味着创建新数组、复制旧数据这个开销在频繁扩容时不可忽视。如果你能预估最终字符串的大致长度最好在创建StringBuilder时就指定容量StringBuilder sb new StringBuilder(1024);这样就能避免中间多次扩容。这个优化在拼接大量字符串时效果明显尤其是最终长度在几千甚至几万字符的场景。3.4 字符串拼接的编译期优化边界有一个细节很多人不知道编译器对字符串拼接的优化是有边界的。对于final修饰的字符串变量编译器会把它当作常量来处理在编译期就完成拼接final String a hello; final String b world; String c a b; // 编译期直接变成 helloworld但如果变量不是final的即使它在运行时的值确定编译器也不会在编译期拼接。这个区别在某些对性能极度敏感的场景下值得注意。另外JDK 9之后字符串拼接的底层实现从StringBuilder改成了invokedynamic指令配合StringConcatFactory。这个改动让拼接的性能进一步优化尤其是在拼接少量字符串时。不过对于开发者来说使用方式没有变化了解这个背景即可。4. String核心API的深水区那些文档没告诉你的细节4.1 equals和hashCode的契约关系equals和hashCode是Object类定义的两个方法它们之间有一个必须遵守的契约如果两个对象equals返回true那么它们的hashCode必须相等反之则不要求。这个契约对于String来说尤其重要因为String是HashMap中最常用的键类型。String的equals方法比较的是字符序列是否完全一致hashCode则是根据字符内容计算出来的。String的hashCode计算方式是这样的int h 0; for (int i 0; i value.length; i) { h 31 * h value[i]; }为什么选31因为31是一个奇素数用31做乘数可以让哈希值分布更均匀减少碰撞。而且31可以被JVM优化成位运算31 * i (i 5) - i计算效率高。这个选择是经过大量实践验证的不是随便定的。有一个坑需要注意String的hashCode是可能重复的。不同的字符串算出相同的hashCode是完全可能的这叫哈希碰撞。所以HashMap在比较键的时候会先用hashCode定位桶再用equals确认是否真的相等。这也是为什么重写equals时必须重写hashCode的原因。4.2 substring在JDK 6和JDK 7的行为差异substring方法有一个著名的历史遗留问题。在JDK 6中substring返回的新String对象会共享原字符串的底层char数组只是通过offset和count来标识自己截取的范围。这个设计本意是节省内存但实际使用中经常导致内存泄漏——如果你从一个很长的字符串中截取一小段但一直持有这个小字符串的引用那么整个大字符串的char数组都无法被回收。JDK 7修复了这个问题substring会创建一个新的char数组只包含截取的部分。虽然牺牲了一点性能需要复制数组但避免了潜在的内存泄漏。如果你现在用的是JDK 7及以上版本这个问题已经不存在了。但如果你维护的是老系统或者面试时被问到这个问题知道这段历史还是很有价值的。4.3 split方法的正则陷阱split方法接受一个正则表达式作为分隔符这既是它的强大之处也是它的陷阱所在。很多人习惯用split(.)来按点号分割字符串结果发现返回的是空数组。原因是点号在正则表达式里是特殊字符表示“任意字符”。正确的写法是split(\\.)。类似的还有split(|)竖线在正则里表示“或”也需要转义成split(\\|)。这些坑几乎每个Java开发者都踩过至少一次。另外split方法的第二个参数limit也值得注意。当limit为0时默认值末尾的空字符串会被丢弃当limit为正数时最多分割成limit个部分当limit为负数时末尾的空字符串会被保留。这个行为差异在处理CSV等格式时特别重要。4.4 字符串比较的多种方式及其适用场景String提供了多个比较方法各有各的用途方法比较内容大小写敏感返回值典型场景equals内容是boolean精确匹配equalsIgnoreCase内容否boolean忽略大小写匹配compareTo字典序是int排序compareToIgnoreCase字典序否int忽略大小写排序contentEquals内容是boolean与CharSequence比较regionMatches部分内容可配置boolean子串匹配compareTo的返回值含义需要记清楚负数表示当前字符串在参数字符串之前0表示相等正数表示在之后。这个方法是Comparable接口的实现决定了String在排序时的默认行为。contentEquals可以接受StringBuffer或StringBuilder作为参数这在需要比较String和可变字符序列时很有用。regionMatches则适合做前缀或子串的精确匹配可以指定是否忽略大小写。5. 内存视角下的String常量池、堆和intern的博弈5.1 不同创建方式的内存分布String对象的创建方式直接影响它在内存中的位置和数量。下面这张表总结了常见创建方式的行为差异创建方式常量池堆说明String s abc有则复用无则创建不创建直接引用常量池String s new String(abc)有则复用无则创建必定创建堆上新对象String s ab c编译期合并为abc不创建等同于字面量String s a b不涉及创建运行时拼接s.intern()有则返回池中引用可能创建手动入池理解这张表的关键在于区分“编译期常量”和“运行期变量”。编译期能确定值的字符串会直接进入常量池运行期才能确定值的字符串则在堆上创建。5.2 intern方法的正确使用姿势intern()方法的作用是手动将字符串放入常量池。在JDK 7之后常量池移到了堆中intern()的行为也有所变化如果池中已有相同内容的字符串返回池中对象的引用如果没有将当前对象的引用放入池中并返回。intern()的典型使用场景是当你需要处理大量重复字符串时用intern()可以让相同内容的字符串共享同一份内存。比如解析日志文件时很多字段的值是重复的用intern()可以显著减少内存占用。但intern()不是银弹。在JDK 6及之前常量池在永久代中大量使用intern()会导致永久代溢出。JDK 7之后虽然移到了堆中但常量池的回收效率不如普通堆对象滥用仍然可能导致内存问题。我的建议是只在确实存在大量重复字符串且内存压力大的场景下使用intern()并且要做好监控。5.3 字符串与编码getBytes和new String的编码陷阱字符串和字节数组之间的转换是另一个容易出问题的地方。getBytes()方法如果不指定字符集会使用平台默认字符集这在跨平台场景下是灾难性的。同样的代码在Windows上跑出来是GBK编码在Linux上跑出来是UTF-8编码结果完全不一样。正确的做法是始终显式指定字符集byte[] bytes str.getBytes(StandardCharsets.UTF_8); String str new String(bytes, StandardCharsets.UTF_8);StandardCharsets类提供了常用的字符集常量比用字符串字面量更安全因为拼写错误会在编译期就被发现。还有一个常见的乱码场景用错误的字符集解码字节数组。比如用UTF-8编码的字节用GBK解码得到的字符串就是乱码。这种问题在读取文件、处理网络数据时经常遇到。排查思路是确认编码端和解码端使用的是同一个字符集。6. 实战中的String优化从代码规范到JVM调优6.1 循环拼接、频繁创建和大字符串的规避策略在实际项目中String相关的性能问题主要集中在三个方面循环内拼接、频繁创建临时字符串、以及处理超大字符串。循环内拼接的解决方案前面已经讲过了用StringBuilder替代。这里补充一个细节如果循环体内有多个拼接操作应该把StringBuilder的创建提到循环外面而不是每次循环都new一个。频繁创建临时字符串的场景很隐蔽。比如在日志打印时很多人会这样写logger.debug(Processing user: user.getName() , age: user.getAge());即使日志级别是INFO这行代码的字符串拼接仍然会执行白白浪费性能。正确的做法是使用占位符logger.debug(Processing user: {}, age: {}, user.getName(), user.getAge());这样只有在需要输出日志时才会进行字符串格式化。处理超大字符串时要特别注意内存占用。一个包含百万字符的String对象在JDK 9之前占用约2MB内存每个char 2字节JDK 9之后如果全是Latin-1字符则占用约1MB。如果同时存在多个大字符串很容易触发Full GC。处理大文本时考虑用流式处理或者分块处理避免一次性加载整个字符串。6.2 用String做HashMap键的注意事项String作为HashMap的键是最常见的用法但有几个细节需要注意。首先String的hashCode是缓存的第一次调用时计算并保存后续调用直接返回缓存值。这意味着用String做键时哈希计算的开销只在第一次发生后续查找效率很高。其次要避免使用可变内容的字符串作为键。虽然String本身不可变但如果你用new String(...)创建了多个内容相同的键它们在HashMap中会被视为不同的键因为equals虽然相等但如果你重写了hashCode或者用了IdentityHashMap就另当别论。实际上HashMap用的是equals和hashCode所以内容相同的String会被视为同一个键不管它们是常量池里的还是堆上的。最后如果键的集合很大要注意hashCode的分布。虽然String的hashCode算法已经足够好但在极端情况下仍然可能出现大量碰撞。如果发现HashMap的性能异常可以用工具分析一下键的哈希分布。6.3 字符串去重与G1 GC的String DeduplicationG1垃圾回收器提供了一个叫String Deduplication字符串去重的特性可以在GC过程中自动识别内容相同的String对象让它们共享同一个底层byte数组。这个特性对于大量使用String的应用非常有用可以显著减少堆内存占用。开启方式是通过JVM参数-XX:UseG1GC -XX:UseStringDeduplication需要注意的是String Deduplication只对堆上的String对象生效常量池里的字符串本来就不会重复。另外这个特性会带来额外的CPU开销因为GC需要遍历和比较字符串内容。是否开启要根据实际的内存压力和CPU情况来权衡。6.4 常见String性能问题的排查思路遇到String相关的性能问题时排查思路可以按照这个顺序来第一步确认问题现象。是CPU高、内存高、还是GC频繁不同的现象指向不同的原因。第二步定位热点代码。用JProfiler、Async Profiler等工具找到消耗最大的方法调用。String相关的问题通常集中在StringBuilder.append、String.substring、String.split这些方法上。第三步分析具体原因。如果是循环拼接改用StringBuilder如果是频繁创建临时字符串考虑用占位符或缓存如果是大字符串导致的内存压力考虑流式处理或分块。第四步验证优化效果。优化后要重新测量确认问题确实得到了改善。有时候优化了一个地方问题转移到了另一个地方需要持续观察。7. 那些年我踩过的String坑真实案例复盘7.1 用比较字符串导致的生产事故前面提过和equals的区别但真正让我记住这个教训的是一次生产事故。当时有一个权限校验的逻辑用比较用户输入的角色名和系统预设的角色名。测试环境一直没问题因为测试时用的字符串都是字面量指向常量池中的同一个对象。但生产环境的角色名是从数据库读出来的每次都是新的String对象比较永远返回false导致所有用户都无法通过权限校验。这个问题的根因是字面量字符串在常量池中共享而运行时创建的字符串在堆上独立存在。测试环境和生产环境的数据来源不同导致了行为差异。修复方案很简单把改成equals就行但排查过程花了几个小时。从那以后我养成了一个习惯只要是比较字符串内容一律用equals绝不用。如果确实需要比较引用那一定是有特殊意图并且要加注释说明。7.2 大字符串substring引发的内存泄漏这个坑发生在JDK 7之前的项目上。当时有一个功能是从一个很大的JSON字符串中截取某个字段的值用的是substring。功能本身没问题但运行一段时间后应用的内存占用越来越高最终OOM。排查后发现substring返回的小字符串一直持有原大字符串的char数组引用。虽然小字符串本身很短但它背后的char数组是整个JSON字符串的大小。只要小字符串不被回收大数组就无法释放。解决方案有两个一是升级到JDK 7substring会自动复制数组二是在JDK 6环境下用new String(str.substring(...))的方式强制创建新的char数组。这个案例让我深刻理解了“看似无害的API背后可能隐藏着巨大的代价”。7.3 编码不一致导致的乱码问题编码问题几乎每个后端开发者都遇到过。我印象最深的一次是本地开发环境一切正常部署到服务器后中文全部变成乱码。排查后发现本地JVM的默认字符集是UTF-8而服务器的默认字符集是GBK。代码里用了getBytes()没有指定字符集导致编码行为不一致。这个问题的教训是任何涉及字符集转换的地方都必须显式指定字符集。不要依赖平台默认值因为不同环境的默认值可能不同。StandardCharsets.UTF_8应该成为你的默认选择除非有明确的理由使用其他字符集。7.4 字符串拼接在日志中的性能陷阱日志打印是字符串拼接的重灾区。我见过一个项目在DEBUG级别打印了大量详细的请求和响应信息用的是字符串拼接。虽然生产环境的日志级别是INFO但拼接操作仍然执行了因为字符串拼接是在方法调用之前完成的。这个问题在流量大的接口上尤其明显。每次请求都要拼接几个甚至几十个字符串累积起来就是可观的性能损耗。改用占位符后CPU使用率下降了将近10%。这个案例说明了一个道理性能优化不一定要做什么高深的事情把基础的东西用对效果就很明显。8. 从String看Java设计哲学不可变、缓存与权衡String这个类身上体现了Java语言设计的很多核心思想。不可变性带来了线程安全和缓存友好但也带来了每次修改都要创建新对象的代价。常量池优化了内存使用和比较效率但也引入了和equals的混淆。Compact Strings节省了内存但增加了实现的复杂度。这些设计没有绝对的好坏都是在特定约束下做出的权衡。理解这些权衡比记住API的用法更重要。因为API会变JDK版本会升级但设计思想是相对稳定的。我在实际工作中有一个体会当你真正理解了一个东西为什么这样设计你就很难再用错它了。比如理解了不可变性你就不会在循环里用拼接字符串理解了常量池你就不会用比较字符串内容理解了编码的本质你就不会在字符集转换上栽跟头。String的学习不会止步于这篇文章。JDK还在演进String的实现也可能继续变化。但只要你掌握了底层原理和设计思路不管API怎么变你都能快速适应。最后分享一个我个人的小习惯每次遇到String相关的奇怪问题先问自己三个问题——这个字符串是在常量池还是堆上这个操作创建了几个对象字符集是什么想清楚这三个问题大部分问题都能迎刃而解。