Java并发编程三：Synchronized底层优化（偏向锁、轻量级锁等各种锁）

缺乏、安全感 2022-02-18 08:19 258阅读 0赞

# [Java并发编程：Synchronized底层优化（偏向锁、轻量级锁等）][Java_Synchronized] #

**目录**

Java并发编程：Synchronized底层优化（偏向锁、轻量级锁）

一，概述

二，CAS算法

三，Java对象的对象头，以及Mark Word

四，各种锁

五，在应用层提高锁效率的方案

六、总结

--------------------

## 一，概述 ##

什么是java的锁？

1，java中使用synchronized关键字来实现同步功能，被synchronized修饰的方法或是代码块，在多线程的情况下不能同时执行，只能挨个执行，以避免一些多线程并发的问题，这是java同步语句本身存在的意义。

为什么java要有锁？

2，在JDK1.5之前，事情就是像前面说的那么简单，当线程A和线程B同时执行到同步代码块时，他们会争抢同步锁，假设线程A抢到了锁，那么线程B就会从运行状态(Running)变成阻塞(Blocked)状态，直到线程A退出同步代码块，线程B才能获得锁，从阻塞状态变成运行状态，进入代码块开始执行。

java的锁为什么需要优化？

3，到JDK1.6，java的开发者们不再满足于这种简单的运行-阻塞-运行模式了，因为这么在操作系统中切换线程的上下文的确挺慢，于是他们搞了一套优化的方案，也就是引入偏向锁，轻量级锁，自旋锁和重量级锁等概念，来提高同步锁的效率。从此，synchronized还是那个synchronized，用法还是那个用法，但是JVM不一定在拿不到锁的时候就直接阻塞线程了，而是有了一套更快一点的方案。

怎么优化的？

4，当锁的竞争很少或者基本没有时，JVM使用偏向锁来处理同步锁，这基本就算是没加锁。锁竞争越激烈的场景，JVM会把锁的处理方案会按照偏向锁，轻量级锁，自旋锁，重量级锁的顺序不断升级（或者叫锁的膨胀），这些锁的方案会消耗越来越多的资源，锁的效率也越来越低，所以JVM能用前面的方案就不会用后面的方案。

## 二，CAS算法 ##

CAS的全称是Compare-And-Swap，CAS算法的基本思想是这样的：当我们要改变一个变量的值时，先判断变量的值是否和某个预期值相同，如果相同则修改，如果不同则不修改。这个算法可以保证在多线程同时修改某个变量时，不会产生线程安全问题。

java中的java.util.concurrent.atomic包下的类很多都实现了这种算法，他们使用compareAndSet()方法来实现CAS，而且往往这个compareAndSet()方法对JVM来说都是原子操作，很安全。

## 三，Java对象的对象头，以及Mark Word ##

java的对象由三部分组成：对象头，实例数据，填充字节。

非数组对象的对象头由两部分组成：指向类的指针和Mark Word。

数组对象的对象头由三部分组成，比非数组对象多了块用于记录数组长度。

Mark Word用于记录对象的HashCode和锁信息等，在32位JVM中的Mark Word长度为32bit，在64位JVM中的Mark Word长度为64bit。

Mark Word的最后2bit是锁标志位，代表当前对象处于哪种锁状态，当Mark Word处于不同的锁状态时，Mark Word记录的信息也有所不同。

