StringBuffer 作为全局变量本身线程安全，但多方法组合、toString快照、外部资源同步等场景仍存在风险，需配合synchronized块或改用ThreadLocal<StringBuilder>等方案。
StringBuffer 作为全局变量时，本身具备线程安全性，但能否安全使用，不只取决于它自己，更取决于你如何用它。
StringBuffer 自身的线程安全机制
StringBuffer 所有公开方法（如 append、insert、delete、toString）都被 synchronized 修饰，锁对象是实例本身（this）。这意味着：
- 多个线程同时调用同一个 StringBuffer 实例的方法，会串行执行，不会出现内部状态错乱（比如 count 字段被并发修改导致越界或丢数据）
- 字符数组扩容、长度更新、缓存清理（toStringCache）等关键步骤都受同一把锁保护
- 它的线程安全是“方法级原子性”，不是“业务逻辑级原子性”——单个方法安全，不代表多个方法组合也安全
作为全局变量时的真实风险点
把 StringBuffer 声明为 static 全局变量（例如 private static StringBuffer sb = new StringBuffer()），容易忽略以下问题：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 多方法组合非原子：比如先 sb.length() == 0 再 sb.append("x")，中间可能被其他线程插入操作，导致判断失效
- toString() 后引用失效：调用 sb.toString() 返回的是新 String，但 StringBuffer 本身还在被其他线程修改；若把该 String 当作“快照”长期使用，内容可能早已过期
- 外部同步缺失：如果在 append 之外还涉及其他共享资源（如日志计数器、Map 更新），仅靠 StringBuffer 的锁无法覆盖整个业务逻辑
- 初始化竞争（极少见但存在）：若静态变量未显式初始化，而通过双重检查等方式延迟构造，需确保构造过程本身线程安全（不过通常 new StringBuffer() 是无状态的，影响较小）
正确使用的实践建议
当必须用 static StringBuffer 时，应遵循这些原则：
立即学习“Java免费学习笔记（深入）”；
- 尽量只做“追加日志”类的单一写入操作，避免混合读-判-写逻辑
- 如需条件写入（例如“只有为空才初始化”），应将整段逻辑用 synchronized(sb) 包裹，而不是依赖单个方法
- 避免将其暴露给不可控代码（如作为 public static 字段），推荐封装在工具类中，提供受控接口
- 高并发场景下，考虑替代方案：用 ThreadLocal<StringBuilder> + 汇总，或使用无锁日志框架（如 Log4j2 AsyncLogger）
与 StringBuilder 的关键区别提醒
有人误以为“只要用了 StringBuffer 就万事大吉”，但要注意：
- StringBuilder 完全没加锁，多个线程共用一个实例必然出错（常见表现：长度异常、ArrayIndexOutOfBoundsException、字符串内容拼接错乱）
- StringBuffer 的锁只保它自己，不保你的业务语义；StringBuilder 虽不安全，但在单线程或每个线程独占实例时，性能更好
- 若全局变量只是供各线程独立使用（比如每个线程 new 一份再传入工具类），那用 StringBuilder 更合适，无需为“假共享”付出同步代价
