关于java:打击面试重灾区Synchronized原理

兄弟们，大家好。时隔多天，我，终于来了。明天咱们来聊一下让人神魂颠倒的Synchronized。

不过呢，在读这篇文章之前，我心愿你真正应用过这个东东，或者理解它到底是干嘛用的，不然很难了解这篇文章解说的货色。

这篇文章的大体程序是：从 无锁 –> 偏差锁 –> 轻量级锁 –> 重量级锁 解说，其中会波及到 CAS， 对象内存布局，缓存行等等知识点。也是满满的干货内容。其中也夹杂了集体在面试过程中呈现的面试题，各位兄弟缓缓享受。

Synchronized在 jdk1.6 做了十分大的优化，防止了很多时候的用户态到内核态的切换，节俭了资源的开销，而这所有的前提均来源于 CAS 这个理念。上面咱们先来聊一下 CAS 的一些根本实践。

CAS全称：CompareAndSwap，故名思意：比拟并替换。他的次要思维就是：我须要对一个值进行批改，我不会间接批改，而是将以后我认为的值和要批改的值传入，如果此时内存中确实为我认为的值，那么就进行批改，否则批改失败。他的思维是一种乐观锁的思维。

一张图解释他的工作流程：

晓得了它的工作原理，咱们来听一个场景：当初有一个 int 类型的数字它等于 1，存在三个线程须要对其进行自增操作。

一般来说，咱们认为的操作步骤是这样：线程从主内存中读取这个变量，到本人的工作空间中，而后执行变量自增，而后回写主内存，但这样在多线程状态下会存在平安问题。而如果咱们保障变量的安全性，罕用的做法是 ThreadLocal 或者间接加锁。（对 ThreadLocal 不理解的兄弟，看我这篇文章一文读懂 ThreadLocal 设计思维）

这个时候咱们思考一下，如果应用咱们下面的 CAS 进行对值的批改，咱们须要如何操作。

首先，咱们须要将以后线程认为的值传入，而后将想要批改的值传入。如果此时内存中的值和咱们的期望值相等，进行批改，否则批改失败。这样是不是解决了一个多线程批改的问题，而且它没有应用到操作系统提供的锁。

下面的流程其实就是类 AtomicInteger 执行自增操作的底层实现，它保障了一个操作的原子性。咱们来看一下源码。

public final int incrementAndGet() {return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
    }

public final int getAndAddInt(Object var1, long var2, int var4) {
        int var5;
        do {
            // 从内存中读取最新值
            var5 = this.getIntVolatile(var1, var2);
            // 批改
        } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));

        return var5;
 }

实现 CAS 应用到了 Unsafe 类，看它的名字就晓得不平安，所以 JDK 不倡议咱们应用。比照咱们下面多个线程执行一个变量的批改流程，这个类的操作仅仅减少了一个自旋，它在一直获取内存中的最新值，而后执行自增操作。

可能有兄弟说了，那 getIntVolatile 和compareAndSwapInt操作如何保障原子性。

对于 getIntVolatile 来说，读取内存中的地址，原本就一部操作，原子性不言而喻。

对于 compareAndSwapInt 来说，它的原子性由 CPU 保障，通过一系列的 CPU 指令实现，其 C++ 底层是依赖于 Atomic::cmpxchg_ptr 实现的

到这里 CAS 讲完了，不过其中还有一个 ABA 问题，有趣味能够去理解我的这篇文章多线程知识点大节。外面有具体的解说。

咱们通过 CAS 能够保障了操作的原子性，那么咱们须要思考一个货色，锁是怎么实现的。比照生存中的 case，咱们通过一组明码或者一把钥匙实现了一把锁，同样在计算机中也通过一个钥匙即synchronized 代码块应用的锁对象。

那其余线程如何判断以后资源曾经被占有了呢？

在计算机中的实现，往往是通过对一个变量的判断来实现，无锁状态为 0，有锁状态为1 等等来判断这个资源是否被加锁了，当一个线程开释锁时仅仅须要将这个变量值更改为 0，代表无锁。

咱们仅仅须要保障在进行变量批改时的原子性即可，而刚刚的 CAS 刚好能够解决这个问题

至于那个锁变量存储在哪里这个问题，就是上面的内容了，对象的内存布局

各位兄弟们，应该都分明，咱们创立的对象都是被寄存到堆中的，最初咱们取得到的是一个对象的援用指针。那么有一个问题就会诞生了，JVM创立的对象的时候，开拓了一块空间，那这个空间里都有什么货色？这个就是咱们这个点的内容。

先来论断：Java中存在两种类型的对象，一种是一般对象，另一种是数组