<table> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;"> 锁状态 </td> 
 <td colspan="3" style="vertical-align:top;"> 25 bit </td> 
 <td style="vertical-align:top;"> 4bit </td> 
 <td style="vertical-align:top;"> 1bit </td> 
 <td style="vertical-align:top;"> 2bit </td> 
 </tr> 
 <tr> 
 <td colspan="2" style="vertical-align:top;"> 23bit </td> 
 <td style="vertical-align:top;"> 2bit </td> 
 <td style="vertical-align:top;"> 是否是偏向锁 </td> 
 <td style="vertical-align:top;"> 锁标志位 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 轻量级锁 </td> 
 <td colspan="5" style="vertical-align:top;"> 指向栈中锁记录的指针 </td> 
 <td style="vertical-align:top;"> 00 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 重量级锁 </td> 
 <td colspan="5" style="vertical-align:top;"> 指向互斥量（重量级锁）的指针 </td> 
 <td style="vertical-align:top;"> 10 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> GC标记 </td> 
 <td colspan="5" style="vertical-align:top;"> 空 </td> 
 <td style="vertical-align:top;"> 11 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 偏向锁 </td> 
 <td style="vertical-align:top;"> 线程ID </td> 
 <td colspan="2" style="vertical-align:top;"> Epoch </td> 
 <td style="vertical-align:top;"> 对象分代年龄 </td> 
 <td style="vertical-align:top;"> 1 </td> 
 <td style="vertical-align:top;"> 01 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 无锁 </td> 
 <td colspan="3" style="vertical-align:top;"> 对象的hashCode </td> 
 <td style="vertical-align:top;"> 对象分代年龄 </td> 
 <td style="vertical-align:top;"> 0 </td> 
 <td style="vertical-align:top;"> 01 </td> 
 </tr> 
 </tbody> 
</table>

## 四，各种锁 ##

1、重量级锁

重量级锁就是java最原始的同步锁，抢不到锁的线程就会被阻塞，在等待池中等待激活。

这种锁不是公平锁，来的早的线程不一定优先激活。上篇文章中向大家介绍了Synchronized的用法及其实现的原理。现在我们应该知道，Synchronized是通过对象内部的一个叫做监视器锁（monitor）来实现的。但是监视器锁本质又是依赖于底层的操作系统的Mutex Lock来实现的。而操作系统实现线程之间的切换这就需要从用户态转换到核心态，这个成本非常高，状态之间的转换需要相对比较长的时间，这就是为什么Synchronized效率低的原因。因此，这种依赖于操作系统Mutex Lock所实现的锁我们称之为“重量级锁”。JDK中对Synchronized做的种种优化，其核心都是为了减少这种重量级锁的使用。JDK1.6以后，为了减少获得锁和释放锁所带来的性能消耗，提高性能，引入了“轻量级锁”和“偏向锁”。

**2、轻量级锁 **

锁的状态总共有四种：无锁状态、偏向锁、轻量级锁和重量级锁。随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁（但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级）。JDK 1.6中默认是开启偏向锁和轻量级锁的，我们也可以通过-XX:-UseBiasedLocking来禁用偏向锁。锁的状态保存在对象的头文件中，以32位的JDK为例：

“轻量级”是相对于使用操作系统互斥量来实现的传统锁而言的。但是，首先需要强调一点的是，轻量级锁并不是用来代替重量级锁的，它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用产生的性能消耗。在解释轻量级锁的执行过程之前，先明白一点，轻量级锁所适应的场景是线程交替执行同步块的情况，如果存在同一时间访问同一锁的情况，就会导致轻量级锁膨胀为重量级锁。

1）、**轻量级锁的加锁过程**

（1）在代码进入同步块的时候，如果同步对象锁状态为无锁状态（锁标志位为“01”状态，是否为偏向锁为“0”），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝，官方称之为 Displaced Mark Word。这时候线程堆栈与对象头的状态如图2.1所示。

（2）拷贝对象头中的Mark Word复制到锁记录中。

（3）拷贝成功后，虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针，并将Lock record里的owner指针指向object mark word。如果更新成功，则执行步骤（3），否则执行步骤（4）。

（4）如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位设置为“00”，即表示此对象处于轻量级锁定状态，这时候线程堆栈与对象头的状态如图2.2所示。

（5）如果这个更新操作失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行。否则说明多个线程竞争锁，轻量级锁就要膨胀为重量级锁，锁标志的状态值变为“10”，Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也要进入阻塞状态。 而当前线程便尝试使用自旋来获取锁，自旋就是为了不让线程阻塞，而采用循环去获取锁的过程。

![820406-20160424105442866-2111954866.png][]

图2.1 轻量级锁CAS操作之前堆栈与对象的状态

![820406-20160424105540163-1019388398.png][]

图2.2 轻量级锁CAS操作之后堆栈与对象的状态

**2）、轻量级锁的解锁过程：**

（1）通过CAS操作尝试把线程中复制的Displaced Mark Word对象替换当前的Mark Word。

（2）如果替换成功，整个同步过程就完成了。

