【回顾】JVM对锁优化的简单理解

从JDK1.6开始，JVM对synchronized锁进行了很多优化；

一、锁消除

在编译的时候，JIT编译器会通过逃逸分析技术，分析synchronized锁对象是不是只可能被一个线程加锁，没有其他的线程来竞争加锁的话，编译的时候就不用加入monitorenter和monitorexit的指令了；

相当于是消除了这个锁，从而提升了这段代码的执行效率，因为可能就只有一个线程会来加锁，不涉及到多个线程来竞争。

二、锁粗化

在编译的时候，如果JIT编译器发现代码里有连续的多次加锁释放锁的代码，就会合并为一个锁，也就是锁的粗化，避免频繁多次加锁与释放锁。如：
synchronized(this){
}
synchronized(this){
}
synchronized(this){
}

三、偏向锁

假设有一个线程A来竞争这个锁的机率比较大，其他线程来竞争这个锁的概率很小，则会考虑转化为偏向锁；

因为monitorenter和monitorexit是要使用CAS操作来加锁和释放锁的，开销较大，因此如果发现大概率只有一个线程来竞争一个锁，就会给这个锁维护一个偏好(Bias)，后面加锁与释放锁，就会基于Bias来执行，不需要通过CAS；
如果有别的线程来竞争这个锁，则会收回掉之前分配的Bias。

四、轻量级锁

如果不同线程之间竞争锁太过频繁，则可以尝试采用轻量级锁的方式来加锁，将对象头的Mark Word里的轻量级指针指向持有锁的线程；
如果是自己加的锁，就顺着执行代码，否则加锁失败，有其他人加了锁，可以将锁升级为重量级锁。

五、自旋锁

是JIT编译器对锁做的另一个优化，如果各个线程持有锁的时间很短，那么一个线程竞争不到锁的时候就会暂停，发生上下文切换，让其他线程来执行，其他线程在很短的时间后又释放掉了锁，暂停的线程才会再次被唤醒；
问题在于线程频繁地进行上下文切换会导致开销过大，所以对于这种线程持有锁时间很短的情况，可以采取忙等策略，也就是一个线程没竞争到锁时，会进入一个while循环不停等待，不会发生暂停和上下文切换；

所谓的自旋锁，就是不断的自选尝试获取锁，避免频繁地进行上下文的切换。