synchronized(从偏向锁到重量级锁)

青旅半醒 2024-04-17 22:01 62阅读 0赞

接触过线程安全的同学想必都使用过synchronized这个关键字，在java同步代码快中，synchronized的使用方式无非有两个:

通过对一个对象进行加锁来实现同步，如下面代码。

synchronized(lockObject){
        //代码
    }

对一个方法进行synchronized声明，进而对一个方法进行加锁来实现同步。如下面代码

public synchornized void test(){
        //代码
    }

但这里需要指出的是，无论是对一个对象进行加锁还是对一个方法进行加锁，实际上，都是对**对象进行加锁**。

也就是说，对于方式2，实际上虚拟机会根据synchronized修饰的是实例方法还是类方法，去取对应的实例对象或者Class对象来进行加锁。

对于synchronized这个关键字，可能之前大家有听过，他是一个**重量级锁**，开销很大，建议大家少用点。但大家可能也听说过，但到了jdk1.6之后，该关键字被进行了很多的优化，已经不像以前那样不给力了，建议大家多使用。

那么它是进行了什么样的优化，才使得synchronized又深得人心呢？为何重量级锁开销就大呢？

想必大家也都听说过轻量级锁，重量级锁，自旋锁，自适应自旋锁，偏向锁等等，他们都有哪些区别呢？  
刚才和大家说，锁是加在对象上的，那么一个线程是如何知道这个对象被加了锁呢？又是如何知道它加的是什么类型的锁呢？

基于这些问题，下面我讲一步一步讲解synchronized是如何被优化的，是如何从偏向锁到重量级锁的。

锁对象

刚才我们说，锁实际上是加在对象上的，那么被加了锁的对象我们称之为**锁对象**，在java中，任何一个对象都能成为锁对象。  
为了让大家更好着理解虚拟机是如何知道这个对象就是一个锁对象的，我们下面简单介绍一下java中一个对象的结构。  
java对象在内存中的存储结构主要有一下三个部分：

1.  对象头
2.  实例数据
3.  填充数据  
    这里强调一下，**对象头**里的数据主要是一些运行时的数据。  
    其简单的结构如下

<table> 
 <thead> 
  <tr> 
   <th>长度</th> 
   <th>内容</th> 
   <th>说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>32/64bit</td> 
   <td>Mark Work</td> 
   <td>hashCode,GC分代年龄，锁信息</td> 
  </tr> 
  <tr> 
   <td>32/64bit</td> 
   <td>Class Metadata Address</td> 
   <td>指向对象类型数据的指针</td> 
  </tr> 
  <tr> 
   <td>32/64bit</td> 
   <td>Array Length</td> 
   <td>数组的长度(当对象为数组时)</td> 
  </tr> 
 </tbody> 
</table>

从该表格中我们可以看到，对象中关于锁的信息是存在Markword里的。  
我们来看一段代码

`LockObject lockObject = new LockObject();//随便创建一个对象`

`synchronized(lockObject){`

`//代码`

`}`

当我们创建一个对象LockObject时，该对象的部分Markword关键数据如下。

<table> 
 <thead> 
  <tr> 
   <th>bit fields</th> 
   <th>是否偏向锁</th> 
   <th>锁标志位</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>hash</td> 
   <td>0</td> 
   <td>01</td> 
  </tr> 
 </tbody> 
</table>

从图中可以看出，**偏向锁**的标志位是“01”，状态是“0”，表示该对象还没有被加上偏向锁。（“1”是表示被加上偏向锁）。该对象被创建出来的那一刻，就有了偏向锁的标志位，这也说明了所有对象都是可偏向的，但所有对象的状态都为“0”，也同时说明所有被创建的对象的偏向锁并没有生效。

偏向锁

不过，当线程执行到临界区（critical section）时，此时会利用CAS(Compare and Swap)操作，将线程ID插入到Markword中，同时修改偏向锁的标志位。

> 所谓临界区，就是只允许一个线程进去执行操作的区域，即同步代码块。CAS是一个原子性操作

此时的Mark word的结构信息如下：

<table> 
 <thead> 
  <tr> 
   <th>bit fields</th> 
   <th>&nbsp;</th> 
   <th>是否偏向锁</th> 
   <th>锁标志位</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>threadId</td> 
   <td>epoch</td> 
   <td>1</td> 
   <td>01</td> 
  </tr> 
 </tbody> 
</table>

