面试官：聊聊 Java 的几把 JVM 级锁吧

点击“开发者技术前线”，选择“星标🔝”

在看|星标|留言,  真爱

作者 | 夏杰

简介

在计算机行业有一个定律叫"摩尔定律"，在此定律下，计算机的性能突飞猛进，而且价格也随之越来越便宜，cpu从单核到了多核，缓存性能也得到了很大提升，尤其是多核cpu技术的到来，计算机同一时刻可以处理多个任务。在硬件层面的发展带来的效率极大提升中，软件层面的多线程编程已经成为必然趋势，然而多线程编程就会引入数据安全性问题，有矛必有盾，于是发明了“锁”来解决线程安全问题。在这篇文章中，总结了java中几把经典的JVM级别的锁。

synchronized

synchronized关键字是一把经典的锁，也是我们平时用得最多的。在jdk1.6之前，syncronized是一把重量级的锁，不过随着jdk的升级，也在对它进行不断的优化，如今它变得不那么重了，甚至在某些场景下，它的性能反而优于轻量级锁。在加了syncronized关键字的方法、代码块中，一次只允许一个线程进入特定代码段，从而避免多线程同时修改同一数据。

synchronized锁有如下几个特点：

a、有锁升级过程

在jdk1.5(含)之前，synchronized的底层实现是重量级的，所以之前一致称呼它为"重量级锁"，在jdk1.5之后，对synchronized进行了各种优化，它变得不那么重了，实现原理就是锁升级的过程。

我们先聊聊1.5之后的synchronized实现原理是怎样的，说到synchronized加锁原理，就不得不先说java对象在内存中的布局，java对象内存布局如下:

如上图所示，在创建一个对象后，在JVM虚拟机(HotSpot)中，对象在Java内存中的存储布局 可分为三块:

(1)对象头区域

此处存储的信息包括两部分：

• 对象自身的运行时数据(MarkWord)

存储hashCode、GC分代年龄、锁类型标记、偏向锁线程ID、CAS锁指向线程LockRecord的指针等，synconized锁的机制与这个部分(markwork)密切相关，用markword中最低的三位代表锁的状态，其中一位是偏向锁位，另外两位是普通锁位

• 对象类型指针(Class Pointer)

对象指向它的类元数据的指针、JVM就是通过它来确定是哪个Class的实例

(2)实例数据区域

 此处存储的是对象真正有效的信息，比如对象中所有字段的内容

(3)对齐填充区域

JVM的实现HostSpot规定对象的起始地址必须是8字节的整数倍，换句话来说，现在64位的OS往外读取数据的时候一次性读取64bit整数倍的数据，也就是8个字节，所以HotSpot为了高效读取对象，就做了"对齐"，如果一个对象实际占的内存大小不是8byte的整数倍时，就"补位"到8byte的整数倍。所以对齐填充区域的大小不是固定的。

当线程进入到synchronized处尝试获取该锁时，synchronized锁升级流程如下：

如上图所示，synchronized锁升级的顺序为：偏向锁->轻量级锁->重量级锁，每一步触发锁升级的情况如下：

偏向锁

在JDK1.8中，其实默认是轻量级锁，但如果设定了

• -XX:BiasedLockingStartupDelay = 0

那在对一个Object做syncronized的时候，会立即上一把偏向锁。当处于偏向锁状态时，markwork会记录当前线程ID

升级到轻量级锁

当下一个线程参与到偏向锁竞争时，会先判断markword中保存的线程ID是否与这个线程ID相等，如果不相等，会立即撤销偏向锁，升级为轻量级锁。每个线程在自己的线程栈中生成一个LockRecord(LR)，然后每个线程通过CAS(自旋)的操作将锁对象头中的markwork设置为指向自己的LR的指针，哪个线程设置成功，就意味着获得锁。

关于synchronized中此时执行的CAS操作是通过native的调用HotSpot中bytecodeInterpreter.cpp文件C++代码实现的，有兴趣的可以继续深挖。

升级到重量级锁

如果锁竞争加剧(如线程自旋次数或者自旋的线程数超过某阈值，JDK1.6之后，由JVM自己控制改规则)，就会升级为重量级锁。此时就会向操作系统申请资源，线程挂起，进入到操作系统内核态的等待队列中，等待操作系统调度，然后映射回用户态。在重量级锁中，由于需要做内核态到用户态的转换，而这个过程中需要消耗较多时间，也就是"重"的原因之一。

