你还在使用 StringBuffer ?

介绍

  Java中常用字符串处理类包括 String、StringBuffer 和 StringBuilder ，当对字符串进行修改的时候，使用 StringBuffer 和 StringBuilder 一般比使用 String 效率更高。因为 StringBuffer 的内部实现方式和 String 不同，StringBuffer 在进行字符串处理时，不生成新的对象，在速度和内存使用上都要优于 String。

String

  String 是被 final 关键字修饰的，它是不可变的，就算调用 String 的 concat 方法，那也只是把字符串拼接起来并重新创建一个新对象，把拼接后的 String 的值赋给新创建的对象。

StringBuffer

  StringBuffer 是可变的，调用StringBuffer 的 append 等方法，来改变 StringBuffer ，相比较于 String 创建新对象，StringBuffer 的 append 等方法直接在原对象上操作，不新建对象，是更高效的，所以如果需要对字符串进行修改推荐使用 StringBuffer。

StringBuilder

  StringBuilder 在 Java 5 中被提出，它拥有与 StringBuffer 几乎相同的方法与用法，但是无论哪方面都完胜 StringBuilder。

StringBuffer vs StringBuilder

  StringBuilder 与 StringBuffer 都继承自 AbstractStringBuilder，在 AbstractStringBuilder 类中也是使用字符数组保存字符串。StringBuffer 很多方法都是 synchronized 修饰的，所以我们常说 StringBuffer 是线程安全的，官方的注释也写着 StringBuffer 是一个线程安全的可变的字符序列，StringBuffer 可以安全的在多线程场景下使用，但事实并非如此。
  事实上，StringBuffer 不是线程安全的，而且效率低下，任何出现 StringBuffer 的地方都可以用 StringBuilder 去替换。道理很简单， append 等方法在多线程环境下，它能保证程序运行结果的正确性和一致性吗？试想一下，使用 append 拼接 SQL，在多线程环境运行，你根本无法预测最终结果，不光无法预测，JVM 自己都不确定最终结果。
  StringBuffer 的线程安全，仅仅是保证 JVM 不抛出异常顺利的往下执行而已，它不保证逻辑正确和调用顺序正确。大多数时候，我们需要的不仅仅是线程安全，而是锁。事实上，你根本找不到一个用 StringBuffer 的理由，《Effective java》的作者 Joshua Bloch 在书中说：
原文：StringBuffer instances are almost always used by a single thread, yet they perform internal synchronization. It is for this reason that StringBuffer was supplanted by StringBuilder, which is just an unsynchronized StringBuffer.
译文：StringBuffer 实例几乎总是由单个线程使用，但它们执行内部同步。正是由于这个原因，StringBuffer 被 StringBuilder 取代，后者只是一个不同步的StringBuffer。

为什么会有 StringBuffer 的存在呢？如果真的没有价值，为什么 JDK 会提供这个类？

  因为最早是没有 StringBuilder 类的，sun 公司的人错误地决定让 StringBuffer 是线程安全的，然后大约 10 年之后，人们终于意识到这是一个多么愚蠢的决定，意识到在这 10 年之中这个愚蠢的决定为 Java 运行速度慢这样的流言贡献了多大的力量，于是，在 JDK1.5 的时候，终于决定提供一个非线程安全的 StringBuffer 实现，并命名为 StringBuilder 。

总结

类	线程安全	性能(一般情况)	使用环境
String	是	低	少量数据
StringBuffer	否	低	单线程环境
StringBuilder	否	高	单线程环境

StringBuffer 基本没有适用场景，你应该在所有的情况下坚定地选择使用 StringBuilder。