String 的“”和“equals()”之争几乎每个 Java 面试官都会问也是日常开发里最容易踩坑的地方之一。我早期写业务代码时就因为在字符串比较上用了“”导致一个订单状态判断死活不生效排查了半天最后发现是字符串对象引用的问题。也是从那次起我把这两个比较方式的底层逻辑彻底摸了一遍。这篇文章就把我这几年的实操经验和踩坑记录整理出来从原理到场景到排查技巧一次说透。1. 从现象到本质为什么会有人用错“”和“equals()”先给新手朋友一个最直观的结论在 Java 里比较的是两个对象的“引用地址”equals()比较的是两个对象的“内容值”。String 是对象不是基本类型int、char 这种所以直接用比较两个字符串本质上是在问“这两个变量是不是指向同一个内存地址”而不是“这两个字符串的内容是不是一样”。很多人刚开始学 Java 时会被基础类型比较惯坏。比如int a 1; int b 1; a b返回 true因为基本类型本身存储的就是值。可到了 String 这里String s1 hello; String s2 hello;再用比较结果居然也是 true这就让不少人产生了“String 也可以用 比较”的错觉。这个错觉的根源在于 JVM 的字符串常量池机制。下面这个例子是我在培训新人时最爱用的“陷阱演示”String a hello; String b hello; System.out.println(a b); // 输出 true原因常量池复用 System.out.println(a.equals(b)); // 输出 true原因内容相同 String c new String(hello); String d new String(hello); System.out.println(c d); // 输出 false原因两个不同对象 System.out.println(c.equals(d)); // 输出 true原因内容相同 String e hel lo; // 编译期常量折叠 System.out.println(a e); // 输出 true原因编译期就已经拼成hello第一组a和b都是直接赋值的字符串字面量JVM 在类加载阶段会把hello放进字符串常量池之后b再从常量池里拿同一个引用所以a b为 true。第三组c和d是用new String()创建的JVM 会在堆上各自创建独立对象它们的内容虽然一样但地址不同所以为 false。第二组是“看起来一样、实际不同”的典型场景。但真正坑人的是第四组hel lo。这里存在一个编译期优化Java 编译器在编译时如果你拼接的两个操作数都是编译期常量字符串字面量、final 常量等会直接帮你算好结果把这个表达式替换成hello字面量。所以e指向的还是常量池里的hello结果为 true。可一旦拼接里出现变量比如String str hel; String f str lo;f就成了运行时通过 StringBuilder 拼接出来的新对象此时f a就是 false。注意这种“为什么一会儿 true 一会儿 false”的现象是新手最容易懵的地方。关键是分清“常量池里的同一个引用”和“堆上新创建的对象引用”而不是死记某个场景的结果。这也引出了标题里的核心问题String 进行 和 equals() 比较时的差异表面上看是比较操作符的区别本质上是“引用相等”和“值相等”两种不同语义的选择问题。2. 深入 JVM字符串常量池、对象创建与引用关系很多人知道结论但说不清原理面试时被一问“为什么”就露馅。我建议把字符串的内存模型彻底吃透搞清楚了后面所有的判断你都能自己推出来。2.1 字符串常量池String Pool是怎么工作的JVM 里有一块专门的内存区域叫字符串常量池在 JDK 7 之前放在永久代PermGenJDK 7 之后挪到了堆内存中所以现在你可以在堆内存里找它。当你写下一个字符串字面量比如helloJVM 会先在常量池里查找是否有内容相同的字符串如果有直接返回已有的引用如果没有就在常量池中创建该字符串并返回引用。这个过程天然保证了常量池中不会存在两个内容相同的字符串这就是“复用”的底层机制。所以前面代码里a和b才会指向同一个对象。这里要稍微区分一下“内容相同”的判定常量池在 JDK 7 之后放的是 String 对象本身这个查找过程用的是 String 类内部的equals()逻辑来判断的。也就是说常量池的复用机制本身就依赖 equals 的语义这一点反过来能帮你理解 equals 到底在做什么。2.2 new String() 到底创建了几个对象这是面试里另一道常见题new String(hello)创建了几个对象标准答案是一个或两个。如果常量池中已经有hello那么只创建一个堆上的 String 对象它内部引用常量池的那个字符数组。如果常量池中没有hello那么创建两个对象一个是在常量池里创建的字面量对象另一个是new在堆上创建的独立 String 对象。你可能会问既然堆上已经有新对象了为什么常量池还要存一份因为在 Java 设计里字符串字面量是代码层面表达的明确常量类加载时就要把它注册到常量池这是对全 JVM 可见的基础设施。而new String()是你显式要求“再单独造一个”它属于业务侧的临时需求。顺便说一个很多人不知道的细节JDK 7 之后String 对象内部不再维护一个char[]的拷贝而是通过value字段指向字符数组。而且new String(hello)生成的堆对象其字符数组可能和常量池中的字符串共用一份。因为String构造方法里有个HotSpotIntrinsicCandidate标注的优化堆上的新 String 直接复用常量池字符串内部的char[]并不会再复制一份字符数组。所以虽然对象是不同的但底层数据是共享的。JDK 9 之后内部存储从char[]换成了byte[]这是为了压缩编码空间的优化但不影响这里的内存语义。2.3 intern() 方法手动入池的正确姿势如果你非要用去比较两个内容相同的运行时字符串方法只有一条让它们都指向常量池里的同一个对象。String 类提供了intern()方法它的行为是如果常量池中存在内容相同的字符串直接返回池中引用否则把当前字符串的内容放入池中并返回池中引用。String c new String(hello); String d new String(hello); System.out.println(c.intern() d.intern()); // 输出 true System.out.println(c d); // 输出 false从实践角度讲intern()在大多数业务代码里并不推荐滥用。因为常量池本身不是无限大的大量使用intern()会把字符串长期钉在池里增加内存占用和 GC 压力。需要大量字符串去重的场景比如海量重复的 URL、日志信息可以考虑用更可控的MapString, String自己做去重或者直接用Guava的Interner实现。这个我后面在问题排查部分展开讲。实操心得不要在每一行字符串比较前都调用intern()这等于把常量池当成免费缓存用。用完的字符串不会被回收内存增长起来你根本意识不到是哪里造成的。2.4 为什么 equals() 才能比较内容String 类并没有自己定义一套全新的 equals 逻辑它是重写了 Object 的equals()方法。重写后的逻辑大致可以概括为先判断this和obj是不是同一个引用是就直接返回 true这是性能优化手段再判断obj是不是 String 类型不是就返回 false是的话比较两个字符串内部的字符数组长度、每个字符是否都相等。这个流程就是“内容相等”的标准定义。你不需要关心两个字符串是不是从常量池来的、是不是 new 出来的、是不是拼接出来的只要字符序列完全相同equals 就返回 true。这里引申出一个关键点为什么所有自定义对象要正确比较内容都必须重写 equals()因为 Object 默认的 equals 就是用判断引用地址的。String 之所以能用 equals 比较内容正是因为官方帮我们把内部逻辑重写好了而不是 equals 天生就具备比较内容的能力。这个理解能帮你一下子想通 HashMap 的 key 查找、HashSet 去重等场景为什么老依赖 equals 和 hashCode。3. 实操案例真实业务里的比较场景拆解理论讲完直接上具体场景。我挑几个日常开发中最常遇见 String 比较的典型场景每个场景都给出正确写法和背后原因。3.1 用户输入与固定值比较业务中经常要判断“用户输入的内容是否等于某个预设值”比如支付状态、订单类型、开关标识。// 反例极端情况下可能出 bug if (orderStatus PAID) { // do something } // 正例永远用 equals if (PAID.equals(orderStatus)) { // do something }反例的问题在于orderStatus如果是通过接口文档解析、数据库读取、JSON 转换来的字符串它往往是一个运行时创建的新 String 对象和代码里的PAID字面量不是同一个引用。比较大概率返回 false导致逻辑直接走不到。而正例你还会发现一个细节常量放在前面调用 equals也就是PAID.equals(orderStatus)。这样做的好处是即便orderStatus为 null也不会抛 NullPointerException只是正常返回 false。我一直建议团队统一用这种写法简洁又安全。3.2 枚举与字符串常量的对比有时候你会看到类型安全性的讨论与其用字符串比较不如用枚举。实践里我的观点是能用枚举就尽量用枚举比如订单状态、支付渠道这种值域固定的字段枚举能带来编译期检查、参数校验、代码重构友好性。但现实项目中不可避免会遇到第三方接口返回的字符串字段这时候你仍然需要字符串比较兜底。在 Spring 项目中很常见的做法是在枚举里维护一个code字段然后提供fromCode(String code)的静态方法public enum OrderStatus { PAID(PAID, 已支付), UNPAID(UNPAID, 未支付); private final String code; private final String desc; OrderStatus(String code, String desc) { this.code code; this.desc desc; } public static OrderStatus fromCode(String code) { for (OrderStatus status : values()) { if (status.code.equals(code)) { return status; } } throw new IllegalArgumentException(未知状态 code); } }你注意看枚举内部的code.equals(code)仍然用的是 equals而不是。虽然枚举的 code 本身来自常量池字面量顺序上成立但外部传入的字符串几乎都是运行时对象必须用 equals 才能保证比较正确。别把枚举当成避开 equals 的银弹。3.3 字符串为空或空串的判断有个开发中经常混淆的问题是空判断。和 equals 在空判断里也有各自的用途不能一刀切。String str getFormValue(); // 判断是否为 null只能用 if (str null) { // 未赋值 } // 判断是否为空字符串用 equals if (.equals(str)) { // 内容为空 } // 更推荐的做法 if (str null || str.isEmpty()) { // 处理空场景 }这里有个容易误用的点是str.equals()如果str是 null直接空指针。所以要么用.equals(str)这种常量置前写法要么先判 null 再判空。isEmpty()是 JDK 6 之后才有的方法它判断的是内部字符数组长度是否为 0。JDK 11 之后还有isBlank()除了空串还会判断纯空白字符空格、制表符、换行等语义更丰富。注意str null和str.isEmpty()是两个不同维度的判断。null 表示变量没有引用任何对象空串表示对象存在但内容长度为 0这两件事不要混在一起。3.4 日志与打印中的字符串拼接陷阱还有个隐蔽的场景日志打印和字符串格式化时也容易偶发用错比较逻辑。虽然日志本身不太涉及但如果你在日志里输出s1 s2的布尔结果很容易被常量池现象误导。比如String x abc; String y abc; System.out.println(x y); // trueOK然后你换一种写法String x abc; String y new String(abc); System.out.println(x y); // false日志里看是 false有人就开始怀疑人生这种调试输出很容易让人混乱。我建议在日志中不要直接打印的比较结果而是显式打印两个对象的System.identityHashCode()这样就能看出来它们是不是同一个对象System.out.println(System.identityHashCode(x)); // 地址标识 System.out.println(System.identityHashCode(y)); // 地址标识地址标识不同必然为 false内容相同则 equals 必然为 true。这个技巧在你排查诡异 bug 时特别有用。4. 跨语言对比C、C# 与 Java 的字符串比较差异既然热搜词里出现了 C、C# 的 string 相关关键词这里也顺带做个横向对比帮你建立更系统的认知。4.1 C# 的 String 比较策略C# 的string类型非常有意思它的运算符被重载过重载后的语义就是比较字符串的内容而不是引用地址。所以在 C# 里你可以放心地写string a hello; string b hello; Console.WriteLine(a b); // true内容比较更进一步C# 的实际上调用的是String.Equals方法它考虑到字符串是不可变的所以直接比较内容是一种安全且高效的默认策略。如果你的确想比较引用C# 提供了object.ReferenceEquals(a, b)方法语义等同于 Java 的对对象引用的比较。从语言设计者的角度思考Java 选择保留的引用语义是为了保持操作符行为的一致性一切对象比较都默认走引用。C# 选择重载为内容语义是为了让日常字符串操作更符合直觉。两种设计都有道理但对开发者而言跨语言写代码时必须时刻提醒自己“当前的 到底是什么语义”。我在同时维护 Java 和 C# 项目的时期偶尔就会有一瞬间搞混。4.2 C 的 string 比较C 里如果你用的是std::stringoperator也是被重载为内容比较的通常也比较大小写敏感有一个专门的compare()方法可以做更多控制。所以 C 写多了的人刚转 Java 时会自然觉得比较字符串没毛病。这个注意点很重要也就是为什么面试官喜欢拿这道题考候选人它考察的是对“语言特性背后设计意图”的理解程度。4.3 语言设计差异的工程意义从工程角度语言差异带来的最大影响是团队代码规范的制定。我建议在多人协作的项目里明确规定Java 代码一律禁止用比较 String所有内容比较走equals()或者Objects.equals()。Objects.equals(a, b)是 JDK 7 引入的静态方法它内部先判引用相等再判a.equals(b)同时处理了a为 null 的情况是比常量.equals(变量)更语义化的写法。// 推荐 if (Objects.equals(status, PAID)) { ... } // 等价且更旧式的写法 if (PAID.equals(status)) { ... }Objects.equals的好处是参数可以都是变量阅读起来更自然且天然处理 null。不过要注意Objects.equals在内部也是调用变量所属类型的 equals 方法如果a是某个自定义类且没有重写 equals那么它实际做的还是引用比较别搞混了。5. 字符串拼接性能对比String、StringBuilder、StringBuffer比较字符串这件事本身绕不开“对象是怎么生成”的问题而字符串拼接正是对象生成的重要途径。这些年我见过不少出问题的字符串比较代码背后都是拼接方式导致的引用混乱所以这一节把拼接相关的知识一起串起来。5.1 三种方式的性能差异Java 里字符串拼接主要有三种常见手段直接用、用StringBuilder、用老的StringBuffer。String String编译器会把str a翻译成new StringBuilder().append(str).append(a).toString()。所以如果你在循环里反复用拼接每次循环都会创建一个新的 StringBuilder 再转成 String性能最差。StringBuilder非线程安全做单线程拼接效率最高。StringBuffer线程安全内部方法加了synchronized关键字但代价是锁开销性能比 StringBuilder 差。我记得刚入行那会儿维护过一段导出报表的代码里面用拼接好几万行文本慢到页面超时。后来全部改造成一个大的 StringBuilder耗时直接降了一个数量级。这个优化原理很简单旧代码每拼一次就产生一个临时 String 对象几十万次拼接就产生了几十万个垃圾对象GC 压力大得惊人而 StringBuilder 是直接在内部可变字符数组中追加不需要这些临时对象。5.2 StringBuffer 转换为 String 的常规姿势StringBuffer 要转成 String直接调toString()就好了这是最简单也最稳妥的路径StringBuffer sb new StringBuffer(); sb.append(hello); sb.append( ); sb.append(world); String result sb.toString();这个toString()会基于当前 StringBuffer 内部的字符数组内容new 出一个新的 String 对象。注意这个新对象和 StringBuffer 内部数组之间有一个复制过程。如果你之后又修改了 StringBuffer 的内容之前得到的result并不会跟着变因为toString()返回的是复制后的独立字符串。这里有一个冷门知识在某些早期 JDK 版本下StringBuffer 的toString()内部直接共享了字符数组一旦后续修改 StringBuffer 就会影响已生成的 String后来才改成复制。JDK 8 及以后你不用担心这个问题直接转即可。实操心得如果有一段代码需要把 StringBuilder/StringBuffer 转 String 后再继续拼接不如直接复用原来的 builder别频繁转来转去。跨转换过程会引入额外的复制和对象创建开销。5.3 编译器对字符串拼接的优化规则前面说过编译期常量拼接会被折叠。这里再展开一点因为“拼接结果到底是不是常量池对象”直接影响的结果。编译器折叠的条件是拼接的操作数都是编译期常量。常量包括字符串字面量如hel被final修饰的 String 变量且声明时就赋值了字面量如final String suffix lo;基本类型字面量拼接成字符串的场景如count 5会直接折叠成count5下面的代码大多数人判断有误final String s1 hello; String s2 s1 world; // 编译期常量折叠等价于 hello world String s3 hello world; System.out.println(s2 s3); // 输出 true String s4 hello; String s5 s4 world; // s4 不是 final运行时用 StringBuilder 拼接 System.out.println(s5 s3); // 输出 false差别就在于s1是final的编译期可以确定它的值所以整个表达式被折叠成了常量hello world而s4是普通变量编译器无法确定它后续是否会被修改虽然 String 不可变但变量引用本身可以重新指向其他字符串只能在运行时通过 StringBuilder 拼接结果自然在堆上创建新对象。实际开发里这种“变量是不是 final”的差别极容易被人忽略。我曾经排查过一个诡异 bug一段代码用判断状态拼接的结果在一个类里正常搬到另一个类里就失败最后发现就是 final 修饰的差异。从那以后我在代码评审时看到 String 比较就格外敏感。5.4 循环拼接的注意点如果你在一个循环里需要拼接大量字符串优先用 StringBuilderStringBuilder sb new StringBuilder(); for (String item : list) { sb.append(item).append(,); } // 删除最后一个多余的逗号 if (sb.length() 0) { sb.setLength(sb.length() - 1); } String result sb.toString();这里有个小技巧setLength(sb.length() - 1)比substring(0, sb.length() - 1)高效得多它只是把长度标记往前移动并不复制底层数组。如果你觉得substring更简洁要注意 JDK 7 以前 substring 可能持有整个原数组的引用容易造成“大数组有小引用”的内存浪费JDK 7 之后改成了复制但性能开销还是在的。我平时写拼接逻辑都喜欢用 setLength 处理尾部符号。如果拼接的数据量特别大比如十几万行 CSV可以给StringBuilder(initialCapacity)指定初始容量减少扩容时的数组复制次数。初始容量估不好也没关系暴露出一个“容量不够就自动扩容”的机制但扩容会触发数组复制属于额外开销。能估算就估算比如你知道大概要拼 10000 行、每行平均 50 字符就可以new StringBuilder(500000)起步。6. 源码视角String.equals 的完整逻辑与 hashCode 的约定想彻底拿捏 equals 的语义还得看源码。我直接带你过一遍 JDK 8 中 String.equals 的核心逻辑这样你能更好地理解它的性能考量和边界处理。public boolean equals(Object anObject) { if (this anObject) { return true; } if (anObject instanceof String) { String aString (String) anObject; if (!COMPACT_STRINGS || this.coder aString.coder) { return StringLatin1.equals(value, aString.value); } } return false; }这段代码有三个关键点第一步this anObject是引用快判。如果两个变量本来就指向同一个 String 对象那内容必然相同直接就返回 true省去后续逐字符比较的开销。这个优化对常量池复用、传参引用相同的场景非常有效。第二步instanceof String检查类型。如果传入的是一个自定义对象切它没有继承 String直接返回 false。注意 String 是final的所以不存在子类instanceof判断就等于判断“它是不是 String”。第三步调StringLatin1.equals(value, aString.value)内部实际上是比较两个byte[]或char[]的长度和每个位置上的字符是否一致。JDK 9 之后因为引入了 Compact Strings用byte[]存储还会有编码LATIN1/UTF16判断如果编码不同直接不等。源码告诉我们一个重要信息String.equals 本身并不是“魔法”它也是一步一步比较内容的。很多初学者以为 equals 是某种内置能力其实它就是一个普普通通的方法重写 Object 的方法而已。这正是为什么你自己写的类如果不重写 equals那它的 equals 行为就和一样因为默认实现就是引用比较。另外重写equals()必须要重写hashCode()这是 Java 对象规范里的硬性约定。String 类也遵守了这个约定它的 hashCode 算法是int hash 0; for (int i 0; i value.length; i) { hash 31 * hash value[i]; }为什么用 31这是 JDK 作者在性能和分布之间取得的经验值31 是一个奇素数可以减少哈希碰撞而且31 * hash可以被 JVM 优化成(hash 5) - hash移位和减法操作比乘法更高效。这个知识点经常出现在面试里属于很典型的“源码细节题”。这下你应该能理解为什么HashMapString, String的 key 查找要用 equals 而不是 。HashMap 的get()流程是先用 key 的 hashCode 定位到桶如果桶里只有一个元素就直接比较引用和 equals如果桶里是链表或红黑树则逐个调用key.equals(k)来判断是否相等。这里用的是 equals 语义因为你在业务里从某个表单拿到一个相同内容的字符串时它和 HashMap 里存的 key 通常不是同一个对象。7. HashMap 查找中 String 比较的实践解析既然是热词里的重点这里再单独展开一下 HashMap 的 get 和 put 过程因为这个过程天然就是一个“String 比较”的实战场景对理解 和 equals 的区别特别有帮助。7.1 put 过程的比较逻辑HashMap.put(key, value)的流程大致是对 key 调用hashCode()得到一个 int 值。通过扰动函数(h key.hashCode()) ^ (h 16)对哈希值做二次混合降低碰撞概率。用(n - 1) hash定位到数组桶下标其中 n 是当前 table 的长度2 的幂。如果该桶为空直接创建 Node 放入。如果该桶不为空则遍历桶内链表或红黑树逐个节点做 key 比较。比较时先判断p.hash hash ((k p.key) key || (key ! null key.equals(k)))。也就是说先比哈希值是否相同再比引用是否相同最后才走到 equals。如果找到相同 key就用新 value 覆盖旧 value返回旧 value如果没有相同 key则新增节点。注意步骤 6 的顺序先比哈希值再比引用最后 equals。这是非常典型的性能优化路径。两个 String 的 hashCode 通常相同才能继续往下比如果哈希值都不问那它们大概率不是同一个字符串内容根本不需要往下走。但你也要明白hashCode 相同不代表内容相同这就是哈希碰撞。所以 HashMap 在哈希值相等后还要继续做引用比较和 equals 比较才能最终确认是不是同一个 key。7.2 get 过程为什么非要用 equalsHashMap.get(key)的流程与 put 查找部分几乎一致计算 key 的 hashCode。定位桶。遍历桶内的节点比较每个节点的 key 和传入的 key 是否相等。找到相等的返回对应的 value找不到返回 null。现在假设你有这样一个场景MapString, String map new HashMap(); map.put(user:1001, 张三); String queryKey new String(user:1001); String value map.get(queryKey);如果 HashMap 用来比较 key那么这里的queryKey和 map 里存的user:1001因为不是同一个引用就会导致 get 返回 null。显然这是不可接受的。所以 HashMap 的 key 比较必须依赖 equals 的内容语义。这就是为什么规范里明确规定作为 HashMap key 的对象必须正确重写 equals() 和 hashCode()否则整个查找逻辑就是错的。7.3 String 作为 HashMap key 的优势正因为 String 本身已经正确实现了 equals 和 hashCode而且它是不可变的String 成为 HashMap key 最常用的选择。不可变意味着它的 hashCode 一旦计算就可以缓存String 内部确实用一个int hash字段缓存了哈希值后续每次 get 都不用重新计算性能非常好。不过在实际开发里我见过不少把大量长字符串作为 key 的设计比如把整个 URL 或者一大段 JSON 字符串作为 key。这种方案虽然在功能上没问题但会带来两个问题一是 hashCode 计算需要遍历所有字符key 太长会让 put/get 变慢二是长字符串本身占用内存较多map 里保存的都是长字符串内存成本很高。这时候可以考虑用唯一 ID、枚举、或者对字符串做哈希摘要需要权衡可读性和唯一性。7.4 为什么有时 string 比较在 HashMap 里“没有触发 equals”有读者可能会好奇我在 HashMap 的 debug 里明明看到 get 没有进 equals 也返回了正确结果这是为什么答案就在那段(k p.key) key的引用比较上。如果你传入的 key 字符串与 map 里的 key 是同一个常量池引用HashMap 能在引用比较阶段直接判定相等就不会再进 equals 了。这属于短路优化的正常路径不是 bug。但不要因此养成“HashMap 的 key 比较不一定走 equals”的错觉。引用相等只是偶然的优化路径equals 才是兜底的正确语义。你要保证自己自定义的类放入 HashMap 时equals 和 hashCode 是正确的才能让程序在任何引用关系下都能正常工作。8. 常见 String 比较错误与排查技巧这部分是全文的精华把我在实际工作和 Code Review 中遇到的高频问题整理成一份“避坑手册”。按问题现象、根本原因、解决方案三列来梳理方便你后续查阅。8.1 常见问题速查表问题现象根本原因解决方案相同内容的字符串返回 false两个字符串对象引用不同一个来自常量池、一个来自运行时创建改用equals()或Objects.equals()在局部测试正常、上线后出问题不同的类加载或字符串来源导致常量池命中情况不同统一使用 equals 比较不要依赖常量池偶然性用str.equals(常量)时抛空指针str为 null用常量.equals(str)或Objects.equals(str, 常量)循环里拼接字符串性能极差每次拼接都创建新 String 和临时 StringBuilder改用StringBuilder.append()substring后出现内存泄漏老 JDKJDK 7 前 substring 共享原始 char[]升级 JDK或复制字符串自定义对象放入 HashMap 后 get 返回 null没有重写 equals/hashCode正确重写两个方法保持 hash 一致StringBuffer 转 String 后又改 StringBuffer原 String 变化早期 JDK 共享数组导致新 JDK 已修复使用 JDK 8toString()后不影响这个表格里的每一条我都踩过或者帮同事排查过。最离谱的是第三条str.equals(常量)空指针的问题几乎每季度都会在某个项目里出现一次有人就是因为“觉得常量放前面丑”所以不肯改写法直到线上 NPE 了才后悔。我后来把常量前置变成团队 Checkstyle 规则了。8.2 排查“字符串比较失败”的标准思路当你遇到一个“明明内容一样比较结果却是 false”的现场我建议按下面这个顺序排查先确认两个值到底是 String 类型还是其他类型。有些框架用 CharSequence、char[]、或者 Optional 包裹内容看起来一样但类型不同equals 直接 false。打印两个字符串的System.identityHashCode()和hashCode()。identityHashCode 不同说明引用不同hashCode 不同说明内容确实不一样极罕见碰撞情况。检查字符串里有没有不可见字符比如行尾多了\r、\n或者全角空格。排查不可见字符最有效的方法是把字符串转成字节数组逐个打印 int 值。我有一次排查了一个多小时最后发现数据库里多个\r。确认比较的一方是否被 trim 过。用户输入和数据库存储经常带首尾空格直接等于一个没有 trim 的值自然就是 false。检查代码是否在比较前做了编码转换比如 UTF-8 和 GBK 转换后内容字节不一致也会导致 String 内容不同。第 3 条是很多人的盲区我换成代码演示一下String origin abc; String weird abc\r; // 注意末尾的 \r System.out.println(origin.equals(weird)); // false System.out.println(Arrays.toString(weird.getBytes(StandardCharsets.UTF_8))); // 输出 [97, 98, 99, 13]最后多了一个 13字符不可见时肉眼完全看不出来这就是为什么一定要用字节数组排查。\r是 13\n是 10全角空格是 -17/-69/-65UTF-8 编码三个字节。这个技巧在对接第三方接口时特别好用因为对方返回的字符串偶尔就会夹带这些不可见字符。8.3 日志相关的比较技巧如果是线上问题在关键比较前打日志特别要注意输出格式log.info(compare result: left[{}], right[{}], equals{}, left, right, Objects.equals(left, right));用[]包裹待比较字符串可以非常直观地看出一侧是否有空格或空串。很多线上 bug 一看日志左右两侧长度不同立刻就能锁定是空格问题。另外你还可以在日志里把两侧字符串的长度打出来log.info(left length{}, right length{}, left.length(), right.length());这个习惯帮我快速区分“空串”和“null”的问题也方便直接在日志里直观判断不可见字符。排在日志后面的 equals 结果用 Objects.equals 而不是left.equals(right)避免 left 为 null 时日志本身先炸了。8.4 常用工具类推荐我实际开发中最常用的字符串比较和判空方式是Objects.equals(a, b)适合两个可能为 null 的变量互相比较。常量.equals(variable)旧式写法空指针安全大量出现在老代码中。StringUtils.equals(a, b)Spring 或 Apache Commons Lang 提供的方法底层就是Objects.equals增强比 JDK 原生更顺手的还有忽略大小写等扩展。str null || str.isEmpty()显式表达判空逻辑时用阅读最直观。str.isBlank()JDK 11判断空白字符串很好用。在用StringUtils.equals这类工具时要留意你引用的到底是谁家的工具类。Spring 的StringUtils.equals和 Apache Commons 的StringUtils.equals对 null 的处理略有差异不过核心都正确。我自己偏好 JDK 自带的Objects.equals因为零依赖、无歧义团队在任何项目里都能直接用。9. String 比较之外的周边知识点编码转换、长字符串与本地化热搜词里有一些看起来和 String 比较不太直接相关但其实紧密关联的主题这一节把它们一次性串起来。9.1 UTF-8 编码转换中的比较注意点如果你做 C# 或 Java 服务端开发经常需要把字符串转成 UTF-8 字节流再传输。这里面有个经典陷阱同一个字符串在不同编码下的字节内容不同转换后再转回来就可能导致内容不一致从而让 equals 失败。String str 中文; byte[] utf8Bytes str.getBytes(StandardCharsets.UTF_8); String converted new String(utf8Bytes, StandardCharsets.UTF_8); System.out.println(str.equals(converted)); // true正常情况 byte[] gbkBytes str.getBytes(Charset.forName(GBK)); String fromGbk new String(gbkBytes, StandardCharsets.UTF_8); // 可能乱码不一定但内容语义已经变了当你用错误的编码去解码字节数组时可能得到一串乱码字符串此时 equals 自然 false。更隐蔽的情况是解码不报错但某些字符被替换成了 UFFFD替换符肉眼根本看不出来。这就是为什么我建议在跨系统交互中约定好统一使用 UTF-8并显式声明编码不要依赖平台默认编码getBytes()无参版本的闹剧已经很多了。另外Oracle 导入时报ORA-01704: string literal too long的错误本质上是一个字符串字面量超过 4000 字节的数据库限制问题。这时候你需要把超长字符串拆分成多个小段拼接或用 CLOB 字段。这个错误和字符串比较无关但排查过程也会涉及到字符串截断、编码长度计算属于 String 周边的高频问题。9.2 超长字符串字面量的处理策略在代码里写一个特别长的字符串常量比如几千字的文案、一大段 SQL除了编译期会占用常量池空间还有一个隐患是代码可读性很差。实践里更合适的做法是把长文案放到资源文件或配置中心通过 key 读取。比如 C# 的本地化资源文件resxJava 的 ResourceBundle都能优雅地解决“长字符串嵌入代码”的问题。热搜里 “combox string 本地化” 大概就是这个场景的典型下拉框ComboBox的显示文本要根据语言环境切换本质是把一组字符串键值对按语言环境映射。这里的逻辑核心就是字符串查找与比较——用户选择某个 value后台拿它和配置项做 equals 匹配。但为了健壮性建议使用语义化 key 作为匹配依据而不是用显示文本本身。因为显示文本可能随语言变化你在一种语言下用 equals 比较是好的换成另一种语言就全对不上了。9.3 敏感信息的字符串处理如果一个字符串是密码、Token 这类敏感信息比如热词里出现的“secret string value”那就不能在日志里直接打印完整值。我把这种字符串的日志统一脱敏成只保留前几位和后几位。比较敏感字符串时同样使用 equals但要注意别把它们的值顺手打进日志if (Objects.equals(inputSecret, storedSecret)) { // 但是这里的 storedSecret 一般不会以明文存储应该比对哈希值 }实践中直接比对明文敏感串的场景其实很少更安全的做法是比对哈希值或使用专门的密钥校验算法。只要设计到脱敏日志里的 equals 结果无论 true 还是 false都不要输出两侧明文。10. 项目中的一点总结与建议客观地说和equals()这个知识点并不难但它背后牵扯到 JVM 内存、编译器优化、集合框架的哈希比较机制、跨语言设计差异是一块非常典型的“小切口、大纵深”内容。把这块彻底理解透对排查线上字符串相关的疑难杂症特别有帮助。我个人在实际操作中的体会是写 Java 代码时除非你能确认两个字符串引用一定相同比如两个变量都来自同一个常量池字面量且没有任何运行时转换否则一律用 equals 或者 Objects.equals 比较内容。这甚至不是一个性能问题因为 String.equals 的第一步本身就是引用判断你直接调 equals 并不会比先写一个再写一个 equals 多出多少开销反而你额外写判断一旦判断错误就会引发逻辑分支紊乱隐患远大于那点理论上的性能收益。最后再分享一个我自己坚持了很多年的习惯每次新建一个实体类我都强制自己重写 equals 和 hashCode并用 IDE 的辅助功能生成标准实现。虽然这些类不一定马上会进入 HashSet 或 HashMap但提前写好了以后把它作为 key 或用于去重时就不会有隐蔽的坑。String 它自己做得很好我们自己写的类也要向它看齐。这个习惯帮我省掉了大量后面排查集合 bug 的时间值得你参考。