一文带你理解Java中Lock的实现原理

拼搏现实的明天。 2022-11-12 02:45 172阅读 0赞

总括：  
          
        对象设置成null可以help GC  
          
          
        凡是有排他特性或者封装后有排他特性的都可做lock  
          
        synchronized: workword moniter enter  
          
          
        lock：封装lock对象（状态，链表） 链表储存阻塞线程，不断自旋，lock状态标志占有，未占有  
        用乐观锁的概念获取lock,  
        获取不到会再尝试获取一次，再获取不到就进入指针队列，添加到队列尾部  
        先进先出，当当前线程到头部（其他线程获取锁完成）再尝试获取  
        释放锁就是状态需改为0  
          
          
          
          
        lock 用的是大量的尝试和自选  
        synchronized  有偏向，自旋，锁升级，锁消除，性能优越于lock源码大部分用synchronized

当多个线程需要访问某个公共资源的时候，我们知道需要通过加锁来保证资源的访问不会出问题。java提供了两种方式来加锁，一种是关键字：synchronized，一种是concurrent包下的lock锁。synchronized是java底层支持的，而concurrent包则是jdk实现。关于synchronized的原理可以阅读[再有人问你synchronized是什么，就把这篇文章发给他。][synchronized]

在这里，我会用尽可能少的代码，尽可能轻松的文字，尽可能多的图来看看lock的原理。

我们以ReentrantLock为例做分析，其他原理类似。

我把这个过程比喻成一个做菜的过程，有什么菜，做法如何？

> 我先列出lock实现过程中的几个关键词：计数值、双向链表、CAS+自旋

使用例子

import java.util.concurrent.locks.ReentrantLock;
    
    public class App {
    
    
        public static void main(String[] args) throws Exception {
    
            final int[] counter = {0};
    
    
            ReentrantLock lock = new ReentrantLock();
    
    
            for (int i= 0; i < 50; i++){
    
                new Thread(new Runnable() {
    
                    @Override
    
                    public void run() {
    
                        lock.lock();
    
                        try {
    
                            int a = counter[0];
    
                            counter[0] = a + 1;
    
                        }finally {
    
                            lock.unlock();
    
                        }
    
                    }
    
                }).start();
    
            }
    
    
            // 主线程休眠，等待结果
    
            Thread.sleep(5000);
    
            System.out.println(counter[0]);
    
        }
    
    }

在这个例子中，开50个线程同时更新counter。分成三块来看看源码（初始化、获取锁、释放锁）

实现原理

**ReentrantLock() 干了啥**

/**
    
         * Creates an instance of {@code ReentrantLock}.
    
         * This is equivalent to using {@code ReentrantLock(false)}.
    
         */
    
        public ReentrantLock() {
    
            sync = new NonfairSync();
    
        }

在lock的构造函数中，定义了一个NonFairSync，

static final class NonfairSync extends Sync

NonfairSync 又是继承于Sync

abstract static class Sync extends AbstractQueuedSynchronizer

一步一步往上找，找到了  
这个鬼AbstractQueuedSynchronizer（简称AQS），最后这个鬼，又是继承于AbstractOwnableSynchronizer(AOS)，AOS主要是保存获取当前锁的线程对象，代码不多不再展开。  
最后我们可以看到几个主要类的继承关系。

![f7ec178b93eeb15cc98dfac8732fea2159b79358][]

FairSync 与 NonfairSync的区别在于，是不是保证获取锁的公平性，因为默认是NonfairSync，我们以这个为例了解其背后的原理。

其他几个类代码不多，最后的主要代码都是在AQS中，我们先看看这个类的主体结构。

**AbstractQueuedSynchronizer是个什么**

![57b7475d527d592e0c626776bf1238b76fa375cf][]

再看看Node是什么？

![831781ec10901a1060ba59cb8947f7df339c15d9][]

看到这里的同学，是不是有种热泪盈眶的感觉，这尼玛，不就是**双向链表**么？我还记得第一次写这个数据结构的时候，发现居然还有这么神奇的一个东西。

***最后我们可以发现锁的存储结构就两个东西:"双向链表" + "int类型状态"。***  
需要注意的是，他们的变量都被"`transient`和`volatile`修饰。

![01ceee2dbde0eae7b901ab3bee596ad38866757c][]

一个int值，一个双向链表是如何烹饪处理锁这道菜的呢，Doug Lea大神就是大神，我们接下来看看，如何获取锁？

**lock.lock()怎么获取锁？**

/**
    
     * Acquires the lock.
    
     */
    public void lock() {
    
        sync.lock();
    
    }

可以看到调用的是，`NonfairSync.lock()`

![5a7809035c292cf28cfb0eebd8202b11038c9f2c][]

