Java字符串拼接应据场景选择：编译期常量用+最高效；运行时优先StringBuilder（单线程）或StringBuffer（多线程共享）；避免循环中用+或重复创建对象，注意容量预设与线程安全。
Java 中拼接字符串看似简单，但不同方式对内存和性能影响很大。频繁用 + 拼接、滥用 String.concat() 或不加控制地创建大量中间字符串，容易引发堆内存压力和 GC 频繁。关键在于：小规模、编译期确定的拼接用 +；运行时动态拼接优先选 StringBuilder（单线程）或 StringBuffer（多线程）；避免在循环中反复创建新 String 对象。
编译期拼接：直接用 + 反而最高效
当所有操作数都是字面量或编译期可确定的常量时（如 "a" + "b" + "c"），Javac 会在编译阶段合并为一个字符串常量，不会产生运行时开销。即使含 final 字段（如 final String s = "x"; String t = s + "y";），也可能被优化。
- ✅ 推荐场景：配置路径、SQL 片段、日志固定前缀等静态拼接
- ❌ 不适用：变量参与且值在运行时才确定（如
str1 + str2），此时+实际被编译为StringBuilder.append()调用，但若在循环中使用，会重复新建对象
运行时拼接：首选 StringBuilder
对于运行时拼接（尤其是循环、方法调用中），StringBuilder 是标准方案。它内部基于可变字符数组，append 操作复用同一块内存，避免每次生成新对象。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 初始化时尽量指定容量（如
new StringBuilder(128)），减少数组扩容拷贝 - 避免在循环内重复创建
StringBuilder实例（如“每轮 new 一个再 toString”），应复用实例或在循环外创建 - 示例：低效 —
String s = ""; for (String item : list) s += item;；高效 —StringBuilder sb = new StringBuilder(); for (String item : list) sb.append(item); String s = sb.toString();
多线程环境：用 StringBuffer 或同步处理
StringBuffer 是 StringBuilder 的线程安全版本，所有方法加了 synchronized。若拼接逻辑天然并发（如多个线程往同一个缓冲区写），可直接用它；但多数情况下，更推荐将拼接逻辑限制在单线程内，或用局部 StringBuilder + 显式同步/分段拼接后合并，避免锁竞争。
立即学习“Java免费学习笔记（深入）”；
- 不要为了“线程安全”盲目用
StringBuffer，除非真有共享实例被多线程调用 - 若需并发构建多个字符串，每个线程用自己
StringBuilder实例，完全无锁 - 高并发下还可考虑
ThreadLocal<stringbuilder></stringbuilder>复用实例，减少对象分配
其他优化技巧与避坑点
除了主流程选择，还有几个细节直接影响内存效率：
- 用
Objects.toString(obj, "")替代obj == null ? "" : obj.toString()，减少条件分支和临时字符串 - 避免隐式装箱拼接，如
"id=" + id（id 是 int）——虽然编译器会优化，但明确用sb.append("id=").append(id)更可控 - JDK 9+ 的字符串压缩（compact strings）已默认启用，对纯 Latin-1 字符串节省一半内存，无需额外干预
- 大量文本拼接（如模板渲染）可考虑
StringJoiner或第三方库（如 Apache Commons Lang 的StrBuilder），语义更清晰且支持分隔符自动处理
