并发编程之Lock

小灰灰 2022-10-08 05:42 198阅读 0赞

### 文章目录 ###

*  Lock 锁
 *   *  概念
     *  Lock 接口
 *  ReentrantLock
 *   *  概念
     *  实现
     *  ReentrantLock 与 synchronized
 *  ReentrantReadWriteLock
 *   *  概念
     *  实现
     *  场景

# Lock 锁 #

## 概念 ##

锁是用来控制多个线程访问共享资源的方式，一般来说，一个锁能够防止多个线程同时访问共享资源，但是有些锁可以允许多个线程并发的访问共享资源，比如读写锁。

在 java SE 5 之前通过 synchronized 关键字实现锁功能，之后 Lock 可以实现显示的加锁和解锁，并且实现了更多操作，比如：可中断的获取锁，超时获取锁等，这些操作是 synchronized 无法实现的，synchronized 是通过隐式的实现加锁和解锁。而且 synchronized 是重量级锁，当然在 java SE 6 之后进行了优化即锁升级。

## Lock 接口 ##

Lock 是 java.util.concurrent 包中的接口，通过源码查看 Lock 接口对外提供了 方法：

<table> 
 <thead> 
  <tr> 
   <th>序号</th> 
   <th>方法名称</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>1</td> 
   <td>void lock();</td> 
   <td>获取锁，调用该方法当前线程将会获取锁</td> 
  </tr> 
  <tr> 
   <td>2</td> 
   <td>void unlock();</td> 
   <td>释放锁</td> 
  </tr> 
  <tr> 
   <td>3</td> 
   <td>boolean tryLock();</td> 
   <td>尝试获取锁，如果能获取到锁就返回true，否则返回false</td> 
  </tr> 
  <tr> 
   <td>4</td> 
   <td>boolean tryLock(long time, TimeUnit unit) throws InterruptedException;</td> 
   <td>尝试获取锁，可以设置超时时间，可以在时间范围内获取返回true，超时返回false，或者可能被中断</td> 
  </tr> 
  <tr> 
   <td>5</td> 
   <td>void lockInterruptibly() throws InterruptedException;</td> 
   <td>可中断地获取锁，和lock() 方法不同，即在获取锁的过程中可以被中断</td> 
  </tr> 
  <tr> 
   <td>6</td> 
   <td>Condition newCondition();</td> 
   <td>获取等待通知组件，该组件和当前的锁绑定，当前线程只有获取了锁，才能调用改组件的wait() 方法，而调用后，当前线程就释放锁。</td> 
  </tr> 
 </tbody> 
</table>

通过以上介绍大概了解了 Lock 接口的各个方法的用处，小小示例如下：

//获取重入锁
            Lock lock = new ReentrantLock();
            try {
                //加锁
                lock.lock();
            }catch (Exception e){
                e.printStackTrace();
            }finally {
                //解锁
                lock.unlock();
            }

分析：
    
    将释放锁的操作放在 finally 中保证获取锁以后最终能够释放锁，
    
    而且获取锁的操作不能放在 try 中，万一获取锁异常，会导致无故释放锁。

当然因为 Lock 是一个接口，如何使用还需要了解它的实现—— ReentrantLock 和 ReentrantReadWriteLock （不要误会 ReentrantReadWrite 并不是 Lock 的直接实现子类）。

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

# ReentrantLock #

## 概念 ##

重入锁 ReentrantLock ，顾名思义，就是支持重进入的锁，它表示该锁能够支持一个线程对资源的重复加锁。而且该锁还支持获取锁的公平和非公平性选择。提到可重入性那么就会想到前面提到的 [synchronized][] 也支持重入性。

当然 ReentrantLock 是 Lock 锁的实现类，同样也可以显式的实现加锁和释放锁等其他灵活操作，同一线程通过 lock() 方法获取锁以后，再次调用 lock() 方法获取锁而不阻塞。

ReentrantLock 还支持获取锁的公平和非公平性选择，公平也不是绝对公平，相对来说公平锁即多个线程根据等待时间长短获取锁，即等待时间长的优先获取锁，短的后获取。非公平锁就不会根据时间长短排列了，所有线程不论等待时间长短都可以抢着获取锁。事实上，公平锁机制往往没有非公平锁效率高，ReentrantLock 默认情况下是非公平锁，当然并不是所有场景都适合非公平锁，公平锁能够减少“饥饿”发生的概率，等待越久的请求越是能够优先得到满足。

## 实现 ##

1.  实现重进入

重进入是指任意线程在获取到锁以后，能够再次获取该锁而不会被锁阻塞，该特性的实现需要解决以下两个问题：

1）线程再次获取锁：

锁需要去识别获取锁的线程是否为当前占据锁的线程，如果是则再次成功获取。

2）锁的最终释放：

