一、Java对象结构

1.1 对象结构

Java对象（Object实例）结构包括三部分：对象头、对象体和对齐字节，具体如图所示。

(1)对象头

对象头包括三个字段：

第一个字段叫作Mark Word（标记字）​，用于存储自身运行时的数据，例如GC标志位、哈希码、锁状态等信息。

第二个字段叫作Class Pointer（类对象指针），用于存放方法区Class对象的地址，虚拟机通过这个指针来确定这个对象是哪个类的实例。

第三个字段叫作Array Length（数组长度）​。如果对象是一个Java数组，那么此字段必须有，用于记录数组长度的数据；如果对象不是一个Java数组，那么此字段不存在，所以这是一个可选字段。

(2)对象体

对象体包含对象的实例变量（成员变量）​，用于成员属性值，包括父类的成员属性值。这部分内存按4字节对齐。

(3)对齐字节

对齐字节也叫作填充对齐，其作用是用来保证Java对象所占内存字节数为8的倍数。HotSpot VM的内存管理要求对象起始地址必须是8字节的整数倍。对象头本身是8的倍数，当对象的实例变量数据不是8的倍数时，便需要填充数据来保证8字节的对齐。

1.2 Mark Word的结构信息

Java内置锁涉及很多重要信息，这些都存放在对象结构中，并且存放于对象头的Mark Word字段中。Mark Word的位长度为JVM的一个Word大小，也就是说32位JVM的Mark Word为32位，64位JVM为64位。

Java内置锁的状态总共有4种，级别由低到高依次为：无锁、偏向锁、轻量级锁和重量级锁。

其实在JDK 1.6之前，Java内置锁还是一个重量级锁，是一个效率比较低下的锁，在JDK 1.6之后，JVM为了提高锁的获取与释放效率，对synchronized的实现进行了优化，引入了偏向锁和轻量级锁，从此以后Java内置锁的状态就有了4种（无锁、偏向锁、轻量级锁和重量级锁）​，并且4种状态会随着竞争的情况逐渐升级，而且是不可逆的过程，即不可降级，也就是说只能进行锁升级（从低级别到高级别）​。

不同锁状态下的Mark Word字段结构

目前主流的JVM都是64位，下面介绍64位的Mark Word。

Mark Word字段的结构与Java内置锁的状态强相关。为了让Mark Word字段存储更多的信息，JVM将Mark Word最低两个位设置为Java内置锁状态位，不同锁状态下的64位Mark Word结构如表所示。

lock：锁状态标记位，占两个二进制位，由于希望用尽可能少的二进制位表示尽可能多的信息，因此设置了lock标记。该标记的值不同，整个Mark Word表示的含义就不同。

biased_lock：对象是否启用偏向锁标记，只占1个二进制位。为1时表示对象启用偏向锁，为0时表示对象没有偏向锁。

lock和biased_lock两个标记位组合在一起共同表示Object实例处于什么样的锁状态。二者组合的含义具体如图所示。

age: 4位的Java对象分代年龄。

identity_hashcode: 31位的对象标识HashCode（哈希码）采用延迟加载技术，当调用Object.hashCode()方法或者System.identityHashCode()方法计算对象的HashCode后，其结果将被写到该对象头中。当对象被锁定时，该值会移动到Monitor（监视器）中。

thread: 54位的线程ID值为持有偏向锁的线程ID。（偏向锁）

epoch：偏向时间戳。（偏向锁）

ptr_to_lock_record：占62位，在轻量级锁的状态下指向栈帧中锁记录的指针。（轻量级锁）

ptr_to_heavyweight_monitor：占62位，在重量级锁的状态下指向对象监视器的指针。（重量级锁）

二、锁介绍：无锁、偏向锁、轻量级锁和重量级锁

在JDK 1.6版本中内置锁一共有4种状态：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，这些状态随着竞争情况逐渐升级。

内置锁可以升级但不能降级，意味着偏向锁升级成轻量级锁后不能再降级成偏向锁。

这种能升级却不能降级的策略，其目的是提高获得锁和释放锁的效率。

