JavaStringBuffer线程安全详解

本文深入剖析了Java中StringBuffer的线程安全特性与实际使用陷阱，明确指出：绝大多数单线程场景应优先选用性能高2–3倍的StringBuilder，仅当多线程共享同一实例且无法或不愿添加额外同步时，才需谨慎选择StringBuffer；同时澄清常见误区——StringBuffer方法级同步不等于组合操作原子性，“查后删”等逻辑仍需手动同步；此外，详解append为何比+高效（复用数组）、如何通过预估容量避免扩容开销、toString()的合理调用时机，以及setCharAt/delete等易踩的边界坑，助你写出既高效又健壮的字符串操作代码。

StringBuffer 和 StringBuilder 到底该选谁

绝大多数情况下，用 StringBuilder 就够了——它和 StringBuffer 接口几乎一样，但没加锁，性能高 2–3 倍。只有当你明确需要在多线程里共享同一个可变字符串对象、且不额外加同步时，才轮到 StringBuffer。

常见错误是“听说 StringBuffer 线程安全就无脑用”，结果在单线程 Servlet 或 Stream 处理里拖慢吞吐量；更隐蔽的问题是：你以为用了 StringBuffer 就高枕无忧，其实 append、delete 这些操作虽原子，但一连串调用（比如先 length() 再 charAt()）并不构成原子块，仍需手动同步。

• 如果对象只在一个线程内创建、使用、丢弃 → 用 StringBuilder
• 如果多个线程会共用同一个实例，且你不想/不能加 synchronized 块 → 才考虑 StringBuffer
• StringBuffer 的每个 public 方法都带 synchronized，但方法间无事务性，别依赖“查完再删”这种组合逻辑

append() 为什么比 + 拼接快，但又不是越长越好

每次用 + 拼接字符串（尤其循环中），JVM 实际会新建多个 StringBuilder（或 StringBuffer），再转成 String，对象分配和 GC 压力大。而 StringBuffer.append() 复用内部 char[] 数组，避免频繁重建。

但数组扩容有代价：初始容量默认 16，超出后会扩为 oldCapacity * 2 + 2，触发数组拷贝。高频追加小字符串时，反复扩容反而比预估容量慢。

• 知道最终长度范围？构造时直接指定：new StringBuffer(256)
• 拼接固定几段？append(a).append(b).append(c) 比分三次调用快（链式调用减少方法入口开销）
• 别用 append(null) —— 它真会塞进字符串 "null"，不是空指针异常

toString() 不是免费的，但也不是每次都得缓存

StringBuffer.toString() 每次都新建一个 String 对象，内容是当前内部 char[] 的副本。如果你循环里反复调用，等于不断制造临时对象。

但反过来，提前把 toString() 结果存到变量里也不总对：如果后续还继续 append()，旧字符串不会自动更新，容易产生逻辑错觉。

• 只读取一次？直接 sb.toString()，别画蛇添足存变量
• 要多次读取且确定不再修改？存变量没问题：String result = sb.toString();
• 想“冻结”状态供并发读？不如转成不可变 String 后丢掉 StringBuffer 引用，避免误改

setCharAt() 和 delete() 的边界陷阱

setCharAt(int index, char ch) 和 delete(int start, int end) 都不检查索引是否“合理”——它们只认 0 和 0 。越界直接抛 StringIndexOutOfBoundsException，不是静默失败。

典型翻车场景：循环删除匹配字符时，删完前面元素，后面索引全偏移了，却还按原位置删；或者用 indexOf() 找到位置后没验证是否为 -1 就直接传给 setCharAt()。

• 删字符优先用 deleteCharAt(int index)，比 delete(i, i+1) 直观不易错
• 所有基于索引的操作前，先确认 index >= 0 && index
• delete(0, sb.length()) 清空比 sb.setLength(0) 稍慢，后者重置长度但不擦数据，复用更快

线程安全不是银弹，StringBuffer 只保单个方法原子性；真正难的是厘清共享状态的访问契约——这点，代码注释比 synchronized 关键字管用得多。

以上就是《JavaStringBuffer线程安全详解》的详细内容，更多关于的资料请关注golang学习网公众号！