线程重复 n 次获取锁，随后在第 n 次释放该锁后，其他线程才能够获取该锁。相当于有一个计数器记录着当前线程获取锁的次数，每获取一次增加1，释放一次减少1，直到为0，当前线程就释放该锁。通过查看 ReentrantLock 源码会发现，它的类中有自定义同步器继承了AQS 队列同步器。

//ReentrantLock 默认为非公平锁
    public ReentrantLock() {
      sync = new NonfairSync();
    }
        
    //自定义同步器继承 AQS
    abstract static class Sync extends AbstractQueuedSynchronizer {...}
    
    final void lock() {
    //第一次获取锁通过 CAS 操作判断是否是第一次进入即状态是否为0，若是则设置 state 为1，并记录当前线程
        if (compareAndSetState(0, 1))
            setExclusiveOwnerThread(Thread.currentThread());
    //以后再次加锁
        else
            acquire(1);
    }
    
    //acquire 会分为公平和非公平锁实现方式，默认为非公平，所以我们以此为例，以下即为主要同步状态值的计算过程。（acquires 参数为1）
            final boolean nonfairTryAcquire(int acquires) {
                final Thread current = Thread.currentThread();
                //获取状态
                int c = getState();
                if (c == 0) {
                    if (compareAndSetState(0, acquires)) {
                        setExclusiveOwnerThread(current);
                        return true;
                    }
                }
                //判断是否是当前线程
                else if (current == getExclusiveOwnerThread()) {
                    int nextc = c + acquires;
                    if (nextc < 0) // overflow
                        throw new Error("Maximum lock count exceeded");
                    setState(nextc);
                    return true;
                }
                return false;
            }

以上通过源码分析大概了解了 ReentrantLock 的实现原理，其实就是底层使用了 AQS队列同步器 和 [CAS 操作][CAS] 。

下面是一个简单示例验证 ReentrantLock 的重入性：

static Lock lock = new ReentrantLock();
    
        public static void main(String[] args) {
            new Thread(() -> test(), "t1").start();
            new Thread(() -> test1(), "t2").start();
    
        }
    
        private static void test(){
            //获取重入锁
            try {
                //加锁
                lock.lock();
                System.out.println(Thread.currentThread().getName() + "获取到test锁");
                Thread.sleep(3000);
    
                test1();
            }catch (Exception e){
                e.printStackTrace();
            }finally {
                //解锁
                lock.unlock();
                System.out.println(Thread.currentThread().getName() + "释放锁test");
            }
        }
    
        private static void test1(){
            //获取重入锁
            try {
                //加锁
                lock.lock();
                System.out.println(Thread.currentThread().getName() + "获取到test1锁");
                Thread.sleep(9000);
            }catch (Exception e){
                e.printStackTrace();
            }finally {
                //解锁
                lock.unlock();
                System.out.println(Thread.currentThread().getName() + "释放锁test1");
            }
        }
        
    结果：
    t1获取到test锁
    t1获取到test1锁
    t1释放锁test1
    t1释放锁test
    t2获取到test1锁
    t2释放锁test1

1.  公平锁和非公平锁

公平锁即根据线程的顺序获取锁，非公平锁即所有线程一哄而上，谁抢到是谁的，不论先来后到。通过查看源码其实公平锁和非公锁的实现方式基本相同。只是公平锁对线程队列进行了判断，即同步队列中当前节点是否有前驱节点，如果有那么需要等待前驱线程获取锁并释放锁才能获取锁。

//其实发现公平锁的实现和非公平锁相同，只是多了一个 !hasQueuedPredecessors() 判断
            protected final boolean tryAcquire(int acquires) {
                final Thread current = Thread.currentThread();
                int c = getState();
                if (c == 0) {
                    if (!hasQueuedPredecessors() &&
                        compareAndSetState(0, acquires)) {
                        setExclusiveOwnerThread(current);
                        return true;
                    }
                }
                else if (current == getExclusiveOwnerThread()) {
                    int nextc = c + acquires;
                    if (nextc < 0)
                        throw new Error("Maximum lock count exceeded");
                    setState(nextc);
                    return true;
                }
                return false;
            }

当然创建锁的时候也有所不同，可以通过参数设定是公平锁还是非公平锁

//默认非公平锁
    Lock lock = new ReentrantLock()  或者  Lock lock = new ReentrantLock(false)
    
    //公平锁
    Lock lock = new ReentrantLock(true)

当然更多的场景使用的是默认的非公平锁，效率更高一些。

## ReentrantLock 与 synchronized ##

ReentrantLock 和 synchronized 各有千秋，其实可以相互替换使用。

它们都具有重入性

synchronized 对于加锁和释放锁通过隐式的方式实现，用起来更方便，若遇到异常自动释放锁。

ReentrantLock 因为实现了接口 Lock 所以有 Lock 的特性，即显式的加锁和释放锁，可中断的获取锁，超时获取锁，尝试获取锁等更加灵活的操作，而且还能设置公平锁和非公平锁。