对象内存布局

咱们来一个一个解释其含意。

文言版：对象头中蕴含又两个字段，Mark Word次要存储改对象的锁信息，GC信息等等 (锁降级的实现)。而其中的Klass Point 代表的是一个类指针，它指向了办法区中类的定义和构造信息。而 Instance Data 代表的就是类的成员变量。在咱们刚刚学习 Java 根底的时候，都听过老师讲过，对象的非动态成员属性都会被寄存在堆中，这个就是对象的Instance Data。绝对于对象而言，数组额定增加了一个数组长度的属性

最初一个对其数据是什么？

咱们拿一个场景来展现这个起因：想像一下，你和女朋友周末打算出去玩，女朋友让你给她带上口红，那么这个时候你仅仅会带上口红嘛？当然不是，而是将所有的必用品通通带上，以防刚一出门就得回家拿货色！！！这种行为叫啥？防患未然，没错，暖男行为 。还不懂？再来一个案例。 你筹备守业了，资金十分短缺，你须要注册一个域名，你仅仅注册一个嘛？不, 而是将所有相干的都注册了，避免当前大价格买域名。一个情理。

而对于 CPU 而言，它在进行计算解决数据的时候，不可能须要什么拿什么吧，那对其性能损耗十分重大。所以有一个协定，CPU在读取数据的时候，不仅仅只拿须要的数据，而是获取一行的数据，这就是缓存行，而一行是 64 个字节。

所以呢？通过这个个性能够玩一些诡异的花色，比方上面的代码。

public class CacheLine {private volatile Long l1 , l2;}

咱们给一个场景：两个线程 t1 和 t2 别离操作 l1 和l2，那么当 t1 对l1做了批改当前，l2需不需要从新读取主内存种值。答案是肯定，依据咱们下面对于缓存行的了解，l1 和 l2必然位于同一个缓存行中，依据缓存一致性协定，当数据被批改当前，其余 CPU 须要从新重主内存中读取数据。这就引发了伪共享的问题

那么为什么对象头要求会存在一个对其数据呢？

HotSpot虚拟机要求每一个对象的内存大小必须保障为 8 字节的整数倍，所以对于不是 8 字节的进行了对其补充。其起因也是因为缓存行的起因

对象 = 对象头 + 实例数据

咱们在后面聊了一下，计算机中的锁的实现思路和对象在内存中的布局，接下来咱们来聊一下它的具体锁实现，为对象加锁应用的是对象内存模型中的对象头，通过对其锁标记位和偏差锁标记位的批改实现对资源的独占即加锁操作。接下来咱们看一下它的内存结构图。

上图就是对象头在内存中的体现 (64 位)，JVM 通过对对象头中的锁标记位和偏差锁位的批改实现“无锁”。

对于无锁这个概念来说，在 1.6 之前，即所有的对象，被创立了当前都处于无锁状态，而在 1.6 之后，偏差锁被开启，对象在经验过几秒的时候 (4~5s) 当前，主动降级为以后线程的偏差锁。(无论经没通过synchronized)。

咱们来验证一下，通过 jol-core 工具打印其内存布局。注：该工具打印进去的数据信息是反的，即最初几位在后面，通过上面的案例能够看到

场景：创立两个对象，一个在刚开始的时候就创立，另一个在 5 秒之后创立，进行比照其内存布局

Object object = new Object();
System.out.println(ClassLayout.parseInstance(object).toPrintable());// 此时处于无锁态
try {TimeUnit.SECONDS.sleep(5);} catch (InterruptedException e) {e.printStackTrace();}
Object o = new Object();
System.out.println("偏差锁开启");
System.out.println(ClassLayout.parseInstance(o).toPrintable());// 五秒当前偏差锁开启

咱们能够看到，线程已开启创立的对象处于无锁态，而在 5 秒当前创立的线程处于偏差锁状态。

同样，当咱们遇到 synchronized 块的时候，也会主动降级为偏差锁，而不是和操作系统申请锁。

说完这个，提一嘴一个面试题吧。解释一下什么是无锁。

从对象内存构造的角度来说，是一个锁标记位的体现；从其语义来说，无锁这个比拟形象了，因为在以前锁的概念往往是与操作系统的锁非亲非故，所以新呈现的基于 CAS 的偏差锁，轻量级锁等等也被成为无锁。而在 synchronized 降级的终点 —- 无锁。这个货色就比拟难以解释，只能说它没加锁。不过面试的过程中从对象内存模型中了解可能会更加难受一点。

在理论开发中，往往资源的竞争比拟少，于是呈现了偏差锁，故名思意，以后资源偏差于该线程，认为未来的所有操作均来自于改线程。上面咱们从对象的内存布局下看看偏差锁

