synchronized 的实现原理

synchronized 的使用

锁代码块（锁对象可指定，可为this、XXX.class、全局变量）
锁普通方法（锁对象是this，即该类实例本身）
锁静态方法（锁对象是该类，即XXX.class）

锁代码块

public class Sync {

    private int a = 0;

    public void add(){
        synchronized (this){
            System.out.println("a values "+ ++a);
        }
    }

}

反编译之后的

public add()V
    TRYCATCHBLOCK L0 L1 L2 null
    TRYCATCHBLOCK L2 L3 L2 null
    ALOAD 0
    DUP
    ASTORE 1
    MONITORENTER
   L0
    GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
    NEW java/lang/StringBuilder
    DUP
    INVOKESPECIAL java/lang/StringBuilder.<init> ()V
    LDC "a values "
    INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
    ALOAD 0
    DUP
    GETFIELD com/arrom/webview/Sync.a : I
    ICONST_1
    IADD
    DUP_X1
    PUTFIELD com/arrom/webview/Sync.a : I
    INVOKEVIRTUAL java/lang/StringBuilder.append (I)Ljava/lang/StringBuilder;
    INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String;
    INVOKEVIRTUAL java/io/PrintStream.println (Ljava/lang/String;)V
    ALOAD 1
    MONITOREXIT
   L1
    GOTO L4
   L2
    ASTORE 2
    ALOAD 1
    MONITOREXIT
   L3
    ALOAD 2
    ATHROW
   L4
    RETURN
    MAXSTACK = 5
    MAXLOCALS = 3
}

由反编译结果可以看出：synchronized代码块主要是靠MONITORENTER和MONITOREXIT这两个原语来实现同步的。当线程进入MONITORENTER获得执行代码的权利时，其他线程就不能执行里面的代码，直到锁Owner线程执行MONITOREXIT释放锁后，其他线程才可以竞争获取锁。

`MONITORENTER`

每个对象有一个监视器锁（monitor）。当monitor被占用时就会处于锁定状态，线程执行monitorenter指令时尝试获取monitor的所有权.

如果monitor的进入数为0，则该线程进入monitor，然后将进入数设置为1，该线程即为monitor的所有者。
如果线程已经占有该monitor，只是重新进入，则进入monitor的进入数加1.
如果其他线程已经占用了monitor，则该线程进入阻塞状态，直到monitor的进入数为0，再重新尝试获取monitor的所有权。

第2点就涉及到了可重入锁，意思就是说当一个线程已经获取一个锁时，它可以再获取无数次，从代码的角度上将就是有无数个相同的synchronized语句块嵌套在一起。在进入时，monitor的进入数+1；退出时就-1，直到为0的时候才可以被其他线程竞争获取。

`MONITOREXIT`

执行MONITOREXIT的线程必须是objectref所对应的monitor的所有者。

指令执行时，monitor的进入数减1，如果减1后进入数为0，那线程退出monitor，不再是这个monitor的所有者。其他被这个monitor阻塞的线程可以尝试去获取这个 monitor 的所有权。

锁普通方法

public class Sync {

    private int a = 0;

    public synchronized void add(){
            System.out.println("a values "+ ++a);
    }

}

反编译之后并没有monitorenter和monitorexit，但是常量池中多了ACC_SYNCHRONIZED标示符。JVM就是根据该标示符来实现方法的同步的：

当方法调用时会检查方法的ACC_SYNCHRONIZED之后才能执行方法体，方法执行完后再释放monitor。

在方法执行期间，其他任何线程都无法再获得同一个monitor对象。这种方式与语句块没什么本质区别，都是通过竞争monitor的方式实现的。只不过这种方式是隐式的实现方法。

MONITORENTER和ACC_SYNCHRONIZED只是起标志作用，并无实质操作。

锁静态方法


private static int a = 0;

public synchronized static void add(){
        System.out.println("a values "+ ++a);
}

常量池中用ACC_STATIC标志了这是一个静态方法，然后用ACC_SYNCHRONIZED标志位提醒线程去竞争monitor。由于静态方法是属于类级别的方法（即不用创建对象就可以被调用），所以这是一个类级别（XXX.class）的锁，即竞争某个类的monitor。

锁的竞争过程

