多线程应用未明确同步要求时为何需使用StringBuffer这类同步实现

核心结论先明确 #

你对两者选型的理解本质上是对的，所谓「多线程应用就必须全用StringBuffer」是广泛流传的错误认知。

• 首先明确两类的本质差异：StringBuffer的所有修改方法都加了synchronized锁保证线程安全，会带来额外的锁开销；StringBuilder无锁设计，相同场景下性能比StringBuffer高10%~30%。
• 多线程应用不等于所有对象都会被多线程共享：绝大多数业务场景下，我们用到的可变字符串对象都是方法内部的局部变量，只会被当前执行方法的线程独有，完全不存在多线程同时修改的可能，这种场景下哪怕跑在多线程服务里，也可以放心用StringBuilder，不需要做任何同步。
• 只有当可变字符串是多线程共享的资源时，才需要考虑用StringBuffer：比如这个字符串是类的静态成员变量、或是存储在全局共享缓存中，多个线程都会对它做追加、修改操作，这时候才需要用到同步实现避免并发修改导致的数据错乱。

很多老旧教程提到的「多线程用StringBuffer，单线程用StringBuilder」是简化表述，完整的正确表述应该是：共享可变字符串场景用StringBuffer，私有可变字符串场景不管单多线程都优先用StringBuilder。

你最后提到的疑问本身不成立：没有任何开发规范要求多线程应用中没有明确同步需求时也要强制用同步实现，同步永远是针对共享可变资源的必要防护，非共享场景加同步只会白白消耗性能、降低服务吞吐量，完全没有必要。

内容的提问来源于stack exchange，提问作者the_novice