此时偏向锁的状态为“1”，说明对象的偏向锁生效了，同时也可以看到，哪个线程获得了该对象的锁。

那么，什么是偏向锁?

偏向锁是jdk1.6引入的一项锁优化，其中的“偏”是偏心的偏。它的意思就是说，这个锁会偏向于第一个获得它的线程，在接下来的执行过程中，假如该锁没有被其他线程所获取，没有其他线程来竞争该锁，那么持有偏向锁的线程将永远不需要进行同步操作。  
也就是说:  
在此线程之后的执行过程中，如果再次进入或者退出同一段同步块代码，并不再需要去进行**加锁**或者**解锁**操作，而是会做以下的步骤：

1.  Load-and-test，也就是简单判断一下当前线程id是否与Markword当中的线程id是否一致.
2.  如果一致，则说明此线程已经成功获得了锁，继续执行下面的代码.
3.  如果不一致，则要检查一下对象是否还是可偏向，即“是否偏向锁”标志位的值。
4.  如果还未偏向，则利用CAS操作来竞争锁，也即是第一次获取锁时的操作。

如果此对象已经偏向了，并且不是偏向自己，则说明存在了**竞争**。此时可能就要根据另外线程的情况，可能是重新偏向，也有可能是做偏向撤销，但大部分情况下就是升级成**轻量级锁**了。  
可以看出，偏向锁是针对于一个线程而言的，线程获得锁之后就不会再有解锁等操作了，这样可以省略很多开销。假如有两个线程来竞争该锁话，那么偏向锁就失效了，进而升级成轻量级锁了。  
为什么要这样做呢？因为经验表明，其实大部分情况下，都会是同一个线程进入同一块同步代码块的。这也是为什么会有偏向锁出现的原因。  
在Jdk1.6中，偏向锁的开关是默认开启的，适用于只有一个线程访问同步块的场景。

锁膨胀

刚才说了，当出现有两个线程来竞争锁的话，那么偏向锁就失效了，此时锁就会膨胀，升级为轻量级锁。这也是我们经常所说的**锁膨胀**

锁撤销

由于偏向锁失效了，那么接下来就得把该锁撤销，锁撤销的开销花费还是挺大的，其大概的过程如下：

1.  在一个安全点停止拥有锁的线程。
2.  遍历线程栈，如果存在锁记录的话，需要修复锁记录和Markword，使其变成无锁状态。
3.  唤醒当前线程，将当前锁升级成轻量级锁。  
    所以，如果某些同步代码块大多数情况下都是有两个及以上的线程竞争的话，那么偏向锁就会是一种累赘，对于这种情况，我们可以一开始就把偏向锁这个默认功能给关闭

轻量级锁

锁撤销升级为轻量级锁之后，那么对象的Markword也会进行相应的的变化。下面先简单描述下锁撤销之后，升级为轻量级锁的过程：

1.  线程在自己的栈桢中创建锁记录 LockRecord。
2.  将锁对象的对象头中的MarkWord复制到线程的刚刚创建的锁记录中。
3.  将锁记录中的Owner指针指向锁对象。
4.  将锁对象的对象头的MarkWord替换为指向锁记录的指针。

对应的图描述如下(图来自周志明深入java虚拟机)  
![图片1][1]  
![图片2][2]

之后Markwork如下：

<table> 
 <thead> 
  <tr> 
   <th>bit fields</th> 
   <th>锁标志位</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>指向LockRecord的指针</td> 
   <td>00</td> 
  </tr> 
 </tbody> 
</table>

注：锁标志位”00”表示**轻量级锁**  
轻量级锁主要有两种

1.  自旋锁
2.  自适应自旋锁

自旋锁

所谓自旋，就是指当有另外一个线程来竞争锁时，这个线程会在原地循环等待，而不是把该线程给**阻塞**，直到那个获得锁的线程释放锁之后，这个线程就可以马上获得锁的。  
注意，锁在原地循环的时候，是会消耗cpu的，就相当于在执行一个啥也没有的for循环。  
所以，轻量级锁适用于那些同步代码块执行的很快的场景，这样，线程原地等待很短很短的时间就能够获得锁了。  
经验表明，大部分同步代码块执行的时间都是很短很短的，也正是基于这个原因，才有了轻量级锁这么个东西。

自旋锁的一些问题

