原理及最佳实践)
开头用过 Java 的都知道字符串比较有个老生常谈却总让人栽跟头的话题和equals()到底有什么区别我之前带过好几个新人第一次写用户登录判断时都写过admin.equals(inputName)或者直接inputName admin结果有的能跑通有的死活匹配不上。后来我发现很多人其实没搞明白这两个比较符背后的机制只是背了个“字符串要用 equals 比较”的结论一旦遇到new String()、拼接、常量池这些场景就懵了。这篇文章我就从底层原理开始把String的和equals()彻底掰开揉碎讲清楚。内容会覆盖字符串常量池、intern()方法、常见误区和实际项目中的最佳实践还会顺便聊聊为什么有的语言没有这个烦恼、哪些场景容易踩坑。不管你是刚学 Java 的新手还是写了好几年代码偶尔还会被字符串比较坑到的老手这篇文章都值得花几分钟认真过一遍。1. 一次线上事故引发的思考字符串比较为什么这么容易出错1.1 一个典型的登录判断 Bug先讲一个我实际遇到过的例子。当时有个同事写了一段用户鉴权代码大致逻辑是这样的String input request.getParameter(username); if (input admin) { // 放行 }本地测试的时候前端传过来的是表单提交的字符串居然能正常通过。因为 Tomcat 解析参数时某些情况下拿到的字符串和常量池里的admin是同一个对象。但换到另一个环境或者改了一下框架版本突然就登录不上了。排查了半天最后发现就是在作怪。这个问题看起来简单但它背后藏着的机制一点都不简单。要彻底理解你得先搞清楚 JVM 里String对象到底是怎么创建和存储的。1.2 先看和equals()的本质区别比较的是“引用”也就是两个变量指向的内存地址是否相同。equals()默认情况下也是比较引用但String类重写了equals()改成了比较“内容”——也就是每个字符是否完全一致。所以问的是“你们两个是不是同一个对象”equals()问的是“你们两个代表的内容是否一致”。前者走地址后者走内容。但有一个关键点很多人容易忽略String有一个字符串常量池String Pool机制。如果你直接写一个字面量abcJVM 会去常量池里找有没有相同内容的对象有就直接复用。这就导致某些情况下两个不同变量用比较也会返回true因为它们在底层就是同一个对象。这种“偶尔等于”的迷惑行为正是无数 Bug 的来源。2. 字符串常量池与new String()背后的真相2.1 字面量创建与常量池复用先看这段代码String s1 java; String s2 java; System.out.println(s1 s2); // true System.out.println(s1.equals(s2)); // trues1和s2都指向常量池里的同一个java对象所以也是true。再看这段String s3 new String(java); System.out.println(s1 s3); // false System.out.println(s1.equals(s3)); // truenew String(java)虽然内容也是java但它在堆上新建了一个对象和常量池里的对象不是同一个引用所以是falseequals()是true。这里要啰嗦一句new String(java)其实创建了两个对象——一个是编译期就确定的字符串字面量java存放在常量池另一个是运行时通过new创建的对象存放在堆内存。虽然常量池中存在相同内容JVM 不会因为你要 new 就跳过创建new就是无条件新建一个对象。2.2 为什么说new String()在实践中应该尽量避免很多刚接触 Java 的人会困惑既然有new String(xxx)这种写法什么时候该用呢我的答案是绝大多数业务代码里根本不该用。原因有几个每次new都在堆里多创建一个对象浪费内存如果被用到高频比较场景还要承担equals()的逐字符比较开销代码可读性变差别人一看new String(xxx)就会怀疑你是不是有什么特殊目的。除非你确实需要一个全新的、可独立修改的字符串副本比如从已有字符串里截取一小段否则直接写字面量就好。注意哪怕是一个字母都不差的内容也可能返回false永远不要用判断字符串内容是否相等。2.3 字符串拼接对比较结果的影响字符串拼接是重灾区。很多人以为拼接出来的字符串和字面量一定一样实际不然String a hello; String b hello; String c a b; // 运行时拼接产生新对象 String d hellohello; System.out.println(c d); // false System.out.println(c.equals(d)); // true但如果拼接的两个部分都是编译期常量情况又不一样了final String a hello; final String b hello; String c a b; String d hellohello; System.out.println(c d); // true编译期就已经确定这个例子特别能说明问题final修饰的常量在编译期被替换为字面量a b在编译期就变成了hellohello所以c和d指向同一个常量池对象。而普通变量的拼接是在运行时通过StringBuilder完成的生成的是新对象。3.intern()手动将字符串“入池”3.1intern()到底做了什么如果你确实有一个运行时才产生的字符串但希望它能够复用一个池里的对象可以用intern()方法String s1 new String(java).intern(); String s2 java; System.out.println(s1 s2); // true原理是intern()会去常量池查找内容相同的字符串如果存在就返回池里的引用如果不存在就在池中创建这个字符串并返回引用。所以调用intern()之后的结果就变成了true。3.2 什么时候需要intern()intern()看起来是个好东西但我在实际项目中见过的使用场景非常少。比较典型的一个是你接收了大量外部输入并且这些输入会被反复当作 Map 的 key 使用。如果同一个字符串出现很多次每次都创建新对象内存占用会很高。这时候intern()能帮你把重复字符串收敛到常量池减少内存压力。但intern()也有自己的坑常量池包括 JDK7 之后移入堆的字符串常量池是全局共享的如果你的字符串数量特别庞大频繁调用intern()会给 GC 带来额外负担。代码可读性变差别人看到intern()还要想半天你为什么这么写。如果字符串本身只有很短的生命周期intern()的收益几乎可以忽略。所以我的建议是默认不要用intern()只有当你能明确证明内存确实被大量重复字符串撑爆时才考虑用它而且最好先在压测环境验证收益。4. 实操案例从代码层面验证和equals()4.1 一组能直接运行的验证代码下面这段代码我建议你亲手跑一遍看看输出结果是不是和你预期一致public class StringCompareDemo { public static void main(String[] args) { String s1 abc; String s2 abc; String s3 new String(abc); String s4 s3.intern(); System.out.println(s1 s2: (s1 s2)); System.out.println(s1 s3: (s1 s3)); System.out.println(s1.equals(s3): s1.equals(s3)); System.out.println(s1 s4: (s1 s4)); String base ab; String plus base c; System.out.println(s1 plus: (s1 plus)); System.out.println(s1.equals(plus): s1.equals(plus)); } }输出结果会是这样s1 s2: true s1 s3: false s1.equals(s3): true s1 s4: true s1 plus: false s1.equals(plus): true注意s1 plus这一行base c在运行时拼接虽然结果也是abc但它是一个新建对象所以和常量池里的s1不是同一个引用。4.2 代码背后的字节码视角如果你用javap -c反编译上面的代码会发现abc字面量的加载使用的是ldc指令它会直接去常量池拿对象new String(abc)使用的是newinvokespecial init真的在堆里构造对象base c在编译后对应的是new StringBuilder()append()toString()除非编译器做了常量折叠优化。看字节码能帮你建立更直观的认识哪些字符串在编译期就确定了哪些是运行时才生成的决定了最终的结果。这也是面试官喜欢追问的细节建议花半小时自己用javap看看比死背结论管用得多。5. 各种常见场景的差异对照表为了方便查阅我把平时最容易遇到的字符串比较场景整理成一个速查表场景结果equals()结果原因abc abctruetrue字面量都指向常量池同一个对象字面量与new String(abc)falsetrue一个在常量池一个在堆内容相同两个new String(abc)falsetrue两个堆对象互相没有引用关系普通变量拼接base c与abcfalsetrue拼接在运行时产生新对象final 常量拼接(a b)与abtruetrue编译期常量折叠指向同一常量池对象intern()之后的字符串与字面量truetrueintern()返回常量池引用这个表基本覆盖了 90% 的项目场景。剩下的 10%比如StringBuilder转String、StringBuffer转String、从集合里取出来的字符串核心判断方法都是一样的看它是不是常量池里的同一个对象。5.1 顺手说说StringBuffer和StringBuilder的比较看到热词里有人搜“stringbuffer 转换为 string”这里补充一个点StringBuffer和StringBuilder都没有重写equals()它们继承的是Object的默认实现比较的是引用地址。所以你要比较两个StringBuilder的内容是否一致必须先toString()转成String再调用equals()。StringBuilder sb1 new StringBuilder(abc); StringBuilder sb2 new StringBuilder(abc); System.out.println(sb1.equals(sb2)); // falseObject 的 equals 比较引用 System.out.println(sb1.toString().equals(sb2.toString())); // true这个坑比String本身的坑还要隐蔽因为很多人想当然地以为equals()在任何对象上都是比较内容。记住只有被重写过的类才比较内容比如String、Integer、Long等包装类。6. 这些场景最容易踩坑请对号入座6.1 从集合或 Map 中取出的字符串很多人在写业务逻辑时会把从HashMap里取出来的值和某个字面量比较MapString, String map new HashMap(); map.put(key, abc); String value map.get(key); if (value abc) { // 不推荐 // 业务逻辑 }这里map.get()返回的字符串来自put进去的abc字面量如果中间没有任何操作它其实就是常量池里的abc可能为true。但假如这个字符串是从文件、数据库、网络接口读进来的或者经历过拼接、截取就会变为false。这种“时灵时不灵”的行为比永远错误还难排查。我的建议很简单只要是从外部数据源或运行时动态生成的字符串一律用equals()哪怕是确定来自字面量的字符串为了代码一致性也统一用equals()。6.2 参数校验和枚举匹配还有一个常见场景是状态判断if (SUCCESS.equals(result.getStatus())) { // 处理成功逻辑 }这里我推荐把常量写在前面用SUCCESS.equals(...)而不是result.getStatus().equals(SUCCESS)。原因有两个如果result.getStatus()为null前者返回false不会抛空指针后者会立刻NullPointerException。代码意图更明确一看就知道你是在拿状态码和常量比较。至于为什么不在这种场景用答案已经讲过无数遍因为result.getStatus()大概率不是直接来自常量池的字面量。6.3 编辑器和 IDE 的优化提示现在的主流 IDEIDEA、Eclipse都会在你写字符串变量 字符串常量时给出黄色警告一般会提示String comparison using or !。很多人直接忽略或者干脆设置了忽略警告这是非常危险的习惯。建议任何条件下都不要把这类警告关掉它基本等于在帮你挡 Bug。如果代码里真的必须按引用比较字符串比如某些内部缓存优化建议显式注释说明原因避免后来者一头雾水或者“好心”帮你改掉。7. 为什么其他语言没有这个烦恼有同学可能会问为什么 C# 里和String.Equals()结果基本一致为什么 Python、JavaScript 里字符串比较和 Java 不一样这里简单对比一下C#虽然字符串也是引用类型但它重载了运算符使得在字符串上等价于逐字符比较内容。所以 C# 程序员很少纠结这个问题。Python直接比较内容没有这种困惑但要注意is比较的是对象身份和 Java 的类似。JavaScript会做类型转换字符串与字符串比较时按内容比较也是内容比较。所以 JS 里也没有这个问题。Go用于字符串比较时是内容比较直接支持。Java 之所以特殊是因为它既保留了引用比较的语义又让String通过常量池做到了字面量复用于是在“碰巧引用相同”的情况下会返回true造成了行为和直觉相悖。其实 JDK 也考虑过类似 C# 的做法但为了兼容性和历史惯性始终没有这么改。所以作为 Java 开发者只能老老实实记住规则比较字符串内容永远用equals()。注意如果你正在写的是其他语言不要盲目套用 Java 的结论先确认该语言字符串的相等语义实现。8. 总结性的实战建议与个人经验最后直接给出我在项目里沉淀下来的一套规则希望对你有用绝大多数情况两个字符串比较内容是否相等用equals()永远不用。一个例外情况你要判断两个字符串变量是否指向同一个对象比如做性能优化、验证常量池复用才用并且一定要写注释说明。空指针规避理想写法是常量.equals(变量)或Objects.equals(变量, 常量)避免变量为null时崩溃。注意StringBuffer/StringBuilder它们没有重写equals()内容比较前先toString()。能用final就多用final编译期常量折叠可以让在字面量比较中返回true但不要依赖它做业务判断。intern()慎用不是不能碰而是要有明确的收益和测试数据支撑。团队约定代码评审时凡是看到字符串用比较的一律打回除非你能说出非用不可的理由。我个人在实际排查中最大的体会是字符串比较问题90% 都能靠“无脑用 equals”化解剩下 10% 是理解机制后的主动选择。只要你把常量池和equals()重写的原理记住遇到任何“诡异”的比较结果都不会慌。希望这篇文章能帮你少走一次弯路哪怕只帮你避免一个线上 Bug我觉得就值了。
Java字符串比较：==与equals()原理及最佳实践
开头用过 Java 的都知道字符串比较有个老生常谈却总让人栽跟头的话题和equals()到底有什么区别我之前带过好几个新人第一次写用户登录判断时都写过admin.equals(inputName)或者直接inputName admin结果有的能跑通有的死活匹配不上。后来我发现很多人其实没搞明白这两个比较符背后的机制只是背了个“字符串要用 equals 比较”的结论一旦遇到new String()、拼接、常量池这些场景就懵了。这篇文章我就从底层原理开始把String的和equals()彻底掰开揉碎讲清楚。内容会覆盖字符串常量池、intern()方法、常见误区和实际项目中的最佳实践还会顺便聊聊为什么有的语言没有这个烦恼、哪些场景容易踩坑。不管你是刚学 Java 的新手还是写了好几年代码偶尔还会被字符串比较坑到的老手这篇文章都值得花几分钟认真过一遍。1. 一次线上事故引发的思考字符串比较为什么这么容易出错1.1 一个典型的登录判断 Bug先讲一个我实际遇到过的例子。当时有个同事写了一段用户鉴权代码大致逻辑是这样的String input request.getParameter(username); if (input admin) { // 放行 }本地测试的时候前端传过来的是表单提交的字符串居然能正常通过。因为 Tomcat 解析参数时某些情况下拿到的字符串和常量池里的admin是同一个对象。但换到另一个环境或者改了一下框架版本突然就登录不上了。排查了半天最后发现就是在作怪。这个问题看起来简单但它背后藏着的机制一点都不简单。要彻底理解你得先搞清楚 JVM 里String对象到底是怎么创建和存储的。1.2 先看和equals()的本质区别比较的是“引用”也就是两个变量指向的内存地址是否相同。equals()默认情况下也是比较引用但String类重写了equals()改成了比较“内容”——也就是每个字符是否完全一致。所以问的是“你们两个是不是同一个对象”equals()问的是“你们两个代表的内容是否一致”。前者走地址后者走内容。但有一个关键点很多人容易忽略String有一个字符串常量池String Pool机制。如果你直接写一个字面量abcJVM 会去常量池里找有没有相同内容的对象有就直接复用。这就导致某些情况下两个不同变量用比较也会返回true因为它们在底层就是同一个对象。这种“偶尔等于”的迷惑行为正是无数 Bug 的来源。2. 字符串常量池与new String()背后的真相2.1 字面量创建与常量池复用先看这段代码String s1 java; String s2 java; System.out.println(s1 s2); // true System.out.println(s1.equals(s2)); // trues1和s2都指向常量池里的同一个java对象所以也是true。再看这段String s3 new String(java); System.out.println(s1 s3); // false System.out.println(s1.equals(s3)); // truenew String(java)虽然内容也是java但它在堆上新建了一个对象和常量池里的对象不是同一个引用所以是falseequals()是true。这里要啰嗦一句new String(java)其实创建了两个对象——一个是编译期就确定的字符串字面量java存放在常量池另一个是运行时通过new创建的对象存放在堆内存。虽然常量池中存在相同内容JVM 不会因为你要 new 就跳过创建new就是无条件新建一个对象。2.2 为什么说new String()在实践中应该尽量避免很多刚接触 Java 的人会困惑既然有new String(xxx)这种写法什么时候该用呢我的答案是绝大多数业务代码里根本不该用。原因有几个每次new都在堆里多创建一个对象浪费内存如果被用到高频比较场景还要承担equals()的逐字符比较开销代码可读性变差别人一看new String(xxx)就会怀疑你是不是有什么特殊目的。除非你确实需要一个全新的、可独立修改的字符串副本比如从已有字符串里截取一小段否则直接写字面量就好。注意哪怕是一个字母都不差的内容也可能返回false永远不要用判断字符串内容是否相等。2.3 字符串拼接对比较结果的影响字符串拼接是重灾区。很多人以为拼接出来的字符串和字面量一定一样实际不然String a hello; String b hello; String c a b; // 运行时拼接产生新对象 String d hellohello; System.out.println(c d); // false System.out.println(c.equals(d)); // true但如果拼接的两个部分都是编译期常量情况又不一样了final String a hello; final String b hello; String c a b; String d hellohello; System.out.println(c d); // true编译期就已经确定这个例子特别能说明问题final修饰的常量在编译期被替换为字面量a b在编译期就变成了hellohello所以c和d指向同一个常量池对象。而普通变量的拼接是在运行时通过StringBuilder完成的生成的是新对象。3.intern()手动将字符串“入池”3.1intern()到底做了什么如果你确实有一个运行时才产生的字符串但希望它能够复用一个池里的对象可以用intern()方法String s1 new String(java).intern(); String s2 java; System.out.println(s1 s2); // true原理是intern()会去常量池查找内容相同的字符串如果存在就返回池里的引用如果不存在就在池中创建这个字符串并返回引用。所以调用intern()之后的结果就变成了true。3.2 什么时候需要intern()intern()看起来是个好东西但我在实际项目中见过的使用场景非常少。比较典型的一个是你接收了大量外部输入并且这些输入会被反复当作 Map 的 key 使用。如果同一个字符串出现很多次每次都创建新对象内存占用会很高。这时候intern()能帮你把重复字符串收敛到常量池减少内存压力。但intern()也有自己的坑常量池包括 JDK7 之后移入堆的字符串常量池是全局共享的如果你的字符串数量特别庞大频繁调用intern()会给 GC 带来额外负担。代码可读性变差别人看到intern()还要想半天你为什么这么写。如果字符串本身只有很短的生命周期intern()的收益几乎可以忽略。所以我的建议是默认不要用intern()只有当你能明确证明内存确实被大量重复字符串撑爆时才考虑用它而且最好先在压测环境验证收益。4. 实操案例从代码层面验证和equals()4.1 一组能直接运行的验证代码下面这段代码我建议你亲手跑一遍看看输出结果是不是和你预期一致public class StringCompareDemo { public static void main(String[] args) { String s1 abc; String s2 abc; String s3 new String(abc); String s4 s3.intern(); System.out.println(s1 s2: (s1 s2)); System.out.println(s1 s3: (s1 s3)); System.out.println(s1.equals(s3): s1.equals(s3)); System.out.println(s1 s4: (s1 s4)); String base ab; String plus base c; System.out.println(s1 plus: (s1 plus)); System.out.println(s1.equals(plus): s1.equals(plus)); } }输出结果会是这样s1 s2: true s1 s3: false s1.equals(s3): true s1 s4: true s1 plus: false s1.equals(plus): true注意s1 plus这一行base c在运行时拼接虽然结果也是abc但它是一个新建对象所以和常量池里的s1不是同一个引用。4.2 代码背后的字节码视角如果你用javap -c反编译上面的代码会发现abc字面量的加载使用的是ldc指令它会直接去常量池拿对象new String(abc)使用的是newinvokespecial init真的在堆里构造对象base c在编译后对应的是new StringBuilder()append()toString()除非编译器做了常量折叠优化。看字节码能帮你建立更直观的认识哪些字符串在编译期就确定了哪些是运行时才生成的决定了最终的结果。这也是面试官喜欢追问的细节建议花半小时自己用javap看看比死背结论管用得多。5. 各种常见场景的差异对照表为了方便查阅我把平时最容易遇到的字符串比较场景整理成一个速查表场景结果equals()结果原因abc abctruetrue字面量都指向常量池同一个对象字面量与new String(abc)falsetrue一个在常量池一个在堆内容相同两个new String(abc)falsetrue两个堆对象互相没有引用关系普通变量拼接base c与abcfalsetrue拼接在运行时产生新对象final 常量拼接(a b)与abtruetrue编译期常量折叠指向同一常量池对象intern()之后的字符串与字面量truetrueintern()返回常量池引用这个表基本覆盖了 90% 的项目场景。剩下的 10%比如StringBuilder转String、StringBuffer转String、从集合里取出来的字符串核心判断方法都是一样的看它是不是常量池里的同一个对象。5.1 顺手说说StringBuffer和StringBuilder的比较看到热词里有人搜“stringbuffer 转换为 string”这里补充一个点StringBuffer和StringBuilder都没有重写equals()它们继承的是Object的默认实现比较的是引用地址。所以你要比较两个StringBuilder的内容是否一致必须先toString()转成String再调用equals()。StringBuilder sb1 new StringBuilder(abc); StringBuilder sb2 new StringBuilder(abc); System.out.println(sb1.equals(sb2)); // falseObject 的 equals 比较引用 System.out.println(sb1.toString().equals(sb2.toString())); // true这个坑比String本身的坑还要隐蔽因为很多人想当然地以为equals()在任何对象上都是比较内容。记住只有被重写过的类才比较内容比如String、Integer、Long等包装类。6. 这些场景最容易踩坑请对号入座6.1 从集合或 Map 中取出的字符串很多人在写业务逻辑时会把从HashMap里取出来的值和某个字面量比较MapString, String map new HashMap(); map.put(key, abc); String value map.get(key); if (value abc) { // 不推荐 // 业务逻辑 }这里map.get()返回的字符串来自put进去的abc字面量如果中间没有任何操作它其实就是常量池里的abc可能为true。但假如这个字符串是从文件、数据库、网络接口读进来的或者经历过拼接、截取就会变为false。这种“时灵时不灵”的行为比永远错误还难排查。我的建议很简单只要是从外部数据源或运行时动态生成的字符串一律用equals()哪怕是确定来自字面量的字符串为了代码一致性也统一用equals()。6.2 参数校验和枚举匹配还有一个常见场景是状态判断if (SUCCESS.equals(result.getStatus())) { // 处理成功逻辑 }这里我推荐把常量写在前面用SUCCESS.equals(...)而不是result.getStatus().equals(SUCCESS)。原因有两个如果result.getStatus()为null前者返回false不会抛空指针后者会立刻NullPointerException。代码意图更明确一看就知道你是在拿状态码和常量比较。至于为什么不在这种场景用答案已经讲过无数遍因为result.getStatus()大概率不是直接来自常量池的字面量。6.3 编辑器和 IDE 的优化提示现在的主流 IDEIDEA、Eclipse都会在你写字符串变量 字符串常量时给出黄色警告一般会提示String comparison using or !。很多人直接忽略或者干脆设置了忽略警告这是非常危险的习惯。建议任何条件下都不要把这类警告关掉它基本等于在帮你挡 Bug。如果代码里真的必须按引用比较字符串比如某些内部缓存优化建议显式注释说明原因避免后来者一头雾水或者“好心”帮你改掉。7. 为什么其他语言没有这个烦恼有同学可能会问为什么 C# 里和String.Equals()结果基本一致为什么 Python、JavaScript 里字符串比较和 Java 不一样这里简单对比一下C#虽然字符串也是引用类型但它重载了运算符使得在字符串上等价于逐字符比较内容。所以 C# 程序员很少纠结这个问题。Python直接比较内容没有这种困惑但要注意is比较的是对象身份和 Java 的类似。JavaScript会做类型转换字符串与字符串比较时按内容比较也是内容比较。所以 JS 里也没有这个问题。Go用于字符串比较时是内容比较直接支持。Java 之所以特殊是因为它既保留了引用比较的语义又让String通过常量池做到了字面量复用于是在“碰巧引用相同”的情况下会返回true造成了行为和直觉相悖。其实 JDK 也考虑过类似 C# 的做法但为了兼容性和历史惯性始终没有这么改。所以作为 Java 开发者只能老老实实记住规则比较字符串内容永远用equals()。注意如果你正在写的是其他语言不要盲目套用 Java 的结论先确认该语言字符串的相等语义实现。8. 总结性的实战建议与个人经验最后直接给出我在项目里沉淀下来的一套规则希望对你有用绝大多数情况两个字符串比较内容是否相等用equals()永远不用。一个例外情况你要判断两个字符串变量是否指向同一个对象比如做性能优化、验证常量池复用才用并且一定要写注释说明。空指针规避理想写法是常量.equals(变量)或Objects.equals(变量, 常量)避免变量为null时崩溃。注意StringBuffer/StringBuilder它们没有重写equals()内容比较前先toString()。能用final就多用final编译期常量折叠可以让在字面量比较中返回true但不要依赖它做业务判断。intern()慎用不是不能碰而是要有明确的收益和测试数据支撑。团队约定代码评审时凡是看到字符串用比较的一律打回除非你能说出非用不可的理由。我个人在实际排查中最大的体会是字符串比较问题90% 都能靠“无脑用 equals”化解剩下 10% 是理解机制后的主动选择。只要你把常量池和equals()重写的原理记住遇到任何“诡异”的比较结果都不会慌。希望这篇文章能帮你少走一次弯路哪怕只帮你避免一个线上 Bug我觉得就值了。
