StringBuffer天生线程安全因其所有公开修改方法均用synchronized修饰，锁住整个对象实例，确保单方法调用不出现数据错乱；但多步操作需手动同步，仅当多线程共享并发修改时才需使用，否则应优先选用性能更高的StringBuilder。
StringBuffer 为什么天生线程安全
因为 StringBuffer 的所有公开修改方法（如 append()、insert()、delete()、reverse()）都加了 synchronized 修饰符，每个方法调用时会锁住整个对象实例。这意味着多个线程同时调用同一个 StringBuffer 实例的任意修改方法，不会出现数据错乱或部分写入问题。
但要注意：这种“安全”只覆盖单个方法调用。如果业务逻辑需要多步操作（比如先 length() 再 append()），不能靠 StringBuffer 自动保证原子性——必须手动加同步块。
什么时候该用 StringBuffer 而不是 StringBuilder
仅当字符串缓冲区被多个线程**共享且并发修改**时才需要 StringBuffer。绝大多数场景下（如局部变量、单线程构建 JSON/SQL），应优先用 StringBuilder——它不加锁，性能通常高 2–3 倍。
- 共享实例：多个线程共用一个
StringBuffer字段（例如作为类的成员变量） - 日志聚合器：多个工作线程往同一个
StringBuffer追加日志行 - 老项目维护：已有代码依赖
StringBuffer的同步语义，且无法重构为无状态设计
反例：在 run() 方法里新建 StringBuffer，然后只在当前线程用——这时用 StringBuilder 更合适。
立即学习“Java免费学习笔记（深入）”；
常见误用：以为 synchronized 方法能保护复合操作
下面这段代码看似安全，实则存在竞态条件：
if (buffer.length() < 10) {
buffer.append("default");
}
length() 和 append() 是两个独立的同步方法，中间可能被其他线程插入修改。正确做法是显式同步：
synchronized (buffer) {
if (buffer.length() < 10) {
buffer.append("default");
}
}
另外注意：toString() 方法虽然也是 synchronized，但它返回的是新创建的 String 对象，后续对该 String 的任何操作都不再受 StringBuffer 锁保护。
性能与替代方案提醒
StringBuffer 的同步开销在高并发写入场景下不可忽视。如果只是拼接、不涉及复杂逻辑，可考虑以下替代：
- 使用
ThreadLocal<stringbuilder></stringbuilder>：每个线程独享实例，避免锁竞争 - 改用不可变 + 并发容器：如用
ConcurrentLinkedQueue<string></string>收集片段，最后由单一线程合并 - JDK 11+ 可尝试
StringJoiner（但它是无状态的，不适用于持续追加场景）
真正需要 StringBuffer 的地方其实不多；多数所谓“线程安全字符串操作”需求，本质是共享状态管理问题，而不是字符串拼接本身的问题。