对象头形容：偏差锁标记位通过 CAS 批改为 1，并且存储该线程的线程指针

当产生了锁竞争，其实也不算锁竞争，就是当这个资源被多个线程应用的时候，偏差锁就会降级。

在降级的期间有一个点 —–全局平安点，只有处在这个点的时候，才会撤销偏差锁。

全局平安点 —– 相似于 CMS 的stop the world，保障这个时候没有任何线程在操作这个资源，这个工夫点就叫做全局平安点。

能够通过 XX:BiasedLockingStartupDelay=0 敞开偏差锁的提早，使其立刻失效。

通过 XX:-UseBiasedLocking=false 敞开偏差锁。

在聊轻量级锁的时候，咱们须要搞明确这几个问题。什么是轻量级锁，什么重量级锁？，为什么就分量了，为什么就轻量了？

轻量级和重量级的规范是依附于操作系统作为规范判断的，在进行操作的时候你有没有调用过操作系统的锁资源，如果有就是重量级，如果没有就是轻量级

接下来咱们看一下轻量级锁的实现。

线程获取锁，判断以后线程是否处于无锁或者偏差锁的状态，如果是，通过 CAS 复制以后对象的对象头到 Lock Recoder 搁置到以后栈帧中 (对于JVM 内存模型不分明的兄弟，看这里入门 JVM 看这一篇就够了
通过 CAS 将以后对象的对象头设置为栈帧中的Lock Recoder, 并且将锁标记位设置为00
如果批改失败，则判断以后栈帧中的线程是否为本人，如果是本人间接获取锁，如果不是降级为重量级锁，前面的线程阻塞

咱们在下面提到了一个 Lock Recoder，这个东东是用来保留以后对象的对象头中的数据的，并且此时在该对象的对象头中保留的数据成为了以后Lock Recoder 的指针

咱们看一个代码模仿案例，

public class QingLock {public static void main(String[] args) {
        try {
            // 睡觉 5 秒，开启偏差锁，能够应用 JVM 参数
            TimeUnit.SECONDS.sleep(5);} catch (InterruptedException e) {e.printStackTrace();}
        A o = new A();
        // 让线程交替执行
        CountDownLatch countDownLatch = new CountDownLatch(1);
        new Thread(()->{o.test();
            countDownLatch.countDown();},"1").start();

        new Thread(()->{
            try {countDownLatch.await();
            } catch (InterruptedException e) {e.printStackTrace();
            }
            o.test();},"2").start();}
}

class A{private Object object = new Object();
    public void test(){System.out.println("为进入同步代码块 *****");
        System.out.println(ClassLayout.parseInstance(object).toPrintable());
        System.out.println("进入同步代码块 ******");
        for (int i = 0; i < 5; i++) {synchronized (object){System.out.println(ClassLayout.parseInstance(object).toPrintable());
            }
        }
    }
}

运行后果为两个线程交替前后

轻量级锁强调的是线程交替应用资源，无论线程的个数有几个，只有没有同时应用就不会降级为重量级锁

在下面的对于轻量级锁加锁步骤的解说中，如果线程 CAS 批改失败，则判断栈帧中的 owner 是不是本人，如果不是就失败降级为重量级锁，而在理论中，JDK退出了一种机制 自旋锁 ，即批改失败当前不会立刻降级而是进行自旋，在JDK1.6 之前自旋次数为 10 次，而在 1.6 又做了优化，改为了 自适应自旋锁 ，由虚拟机判断是否须要进行自旋，判断起因有： 以后线程之前是否获取到过锁，如果没有，则认为获取锁的几率不大，间接降级，如果有则进行自旋获取锁。

后面咱们谈到了无锁 –> 偏差锁 –> 轻量级锁，当初最初咱们来聊一下重量级锁。

这个锁在咱们开发过程中很常见，线程抢占资源大部分都是同时的，所以 synchronized 会间接降级为重量级锁。咱们来代码模仿看一下它的对象头的情况。

代码模仿

public class WeightLock {public static void main(String[] args) {A a = new A();
        for (int i = 0; i < 2; i++) {new Thread(()->{a.test();
             },"线程"+ i).start();}
    }
}

未进入代码块之前, 两者均为无锁状态

开始执行循环，进入代码块

在看一眼，对象头锁标记位

比照上图，能够发现，在线程竞争的时候锁，曾经变为了重量级锁。接下来咱们来看一下重量级锁的实现

咱们先从 Java 字节码剖析 synchronzied 的底层实现，它的次要实现逻辑是依赖于一个 monitor 对象，以后线程执行遇到 monitorenter 当前，给以后对象的一个属性 recursions 加一（上面会具体解说），当遇到 monitorexit 当前该属性减一，代表开释锁。

代码

Object o = new Object();
synchronized (o){}

汇编码

上图就是下面的四行代码的汇编码，咱们能够看到 synchronized 的底层是两个汇编指令

monitoreneter代表 synchronized 块开始
monitorexit代表 synchronized 块完结

有兄弟要说了 为什么会有两个monitorexit? 这也是我已经遇到的一个面试题

第一个 monitorexit 代表了 synchronized 块失常退出

第二个 monitorexit 代表了 synchronized 块异样退出

很好了解，当在 synchronized 块中呈现了异样当前，不能以后线程始终拿着锁不让其余线程应用吧。所以呈现了两个monitorexit

同步代码块了解了，咱们再来看一下同步办法。

代码

public static void main(String[] args) {

}

public synchronized void test01(){}

汇编码

咱们能够看到，同步办法减少了一个 ACC_SYNCHRONIZED 标记，它会在同步办法执行之前调用 monitorenter，完结当前调用monitorexit 指令。

在 Java 汇编码的解说中，咱们提到了两个指令 monitorenter 和monitorexit，其实他们是来源于一个 C++ 对象 monitor，在Java 中每创立一个对象的时候都会有一个 monitor 对象被隐式创立，他们和以后对象绑定，用于监督以后对象的状态。其实说绑定也不算正确，其理论流程为：线程自身保护了两个 MonitorList 列表，别离为闲暇 (free) 和曾经应用 (used)，当线程遇到同步代码块或者同步办法的时候，会从闲暇列表中申请一个monitor 应用，如果当先线程曾经没有闲暇的了，则间接从全局 (JVM) 获取一个 monitor 应用

咱们来看一下 C++ 对这个对象的形容

ObjectMonitor() {
    _header       = NULL;
    _count        = 0;
    _waiters      = 0,
    _recursions   = 0; // 重入次数
    _object       = NULL; // 存储该 Monitor 对象
    _owner        = NULL; // 领有该 Monitor 对象的对象
    _WaitSet      = NULL; // 线程期待汇合(Waiting)
    _WaitSetLock  = 0 ;
    _Responsible  = NULL ;
    _succ         = NULL ;
    _cxq          = NULL ; // 多线程竞争时的单向链表
    FreeNext      = NULL ;
    _EntryList    = NULL ; // 阻塞链表(Block)
    _SpinFreq     = 0 ;
    _SpinClock    = 0 ;
    OwnerIsThread = 0 ;
    _previous_owner_tid = 0;
  }

线程加锁模型

加锁流程：

最新进入的线程会进入 _cxp 栈中，尝试获取锁，如果以后线程取得锁就执行代码，如果没有获取到锁则增加到 EntryList 阻塞队列中
如果在执行的过程的以后线程被挂起 (wait) 则被增加到 WaitSet 期待队列中，期待被唤醒继续执行
当同步代码块执行结束当前，从 _cxp 或者 EntryList 中获取一个线程执行

monitorenter加锁实现

CAS批改以后 monitor 对象的 _owner 为以后线程，如果批改胜利，执行操作；
如果批改失败，判断 _owner 对象是否为以后线程，如果是则令 _recursions 重入次数加一
如果以后实现是第一次获取到锁，则将 _recursions 设置为一
期待锁开释

阻塞和获取锁实现

将以后线程封装为一个 node 节点，状态设置为ObjectWaiter::TS_CXQ
将之增加到 _cxp 栈中，尝试获取锁，如果获取失败，则将以后线程挂起，期待唤醒
唤醒当前，从挂终点执行剩下的代码

monitorexit开释锁实现

让以后线程的 _recursions 重入次数减一，如果以后重入次数为 0，则间接退出，唤醒其余线程

参考资料：

马士兵多线程技术详解书籍

HotSpot 源码

往期举荐：

一文带你理解 Spring MVC 的架构思路

Mybatis 你只会 CRUD 嘛

IOC 的架构你理解嘛

关于java:打击面试重灾区Synchronized原理

1. CAS

2. 内存布局

3. 无锁

4. 偏差锁

5. 轻量级锁

6. 重量级锁

6.1 Java 汇编码剖析

6.2 C++ 代码

Just My Socks（注册教程内含优惠码）

关于java:打击面试重灾区Synchronized原理

1. CAS

2. 内存布局

3. 无锁

4. 偏差锁

5. 轻量级锁

6. 重量级锁

6.1 Java 汇编码剖析

6.2 C++ 代码

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）