（3）如果替换失败，说明有其他线程尝试过获取该锁（此时锁已膨胀），那就要在释放锁的同时，唤醒被挂起的线程。

**3、偏向锁**

引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径，因为轻量级锁的获取及释放依赖多次CAS原子指令，而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令（由于一旦出现多线程竞争的情况就必须撤销偏向锁，所以偏向锁的撤销操作的性能损耗必须小于节省下来的CAS原子指令的性能消耗）。上面说过，轻量级锁是为了在线程交替执行同步块时提高性能，而偏向锁则是在只有一个线程执行同步块时进一步提高性能。

**1）、偏向锁获取过程：**

（1）访问Mark Word中偏向锁的标识是否设置成1，锁标志位是否为01——确认为可偏向状态。

（2）如果为可偏向状态，则测试线程ID是否指向当前线程，如果是，进入步骤（5），否则进入步骤（3）。

（3）如果线程ID并未指向当前线程，则通过CAS操作竞争锁。如果竞争成功，则将Mark Word中线程ID设置为当前线程ID，然后执行（5）；如果竞争失败，执行（4）。

（4）如果CAS获取偏向锁失败，则表示有竞争。当到达全局安全点（safepoint）时获得偏向锁的线程被挂起，偏向锁升级为轻量级锁，然后被阻塞在安全点的线程继续往下执行同步代码。

（5）执行同步代码。

**2）、偏向锁的释放：**

**　　**偏向锁的撤销在上述第四步骤中有提到**。**偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程不会主动去释放偏向锁。偏向锁的撤销，需要等待全局安全点（在这个时间点上没有字节码正在执行），它会首先暂停拥有偏向锁的线程，判断锁对象是否处于被锁定状态，撤销偏向锁后恢复到未锁定（标志位为“01”）或轻量级锁（标志位为“00”）的状态。

启用偏向锁的方式：

> \-XX:+UseBiasedLocking
> 
> \-XX:BiasedLockingStartupDelay=0

关闭偏向锁的方式：

> \-XX:-UseBiasedLocking

**3）、重量级锁、轻量级锁和偏向锁之间转换**

![820406-20160424163618101-624122079.png][]

图 2.3三者的转换图

该图主要是对上述内容的总结，如果对上述内容有较好的了解的话，该图应该很容易看懂。

4，自旋锁 SpinLock  
spin在英文中用于描述纺纱的纱轮疯狂自转的样子，瞧这名字起的，一看就很耗CPU。

自旋锁其实并不属于锁的状态，从Mark Word的说明可以看到，并没有一个锁状态叫自旋锁。所谓自旋其实指的就是自己重试，当线程抢锁失败后，重试几次，要是抢到锁了就继续，要是抢不到就阻塞线程。说白了还是为了尽量不要阻塞线程。

由此可见，自旋锁是是比较消耗CPU的，因为要不断的循环重试，不会释放CPU资源。另外，加锁时间普遍较短的场景非常适合自旋锁，可以极大提高锁的效率。

在JDK1.6之前，自旋锁可以用参数来确定是否启用，以及自旋的次数：

\-XX:+UseSpinning 启用自旋锁

\-XX:PreBlockSpin=10 自旋次数10次

而从JDK1.7开始，自旋锁默认启用，而且JVM有了一套确认自旋次数和自旋周期的方案：

1，如果平均负载小于CPUs则一直自旋。

2，如果有超过(CPUs/2)个线程正在自旋，则后来线程直接阻塞。

3，如果正在自旋的线程发现Owner发生了变化则延迟自旋时间（自旋计数）或进入阻塞。

4，如果CPU处于节电模式则停止自旋。

5，自旋时间的最坏情况是CPU的存储延迟（CPU A存储了一个数据，到CPU B得知这个数据之间的时间差）。

6，自旋时会适当放弃线程优先级之间的差异。

java代码可以实现类似自旋锁的功能，网上有很多，我贴一个jetty中写的自旋锁的例子：