2.1 无锁状态

Java对象刚创建时还没有任何线程来竞争，说明该对象处于无锁状态（无线程竞争它）​，这时偏向锁标识位是0，锁状态是01。无锁状态下对象的Mark Word如图所示。

2.2 偏向锁状态

偏向锁是指一段同步代码一直被同一个线程所访问，那么该线程会自动获取锁，降低获取锁的代价。

如果内置锁处于偏向状态，当有一个线程来竞争锁时，先用偏向锁，表示内置锁偏爱这个线程，这个线程要执行该锁关联的同步代码时，不需要再做任何检查和切换。

偏向锁在竞争不激烈的情况下效率非常高。

偏向锁状态的Mark Word会记录内置锁自己偏爱的线程ID。偏向锁状态下对象的Mark Word如图所示。

2.3 轻量级锁状态

当有两个线程开始竞争这个锁对象时，情况就发生变化了，不再是偏向（独占）锁了，锁会升级为轻量级锁，两个线程公平竞争，哪个线程先占有锁对象，锁对象的Mark Word就指向哪个线程的栈帧中的锁记录。

轻量级锁状态下对象的Mark Word如图所示。

当锁处于偏向锁，又被另一个线程企图抢占时，偏向锁就会升级为轻量级锁。

企图抢占的线程会通过自旋的形式尝试获取锁，不会阻塞抢锁线程，以便提高性能。

自旋原理非常简单，如果持有锁的线程能在很短时间内释放锁资源，那么那些等待竞争锁的线程就不需要进行内核态和用户态之间的切换来进入阻塞挂起状态，它们只需要等一等（自旋）​，等持有锁的线程释放锁后即可立即获取锁，这样就避免了用户线程和内核切换的消耗。

但是，线程自旋是需要消耗CPU的，如果一直获取不到锁，那么线程也不能一直占用CPU自旋做无用功，所以需要设定一个自旋等待的最大时间。

JVM对于自旋周期的选择，JDK 1.6之后引入了适应性自旋锁，适应性自旋锁意味着自旋的时间不是固定的，而是由前一次在同一个锁上的自旋时间以及锁的拥有者的状态来决定的。线程如果自旋成功了，下次自旋的次数就会更多，如果自旋失败了，自旋的次数就会减少。

如果持有锁的线程执行的时间超过自旋等待的最大时间仍没有释放锁，就会导致其他争用锁的线程在最大等待时间内还是获取不到锁，自旋不会一直持续下去，这时争用线程会停止自旋进入阻塞状态，该锁膨胀为重量级锁。

2.4 重量级锁

重量级锁会让其他申请的线程进入阻塞，性能降低。重量级锁也叫同步锁，这个锁对象Mark Word再次发生变化，会指向一个监视器对象，该监视器对象用集合的形式来登记和管理排队的线程。

重量级锁状态下对象的Mark Word如图所示。

三、各个锁的原理

3.1偏向锁

偏向锁主要解决无竞争下的锁性能问题，所谓的偏向就是偏心，即锁会偏向于当前已经占有锁的线程。

（1）引入偏向锁的原因：

如果一个同步块（或方法）没有多个线程竞争，而且总是由同一个线程多次重入获取锁，如果每次还有阻塞线程，唤醒CPU从用户态转为核心态，那么对于CPU是一种资源的浪费，为了解决这类问题，就引入了偏向锁的概念。

（2）偏向锁的核心原理：

如果不存在线程竞争的一个线程获得了锁，那么锁就进入偏向状态，此时Mark Word的结构变为偏向锁结构，锁对象的锁标志位(lock)被改为01，偏向标志位(biased_lock)被改为1，然后线程的ID记录在锁对象的Mark Word中（使用CAS操作完成）​。以后该线程获取锁时判断一下线程ID和标志位，就可以直接进入同步块，连CAS操作都不需要，这样就省去了大量有关锁申请的操作，从而也就提升了程序的性能。

假如在大部分情况下同步块是没有竞争的，那么可以通过偏向来提高性能。