看到这里，我们基本有了一个大概的了解，还记得之前AQS中的int类型的state值，这里就是通过CAS（乐观锁）去修改state的值。**lock的基本操作还是通过乐观锁来实现的**。

获取锁通过CAS，那么没有获取到锁，等待获取锁是如何实现的？我们可以看一下else分支的逻辑，acquire方法：

public final void acquire(int arg) {
    
        if (!tryAcquire(arg) &&
    
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
    
            selfInterrupt();
    
    }

这里干了三件事情：

*  tryAcquire：会尝试再次通过CAS获取一次锁。
 *  addWaiter：将当前线程加入上面锁的双向链表（等待队列）中
 *  acquireQueued：通过自旋，判断当前队列节点是否可以获取锁。

**addWaiter 添加当前线程到等待链表中**![811ad99c49d08e940aeacd7becc8cb98e59cf190][]

可以看到，通过CAS确保能够在线程安全的情况下，将当前线程加入到链表的尾部。  
enq是个自旋+上述逻辑，有兴趣的可以翻翻源码。

acquireQueued

![c14e8bb94f0218794ac03e87c2e556eabd2451aa][]

可以看到，当当前线程到头部的时候，尝试CAS更新锁状态，如果更新成功表示该等待线程获取成功。从头部移除。

![71e8b71038243dfaf21ebcf6f9fcc5fbaa659b08][]

最后简要概括一下，获取锁的一个流程

![48c01d6093d60683cf2d842a26d7e407cfbcde7f][]  
  
**lock.unlock() 释放锁**

public void unlock() {
    
        sync.release(1);
    
    }

可以看到调用的是，NonfairSync.release()

![7330906450a4f71f1d693be4a8c7b742d8466c84][]

最后有调用了NonfairSync.tryRelease()

![f69fb329fa6298b88109b96e611db6ff925b445f][]

基本可以确认，释放锁就是对AQS中的状态值State进行修改。同时更新下一个链表中的线程等待节点。

**总结**

*  lock的存储结构：一个int类型状态值（用于锁的状态变更），一个双向链表（用于存储等待中的线程）
 *  lock获取锁的过程：本质上是通过CAS来获取状态值修改，如果当场没获取到，会将该线程放在线程等待链表中。
 *  lock释放锁的过程：修改状态值，调整等待链表。
 *  可以看到在整个实现过程中，lock大量使用CAS+自旋。因此根据CAS特性，lock建议使用在低锁冲突的情况下。目前java1.6以后，官方对synchronized做了大量的锁优化（偏向锁、自旋、轻量级锁）。因此在非必要的情况下，建议使用synchronized做同步操作。

最后，希望我的分析，能对你理解锁的实现有所帮助。

[synchronized]: https://yq.aliyun.com/go/articleRenderRedirect?url=http%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzI3NzE0NjcwMg%3D%3D%26amp%3Bmid%3D2650121805%26amp%3Bidx%3D1%26amp%3Bsn%3D8aea8c329a018c82a7ebfe80ec604226%26amp%3Bchksm%3Df36bbb6cc41c327acc23d3d7cdf0b785e318d8e970d564ba9ce8b28a1ae6b41499d351497af3%26amp%3Bscene%3D21%23wechat_redirect
[f7ec178b93eeb15cc98dfac8732fea2159b79358]: /images/20221022/4191519de820485684927903728357c8.png
[57b7475d527d592e0c626776bf1238b76fa375cf]: /images/20221022/09986c4bc72240f9b21d1272628193f2.png
[831781ec10901a1060ba59cb8947f7df339c15d9]: /images/20221022/22ed19927e524c6cb40d1a89ef7a3263.png
[01ceee2dbde0eae7b901ab3bee596ad38866757c]: /images/20221022/528857e1644142c3995ac5f857275f6d.png
[5a7809035c292cf28cfb0eebd8202b11038c9f2c]: /images/20221022/b091ad521d2947b99ccb4ec828818b94.png
[811ad99c49d08e940aeacd7becc8cb98e59cf190]: /images/20221022/dd992d41521043c9923193bfadabf1bc.png
[c14e8bb94f0218794ac03e87c2e556eabd2451aa]: /images/20221022/5ac5a3eaedb74baabc7c9166ba30f519.png
[71e8b71038243dfaf21ebcf6f9fcc5fbaa659b08]: /images/20221022/3b2100c7c8ae4597b2bb7caa2988c5f1.png
[48c01d6093d60683cf2d842a26d7e407cfbcde7f]: /images/20221022/99557943b3f04d48924bcba274af5c19.png
[7330906450a4f71f1d693be4a8c7b742d8466c84]: /images/20221022/2e13db7fb1844ca7a24ab5fd8a3c4668.png
[f69fb329fa6298b88109b96e611db6ff925b445f]: /images/20221022/12ad896f18bc45b68f2ecb68218bf86e.png