synchronized的实现原理

在多线程并发编程中，synchronized一直是元老级角色，很多人称呼它为重量级锁。但是在Java SE 1.6之后为了减少获得锁和释放锁的带来的性能消耗而对其进行了各种优化，例如引入了偏向锁和轻量级锁，使得有些情况下synchronized也不那么重了。

利用synchronized实现同步的基础是Java中的每一个对象都可以作为锁即同步监视器（对象如同锁），主要有以下三种方式：
（1）对于普通同步方法（非静态同步方法），锁是this关键字表示本类对象的引用（当前实例对象）；
（2）对于静态同步方法，锁是当前类的Class对象本身（运行时类信息/字节码文件对象/Class类对象本身）；
（3）对于同步代码块，锁是synchronized括号中配置的对象。

当一个线程试图访问同步块时，首先必须得到锁，在退出或者抛出异常时必须要释放锁。

从JVM规范中可以看到synchronized在JVM里的实现原理，JVM基于进入和退出Monitor对象来实现方法同步和代码块同步，但是两者的实现细节不一样。代码块同步是使用monitorenter和monitorexit这两条字节码指令来实现的，而方法同步则是使用另外一种方式实现，其细节在JVM规范里并没有详细说明，但是方法同步也可以使用上述的两条字节码指令（monitorenter和monitorexit）来实现。

monitorenter指令是在编译后插入到同步代码块的开始位置，而monitorexit指令则是插入到方法的结束处或者异常处，JVM保证每个monitorenter指令都必须有对应的monitorexit指令与之配对。任何对象都会有一个monitor与之关联，且当一个monitor被持有后，它就处于锁定状态了。线程在执行到monitorenter指令时，将会尝试获取对象所对应的monitor的所有权，即尝试获取对象的锁。

重量级锁需要向操作系统申请资源，即从用户态（3级特权级）切换到内核态（0级特权级），此时线程会被挂起，进入等待队列，等待操作系统调度，然后再映射回用户空间。Java中的每一个对象都关联了一个监视器锁monitor，当monitor被占用时就会处于锁定状态，当线程执行monitorenter字节码指令时就是在尝试获取monitor的所有权，过程如下：
（1）如果monitor的进入数为0，则该线程可以进入monitor，并将monitor的进入数设置为1，该线程即为monitor的所有者；
（2）如果该线程已经占有了monitor，只是重新进入monitor，则再次进入monitor时会将monitor的进入数+1；
（3）如果monitor已经被其他线程占用，则该线程会被阻塞直到monitor的进入数为0，才会重新尝试获得monitor的所有权。
monitor是可重入的，monitor是非公平的。monitor是依赖操作系统的互斥锁实现的，线程被阻塞后进入内核态，这会导致系统在用户态和内核态之间来回切换，严重影响锁的性能。我们应当尽量在用户态时就把加锁问题解决掉，以避免进入内核态的线程阻塞。

对象头：
synchronized用的锁是存在Java对象头里的。
如果对象是数组类型，则Java对象头（占3个字宽Word，32位虚拟机中1个字宽等于4个字节即32bits，64位虚拟机中1个字宽等于8个字节即64bits）中存储了：
（1）存储了对象自身的运行时数据，比如对象哈希码（hashCode）、分代年龄（对象分代年龄/GC分代年龄）、锁标志位（锁标记位）等；
（2）存储了指向方法区对象类型数据的指针；
（3）存储了数组的长度。
如果对象是非数组类型，则Java对象头（占2个字宽Word，32位虚拟机中1个字宽等于4个字节即32bits，64位虚拟机中1个字宽等于8个字节即64bits）中存储了：
（1）存储了对象自身的运行时数据，比如对象哈希码（hashCode）、分代年龄（对象分代年龄/GC分代年龄）、锁标志位（锁标记位）等；
（2）存储了指向方法区对象类型数据的指针。

Java对象头的长度：

长度	内容	说明
32/64bits	Mark Word	存储对象的hashCode或者锁信息等
32/64bits	Class Metedata Address	存储到对象类型数据的指针
32/32bits	Array Length	数组的长度（如果对象是数组类型）

Java对象头里的Mark Word默认存储了对象的哈希码（hashCode）、分代年龄（对象分代年龄/GC分代年龄）、锁标志位（锁标记位）等信息。

Java对象头里的Mark Word主要包括以下5种状态：
32位虚拟机：
（1）无锁状态（未锁定）：25bits的对象hashCode，4bits的对象分代年龄，1bit是否是偏向锁（设置为0），2bits锁标志位（01）;
（2）轻量级锁定状态：30bits的指向栈中锁记录的指针，2bits的锁标志位（00）；
（3）重量级锁状态：30bits指向互斥量（重量级锁）的指针，2bits的锁标志位（10）；
（4）GC标记：30bits为空，2bits的锁标志位（11）；
（5）偏向锁：23bits的偏向线程ID，2bits的偏向时间戳（epoch），4bits的对象分代年龄，1bit是否是偏向锁（设置为1），2bits的锁标志位（01）。
64位虚拟机：
（1）无锁状态（未锁定）：25bits的unused，31bits对象hashCode，1bit的cms_free，4bits的对象分代年龄，1bit是否是偏向锁（设置为0），2bits锁标志位（01）；
（2）偏向锁状态：54bits的偏向线程ID，2bits的偏向时间戳（epoch），1bit的cms_free，4bits的对象分代年龄，1bit是否是偏向锁（设置为1），2bits的锁标志位（01）。

