JVM09 Java虚拟机是如何实现synchronized的？

synchronized--面试的热点问题了吧，用法大家都知道：可以作用在代码块、静态方法、实例方法，也知道三种用法锁的对象是啥，底层原理是什么呢？虚拟机是如何实现的呢？

先看一段被synchronized声明的代码块编译后的字节码。

public void foo(Object lock) {
    synchronized (lock) {
      lock.hashCode();
    }
  }
// 上面的 Java 代码将编译为下面的字节码
 public void foo(java.lang.Object);
    Code:
       0: aload_1
       1: dup
       2: astore_2
       3: monitorenter
       4: aload_1
       5: invokevirtual java/lang/Object.hashCode:()I
       8: pop
       9: aload_2
      10: monitorexit
      11: goto          19
      14: astore_3
      15: aload_2
      16: ***monitorexit***
      17: aload_3
      18: athrow
      19: return
    Exception table:
       from    to  target type
           4    11    14   any
          14    17    14   any

字节码的每行意思暂且不研究，会发现很醒目的三行命令，第3行的monitorenter，第10行和第16行的monitorexit。当声明 synchronized 代码块时，编译而成的字节码将包含 monitorenter 和 monitorexit 指令。这两种指令均会消耗操作数栈上的一个引用类型的元素（也就是 synchronized 关键字括号里的引用），作为所要加锁解锁的锁对象。

声明方法时的字节码

public synchronized void foo(Object lock) {
    lock.hashCode();
  }
  // 上面的 Java 代码将编译为下面的字节码
  public synchronized void foo(java.lang.Object);
    descriptor: (Ljava/lang/Object;)V
    flags: (0x0021) ACC_PUBLIC, ACC_SYNCHRONIZED
    Code:
      stack=1, locals=2, args_size=2
         0: aload_1
         1: invokevirtual java/lang/Object.hashCode:()I
         4: pop
         5: return

你会看到字节码中方法的访问标记包括 ACC_SYNCHRONIZED，这里 monitorenter 和 monitorexit 操作所对应的锁对象是隐式的。对于实例方法来说，这两个操作对应的锁对象是 this；对于静态方法来说，这两个操作对应的锁对象则是所在类的 Class 实例。

讲到这里插入一个Jvm中对象的概念：对象的内存布局
对象在内存中的布局可以分为3块区域：对象头（header)，实例数据(Instance Data)和对齐填充(Padding)。
对象头包括两部分信息：
第一部分用于存储对象自身的运行时数据。如哈希码，GC分代年龄，锁状态标志，线程持有的锁，偏向线程id，偏向时间戳等。考虑到虚拟机的空间效率，此部分在32位和64位虚拟机中只占32位或者64位的大小。
第二部分是类型指针。即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。（并不是所有的虚拟机实现都保留类型指针，查找对象的元数据信息不一定要通过对象本身）
如果该对象是数组，那么对象头还会保留一块数据，用于记录数组长度。

很多文章都讲到synchronized底层是对象头+monitor实现的，没错，那具体是怎么实现的呢？
对象头的作用就是提供锁计数器和指向线程的指针的
当执行 monitorenter 时，如果计数器为 0，说明没有被其他线程所持有。Java 虚拟机会将该锁对象的持有线程指向当前线程，并且将其计数器加 1；如果计数器的值不为0，先判断指针指向是否是当前线程，若是则可获取锁（可重入锁），并且计数器加1，若不是则进入阻塞状态
当执行 monitorexit 时，Java 虚拟机则需将锁对象的计数器减 1。当计数器减为 0 时，那便代表该锁已经被释放掉了。
为什么上面字节码中出现两次 monitorexit？那是考虑到异常情况也要释放锁。

自JDK1.5之后就对synchronized做了很大的优化，加入了自旋锁，轻量级锁，偏向锁等

重量级锁

Java 虚拟机中最为基础的锁实现。在这种状态下，Java 虚拟机会阻塞加锁失败的线程，并且在目标锁被释放的时候，唤醒这些线程。
缺点：Java 线程的阻塞以及唤醒，都是依靠操作系统来完成的，这些操作将涉及系统调用，需要从操作系统的用户态切换至内核态，其开销非常之大。

自旋锁

为了尽量避免昂贵的线程阻塞、唤醒操作，Java 虚拟机会在线程进入阻塞状态之前，以及被唤醒后竞争不到锁的情况下，进入自旋状态，在处理器上空跑并且轮询锁是否被释放。如果此时锁恰好被释放了，那么当前线程便无须进入阻塞状态，而是直接获得这把锁。
缺点：很明显，自旋占用cup资源，在高并发的情况下很影响系统性能。

轻量级锁

采用 CAS 操作，将锁对象的标记字段替换为一个指针，指向当前线程栈上的一块空间，存储着锁对象原本的标记字段。它针对的是多个线程在不同时间段申请同一把锁的情况。

偏向锁

只会在第一次请求时采用 CAS 操作，在锁对象的标记字段中记录下当前线程的地址。在之后的运行过程中，持有该偏向锁的线程的加锁操作将直接返回。它针对的是锁仅会被同一线程持有的情况。

网上很多文章还在说synchronized的性能不如lock，那是以前，现在看来synchronized的性能会更好，当然考虑到synchronized是非公平锁，无法手动释放，没有读写分离功能还是要选择lock。