Java中使用==比较String的相等性差异及底层逻辑分析

差异的本质是Java编译器受限于编译阶段可获取的确定信息边界，对不同可确定性的表达式做了符合语言规范的强制适配，并非Java对字符串拼接存在两套独立的池化逻辑。

能命中常量池的拼接场景判定规则 #

按照Java语言规范的强制要求：

• 只要拼接操作的所有操作数都是编译期常量表达式，编译器必须在编译阶段直接完成字符串拼接的折叠，将整段拼接表达式替换为最终结果对应的字符串字面量。
• 示例中的"hello" + " web"，两个操作数都是固定的字符串字面量，没有任何运行期依赖，编译器在编译时就能100%确定拼接结果是"hello web"，不会生成任何运行期拼接逻辑，代码等价于直接写String s1 = "hello web";。
• 这种折叠后生成的字符串字面量，会自然被纳入字符串常量池缓存，因此s1 == s2的引用比对结果为true。

运行期拼接无法命中常量池的原因 #

对于a + b这类拼接场景：

• 示例中的a和b都是普通的可变局部变量，不属于编译期常量。编译器在编译阶段无法100%保证这两个变量运行时的取值，因此不能提前折叠拼接结果。
• 这类拼接逻辑会被编译器转成运行期执行的new StringBuilder().append(a).append(b).toString()流程，最终生成的是堆内存上的全新String对象，不会自动被纳入字符串常量池。
• 正因为生成的对象和常量池中提前缓存的"ab"是不同内存地址的实例，因此check1和check2的引用比对结果均为false。

可验证的补充结论：如果将a和b修饰为编译期常量，a + b的拼接行为会和字面量拼接完全一致：

final String a = "a";
final String b = "b";
String ab = "ab";
// 此时该比对结果为true，因为a+b被编译期折叠为"ab"字面量
boolean check2 = (a + b == ab);

这也能直接证明差异的核心不是拼接动作本身，而是编译期对表达式值的可确定性判断。

常见误区：运行期通过StringBuilder拼接生成的字符串，默认不会自动进入字符串常量池，只有手动调用intern()方法主动触发入池逻辑时，才会和常量池中的已有实例做引用关联。

内容的提问来源于stack exchange，提问作者cottonpower