b、可重入

synchronized拥有强制原子性的内部锁机制，是一把可重入锁。因此，在一个线程使用synchronized方法时调用该对象另一个synchronized方法，即一个线程得到一个对象锁后再次请求该对象锁，是永远可以拿到锁的。在Java中线程获得对象锁的操作是以线程为单位的，而不是以调用为单位的。

synchronized锁的对象头的markwork中会记录该锁的线程持有者和计数器，当一个线程请求成功后，JVM会记下持有锁的线程，并将计数器计为1。此时其他线程请求该锁，则必须等待。而该持有锁的线程如果再次请求这个锁，就可以再次拿到这个锁，同时计数器会递增。

当线程退出一个synchronized方法/块时，计数器会递减，如果计数器为0则释放该锁锁。

c、悲观锁(互斥锁、排他锁)

synchronized是一把悲观锁(独占锁)，当前线程如果获取到锁，会导致其它所有需要锁该的线程等待，一直等待持有锁的线程释放锁才继续进行锁的争抢

ReentrantLock

ReentrantLock从字面可以看出是一把可重入锁，这点和synchronized一样，但实现原理也与syncronized有很大差别。

它是基于经典的AQS(AbstractQueueSyncronized)实现的,AQS是基于volitale和CAS实现的。其中AQS中维护一个valitale类型的变量state来做一个可重入锁的重入次数，加锁和释放锁也是围绕这个变量来进行的。ReentrantLock也提供了一些synchronized没有的特点，因此比synchronized好用。

AQS模型如下图：

ReentrantLock有如下特点：

a、可重入

ReentrantLock和syncronized关键字一样，都是可重入锁，不过两者实现原理稍有差别，RetrantLock利用AQS的的state状态来判断资源是否已锁，同一线程重入加锁，state的状态+1; 同一线程重入解锁,state状态-1(解锁必须为当前独占线程，否则异常); 当state为0时解锁成功。

b、需要手动加锁、解锁

synchronized关键字是自动进行加锁、解锁的，而ReentrantLock需要lock()和unlock()方法配合try/finally语句块来完成，来手动加锁、解锁。

c、支持设置锁的超时时间

synchronized关键字无法设置锁的超时时间，如果一个获得锁的线程内部发生死锁，那么其他线程就会一直进入阻塞状态，而ReentrantLock提供tryLock方法，允许设置线程获取锁的超时时间，如果超时，则跳过，不进行任何操作，避免死锁的发生。

d、支持公平/非公平锁

synchronized关键字是一种非公平锁，先抢到锁的线程先执行。而ReentrantLock的构造方法中允许设置true/false来实现公平、非公平锁，如果设置为true，则线程获取锁要遵循"先来后到"的规则，每次都会构造一个线程Node，然后到双向链表的"尾巴"后面排队，等待前面的Node释放锁资源。

e、可中断锁

ReentrantLock中的lockInterruptibly()方法使得线程可以在被阻塞时响应中断，比如一个线程t1通过lockInterruptibly()方法获取到一个可重入锁，并执行一个长时间的任务，另一个线程通过interrupt()方法就可以立刻打断t1线程的执行，来获取t1持有的那个可重入锁。

而通过ReentrantLock的lock()方法或者Synchronized持有锁的线程是不会响应其他线程的interrupt()方法的，直到该方法主动释放锁之后才会响应interrupt()方法。

ReentrantReadWriteLock

ReentrantReadWriteLock(读写锁)其实是两把锁：

• 一把是WriteLock(写锁)

• 一把是读锁，ReadLock

读写锁的规则是：读读不互斥、读写互斥、写写互斥。在一些实际的场景中，读操作的频率远远高于写操作，如果直接用一般的锁进行并发控制的话，就会读读互斥、读写互斥、写写互斥，效率低下，读写锁的产生就是为了优化这种场景的操作效率。一般情况下独占锁的效率低来源于高并发下对临界区的激烈竞争导致线程上下文切换。因此当并发不是很高的情况下，读写锁由于需要额外维护读锁的状态，可能还不如独占锁的效率高。因此需要根据实际情况选择使用。

ReentrantReadWriteLock的原理也是基于AQS进行实现的。

与ReentrantLock的差别在于ReentrantReadWriteLock锁拥有共享锁、排他锁属性。读写锁中的加锁、释放锁也是基于Sync(继承于AQS)，并且主要使用AQS中的state和node中的waitState变量进行实现的。

