stringbuffer线程安全靠synchronized方法实现，所有公共修改方法（如append、insert、delete）均加锁，确保同一实例上多线程操作串行执行，提供原子性、可见性与有序性保障。
StringBuffer 线程安全的核心在于所有公共修改方法（如 append、insert、delete）都用 synchronized 修饰，保证同一时刻只有一个线程能执行这些操作。它不是靠“无锁”或“CAS”，而是通过对象级锁实现串行化访问——这在多线程共享单个实例时有效，但需注意适用边界和性能代价。
StringBuffer 的线程安全机制怎么起作用
它的每个关键方法（比如 append(String)）声明为 public synchronized StringBuffer append(...)，意味着调用时会自动获取该 StringBuffer 实例的对象锁。其他线程若同时调用同一实例的任意同步方法，必须等待锁释放。
- 锁粒度是整个对象，不是某段逻辑或某个字段，所以并发吞吐受限
- 即使只读方法（如
length()、charAt()）也同步，但 JDK 后续版本已优化部分只读操作为非同步（注意：JDK 9+ 中部分 getter 不再强制同步，但行为仍以文档为准） - 构造函数不加锁，但初始化后所有修改入口均受控，因此“安全”始于首次调用同步方法
什么时候该用 StringBuffer 而不是 StringBuilder
仅当多个线程**共享同一个 StringBuffer 实例**并**并发调用其修改方法**时，才需要 StringBuffer。常见于旧系统、工具类静态缓存、日志聚合器等场景。
- 单线程环境一律用 StringBuilder —— 性能高且语义清晰
- 每个线程各自 new 一个 StringBuffer，也无需考虑线程安全，此时用 StringBuilder 更合适
- 若需跨线程传递字符串结果，推荐用不可变的 String 或通过线程安全容器（如
ConcurrentHashMap）协调，而非共享可变缓冲区
实际并发设计中的典型误区
开发者常误以为“用了 StringBuffer 就万无一失”，但线程安全仅覆盖其自身方法调用。复合操作仍可能出错。
-
非原子组合操作：比如
if (sb.length() 不是原子的，两个线程可能同时通过判断、同时追加，导致超长。应加外部同步或改用更高层抽象 - 与外部状态耦合：若 StringBuffer 内容影响其他共享变量（如计数器、标志位），同步范围必须扩大到整个业务逻辑块
-
误用静态实例：
static StringBuffer buffer = new StringBuffer()是高危模式，除非有明确的全局协调需求，否则极易成为瓶颈和错误源头
替代方案与现代实践建议
纯字符串拼接类场景中，StringBuffer 已非首选；更健壮的并发设计倾向于规避共享可变状态。
- 优先使用
String.join()、String.formatted()或TextBlock（Java 15+）处理静态拼接 - 高频动态构建可用
ThreadLocal<stringbuilder></stringbuilder>，避免锁竞争又保持可变性 - 异步日志、消息组装等场景，推荐用线程安全的队列（如
BlockingQueue）+ 单消费者模式，而非共享缓冲区 - 必要时封装带锁的工具类，把同步逻辑收拢，比裸用 StringBuffer 更易维护和测试
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