Java SE 1.6为了减少获得锁和释放锁所带来的性能消耗而引入了偏向锁和轻量级锁。在Java SE 1.6中，锁一共有4种状态，级别从低到高依次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，这几个状态会根据竞争情况逐渐升级。锁只能升级而不能降级，这意味着偏向锁升级为轻量级锁后不能在降级为偏向锁。这种锁升级而不能降级的策略，其目的就是为了提高获得锁和释放锁的效率。

偏向锁：

大多数情况下，锁不仅不存在多线程竞争，而且总是由同一个线程多次获得，为了使线程获得锁的代价更低而引入了偏向锁。线程在执行同步块之前，虚拟机首先会在当前线程的虚拟机栈的栈桢中创建一个名为锁记录（Lock Record）的空间，用于存储锁对象的对象头的Mark Word拷贝，官方称为Displaced Mark Word。当线程访问一个同步块并获得锁时，会在对象头的Mark Word和栈桢中的锁记录中存储锁偏向的线程ID，以后该线程再进入和退出同步块时就不需要进行CAS操作来加锁和解锁了，只需要简单地测试一下对象头的Mark Word中是否存储了指向当前线程的偏向锁，如果测试成功，则表示线程已经获得了锁；如果测试失败，则还需要再测试一次对象头的Mark Word中的偏向锁的标识是否设置为1（是否是偏向锁），如果没有设置，则说明偏向锁不可用，此时进入轻量级锁逻辑，使用CAS来竞争锁；如果设置了，则说明偏向锁可用，可以尝试通过CAS来将对象头的偏向锁指向当前线程（将对象头的Mark Word中的偏向线程ID替换为当前线程ID）。
偏向锁使用了一种竞争出现时才释放锁的机制，所以当有其他线程竞争偏向锁时，持有偏向锁的线程才会释放锁。撤销偏向锁时，会等待全局安全点（Safe Point，在这个时间点没有正在执行的字节码），它会先检查持有偏向锁的线程是否还活着，如果线程没有处于活动状态，则将对象头设置成无锁状态；如果线程仍然活着，则拥有偏向锁的栈会被执行，遍历偏向对象的锁记录，栈桢中的锁记录或者对象头的Mark Word要么重新偏向其他线程，要么会恢复成无锁状态或者标记对象不适合作为偏向锁，最后唤醒暂停的线程。
偏向锁在Java SE 6和Java SE 7中都是默认开启的，但是它会在应用程序启动几秒钟之后才会被激活，若有必要可以通过JVM参数-XX:BiasedLockingStartupDelay=0来关闭延迟。如果你能确定应用程序中所有的锁通常情况下都会处于竞争状态，则可以通过JVM参数-XX:-UsedBiasedLocking=false来关闭偏向锁，那么程序会默认进入轻量级锁状态。

轻量级锁：

（1）轻量级锁的加锁
线程在执行同步块之前，JVM会先在当前线程的虚拟机栈的栈桢中开辟一个名为锁记录（Lock Record）的空间，然后将锁对象的对象头的Mark Word复制到锁记录中，官方称为Displaced Mark Word。然后线程尝试使用CAS来将对象头中的Mark Word替换为指向栈中锁记录的指针，如果替换成功，则当前线程获得锁，如果替换失败，则表示有其他线程竞争锁，此时当前线程将尝试使用自旋来获得锁。
（2）轻量级锁的解锁
轻量级锁解锁时，会尝试使用原子的CAS操作将Displaced Mark Word替换回对象头，如果替换成功，则表示没有竞争发生；如果替换失败，则表示当前锁存在竞争，锁会膨胀为重量级锁。

因为自旋会消耗CPU，为了避免无用的自旋（比如获得锁的线程被阻塞住了），一旦锁升级为重量级锁，就不会再恢复成轻量级锁状态。当锁处于这个状态（重量级锁）状态，其他线程试图获取锁时，都会被阻塞住，当持有锁的线程释放锁之后会唤醒这些线程，被唤醒的线程就会进行新一轮的夺锁之争。

偏向锁、轻量级锁及重量级锁的优缺点：

锁	优点	缺点	适用场景
偏向锁	加锁和解锁不需要额外的消耗，与执行非同步方法相比仅存在纳秒级的差距	如果线程之间存在竞争，则会带来额外的锁撤销的消耗	只有一个线程访问同步块
轻量级锁	竞争的线程不会阻塞，提高了程序的响应速度	始终得不到锁竞争的线程，使用自旋会消耗CPU	追求响应速度，同步块的执行速度非常快
重量级锁	线程竞争不使用自旋，不会消耗CPU	线程阻塞，响应时间缓慢	追求吞吐量，同步块的执行速度较长

参考自《Java并发编程的艺术》~~