stringbuffer线程安全但性能低，stringbuilder非线程安全但速度快；二者底层实现和api完全一致，选择取决于是否需多线程共享：单线程用stringbuilder，多线程共享且需一致性用stringbuffer。
线程安全是核心区别
StringBuffer 的所有公共方法（如 append、insert、delete）都加了 synchronized 关键字，因此天然支持多线程并发访问，不会出现数据错乱。StringBuilder 完全没有同步机制，同一实例被多个线程同时调用时，可能产生不可预期的结果，比如字符丢失或顺序混乱。
性能表现差距明显
由于同步锁的开销，StringBuffer 在单线程场景下比 StringBuilder 慢不少——实测中，10 万次拼接操作，StringBuffer 耗时通常是 StringBuilder 的 5–15 倍。这种差异不是微小优化，而是架构级取舍：要不要为“可能用不到”的线程安全，付出确定的性能代价。
底层实现几乎一致
两者都继承自 AbstractStringBuilder，内部使用可变的 char[] 数组存储内容，初始容量默认都是 16。扩容逻辑也相同：新容量 = 旧容量 × 2 + 2。它们的 API 完全兼容，方法签名、返回类型、行为语义一模一样，只是 StringBuffer 多了一层锁。
怎么选？看运行环境
- 明确是单线程，或字符串对象只在本线程内创建、使用、丢弃 → 用 StringBuilder
- 对象会被多个线程共享，且需保证修改结果始终一致（如日志聚合器、配置构建器）→ 用 StringBuffer
- 不确定是否多线程，又不愿承担锁开销 → 不要直接共享 StringBuilder 实例；可考虑局部创建、用完即弃，或改用线程局部变量（ThreadLocal
）