实现读写锁与实现普通互斥锁的主要区别在于需要分别记录读锁状态及写锁状态，并且等待队列中需要区别处理两种加锁操作。ReentrantReadWriteLock中将AQS中的int类型的state分为高16位与第16位分别记录读锁和写锁的状态，如下图所示：

a、WriteLock(写锁)是悲观锁(排他锁、互斥锁)

通过计算 state&((1<<16)-1)，将state的高16位全部抹去，因此state的低位记录着写锁的重入计数

获取写锁源码：

释放写锁源码：

b、ReadLock(读锁)是共享锁(乐观锁)

通过计算 state>>>16 进行无符号补0，右移16位，因此state的高位记录着写锁的重入计数。

读锁获取锁的过程比写锁稍微复杂些，首先判断写锁是否为0并且当前线程不占有独占锁，直接返回；否则，判断读线程是否需要被阻塞并且读锁数量是否小于最大值并且比较设置状态成功：

若当前没有读锁，则设置第一个读线程：

• firstReader

• firstReaderHoldCount；

若当前线程线程为第一个读线程，则增加：

• firstReaderHoldCount

否则，将设置当前线程对应的HoldCounter对象的值。

更新成功后会在readHolds(ThreadLocal类型的)的本线程副本中记录当前线程重入数，这是为了实现jdk1.6中加入的getReadHoldCount()方法的，这个方法能获取当前线程重入共享锁的次数(state中记录的是多个线程的总重入次数)，加入了这个方法让代码复杂了不少。

但是其原理还是很简单的：

• 如果当前只有一个线程的话，还不需要动用ThreadLocal；

• 直接往firstReaderHoldCount这个成员变量里存重入数；

• 当有第二个线程来的时候，就要动用ThreadLocal变量readHolds了，每个线程拥有自己的副本，用来保存自己的重入数。
  

获取读锁源码： 

释放读锁源码：

通过分析可以看出：

在线程持有读锁的情况下，该线程不能取得写锁(因为获取写锁的时候，如果发现当前的读锁被占用，就马上获取失败，不管读锁是不是被当前线程持有)。

在线程持有写锁的情况下，该线程可以继续获取读锁（获取读锁时如果发现写锁被占用，只有写锁没有被当前线程占用的情况才会获取失败）。

LongAdder

在高并发的情况下，我们对一个Integer类型的整数直接进行i++的时候，无法保证操作的原子性，会出现线程安全的问题。为此我们会用juc下的AtomicInteger，它是一个提供原子操作的Interger类，内部也是通过CAS实现线程安全的。

但当大量线程同时去访问时，就会因为大量线程执行CAS操作失败而进行空旋转，导致CPU资源消耗过多，而且执行效率也不高。Doug Lea大神应该也不满意，于是在JDK1.8中对CAS进行了优化，提供了LongAdder，它是基于了CAS分段锁的思想实现的。

线程去读写一个LongAdder类型的变量时，流程如下：

LongAdder也是基于Unsafe提供的CAS操作+valitale去实现的。在LongAdder的父类Striped64中维护着一个base变量和一个cell数组，当多个线程操作一个变量的时候，先会在这个base变量上进行cas操作，当它发现线程增多的时候，就会使用cell数组。

比如当base将要更新的时候发现线程增多（也就是调用casBase方法更新base值失败），那么它会自动使用cell数组，每一个线程对应于一个cell，在每一个线程中对该cell进行cas操作，这样就可以将单一value的更新压力分担到多个value中去，降低单个value的 “热度”，同时也减少了线程大量线程的空转，提高并发效率，分散并发压力。这种分段锁需要额外维护一个内存空间cells，不过在高并发场景下，这点成本几乎可以忽略。

分段锁是一种优秀的优化思想，juc中提供的的ConcurrentHashMap也是基于分段锁保证读写操作的线程安全。

在这里，我为大家准备了一份2020年最新最全的《Java面试题及答案V3.0》，这套电子书涵盖了诸多后端技术栈的面试题和答案，相信可以帮助大家在最短的时间内复习Java后端的大多数面试题，从而拿到自己心仪的offer。

截了张图，大家可以仔细查看左边的菜单栏，覆盖的知识面真的很广，而且质量都很不错。
资料获取方法

1. 扫描下方二维码加我微信

2. 后台回复关键词：Java核心整理

END

历史推荐

好文点个在看吧！