java Synchronized 锁

Posted 2023-02-21 安然_随心

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了java Synchronized 锁相关的知识，希望对你有一定的参考价值。

原文地址：https://www.cnblogs.com/mr-ziyoung/p/13085213.html
https://github.com/farmerjohngit/myblog/issues/12

文章目录

锁优化
锁升级
总结
参考文献

Synchronized关键字，用来给一段代码加上一个锁，从而实现多个线程在访问同一资源对象锁的时候进行同步执行（也即串行执行）。它是一个独享、非公平、悲观的锁。

锁优化

在使用锁的时候，JVM会对包含锁的代码进行锁优化，锁优化包括两种：锁消除和锁粗化。

锁消除

锁消除可以通过JVM的参数来设置，-XX:+DoEscapeAnalysis
-XX:+EliminateLocks。当这样设置后，当某一个本方法只被一个线程重复调用，不存在产生安全问题时，JIT会触发优化，在方法被连续调用时默认去掉多余的锁。比如某一方法使用StringBuffer的append方法进行连续调用时，则会消除中间调用方法里的synchronized。

锁粗化

锁粗化和锁消除类似，将代码中使用多个同一个对象锁的synchronized关键字进行合并，只使用一个。

锁升级

我们知道，当没有线程来争夺锁的时候，这个锁就是一个无状态锁，这个时候任何线程都可以去尝试来争夺该锁并对共享资源进行修改。而随着多个线程竞争情况的升级，锁的状态也会随着升级

Java 对象头

因为在Java中任意对象都可以用作锁，因此必定要有一个映射关系，存储该对象以及其对应的锁信息（比如当前哪个线程持有锁，哪些线程在等待）。一种很直观的方法是，用一个全局map，来存储这个映射关系，但这样会有一些问题：需要对map做线程安全保障，不同的synchronized之间会相互影响，性能差；另外当同步对象较多时，该map可能会占用比较多的内存。

所以最好的办法是将这个映射关系存储在对象头中，因为对象头本身也有一些hashcode、GC相关的数据，所以如果能将锁信息与这些信息共存在对象头中就好了。

对象头的内容如下：

长度	内容	说明
32/64bit	Mark Word	存储对象的hashCode或锁信息等
32/64bit	Class Metadata Address	存储到对象类型数据的指针
32/64bit	Array length	数组的长度（如果是数组）

从上表中我们可以看出对象的锁信息存放在Mark Word字段中，那么我们来看一下具体的Mark Word里边的内容：

说明	29 bit 或 61 bit	1 bit 是否是偏向锁	2 bit 锁标志位
无锁	对象的hashcode(25bit)和分代年龄(4bit)	0	01
偏向锁	线程ID(23bit)、Epoch时间戳(2bit)、分代年龄(4bit)	1	01
轻量级锁	指向栈中锁记录的指针	此时这一位不用于表示偏向锁	00
重量级锁	指向互斥量（重量级锁）的指针	此时这一位不用于表示偏向锁	10
GC标记			11

可以看到：

当对象状态为偏向锁时，Mark Word存储的是偏向的线程ID
当状态为轻量级锁时，Mark Word存储的是指向线程栈中锁记录的指针
当状态为重量级锁时，Mark Word为指向堆中的monitor对象的指针。
现在我们知道了对象的锁信息被存放在对象头的Mark Word里边，那么我们来看一下这个对象锁是怎么一步一步升级的。

偏向锁

一个线程在第一次进入同步块时，会在对象头和栈帧中的锁记录里存储锁的偏向的线程ID。当下次该线程进入这个同步块时，会去检查锁的Mark Word里面是不是放的自己的线程ID。
如果是，表明该线程已经获得了锁，以后该线程在进入和退出同步块时不需要花费CAS操作来加锁和解锁；如果不是，就代表有另一个线程来竞争这个偏向锁。这个时候会尝试使用CAS来替换Mark Word里面的线程ID为新线程的ID，这个时候要分两种情况：

成功，表示之前的线程不存在了， Mark Word里面的线程ID为新线程的ID，锁不会升级，仍然为偏向锁；
失败，表示之前的线程仍然存在，那么暂停之前的线程，设置偏向锁标识为0，并设置锁标志位为00，升级为轻量级锁，会按照轻量级锁的方式进行竞争锁。

图中涉及到了lock record指针指向当前堆栈中的最近一个lock record，是轻量级锁按照先来先服务的模式进行了轻量级锁的加锁（即开始拥有偏向锁的线程或拥有轻量级锁）

撤销偏向锁