即在无竞争时，之前获得锁的线程再次获得锁时会判断偏向锁的线程ID是否指向自己，如果是，那么该线程将不用再次获得锁，直接就可以进入同步块；如果未指向当前线程，当前线程就会采用CAS操作将Mark Word中的线程ID设置为当前线程ID，如果CAS操作成功，那么获取偏向锁成功，执行同步代码块，如果CAS操作失败，那么表示有竞争，抢锁线程被挂起，撤销占锁线程的偏向锁，然后将偏向锁膨胀为轻量级锁。

（3）偏向锁的缺点：

如果锁对象时常被多个线程竞争，偏向锁就是多余的，并且其撤销的过程会带来一些性能开销。

（4）偏向锁的加锁过程：

新线程只需要判断内置锁对象的Mark Word中的线程ID是不是自己的ID，如果是就直接使用这个锁，而不使用CAS交换；如果不是，比如在第一次获得此锁时内置锁的线程ID为空，就使用CAS交换，新线程将自己的线程ID交换到内置锁的Mark Word中，如果交换成功，就加锁成功。

（5）偏向锁的撤销：

撤销偏向锁的条件：

(1)多个线程竞争偏向锁。

(2)调用偏向锁对象的hashcode()方法或者System.identityHashCode()方法计算对象的HashCode之后，将哈希码放置到Mark Word中，内置锁变成无锁状态，偏向锁将被撤销。

偏向锁撤销过程：

(1)在一个安全点停止拥有锁的线程。

(2)遍历线程的栈帧，检查是否存在锁记录。如果存在锁记录，就需要清空锁记录，使其变成无锁状态，并修复锁记录指向的Mark Word，清除其线程ID。

(3)将当前锁升级成轻量级锁。

(4)唤醒当前线程。

所以，如果某些临界区存在两个及两个以上的线程竞争，那么偏向锁反而会降低性能。在这种情况下，可以在启动JVM时就把偏向锁的默认功能关闭。

（6）偏向锁的膨胀：

何时膨胀：

当有多个线程来竞争偏向锁，此对象锁已经有所偏向，其他的线程发现偏向锁并不是偏向自己，就说明存在了竞争，尝试撤销偏向锁（很可能引入安全点），然后膨胀到轻量级锁。

如果偏向锁被占据，一旦有第二个线程争抢这个对象，因为偏向锁不会主动释放，所以第二个线程可以看到内置锁偏向状态，这时表明在这个对象锁上已经存在竞争了。JVM检查原来持有该对象锁的占有线程是否依然存活，如果挂了，就可以将对象变为无锁状态，然后进行重新偏向，偏向为抢锁线程。如果JVM检查到原来的线程依然存活，就进一步检查占有线程的调用堆栈是否通过锁记录持有偏向锁。如果存在锁记录，就表明原来的线程还在使用偏向锁，发生锁竞争，撤销原来的偏向锁，将偏向锁膨胀(INFLATING)为轻量级锁。

（7）偏向锁的好处：

经验表明，其实大部分情况下进入一个同步代码块的线程都是同一个线程。这也是JDK会引入偏向锁的原因。所以，总体来说，使用偏向锁带来的好处还是大于偏向锁撤销和膨胀所带来的代价。

3.2轻量级锁

（1）引入轻量级锁的主要目的：

在多线程竞争不激烈的情况下，通过自选CAS机制竞争锁减少重量级锁产生的性能损耗。

轻量锁存在的目的是尽可能不动用操作系统层面的互斥锁，因为其性能比较差。重量级锁使用了操作系统底层的互斥锁(Mutex Lock)，会导致线程在用户态和核心态之间频繁切换，从而带来较大的性能损耗。

我们可以发现，很多对象锁的锁定状态只会持续很短的一段时间，通常自旋不久即可获取锁，因此引入了轻量级锁。

（2）轻量级锁的原理和执行过程：

轻量级锁是一种自旋锁，因为JVM本身就是一个应用，所以希望在应用层面上通过自旋解决线程同步问题。

轻量级锁的执行过程和原理：

