stringbuffer 多线程安全本质是实例级 synchronized 锁，所有公共修改方法均同步，保证 value 数组和 count 字段操作原子性；但跨方法组合操作需手动同步。
Java 中 StringBuffer 在多线程下的竞争执行模型，本质是“方法级串行化访问”——所有修改状态的公共方法（如 append、insert、delete）都用 synchronized 修饰，锁住当前实例（this），让并发线程排队执行，而非并行操作。
竞争发生的位置：锁在实例上，不是在方法名上
多个线程调用同一个 StringBuffer 实例的 append()，不是“方法被锁住”，而是“这个对象被锁住”。只要一个线程进入任意一个 synchronized 方法，其他线程对同一实例的任何 synchronized 方法调用都会阻塞，直到锁释放。这意味着：
- 线程 A 正在执行 sb.append("x")，线程 B 尝试调用 sb.insert(0, "y") 会等待
- 线程 C 调用 sb.toString() 也会等——因为 toString() 也是 synchronized 方法
- 锁粒度是整个对象，不是某个字段或某段逻辑
内部状态受保护：value 数组和 count 字段不会错乱
StringBuffer 底层复用 AbstractStringBuilder 的 char[] value 和 int count。这些字段本身不加锁，但所有读写它们的路径（append、delete、length 等）都被同步方法包裹。因此：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- count 增加和 value 写入总是一起完成，不会出现“count+1 但 value 没写”这种中间态
- 扩容操作（ensureCapacityInternal）也在线程安全上下文中执行，避免多个线程同时 realloc 导致数组覆盖
- 即使高并发调用，也不会抛 ArrayIndexOutOfBoundsException 或产生乱码
竞争不是均匀分布的：取决于调用频率与线程行为
实际竞争强度不只看线程数，更取决于写入密度和操作耗时：
- 若线程偶尔追加短字符串（如日志打点），锁持有时间极短，JVM 可能通过锁消除或偏向锁优化，竞争感知弱
- 若多个线程高频调用 append() 且每次拼接长内容，锁争抢明显，线程频繁挂起/唤醒，吞吐量下降显著
- 实测显示：4 线程并发各 append 10 万次，耗时约为单线程 StringBuilder 的 2.8 倍
组合操作仍需手动同步：原子性止步于单方法
synchronized 保障单个方法的原子性，但跨方法逻辑不自动受保护：
- if (sb.length()
- 正确做法是显式用 synchronized(sb) 包裹整块判断+操作
- toString() 返回不可变 String，但若该 String 被其他线程长期引用，而 StringBuffer 后续又被修改，可能引发业务逻辑混淆（数据一致，语义未必一致）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
