StringBuffer线程安全靠方法级synchronized锁this，仅用单锁且不嵌套锁其他对象，故不会死锁；需警惕高竞争等待和外部代码引发的伪死锁，使用时应确认共享必要性、避免非原子组合操作、不暴露内部引用。
StringBuffer 的线程安全不依赖复杂锁协调，而是靠方法级 synchronized 锁住实例自身（this），天然规避了多把锁交叉等待导致的死锁风险——它只用一把锁，且从不主动获取其他对象的锁。
同步机制本身不引发死锁
StringBuffer 所有修改方法（如 append()、insert()、delete()）和部分读方法（如 length()、toString()）都声明为 synchronized，锁目标始终是当前实例。这意味着：
- 每次调用只尝试获取一个锁（
this），不存在锁顺序问题 - 方法内部不调用外部可重入或未知同步逻辑，不嵌套锁其他对象
- 没有
wait()/notify()等协作等待，也不参与条件队列竞争
真正需警惕的“伪死锁”场景
所谓“死锁”在 StringBuffer 上几乎不会发生，但开发者可能误判以下两类阻塞现象：
- 高竞争下的长时等待：多个线程频繁争抢同一 StringBuffer 实例，导致某些线程长时间排队。这不是死锁，而是同步瓶颈，表现为响应延迟或吞吐骤降
- 外部代码引入的锁依赖：比如在 synchronized 块中先锁 A，再调用 StringBuffer.append()；而另一处先锁 StringBuffer，再试图锁 A —— 此时死锁根源在业务代码，与 StringBuffer 无关
安全使用的三条关键原则
要真正发挥其线程安全优势，同时避免性能陷阱和误用风险：
立即学习“Java免费学习笔记（深入）”；
- 共享前确认必要性：仅当多个线程必须写入同一个 StringBuffer 实例（如日志聚合器、全局统计缓冲）时才用它；否则优先用 StringBuilder 或 ThreadLocal<StringBuilder>
-
避免组合操作裸调用：像
if (sb.length() == 0) sb.append("init")这类判断+修改不是原子的，需外层加 synchronized 块保护整个逻辑 - 不暴露内部引用：若封装成 Builder 工具类，不要提供 getBuffer() 方法返回 StringBuffer 引用，防止外部绕过同步直接操作底层 char[]
替代方案比“规避死锁”更值得考虑
与其费力设计复杂的 StringBuffer 共享策略，不如根据场景选更轻量、更清晰的方案：
- 单线程拼接 → 直接用 StringBuilder
- 每个线程独立拼接 → ThreadLocal<StringBuilder>
- 多线程结果需合并 → 各自 StringBuilder 拼完后，由主线程收集并拼接
- 高并发日志/统计 → 用无锁队列（如 Disruptor）或分段聚合，而非共用一个 StringBuffer