在抢锁线程进入临界区之前，如果内置锁（临界区的同步对象）没有被锁定，JVM首先将在抢锁线程的栈帧中建立一个锁记录(Lock Record)，用于存储对象目前Mark Word的拷贝，这时的线程堆栈与内置锁对象头大致如图所示。

然后抢锁线程将使用CAS自旋操作，尝试将内置锁对象头的Mark Word的ptr_to_lock_record（锁记录指针）更新为抢锁线程栈帧中锁记录的地址，如果这个更新执行成功了，这个线程就拥有了这个对象锁。

然后JVM将Mark Word中的lock标记位改为00（轻量级锁标志）​，即表示该对象处于轻量级锁状态。

抢锁成功之后，JVM会将Mark Word中原来的锁对象信息（如哈希码等）保存在抢锁线程锁记录的Displaced Mark Word（可以理解为放错地方的Mark Word）字段中，再将抢锁线程中锁记录的owner指针指向锁对象。

在轻量级锁抢占成功之后，锁记录和对象头的状态如图所示。

锁记录是线程私有的，每个线程都有自己的一份锁记录，在创建完锁记录后，会将内置锁对象的Mark Word复制到锁记录的Displaced Mark Word字段。这是因为内置锁对象的Mark Word的结构会有所变化，Mark Word将会出现一个指向锁记录的指针，而不再存着无锁状态下的锁对象哈希码等信息，所以必须将这些信息暂存起来，供后面在锁释放时使用。

（3）轻量级锁分类

轻量级锁的分类轻量级锁主要有两种：普通自旋锁和自适应自旋锁。

普通自旋锁：

所谓普通自旋锁，就是指当有线程来竞争锁时，抢锁线程会在原地循环等待，而不是被阻塞，直到那个占有锁的线程释放锁之后，这个抢锁线程才可以获得锁。

说明

锁在原地循环等待的时候是会消耗CPU的，就相当于在执行一个什么也不干的空循环。所以轻量级锁适用于临界区代码耗时很短的场景，这样线程在原地等待很短的时间就能够获得锁了。

默认情况下，自旋的次数为10次，用户可以通过-XX:PreBlockSpin选项来进行更改。

自适应自旋锁

所谓自适应自旋锁，就是等待线程空循环的自旋次数并非是固定的，而是会动态地根据实际情况来改变自旋等待的次数，自旋次数由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。

自适应自旋锁的大概原理是：

(1)如果抢锁线程在同一个锁对象上之前成功获得过锁，JVM就会认为这次自旋很有可能再次成功，因此允许自旋等待持续相对更长的时间。

(2)如果对于某个锁，抢锁线程很少成功获得过，那么JVM将可能减少自旋时间甚至省略自旋过程，以避免浪费处理器资源。

说明

JDK 1.6的轻量级锁使用的是普通自旋锁，且需要使用-XX:+UseSpinning选项手工开启。

JDK 1.7后，轻量级锁使用自适应自旋锁，JVM启动时自动开启，且自旋时间由JVM自动控制。轻量级锁也被称为非阻塞同步、乐观锁，因为这个过程并没有把线程阻塞挂起，而是让线程空循环等待。

（4）轻量级锁的膨胀

虽然大部分临界区代码的执行时间都是很短的，但是也会存在执行得很慢的临界区代码。临界区代码执行耗时较长，在其执行期间，其他线程都在原地自旋等待，会空消耗CPU。

因此，如果竞争这个同步锁的线程很多，就会有多个线程在原地等待继续空循环消耗CPU（空自旋）​，这会带来很大的性能损耗。轻量级锁的本意是为了减少多线程进入操作系统底层的互斥锁(Mutex Lock)的概率，并不是要替代操作系统互斥锁。所以，在争用激烈的场景下，轻量级锁会膨胀为基于操作系统内核互斥锁实现的重量级锁。

如果持有锁的线程执行的时间超过自旋等待的最大时间仍没有释放锁，就会导致其他争用锁的线程在最大等待时间内还是获取不到锁，自旋不会一直持续下去，这时争用线程会停止自旋进入阻塞状态，该锁膨胀为重量级锁。