import java.util.concurrent.atomic.AtomicReference; 
public class SpinLock 
\{ 
    private final AtomicReference<Thread> \_lock = new AtomicReference<>(null); 
    private final Lock \_unlock = new Lock(); 
    
    public Lock lock() 
    \{ 
        Thread thread = Thread.currentThread(); 
        while(true) 
        \{ 
            if (!\_lock.compareAndSet(null,thread)) 
            \{ 
                if (\_lock.get()==thread) 
                    throw new IllegalStateException("SpinLock is not reentrant"); 
                continue; 
            \} 
            return \_unlock; 
        \} 
    \} 
    
    public boolean isLocked() 
    \{ 
        return \_lock.get()!=null; 
    \} 
    
    public boolean isLockedThread() 
    \{ 
        return \_lock.get()==Thread.currentThread(); 
    \} 
    
    public class Lock implements AutoCloseable 
    \{ 
        @Override 
        public void close() 
        \{ 
            \_lock.set(null); 
        \} 
    \} 
\} 
主要是思路就是用AtomicReference类的compareAndSet()方法，这个方法是原子操作，通过不断循环来重试获得锁。

## 五，在应用层提高锁效率的方案 ##

上面所说的锁的优化方案都是在JVM内部的，由JVM自己搞定。在应用层，开发者也可以采取一些措施，提高锁的效率。

1，减少锁的持有时间

指的是不需要同步执行的代码，不要放在同步代码块中。同步块中代码减少，锁的持续时间短，锁的性能会有所提高。

2，减小锁粒度

指的是把资源分批使用不同的锁，不同批次的资源的操作互不影响。

比如ConturrentHashMap类，把map分成多段，每段一个锁，不在一段的数据可以同时修改。

3，锁分离

把关系不大的操作使用不同的锁，使这些操作互不影响。

比如LinkedBlockingQueue类，从队列头获取数据的take()方法和从队列末尾添加数据的put()方法分别使用不同的锁，两者互不影响。

4，**锁粗化（Lock Coarsening）：**指的是当虚拟机需要连续对同一把锁进行加锁和释放时，尽量改成只使用一次锁。锁粗化的概念应该比较好理解，就是将多次连接在一起的加锁、解锁操作合并为一次，将多个连续的锁扩展成一个范围更大的锁。比如连续多个synchronized语句块，或循环中的synchronized语句块，用的是同一个对象作为锁，那还不如直接用一个synchronized语句块把他们都包含起来。举个例子：

![复制代码][copycode.gif]

1 package com.paddx.test.string;
     2 
     3 public class StringBufferTest {
     4     StringBuffer stringBuffer = new StringBuffer();
     5 
     6     public void append(){
     7         stringBuffer.append("a");
     8         stringBuffer.append("b");
     9         stringBuffer.append("c");
    10     }
    11 }

![复制代码][copycode.gif]

这里每次调用stringBuffer.append方法都需要加锁和解锁，如果虚拟机检测到有一系列连串的对同一个对象加锁和解锁操作，就会将其合并成一次范围更大的加锁和解锁操作，即在第一次append方法时进行加锁，最后一次append方法结束后进行解锁。

**5、锁消除（Lock Elimination）：**锁消除即删除不必要的加锁操作。根据代码逃逸技术，如果判断到一段代码中，堆上的数据不会逃逸出当前线程，那么可以认为这段代码是线程安全的，不必要加锁。看下面这段程序：

![复制代码][copycode.gif]

1 package com.paddx.test.concurrent;
 2 
 3 public class SynchronizedTest02 {
 4 
 5 public static void main(String[] args) {
 6 SynchronizedTest02 test02 = new SynchronizedTest02();
 7 //启动预热
 8 for (int i = 0; i < 10000; i++) {
 9 i++;
 10 }
 11 long start = System.currentTimeMillis();
 12 for (int i = 0; i < 100000000; i++) {
 13 test02.append("abc", "def");
 14 }
 15 System.out.println("Time=" + (System.currentTimeMillis() - start));
 16 }
 17 
 18 public void append(String str1, String str2) {
 19 StringBuffer sb = new StringBuffer();
 20 sb.append(str1).append(str2);
 21 }
 22 }

![复制代码][copycode.gif]

虽然StringBuffer的append是一个同步方法，但是这段程序中的StringBuffer属于一个局部变量，并且不会从该方法中逃逸出去，所以其实这过程是线程安全的，可以将锁消除。下面是我本地执行的结果：

![820406-20160424211554570-376308694.png][]

