17370845950

字符串格式化效率排序为：直接拼接（+）＞StringBuilder＞MessageFormat＞String.format；高频场景用+或StringBuilder，国际化用MessageFormat，调试日志可用String.format，JDK21 StringTemplate为未来优选。

Java中字符串格式化效率差异主要来自底层实现机制，关键看是否创建中间对象、是否支持缓存、是否需解析格式串。简单拼接最快，String.format最慢但最通用，MessageFormat适合国际化场景，而StringBuilder手动拼接在循环或复杂逻辑中更可控。

直接拼接（+）与 StringBuilder：适合简单、确定性场景

编译期能确定的字符串常量拼接（如 "Hello" + "World"）会被JVM自动优化为单个字符串字面量，零开销。运行时拼接（含变量）则触发隐式StringBuilder构建——单次拼接影响小，但循环内反复用+会频繁新建对象，造成GC压力。

• 推荐：固定模板+少量变量 → 直接用+，简洁且JIT友好
• 推荐：多次追加（尤其循环中）→ 显式用StringBuilder，预设容量避免扩容
• 示例：new StringBuilder(64).append("ID:").append(id).append(", name:").append(name).toString()

String.format：语义清晰但性能开销明显

每次调用都会解析格式字符串（正则匹配占大头）、创建Formatter实例、装箱基本类型、生成新String。JDK 15+虽有小幅优化，但无法规避反射式参数处理和临时对象分配。

• 适用：日志调试、配置提示等对吞吐不敏感的场景
• 避免：高频路径（如Netty编解码、实时计费计算）中使用
• 注意：String.format(Locale.US, ...)比无Locale参数略快，因跳过本地化查找

MessageFormat：专为多语言设计，非通用高性能方案

内部基于模式解析+缓存Format子类（如NumberFormat），首次解析慢，后续复用快；但线程不安全，需自行同步或每个线程独享实例。它不优化字符串拼接本身，而是解决“同一模板适配不同语言数字/日期格式”的问题。

• 只在需要i18n（如{0,date} {1,number,currency}）时选用
• 高频使用建议预热：构造一次后长期复用其format(Object[])方法
• 不要用它替代String.format做简单占位符替换，得不偿失

进阶选择：StringTemplate（JDK 21+ 预览特性）与第三方库

JDK 21引入StringTemplate（需开启预览），编译期校验插值语法，运行时零解析开销，本质是语法糖+高效StringBuilder封装。目前仍预览中，生产环境慎用。

• 轻量替代：Apache Commons Text 的 StrSubstitutor（支持递归、自定义前缀）
• 极致性能：Log4j2 的ParameterizedMessage（延迟格式化，不打印就不解析）
• 模板引擎：仅当需动态模板（如HTML邮件）才考虑Freemarker/Thymeleaf，别为简单拼接引入重量级依赖

基本上就这些。选方案先问自己：是否高频？是否要国际化？模板是否固定？满足前两条就绕开String.format，第三条成立就优先直接拼接或StringBuilder。