3.3重量级锁的原理

在JVM中，每个对象都关联一个监视器。监视器是一个同步工具，相当于一个许可证，拿到许可证的线程即可进入临界区进行操作，没有拿到则需要阻塞等待。重量级锁通过监视器的方式保障了任何时间只允许一个线程通过受到监视器保护的临界区代码。

本质上，监视器是一种同步工具，也可以说是一种同步机制，主要特点是：

(1)同步。监视器所保护的临界区代码是互斥地执行的。一个监视器是一个运行许可，任一线程进入临界区代码都需要获得这个许可，离开时把许可归还。

(2)协作。监视器提供Signal机制，允许正持有许可的线程暂时放弃许可进入阻塞等待状态，等待其他线程发送Signal去唤醒；其他拥有许可的线程可以发送Signal，唤醒正在阻塞等待的线程，让它可以重新获得许可并启动执行。

在Hotspot虚拟机中，监视器是由C++类ObjectMonitor实现的，ObjectMonitor类定义在ObjectMonitor.hpp文件中。

ObjectMonitor的WaitSet、Cxq、EntryList这三个队列存放抢夺重量级锁的线程，而ObjectMonitor的Owner所指向的线程即为获得锁的线程。

ObjectMonitor抢锁过程如图所示：

Cxq：

竞争队列(Contention Queue)，所有请求锁的线程首先被放在这个竞争队列中。

在线程进入Cxq前，抢锁线程会先尝试通过CAS自旋获取锁，如果获取不到，就进入Cxq队列，这明显对于已经进入Cxq队列的线程是不公平的。所以，synchronized同步块所使用的重量级锁是不公平锁。

EntryList:

Cxq中那些有资格成为候选资源的线程被移动到EntryList中。

Cxq会被线程并发访问，为了降低对Cxq队尾的争用，而建立EntryList。在Owner线程释放锁时，JVM会从Cxq中迁移线程到EntryList，并会指定EntryList中的某个线程（一般为Head）为OnDeck Thread(Ready Thread)。EntryList中的线程作为候选竞争线程而存在。

OnDeck Thread与Owner Thread

JVM不直接把锁传递给Owner Thread，而是把锁竞争的权利交给OnDeck Thread, OnDeck需要重新竞争锁。这样虽然牺牲了一些公平性，但是能极大地提升系统的吞吐量，在JVM中，也把这种选择行为称为“竞争切换”​。OnDeck Thread获取到锁资源后会变为Owner Thread。无法获得锁的OnDeck Thread则会依然留在EntryList中，考虑到公平性，OnDeck Thread在EntryList中的位置不发生变化（依然在队头）​。在OnDeck Thread成为Owner的过程中，还有一个不公平的事情，就是后来的新抢锁线程可能直接通过CAS自旋成为Owner而抢到锁。

WaitSet：

某个拥有ObjectMonitor的线程在调用Object.wait()方法之后将被阻塞，然后该线程将被放置在WaitSet链表中。

如果Owner线程被Object.wait()方法阻塞，就转移到WaitSet队列中，直到某个时刻通过Object.notify()或者Object.notifyAll()唤醒，该线程就会重新进入EntryList中。

重量级锁的开销

等待队列中的线程都处于阻塞状态，线程的阻塞或者唤醒都需要操作系统来帮忙，进程需要从用户态切换到内核态。

用户态与内核态有各自专用的内存空间、专用的寄存器等，进程从用户态切换至内核态需要传递许多变量、参数给内核，内核也需要保护好用户态在切换时的一些寄存器值、变量等，以便内核态调用结束后切换回用户态继续工作。切换过程开销很大。

由于JVM轻量级锁使用CAS进行自旋抢锁，这些CAS操作都处于用户态下，进程不存在用户态和内核态之间的运行切换，因此JVM轻量级锁开销较小。而JVM重量级锁使用了Linux内核态下的互斥锁，这是重量级锁开销很大的原因。