同样 ReentrantLock 特别注意释放锁，否则其他线程永远获取不到锁了，以及创建锁时不要再 try 中防止获取锁异常而导致无故释放锁。

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

# ReentrantReadWriteLock #

## 概念 ##

前面学习的锁 ReentrantLock以及关键字 [synchronized][] 都是排他锁，也就是在同一时刻只允许一个线程进行访问，而读写锁在同一时刻可以允许多个读线程访问，但是写线程访问时，所有读线程和其他写线程均被阻塞。由于读写锁维护了一对锁，一个读锁，一个写锁，读锁为共享锁，写锁为排他锁，通过分离读锁和写锁，使得并发性相比一般排他锁有很大提升。

ReentrantReadWriteLock 读写锁，前面提到 ReentrantLock 重入锁是接口 Lock 的实现类，而 ReentrantReadWriteLock 虽与它长的相似，但是读写锁并非接口 Lock 的实现类，而 Lock 的实现类有读锁 ReadLock 以及写锁 WriteLock 。关系图如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70]

## 实现 ##

首先从 Lock 锁接口开始，此接口提供了获取锁，释放锁，超时获取锁，中断的获取锁等显式对锁的操作，而 ReadLock 和 WriteLock 实现了 Lock 接口，那么就会实现这些接口与重入锁ReentrantLock 相似。

其次接口 ReadWriteLock 即读写锁接口，提供了两个方法分别为获取读锁和写锁，源码如下：

public interface ReadWriteLock {
        /**
         * Returns the lock used for reading.
         *
         * @return the lock used for reading
         */
        Lock readLock();
    
        /**
         * Returns the lock used for writing.
         *
         * @return the lock used for writing
         */
        Lock writeLock();
    }

java 并发包踢动读写锁的实现类 ReentrantReadWriteLock 通过名称与重入锁相似，它也提供了一些特性：

<table> 
 <thead> 
  <tr> 
   <th>特性</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>公平性选择</td> 
   <td>默认支持非公平锁，也可以获取公平锁，吞吐量非公平锁大于公平锁</td> 
  </tr> 
  <tr> 
   <td>重进入</td> 
   <td>该锁支持重进入，虽然分为读锁和写锁，若线程获取其中一种锁就可以再次进入读锁和写锁</td> 
  </tr> 
  <tr> 
   <td>锁降级</td> 
   <td>遵循获取写锁、获取读锁再释放写锁的次序，写锁能够降级为读锁</td> 
  </tr> 
 </tbody> 
</table>

ReentrantReadWriteLock 锁底层实现与 ReentrantLock 类似自定义了同步器继承 AQS 队列同步器。

示例如下：

static ReentrantReadWriteLock reentrantReadWriteLock = new ReentrantReadWriteLock(true);
    
        public static void main(String[] args) {
            Lock readLock = reentrantReadWriteLock.readLock();
            Lock writeLock = reentrantReadWriteLock.writeLock();
            for(int i=0;i<3;i++){
                new Thread(()->test2(writeLock), "写锁：" + i).start();
            }
            for(int i=0;i<5;i++){
                new Thread(()->test2(readLock), "读锁：" + i).start();
            }
        }
    
        private static void test2(Lock lock){
            lock.lock();
            try {
                Thread.sleep(2000);
                System.out.println(Thread.currentThread().getName() + "进来了");
            }catch (Exception e){
                e.printStackTrace();
            } finally {
                lock.unlock();
            }
        }
    结果：
    写锁：0进来了
    写锁：1进来了
    写锁：2进来了
    读锁：2进来了
    读锁：1进来了
    读锁：0进来了
    读锁：4进来了
    读锁：3进来了

分析：
    
    首先创建了一下公平锁 ReentrantReadWriteLock 通过测试过程以及结果发现，写锁是按照顺序获取锁的，而且在打印结果的时候会执行睡眠2秒，而读锁结果打印的时候立马所有的读锁结果就打印出来了。
    
    由此说明两个问题：
    1. 公平锁根据线程顺序执行
    
    2. 写锁为排他锁，读锁为共享锁
    
    写锁被获取以后其他线程无论是读线程还是写线程都无法获取锁进入阻塞状态，直到锁被释放其他线程才能获取锁；
    
    读锁被获取以后所有读线程可以进入，写线程被阻塞，直到读锁被全部释放写线程还能获取锁

## 场景 ##

读写锁是一对锁，分为读锁和写锁，所以能够简化读写交互场景的编程方式，多数场景读多于写。在读多于写的情况下，读写锁能够提供比排他锁更好的并发性和吞吐量。当然为了保证数据的安全性写操作对读操作有可见性。

[synchronized]: https://blog.csdn.net/weixin_43915808/article/details/118067511
[CAS]: https://blog.csdn.net/weixin_43915808/article/details/109412653
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70]: /images/20221005/f39a990eb7d5405ea29230a6689ddd43.png