（1）、多个线程请求锁，首先进入Contention List，它可以接纳所有请求线程，而且是一个后进先出（LIFO）的虚拟队列，通过结点Node和next指针构造。
（2）（3）、ContentionList会被线程并发访问，EntryList为了降低线程对ContentionList队尾的争用而构造出来。当Owner释放锁时，会从ContentionList中迁移线程到EntryList，并会指定EntryList中的某个线程（一般为Head结点）为Ready Thread，也就是说某个时刻最多只有一个线程正在竞争锁。
（4）、Owner并不是直接把锁交给OnDeck线程，而是将竞争锁的权利交给OnDeck（将锁释放了），然后让OnDeck自己去竞争。竞争成功后，OnDeck线程就变成Owner；否则继续留在EntryList的队头。
（5）（6）、当线程调用wait方法被阻塞时，进入WaitSet；当其他线程调用notifyAll()（notify()）方法后，阻塞队列的（某个）线程就会进入EntryList中。

处于ContetionList、EntryList、WaitSet的线程均处于阻塞状态。而线程被阻塞涉及到用户态与内核态的切换（Liunx），系统切换严重影响锁的性能。解决这个问题的办法就是自旋。自旋就是线程不断进行内部循环，即for循环什么也不做，防止线程wait()阻塞，在自旋过程中不断尝试获取锁，如果自旋期间，Owner刚好释放锁，此时自旋线程就可以去竞争锁。如果自旋了一段时间还没获取到锁，那没办法，只能调用wait()阻塞了。
为什么自旋了一段时间后又调用wait()方法呢？因为自旋是要消耗CPU的，而且还有线程上下文切换，因为CPU还可以调度线程，只不过执行的是空的for循环罢了。
对自旋锁周期的选择上，HotSpot认为最佳时间应是一个线程上下文切换的时间，但目前并没有做到。
所以，synchronized是什么时候进行自旋的？答案是在进入ContetionList之前，因为它自旋一定时间后还没获取锁，最后它只好在ContetionList中阻塞等待了。

对象头

对象头(Object Header)包括两部分信息。

一部分用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等等，这部分数据的长度在32位和64位的虚拟机（暂不考虑开启压缩指针的场景）中分别为32个和64个Bits，官方称它为“Mark Word”。

对象需要存储的运行时数据很多，其实已经超出了32、64位Bitmap结构所能记录的限度，但是对象头信息是与对象自身定义的数据无关的额外存储成本，考虑到虚拟机的空间效率，Mark Word被设计成一个非固定的数据结构以便在极小的空间内存储尽量多的信息，它会根据对象的状态复用自己的存储空间。例如在32位的HotSpot虚拟机中对象未被锁定的状态下，Mark Word的32个Bits空间中的25Bits用于存储对象哈希码（HashCode），4Bits用于存储对象分代年龄，2Bits用于存储锁标志位，1Bit固定为0，在其他状态（轻量级锁定、重量级锁定、GC标记、可偏向）下对象的存储内容如下表所示。

另外一部分是类型指针，即是对象指向它的类的元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。并不是所有的虚拟机实现都必须在对象数据上保留类型指针，换句话说查找对象的元数据信息并不一定要经过对象本身。另外，如果对象是一个Java数组，那在对象头中还必须有一块用于记录数组长度的数据，因为虚拟机可以通过普通Java对象的元数据信息确定Java对象的大小，但是从数组的元数据中无法确定数组的大小。

为了减少锁释放带来的消耗，锁有一个升级的机制，从轻到重依次是：无锁状态 ——> 偏向锁 ——> 轻量级锁 ——>重量级锁。

偏向锁

在无其它线程与它竞争的情况下，持有偏向锁的线程永远也不需要同步。

它的加锁过程很简单：线程访问同步代码块时检查偏向锁中线程ID是否指向自己，如果是表明该线程已获得锁；否则，检测偏向锁标记是否为1，不是的话则CAS竞争锁，如果是就将对象头中线程ID指向自己。

当存在线程竞争锁时，偏向锁才会撤销，转而升级为轻量级锁。而这个撤销过程则需要有一个全局安全点（即这个时间点上没有正在执行的字节码）

在撤销锁的时候，栈中对象头的Mark Word要么偏向于其他线程，要么恢复到无锁或者轻量级锁。

优点：加锁和解锁无需额外消耗
缺点：锁进化时会带来额外锁撤销的消耗
适用场景：只有一个线程访问同步代码块

轻量级锁

优点：竞争的线程不阻塞，也就是不涉及到用户态与内核态的切换（Liunx），减少系统切换锁带来的开销
缺点：如果长时间竞争不到锁，自旋会消耗CPU
适用场景：追求响应时间、同步块执行速度非常快

重量级锁

它是传统意义上的锁，通过互斥量来实现同步，线程阻塞，等待Owner释放锁唤醒。

优点：线程竞争不自旋，不消耗CPU
缺点：线程阻塞，响应时间慢
适用场景：追求吞吐量、同步块执行时间较长