Thoroughly understand the difference between StringBuffer and StringBuilder
When I asked about the difference between StringBuffer and StringBuilder, I opened my mouth to say that StringBuffer is thread-safe, because its related methods have added the synchronized keyword, and StringBuilder is not thread-safe. That's right, it is true, but we have checked the source code and found that StringBuffer started from jdk1.0, and StringBuilder started from jdk1.5. So I have such a question, since there is already a StringBuffer, why jdk5 has another StringBuilder, that is, what is the difference between StringBuffer and StringBuilder when single-threaded.
1. What StringBuffer and StringBuilder have in common
1. Both have become the abstract class AbstractStringBuilder, which implements the CharSequence interface
public final class StringBuilder
extends AbstractStringBuilder
implements java.io.Serializable, CharSequence
public final class StringBuffer
extends AbstractStringBuilder
implements java.io.Serializable, CharSequence2. Its append method is super.append(str), calling the append(String str) method of the parent class AbstractStringBuilder
@Override
public StringBuilder append(String str) {
super.append(str);
return this;
}
@Override
public synchronized StringBuffer append(String str) {
toStringCache = null;
super.append(str);
return this;
}3. The initial capacity is 16 and the expansion mechanism is "old capacity * 2+2"
4. The bottom layer is implemented with char[] character array, and the character array is variable, which is different from String
2. The difference between StringBuffer and StringBuilder
1. StringBuffer is multi-thread safe, but StringBuilder is uneasy about multi-threading
2. StringBuffer has been available since JDK1.0, and StringBuilder only appeared in JDK5.0
3. StringBuffer has one more toStringCache field than StringBuilder, which is used for caching in the toString method. Before each append operation, set toStringCache to null. If the toString method is called repeatedly, it can avoid Arrays.copyOfRange(value , 0, count) operation to save performance.
@Override
public synchronized StringBuffer append(String str) {
toStringCache = null;
super.append(str);
return this;
}
@Override
public synchronized String toString() {
if (toStringCache == null) {
toStringCache = Arrays.copyOfRange(value, 0, count);
}
return new String(toStringCache, true);
}4、由于StringBuilder没有考虑同步，在单线程情况下，StringBuilder的性能要优于StringBuffer
三、单线程StringBuffer与StringBuilder区别
这个才是我们重点讨论的，单线程下StringBuffer加了synchronized，虽然是单线程， 但是synchronized获取锁和释放锁也还是需要时间的， 而StringBuilder没有，这个就是重点区别。因此重点要讨论synchronized锁的状态，从获取锁到释放锁的过程，因此需要讨论一下锁的升级和优化。
锁的4中状态：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态(级别从低到高)
(1)偏向锁：
偏向锁是指一段同步代码一直被一个线程所访问，那么该线程会自动获取锁。降低获取锁的代价。
为什么要引入偏向锁？
因为经过HotSpot的作者大量的研究发现，大多数时候是不存在锁竞争的，常常是一个线程多次获得同一个锁，因此如果每次都要竞争锁会增大很多没有必要付出的代价，为了降低获取锁的代价，才引入的偏向锁。
偏向锁的升级
当线程1访问代码块并获取锁对象时，会在java对象头和栈帧中记录偏向的锁的threadID，因为偏向锁不会主动释放锁，因此以后线程1再次获取锁的时候，需要比较当前线程的threadID和Java对象头中的threadID是否一致，如果一致(还是线程1获取锁对象)，则无需使用CAS来加锁、解锁；如果不一致(其他线程，如线程2要竞争锁对象，而偏向锁不会主动释放因此还是存储的线程1的threadID)，那么需要查看Java对象头中记录的线程1是否存活，如果没有存活，那么锁对象被重置为无锁状态，其它线程(线程2)可以竞争将其设置为偏向锁；如果存活，那么立刻查找该线程(线程1)的栈帧信息，如果还是需要继续持有这个锁对象，那么暂停当前线程1，撤销偏向锁，升级为轻量级锁，如果线程1 不再使用该锁对象，那么将锁对象状态设为无锁状态，重新偏向新的线程。
偏向锁的取消：
偏向锁是默认开启的，而且开始时间一般是比应用程序启动慢几秒，如果不想有这个延迟，那么可以使用-XX:BiasedLockingStartUpDelay=0；
如果不想要偏向锁，那么可以通过-XX:-UseBiasedLocking = false来设置；
(2)轻量级锁
轻量级锁是指当锁是偏向锁的时候，被另一个线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，提高性能
为什么要引入轻量级锁？
轻量级锁考虑的是竞争锁对象的线程不多，而且线程持有锁的时间也不长的情景。因为阻塞线程需要CPU从用户态转到内核态，代价较大，如果刚刚阻塞不久这个锁就被释放了，那这个代价就有点得不偿失了，因此这个时候就干脆不阻塞这个线程，让它自旋这等待锁释放。
(3)重量级锁
重量级锁是指当锁为轻量级锁的时候，另一个线程虽然是自旋，但自旋不会一直持续下去，当自旋一定次数的时候，还没有获取到锁，就会进入阻塞，该锁膨胀为重量级锁。重量级锁会让其他申请的线程进入阻塞，性能降低。
轻量级锁什么时候升级为重量级锁？
线程1获取轻量级锁时会先把锁对象的对象头MarkWord复制一份到线程1的栈帧中创建的用于存储锁记录的空间(称为DisplacedMarkWord)，然后使用CAS把对象头中的内容替换为线程1存储的锁记录(DisplacedMarkWord)的地址；
如果在线程1复制对象头的同时(在线程1CAS之前)，线程2也准备获取锁，复制了对象头到线程2的锁记录空间中，但是在线程2CAS的时候，发现线程1已经把对象头换了，线程2的CAS失败，那么线程2就尝试使用自旋锁来等待线程1释放锁。
但是如果自旋的时间太长也不行，因为自旋是要消耗CPU的，因此自旋的次数是有限制的，比如10次或者100次，如果自旋次数到了线程1还没有释放锁，或者线程1还在执行，线程2还在自旋等待，这时又有一个线程3过来竞争这个锁对象，那么这个时候轻量级锁就会膨胀为重量级锁。重量级锁把除了拥有锁的线程都阻塞，防止CPU空转。
*注意：为了避免无用的自旋，轻量级锁一旦膨胀为重量级锁就不会再降级为轻量级锁了；偏向锁升级为轻量级锁也不能再降级为偏向锁。一句话就是锁可以升级不可以降级，但是偏向锁状态可以被重置为无锁状态。
综上可知，StringBuffer虽然是单线程，但它是有偏向锁升级过程判断的，会耗费时间，效率固然低于StringBuilder
四、StringBuffer与StringBuilder的应用场景
1、StringBuffer多线程安全，但是加了synchronized，其效率低。故适用于多线程下，并发量不是很高的场景
2、StringBuilder没有加任何锁，其效率高，适用单线程场景，但同时也适用于高并发场景中，提高高并发场景下程序的响应性能，至于线程安全问题可以通过其它手段解决，如ThreadLocal，CAS操作等。
3、所以对于高并发场景下，若有用到二者，还是建议优先使用StringBuilder的。