为了尽量减少其他因素的影响，这里禁用了偏向锁（-XX:-UseBiasedLocking）。通过上面程序，可以看出消除锁以后性能还是有比较大提升的。

注：可能JDK各个版本之间执行的结果不尽相同，我这里采用的JDK版本为1.6。

6，弃用synchronized关键字

不使用synchronized关键字，可以自己编写代码实现类似偏向锁、自旋锁的功能，减少因为同步锁而带来的效率损耗。比如上文中jetty自己实现的自旋锁。

## **六、总结 ** ##

本文重点介绍了JDk中采用轻量级锁和偏向锁等对Synchronized的优化，但是这两种锁也不是完全没缺点的，比如竞争比较激烈的时候，不但无法提升效率，反而会降低效率，因为多了一个锁升级的过程，这个时候就需要通过-XX:-UseBiasedLocking来禁用偏向锁。下面是这几种锁的对比：

<table> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;"> 锁 </td> 
 <td style="vertical-align:top;"> 优点 </td> 
 <td style="vertical-align:top;"> 缺点 </td> 
 <td style="vertical-align:top;"> 适用场景 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 偏向锁 </td> 
 <td style="vertical-align:top;"> 加锁和解锁不需要额外的消耗，和执行非同步方法比仅存在纳秒级的差距。 </td> 
 <td style="vertical-align:top;"> 如果线程间存在锁竞争，会带来额外的锁撤销的消耗。 </td> 
 <td style="vertical-align:top;"> 适用于只有一个线程访问同步块场景。 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 轻量级锁 </td> 
 <td style="vertical-align:top;"> 竞争的线程不会阻塞，提高了程序的响应速度。 </td> 
 <td style="vertical-align:top;"> 如果始终得不到锁竞争的线程使用自旋会消耗CPU。 </td> 
 <td style="vertical-align:top;"> 追求响应时间。 同步块执行速度非常快。 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 重量级锁 </td> 
 <td style="vertical-align:top;"> 线程竞争不使用自旋，不会消耗CPU。 </td> 
 <td style="vertical-align:top;"> 线程阻塞，响应时间缓慢。 </td> 
 <td style="vertical-align:top;"> 追求吞吐量。 同步块执行速度较长。 </td> 
 </tr> 
 </tbody> 
</table>

** 参考文献：**

[http://www.iteye.com/topic/1018932][http_www.iteye.com_topic_1018932]

[http://www.infoq.com/cn/articles/java-se-16-synchronized][http_www.infoq.com_cn_articles_java-se-16-synchronized]

[http://frank1234.iteye.com/blog/2163142][http_frank1234.iteye.com_blog_2163142]

[https://www.artima.com/insidejvm/ed2/threadsynch3.html][https_www.artima.com_insidejvm_ed2_threadsynch3.html]

[http://www.tuicool.com/articles/2aeAZn][http_www.tuicool.com_articles_2aeAZn]

[Java_Synchronized]: https://www.cnblogs.com/paddix/p/5405678.html
[820406-20160424105442866-2111954866.png]: /images/20220218/4e9c813c791744f4ba8dfaeef2e9f25f.png
[820406-20160424105540163-1019388398.png]: /images/20220218/0e73b3e55a9c40c4b1da7382a2cb105c.png
[820406-20160424163618101-624122079.png]: /images/20220218/cb9dfdeffa984897a7b168c3d01da05e.png
[copycode.gif]: /images/20220218/96a83a7948004b61a724b9ac392d9be0.png
[820406-20160424211554570-376308694.png]: /images/20220218/b986847b16584ede8788be70f2efeb1c.png
[http_www.iteye.com_topic_1018932]: http://www.iteye.com/topic/1018932
[http_www.infoq.com_cn_articles_java-se-16-synchronized]: http://www.infoq.com/cn/articles/java-se-16-synchronized
[http_frank1234.iteye.com_blog_2163142]: http://frank1234.iteye.com/blog/2163142
[https_www.artima.com_insidejvm_ed2_threadsynch3.html]: https://www.artima.com/insidejvm/ed2/threadsynch3.html
[http_www.tuicool.com_articles_2aeAZn]: http://www.tuicool.com/articles/2aeAZn