偏向锁使用了一种等到竞争出现才释放锁的机制，所以当其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁。偏向锁升级成轻量级锁时，会暂停拥有偏向锁的线程，重置偏向锁标识，这个过程看起来容易，实则开销还是很大的，大概的过程如下：

在一个安全点（在这个时间点上没有字节码正在执行）停止拥有锁的线程。
遍历线程栈，如果存在锁记录的话，需要修复锁记录和Mark Word，使其变成无锁状态。
唤醒被停止的线程，将当前锁升级成轻量级锁。
所以，如果应用程序里所有的锁通常处于竞争状态，那么偏向锁就会是一种累赘，对于这种情况，我们可以一开始就把偏向锁这个默认功能给关闭：

轻量级锁

JVM会为每个线程在当前线程的栈帧中创建用于存储锁记录的空间，我们称为Displaced Mark Word。如果一个线程获得锁的时候发现是轻量级锁，会把锁的Mark Word复制到自己的Displaced Mark Word里面。

然后线程尝试用CAS将锁的Mark Word中用来指向栈中锁记录的位置替换为指向锁记录的指针。如果成功，当前线程获得锁，那么当前线程的栈帧中存储着锁的记录，另外栈中还有一个用来指向当前对象的对象头Mark Word的一个owner存储空间，用来说明当前引用的是哪个对象锁。如果失败，表示Mark Word已经被替换成了其他线程的锁记录，说明在与其它线程竞争锁，当前线程就尝试使用自旋来获取锁。

自旋是需要消耗CPU的，如果一直获取不到锁的话，那该线程就一直处在自旋状态，白白浪费CPU资源。解决这个问题最简单的办法就是指定自旋的次数，例如让其循环10次，如果还没获取到锁就进入阻塞状态。
但是JDK采用了更聪明的方式——适应性自旋，简单来说就是线程如果自旋成功了，则下次自旋的次数会更多，如果自旋失败了，则自旋的次数就会减少。
自旋也不是一直进行下去的，如果自旋到一定程度（和JVM、操作系统相关），依然没有获取到锁，称为自旋失败，那么这个线程会阻塞。同时这个锁就会升级成重量级锁。
轻量级锁的释放：
在释放锁时，当前线程会使用CAS操作将Displaced Mark Word的内容复制回锁的Mark Word里面。如果没有发生竞争，那么这个复制的操作会成功。如果有其他线程因为自旋多次导致轻量级锁升级成了重量级锁，那么CAS操作会失败，此时会释放锁并唤醒被阻塞的线程。
请参考下边的加锁和解锁流程图：

重量级锁

当一个对象锁成为了重量级锁之后，它的Mark Word中就有一个位置用来指向一个用来监视线程状态的对象监视器，它是通过互斥量来实现的。重量级锁依赖于操作系统的互斥量（mutex）实现的，而操作系统中线程间状态的转换需要相对比较长的时间，所以重量级锁效率很低，但被阻塞的线程不会消耗CPU。
前面说到，每一个对象都可以当做一个锁，当多个线程同时请求某个对象锁时，对象锁会使用一个对象监视器Monitor来监视该对象。

这个Monitor中设置几种状态用来区分请求的线程：

Contention List：所有请求锁的线程将被首先放置到该竞争队列
Entry List：Contention List中那些有资格成为候选人的线程被移到Entry List
Wait Set：那些调用wait方法被阻塞的线程被放置到Wait Set
OnDeck：任何时刻最多只能有一个线程正在竞争锁，该线程称为OnDeck
Owner：获得锁的线程称为Owner
!Owner：释放锁的线程
当一个线程尝试获得锁时，如果该锁已经被占用，则会将该线程封装成一个ObjectWaiter对象插入到Contention List的队列的队首，然后调用park函数挂起当前线程。
当线程释放锁时，会从Contention List或EntryList中挑选一个线程唤醒，被选中的线程叫做Heir presumptive即假定继承人，假定继承人被唤醒后会尝试获得锁，但synchronized是非公平的，所以假定继承人不一定能获得锁。这是因为对于重量级锁，线程先自旋尝试获得锁，这样做的目的是为了减少执行操作系统同步操作带来的开销。如果自旋不成功再进入等待队列。这对那些已经在等待队列中的线程来说，稍微显得不公平，还有一个不公平的地方是自旋线程可能会抢占了Ready线程的锁。
如果线程获得锁后调用Object.wait方法，则会将线程加入到WaitSet中，当被Object.notify唤醒后，会将线程从WaitSet移动到Contention List或EntryList中去。需要注意的是，当调用一个锁对象的wait或notify方法时，如当前锁的状态是偏向锁或轻量级锁则会先膨胀成重量级锁。