1.字节码层面

通常我们使用synchronized有2种用法，一种是同步方法，一种是同步代码块。

如图1所示

对Test类进行反编译，我们发现同步方法JVM是通过ACC_SYNCHRONIZED标记符来实现同步的，当某个线程访问某个方法时，会检查是否有ACC_SYNCHRONIZED，如果有，则需要先获得锁，然后执行方法，方法执行之后再释放锁。这时如果其他线程来请求执行方法，会因为无法获得锁而被阻断住。

而同步代码块JVM是通过字节码指令monitorenter和monitorexit实现的，monitorenter相当于加锁，monitorexit相当于解锁，另外，每个对象还维护着一个计数器用来记录被锁的次数，这个后文看源码我们会看到，当一个线程获得了锁，那么计数器就加1，如果同一个线程再次获得此锁，那么计数器再次加1，当线程释放锁时，计数器减1，当计数器为0时表示锁被释放。

这里有一点需要说明下，我们看图1中，同步代码块有1个monitorenter，但是却有2个monitorexit，这是因为JVM为了保证方法在出异常时也能正常释放锁，编译器会自动产生一个异常处理器，目的就是用来执行monitorexit指令。

好了，说到这里，我们已经简单的了解了synchronized的锁原理，那么这个锁到底是什么呢，他是怎么实现的呢？

2.对象锁

这个锁就是对象锁，或者叫监视器(monitor)锁，他是存储在对象头中的，这里简单说一下java对象的内存布局，java对象在内存中分为3个部分：对象头，实例数据，对齐填充。对象头又分为2部分，一部分用来存储对象运行时数据，比如哈希码，GC分代年龄，锁标志位，偏向线程ID，偏向时间戳等，通常称之为Mark Word,另一部分存储类型指针。网上找了张图，如图2所示

synchronized就是通过对Mark Word中锁标志位，偏向线程ID等数据的设置来实现锁的。

下面我们来说一下具体实现。

Java中的每一个对象在JVM内部都会有一个native的C++对象与之对应。JVM采用OOP-Klass模型来描述Java对象实例，OOP(Ordinary Object Point)指的是普通对象指针，Klass用来描述对象实例的具体类型。简单的说，OOP就相当于我们java里创建的实例对象，Klass相当于java类。

我们来看一下OOP的源码结构，在oop.hpp中，如图3，图4所示

其中markOop就是我们说的对象头，我们在看一下markOop中的结构，在markOop.hpp中，如图5，图6所示

图5中的字段对应的就是图2里表格的内容，图6表示的是锁的状态，这个后面介绍。而正如我们java里所有的对象都继承于Object类，在JVM里所有的对象同样继承于一个oopDesc对象，我们对锁的获取是通过一个monitor()方法来实现的，而markOop这个对象头对象扩展了这个方法，如下图所示

返回一个ObjectMonitor对象，我们继续看下这个对象，在objectMonitor.hpp中，如图8所示

所有获得锁的线程都会被记录在_owner这个字段中。

到此我们通过对象的结构分析了解了下锁的实现，下面我们来看下线程是如何竞争锁的。

从JDK1.6开始，JVM对synchronized进行了大量优化，包括自旋锁，适应性自旋锁，锁消除，锁粗化，偏向锁，轻量级锁等，而我们传统意义上的锁称之为重量级锁。锁一共会有四种状态，锁的状态根据竞争激烈程度从低到高分别是:无锁状态->偏向锁状态->轻量级锁状态->重量级锁状态。这几个状态会随着锁竞争逐步升级。为了提高获得锁和释放锁的效率，锁可以升级但是不能降级。

关于锁之间的竞争过程在网上找了张图，如图9所示

其中具体的细节已经讲的很清楚了，有几点需要注意下：

1.偏向锁只有撤销，没有释放，当线程A获得偏向锁，执行完方法退出后，对象头中记录的偏向线程ID仍然是A，当A第二次来访问时，如果在此期间没有其他线程访问，那么A无需同步，直接执行方法。如果在执行方法期间，线程B访问该方法，那么B会尝试CAS替换对象头中的偏向线程ID，结果肯定是失败的，那么他会向JVM发起撤销请求，然后开始偏向锁的撤销。

2.当轻量级锁释放锁时，如果在锁定期间，有其他线程来访问，并且自旋失败了，那么他们会将轻量级锁膨胀为重量级锁，将锁记录指针指向重量级锁，所以此时轻量级锁会CAS操作失败，然后去唤醒那些被挂起的线程。

3.JVM内部为每个类维护了一个偏向锁revoke计数器，对偏向锁撤销进行计数，当这个值达到指定阈值时，JVM会认为这个类的偏向锁有问题，需要重新偏向(rebias),对所有属于这个类的对象进行重偏向，称之为批量重偏向(bulk rebias)。在做bulk rebias时，会对这个类的epoch的值做递增，这个epoch会存储在对象头中的epoch字段。如果这个类的revoke计数器的值继续增加到一个阈值，那么JVM会认为这个类不适合偏向锁，就需要进行批量撤销(bulk revoke)操作。