单线程拼接字符串应首选 stringbuilder。它与 stringbuffer 功能一致但无 synchronized 开销，性能高 5–15 倍；stringbuffer 仅方法级同步，复合操作仍需手动加锁，且现代开发应避免共享可变对象。
单线程拼接字符串，该用 StringBuilder 还是 StringBuffer？
直接结论：StringBuilder 是单线程场景下的明确首选。它和 StringBuffer 功能几乎完全一致，但去掉了所有 synchronized 修饰，避免了锁获取、检查、释放的开销。
实操建议：
- 只要确定当前代码段只被一个线程调用（比如普通方法内、Stream 的
map中、Servlet 的doGet单次请求处理里），就无条件选StringBuilder - 别因为“听说 StringBuffer 更老更稳”就下意识用它——JDK 5 引入
StringBuilder就是为了替代它在单线程下的角色 - 常见错误现象：用
StringBuffer在 for 循环里拼接日志，压测时发现锁竞争导致吞吐掉 10%+，换成StringBuilder后立刻恢复
多线程共享同一个缓冲对象时，StringBuffer 真的安全吗？
安全，但仅限于「方法级别」同步——append()、insert()、delete() 这些公共方法确实加了 synchronized，能防止并发修改导致字符数组越界或内容错乱。
但要注意这些坑：
- 它不保证复合操作原子性。比如
if (sb.length() > 10) sb.delete(0, 5);这种判断+修改，中间可能被其他线程插入，必须手动加锁或改用ReentrantLock - 如果把
StringBuffer当作共享状态在多个线程间传递并频繁读写，性能会明显下降（实测单线程下StringBuilder比StringBuffer快 5–15 倍） - 现代高并发场景更推荐「避免共享可变对象」：每个线程用各自的
StringBuilder，最后用ConcurrentHashMap或BlockingQueue汇总结果
StringBuilder 和 StringBuffer 的底层实现真的一样吗？
95% 一样：都继承 AbstractStringBuilder，底层都是可变的 char[] 数组，扩容策略都是「旧容量 × 2 + 2」，初始容量默认都是 16。
关键差异点在细节：
-
StringBuffer多一个toStringCache字段，用于缓存上一次toString()的结果，避免重复拷贝数组；而StringBuilder每次都重新Arrays.copyOfRange(value, 0, count) -
StringBuffer的每个 public 方法签名都带synchronized，哪怕只是length()或charAt()这种只读操作 - 两者 API 完全兼容，意味着你可以先写
StringBuilder，等真遇到线程安全问题再全局替换为StringBuffer（但通常不该这么干，应重构设计）
为什么 IDE 总提示“Replace StringBuffer with StringBuilder”？
因为绝大多数 Java 工程中的字符串拼接，实际运行路径都是单线程的——HTTP 请求处理、定时任务、批处理脚本、单元测试里的 setup，基本不存在跨线程共用同一实例的场景。
IDE 的警告本质是性能提醒：
- 不是说你用了
StringBuffer就错了，而是它带来了不必要的同步成本 - 即使 JVM 对无竞争的
synchronized做了偏向锁优化，也仍需执行锁状态检查逻辑，比直接调用快不了多少 - 真正需要
StringBuffer的地方极少，比如自定义的静态工具类中暴露了一个全局StringBuffer实例供多处 append（这种设计本身也值得质疑）
最常被忽略的一点：很多人以为“用在多线程环境”就该选 StringBuffer，但其实更关键的是「是否多个线程同时操作同一个实例」。线程多，但各自 new 自己的 StringBuilder，就完全没问题。