1.  如果同步代码块执行的很慢，需要消耗大量的时间，那么这个时侯，其他线程在原地等待空消耗cpu，这会让人很难受。
2.  本来一个线程把锁释放之后，当前线程是能够获得锁的，但是假如这个时候有好几个线程都在竞争这个锁的话，那么有可能当前线程会获取不到锁，还得原地等待继续空循环消耗cup，甚至有可能一直获取不到锁。

基于这个问题，我们必须给线程空循环设置一个次数，当线程超过了这个次数，我们就认为，继续使用自旋锁就不适合了，此时锁会再次膨胀，升级为**重量级锁**。  
默认情况下，自旋的次数为10次，用户可以通过-XX:PreBlockSpin来进行更改。

> 自旋锁是在JDK1.4.2的时候引入的

自适应自旋锁

所谓自适应自旋锁就是线程空循环等待的自旋次数并非是固定的，而是会动态着根据实际情况来改变自旋等待的次数。  
其大概原理是这样的：  
假如一个线程1刚刚成功获得一个锁，当它把锁释放了之后，线程2获得该锁，并且线程2在运行的过程中，此时线程1又想来获得该锁了，但线程2还没有释放该锁，所以线程1只能自旋等待，但是虚拟机认为，**由于线程1刚刚获得过该锁，那么虚拟机觉得线程1这次自旋也是很有可能能够再次成功获得该锁的，所以会延长线程1自旋的次数**。  
另外，如果对于某一个锁，一个线程自旋之后，很少成功获得该锁，那么以后这个线程要获取该锁时，是有可能直接忽略掉自旋过程，直接升级为重量级锁的，以免空循环等待浪费资源。

> 轻量级锁也被称为**非阻塞同步**、**乐观锁**，因为这个过程并没有把线程阻塞挂起，而是让线程空循环等待，串行执行。

重量级锁

轻量级锁膨胀之后，就升级为重量级锁了。重量级锁是依赖对象内部的monitor锁来实现的，而monitor又依赖操作系统的MutexLock(互斥锁)来实现的，所以重量级锁也被成为**互斥锁**。  
当轻量级所经过锁撤销等步骤升级为重量级锁之后，它的Markword部分数据大体如下

<table> 
 <thead> 
  <tr> 
   <th>bit fields</th> 
   <th>锁标志位</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>指向Mutex的指针</td> 
   <td>10</td> 
  </tr> 
 </tbody> 
</table>

为什么说重量级锁开销大呢

主要是，当系统检查到锁是重量级锁之后，会把等待想要获得锁的线程进行**阻塞**，被阻塞的线程不会消耗cup。但是阻塞或者唤醒一个线程时，都需要操作系统来帮忙，这就需要从**用户态**转换到**内核态**，而转换状态是需要消耗很多时间的，有可能比用户执行代码的时间还要长。  
这就是说为什么重量级线程开销很大的。

> 互斥锁(重量级锁)也称为**阻塞同步**、**悲观锁**

总结

通过上面的分析，我们知道了为什么synchronized关键字为何又深得人心，也知道了锁的演变过程。  
也就是说，synchronized关键字并非一开始就该对象加上重量级锁，也是从偏向锁，轻量级锁，再到重量级锁的过程。  
这个过程也告诉我们，假如我们一开始就知道某个同步代码块的竞争很激烈、很慢的话，那么我们一开始就应该使用重量级锁了，从而省掉一些锁转换的开销。  
讲到这里就大概完了，希望能对你有所帮助

**完**  
**参考资料**

1.  深入理解java虚拟机(JVM高级特性与最佳实践)
2.  java并发编程
3.  [Eliminating Synchronization Related Atomic Operations with Biased Locking and Bulk Rebiasing][]

[1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91c2VyLWdvbGQtY2RuLnhpdHUuaW8vMjAxOC84LzIyLzE2NTYxNDg5M2E1OWJlMzQ_dz03MjEmaD0zNDQmZj1wbmcmcz00MjAzMw?x-oss-process=image/format,png
[2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91c2VyLWdvbGQtY2RuLnhpdHUuaW8vMjAxOC84LzIyLzE2NTYxNDk2MGFiZjJmMGU_dz01NDkmaD0zNDMmZj1wbmcmcz0zNTUyMg?x-oss-process=image/format,png
[Eliminating Synchronization Related Atomic Operations with Biased Locking and Bulk Rebiasing]: http://www.oracle.com/technetwork/java/javase/tech/biasedlocking-oopsla2006-preso-150106.pdf