synchronized关键字

在java里，使用的最基本互斥同步手段就是synchronized关键字。synchronized关键字经过Javac编译后，会在同步代码块的前后分别形成一个monitorEnter 和 monitorExit 两个字节码指令。这两个字节码指令都需要一个reference类型的参数来指明要锁定和解锁的对象。如果代码中synchronized明确指定了对象，那么就以这个对象的引用作为reference。如果没有指定，那么将根据synchronized所修饰的方法类型（实例还是static）来决定是取代码所在的对象实例还是方法对应的Class对象来作为线程持有的锁。

当前线程在执行monitorEnter指令时，首先要去尝试获取对象的锁，如果对象没有被锁定，或者当前线程已经持有了锁，则会把锁的计数器加一，而在执行monitorExit 指令时会将锁计数器减一。一旦锁计数器的值为0，锁就等于是被释放了。如果获取对象锁失败，那么当前线程就应当被阻塞等待，直到请求锁定的对象被持有它的线程释放为止。

可以看出，持有锁是一个重量级的操作，因为如果要阻塞和唤醒一个线程，则需要操作系统来帮忙，同时会发生用户态与内核态的转换，这种状态的转换会额外消耗处理时间，尤其是对于代码特别简单的同步代码块（比如被synchronized关键字修饰的get或set），状态转换消耗的时间可能超过了代码执行的时间，为了优化这一问题，JVM引用了锁优化机制。

锁优化机制

1.锁消除

锁消除是指虚拟机即时编译器在运行时，对一些代码要求同步，但是对被检测刀不可能存在共享数据竞争的锁进行消除。锁消除的主要判定依据来源于逃逸分析的数据支持，如果判断到一段代码中，在堆上的所有数据都不会逃逸出去被其他线程访问到，那么则认为它们是线程私有的，即不会进行加锁操作。例如使用StringBuffer时，StringBuffer的append()中都有一个synchronized同步代码块，但是如果经过逃逸分析得出当前的StringBuffer实例不会被其他线程访问到的话，就不会进行加锁操作。

2.锁粗化

对与一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作出现在循环体之中，那即使没有线程竞争，频繁的进行互斥同步操作也会导致不必要的性能损耗。所以为了使加锁操作数量尽可能的小，会对一些连续的对同一个对象反复加锁和解锁的情况，会将锁同步的范围扩大到整个操作外部。

3.轻量级锁

轻量级锁：在代码即将进入同步块的时候，JVM默认会进行轻量级锁的上锁：如果此同步对象没有被锁定，则JVM会在当前线程的栈帧中建立一个锁记录的空间，用于储存锁对象的Mark Word的拷贝（对象头中储存HashCode和分代年龄和偏向模式的二进制码）。然后虚拟机会采用CAS操作尝试把Mark Word更新为指向锁记录空间的指针，同时将锁标志位改为00，如果这个操作成功了，则代表当前线程获得了该锁。如果更新操作失败了，说明有别的线程在竞争获取该对象的锁。虚拟机首先会去检查对象的Mark Word是否指向当前线程的栈帧中的锁记录空间，如果是，则说明当前线程已经拥有了锁，继续执行同步代码块即可。否则就说明对象已经被其他线程抢占了，此时轻量级锁就不再有效，必须膨胀为重量级锁（互斥锁），此时锁对象Mark Word会重新指向重量级锁的指针，并把锁标志位改为10。当不存在锁竞争时，轻量级锁通过CAS操作避免了使用互斥量的开销，不过一旦有锁竞争，不仅会有互斥量的开销，也会有CSA操作带来的开销。（轻量级锁膨胀为重量级锁）

4.偏向锁

偏向锁（通过-XX:+UseBiasedLocking参数开启）：如果JVM开启偏向锁，那么当锁对象第一次被线程获取的时候，虚拟机会将对象头中的锁标志为改为01，同时使用CAS操作把获取到锁的线程ID记录在对象头中的Mark Word中（占用hashcode的空间，即偏向锁的特征是锁标志位为01，且无hashcode）。如果CAS操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机不再进行任何同步操作（加锁、解锁，对mark word更新）。不过一旦出现另外一个线程尝试获取这个锁的情况，偏向锁就不再生效了，会根据当前对象锁是否被持有来决定撤销偏向锁后将锁的标志位更新为01（未锁定）还是00（轻量级锁），后续的同步操作则按照轻量级锁的操作去执行，且当前对象不能再进入到偏向锁状态（拥有hashcode的对象，无法进入偏向锁状态）。（偏向锁膨胀为轻量级锁）