java编译器javac仅对字符串常量拼接做编译期折叠，不生成stringbuilder；jit在运行时对热点代码中的循环拼接等特定模式进行优化；手动使用stringbuilder最可靠。
Java 编译器（javac）本身不会把任意 String 拼接都优化成 StringBuilder；真正起作用的是 JVM 的即时编译器（JIT），而且仅限于特定场景——最典型的是 字符串常量拼接 和 循环内可识别的字符串累积。很多人误以为 javac 会重写字节码，其实它只做简单常量折叠，复杂优化由 HotSpot JIT 在运行时完成。
编译期：javac 只做常量折叠，不生成 StringBuilder
javac 对 纯字符串字面量拼接（如 "a" + "b" + "c"）会在编译时直接合并为一个常量 "abc"，字节码中根本不会出现 StringBuilder 调用。这不是优化成 StringBuilder，而是直接消除拼接过程。
- 示例：
String s = "Hello" + " " + "World";→ 编译后等价于String s = "Hello World"; - 只要所有操作数都是编译期常量（final 字符串、字面量、常量表达式），javac 就折叠；一旦含变量（如
str + "abc"），就无法折叠
运行期：JIT 在热点代码中识别模式并内联优化
HotSpot JVM 的 C2 编译器在方法被频繁执行（成为热点）后，会分析字节码和控制流。对形如 for 循环中反复执行 s += "x" 的模式，JIT 可能将整个循环优化为等效的 StringBuilder 构建逻辑（包括预分配容量、append 调用等），甚至进一步内联或向量化。
- 触发条件：方法调用次数足够多（默认阈值约 10000 次），且拼接模式稳定可推断
- 注意：这种优化是透明的、不可见的，你查不到 StringBuilder 实例，也看不到新字节码——它是 JIT 的中间表示（IR）级变换
- 若循环中拼接对象类型不固定（如混用 String、int、null），或存在分支干扰，JIT 可能放弃优化
手动使用 StringBuilder 才是最可靠、最可控的方式
依赖 JIT 优化有不确定性：开发环境可能未触发（未达热点）、不同 JVM 版本策略不同、代码稍作改动（如加个日志）就导致优化失效。明确写出 StringBuilder，既语义清晰，又保证性能。
- 推荐写法：
StringBuilder sb = new StringBuilder(); for (...) sb.append(item); return sb.toString(); - 避免
+=在循环里拼接大量字符串——即使 JIT 有时能优化，也不如手写直观、稳定、易维护 - 小规模拼接（2~3 个变量）用
String.join()或MessageFormat更可读，不必强求 StringBuilder
如何验证是否被优化？别看字节码，要看 JIT 日志
反编译 class 文件看到的仍是 new StringBuilder().append(...).toString() 或 + 运算符，这不代表运行时行为。要确认 JIT 是否优化，需开启 JVM 参数观察：
-
-XX:+UnlockDiagnosticVMOptions -XX:+PrintCompilation：看方法是否被 C2 编译 -
-XX:+TraceClassLoading -XX:+LogCompilation（配合hotspot.log分析）：查看优化详情，搜索 “string concatenation” 相关节点 - 工具如 JITWatch 可图形化展示 IR 变换过程，比手动读日志更直观
不复杂但容易忽略：javac 做常量折叠，JIT 做运行时模式优化，而人该做的，是写清楚意图——该 StringBuilder 就明写，该常量就写死，别指望编译器替你猜。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
