并发编程之Lock，LockSupport，重入锁，读写锁 -- 07

曾经终败给现在 2022-03-26 10:55 424阅读 0赞

### 文章目录 ###

*   *   *  一、Lock
         *   *  1. ReentrantLock
             *  2. ReentrantReadWriteLock
             *  3. ReentrantLock原理
             *  4.ReentrantLock lock加锁原理
             *   *  4.1 ReentrantLock.lock
                 *  4.2 NonfairSync.lock
                 *  4.3 AbstractQueuedSynchronizer.acquire
                 *   *  4.3.1 NonfairSync.tryAcquire
                     *  4.3.2 AbstractQueuedSynchronizer.addWaiter
                     *  4.3.3 AbstractQueuedSynchronizer.acquireQueued
             *  5.ReentrantLock unLock解锁原理
             *  6.公平锁和飞公平锁的区别
             *   *  6.1 不同点一、lock方法
                 *  6.1 不同点二、tryAcquire方法
             *  总结：
         *  二、LockSupport

我们知道，锁是用来控制多个线程访问共享资源的方式，一般来说，一个锁能够防止多个线程同时访问共享资源，在Lock接口出现之前，Java应用程序只能依靠synchronized关键字来实现同步锁的功能，在java5以后，增加了JUC的并发包且提供了Lock接口用来实现锁的功能，它提供了与synchroinzed关键字类似的同步功能，只是它比synchronized更灵活，能够显示的获取和释放锁。

### 一、Lock ###

Lock是一个接口，核心的两个方法lock和unlock，它有很多的实现，比如ReentrantLock、ReentrantReadWriteLock类中的内部类;

#### 1. ReentrantLock ####

ReentrantLock重入锁，表示支持重新进入的锁，也就是说，如果当前线程t1通过调用lock方法获取了锁之后，再次调用lock，是不会再阻塞去获取锁的，直接增加重试次数就行了。当然也是排他锁，当前线程获取了，其他线程就不能获取了。

使用如下:

public class AtomicDemo { 
      private static int count=0;
      static Lock lock=new ReentrantLock();
      public static void inc(){ 
        lock.lock();
        try { 
          Thread.sleep(1);
       } catch (InterruptedException e) { 
          e.printStackTrace();
       }
        count++;
        lock.unlock();
     }
      public static void main(String[] args) throws InterruptedException { 
        for(int i=0;i<1000;i++){ 
          new Thread(()->{ AtomicDemo.inc();}).start();;
       }
        Thread.sleep(3000);
        System.out.println("result:"+count);
     }
    }

#### 2. ReentrantReadWriteLock ####

我们以前理解的锁，基本都是排他锁，也就是这些锁在同一时刻只允许一个线程进行访问，而读写锁在同一时刻可以允许多个线程访问，但是在写线程访问时，所有的读线程和其他写线程都会被阻塞。读写锁维护了一对锁，一个读锁、一个写锁; 一般情况下，读写锁的性能都会比排它锁好，因为大多数场景读是多于写的。在读多于写的情况下，读写锁能够提供比排它锁更好的并发性和吞吐量。

读写锁的实现ReentrantReadWriteLock，它是实现**ReadWriteLock接口而不是Lock**接口。其中的内部类 ReadLock，WriteLock 是实现的Lock接口的。

使用方法：

public class LockDemo { 
      static Map<String,Object> cacheMap=new HashMap<>();
      static ReentrantReadWriteLock rwl=new ReentrantReadWriteLock();
      static Lock read=rwl.readLock();
      static Lock write=rwl.writeLock();
      public static final Object get(String key) { 
        System.out.println("开始读取数据");
        read.lock(); //读锁
        try { 
          return cacheMap.get(key);
       }finally { 
          read.unlock();
       }
     }
      public static final Object put(String key,Object value){ 
        write.lock();
        System.out.println("开始写数据");
        try{ 
          return cacheMap.put(key,value);
       }finally { 
          write.unlock();
       }
     }
    }

> 注： 在这个案例中，通过hashmap来模拟了一个内存缓存，然后使用读写所来保证这个内存缓存的线程安全性。当执行读操作的时候，需要获取读锁，在并发访问的时候，读锁不会被阻塞，因为读操作不会影响执行结果。  
>   在执行写操作是，线程必须要获取写锁，当已经有线程持有写锁的情况下，当前线程会被阻塞，只有当写锁释放以后，其他读写操作才能继续执行。使用读写锁提升读操作的并发性，也保证每次写操作对所有的读写操作的可见性。和数据库的读写锁类似  
>   
> l 读锁 与 读锁可以共享  
> l 读锁 与 写锁不可以共享（排他）  
> l 写锁 与 写锁不可以共享（排他）

#### 3. ReentrantLock原理 ####

ReentrantLock 如图所示UML图,原理还是使用AQS。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDc5Mjg3OA_size_16_color_FFFFFF_t_70]

这里使用非公平锁原理，加锁调用的时序图如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDc5Mjg3OA_size_16_color_FFFFFF_t_70 1]

#### 4.ReentrantLock lock加锁原理 ####

##### 4.1 ReentrantLock.lock #####

public void lock() { 
      sync.lock();
    }

这个是获取锁的入口，调用了sync.lock； sync是一个实现了AQS的抽象类，这个类的主要作用是用来实现同步控制的，并且sync有两个实现，一个是NonfairSync(非公平锁)、另一个是FailSync(公平锁)； 我们先来分析一下非公平锁的实现

##### 4.2 NonfairSync.lock #####

final void lock() { 
      		if (compareAndSetState(0, 1)) //这是跟公平锁的主要区别,一上来就试探锁是否空闲,如果可以插队，则设置获得锁的线程为当前线程,state =0 表示没有锁状态
    //exclusiveOwnerThread属性是AQS从父类AbstractOwnableSynchronizer中继承的属性，用来保存当前占用
    同步状态的线程
        setExclusiveOwnerThread(Thread.currentThread());
      else
        acquire(1); //尝试去获取锁
    }

compareAndSetState，这个方法通过cas算法去改变state的值，而这个state是什么呢？ 在AQS中存在一个变量state，对于ReentrantLock来说，如果state=0表示无锁状态、如果state>0表示有锁状态。

所以在这里，是表示当前的state如果等于0，则替换为1，如果替换成功表示获取锁成功了.

由于ReentrantLock是可重入锁，所以持有锁的线程可以多次加锁，经过判断加锁线程就是当前持有锁的线程时（即exclusiveOwnerThread==Thread.currentThread()），即可加锁，每次加锁都会将state的值+1，state等于几，就代表当前持有锁的线程加了几次锁;解锁时每解一次锁就会将state减1，state减到0后，锁就被释放掉，这时其它线程可以加锁；

##### 4.3 AbstractQueuedSynchronizer.acquire #####

如果CAS操作未能成功，说明state已经不为0，此时继续acquire(1)操作,acquire是AQS中的方法 当多个线程同时进入这个方法时，首先通过cas去修改state的状态，如果修改成功表示竞争锁成功，竞争失败的，tryAcquire会返回false

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

> 这个方法的主要作用是:
> 
>  *  尝试获取独占锁，获取成功则返回，否则
>  *  自旋获取锁，并且判断中断标识，如果中断标识为true，则设置线程中断
>  *  addWaiter方法把当前线程封装成Node，并添加到队列的尾部

###### 4.3.1 NonfairSync.tryAcquire ######

tryAcquire方法尝试获取锁，如果成功就返回，如果不成功，则把当前线程和等待状态信息构适成一个Node节点，并将结点放入同步队列的尾部。然后为同步队列中的当前节点循环等待获取锁，直到成功

**tryAcquire方法**

protected final boolean tryAcquire(int acquires) { 
      return nonfairTryAcquire(acquires);
    }

**nonfairTryAcquire方法**

final boolean nonfairTryAcquire(int acquires) { 
      final Thread current = Thread.currentThread();
      int c = getState(); //获取当前的状态，前面讲过，默认情况下是0表示无锁状态
      if (c == 0) { 
        if (compareAndSetState(0, acquires)) {  //通过cas来改变state状态的值，如果更新成功，表示获取锁成功, 这个操作外部方法lock()就做过一次，这里再做只是为了再尝试一次，尽量以最简单的方式获取锁。
          setExclusiveOwnerThread(current);
          return true;
       }
     }
      else if (current == getExclusiveOwnerThread()) { //如果当前线程等于获取锁的线程，表示重入，直接累加重入次数
        int nextc = c + acquires;
        if (nextc < 0) // overflow 如果这个状态值越界，抛出异常；如果没有越界，则设置后返回true
          throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
     }
    //如果状态不为0，且当前线程不是owner，则返回false。
      return false; //获取锁失败，返回false
    }

###### 4.3.2 AbstractQueuedSynchronizer.addWaiter ######

当前锁如果已经被其他线程锁持有，那么当前线程来去请求锁的时候，会进入这个方法,这个方法主要是把当前线程封装成node，添加到AQS的链表中

addWaiter方法

private Node addWaiter(Node mode) { 
      Node node = new Node(Thread.currentThread(), mode); //创建一个独占的Node节点,mode为排他模式
     // 尝试快速入队,如果失败则降级至full enq
      Node pred = tail; // tail是AQS的中表示同步队列队尾的属性，刚开始为null，所以进行enq(node)方法
      if (pred != null) { 
        node.prev = pred;
        if (compareAndSetTail(pred, node)) {  // 防止有其他线程修改tail,使用CAS进行修改,如果失败则降级至full enq
          pred.next = node; // 如果成功之后旧的tail的next指针再指向新的tail,成为双向链表
          return node;
       }
     }
      enq(node); // 如果队列为null或者CAS设置新的tail失败
      return node;
    }

**enq方法**  
  enq就是通过自旋操作把当前节点加入到队列中

private Node enq(final Node node) { 
      for (;;) {   //无效的循环，为什么采用for(;;)，是因为它执行的指令少，不占用寄存器
        Node t = tail;// 此时head, tail都为null
        if (t == null) {  // Must initialize// 如果tail为null则说明队列首次使用,需要进行初始化
          if (compareAndSetHead(new Node()))// 设置头节点,如果失败则存在竞争,留至下一轮循环
            tail = head; // 用CAS的方式创建一个空的Node作为头结点，因为此时队列中只一个头结点，所以tail也指向head，第一次循环执行结束
       } else { 
    //进行第二次循环时，tail不为null，进入else区域。将当前线程的Node结点的prev指向tail，然后使用CAS将tail指向Node
    //这部分代码和addWaiter代码一样，将当前节点添加到队列
          node.prev = t;
          if (compareAndSetTail(t, node)) { 
            t.next = node; //t此时指向tail,所以可以CAS成功，将tail重新指向CNode。此时t为更新前的tail的值，即指向空的头结点，t.next=node，就将头结点的后续结点指向Node，返回头结点
            return t;
         }
       }
     }
    }

加入队列后如图：  
![加入队列后如图：][20190119103452383.png]

###### 4.3.3 AbstractQueuedSynchronizer.acquireQueued ######

final boolean acquireQueued(final Node node, int arg) { 
      boolean failed = true;
      try { 
        boolean interrupted = false;
        for (;;) { 
          final Node p = node.predecessor();// 获取prev节点,若为null即刻抛出
    NullPointException
          if (p == head && tryAcquire(arg)) { // 如果前驱为head才有资格进行锁的抢夺
            setHead(node); // 获取锁成功后就不需要再进行同步操作了,获取锁成功的线程作为新的head节点
    //凡是head节点,head.thread与head.prev永远为null, 但是head.next不为null
            p.next = null; // help GC
            failed = false; //获取锁成功
            return interrupted;
         }
    //如果获取锁失败，则根据节点的waitStatus决定是否需要挂起线程
          if (shouldParkAfterFailedAcquire(p, node) &&
            parkAndCheckInterrupt())// 若前面为true,则执行挂起,待下次唤醒的时候检测中断的标志
            interrupted = true;
       }
     } finally { 
        if (failed) // 如果抛出异常则取消锁的获取,进行出队(sync queue)操作
          cancelAcquire(node);
     }
    }

原来的head节点释放锁以后，会从队列中移除，原来head节点的next节点会成为head节点  
![在这里插入图片描述][2019011910394077.png]

**shouldParkAfterFailedAcquire**  
  从上面的分析可以看出，只有队列的第二个节点可以有机会争用锁，如果成功获取锁，则此节点晋升为头节点。对于第三个及以后的节点，if (p == head)条件不成立，首先进行shouldParkAfterFailedAcquire(p, node)操作;

shouldParkAfterFailedAcquire方法是判断一个争用锁的线程是否应该被阻塞。它首先判断一个节点的前置节点的状态是否为Node.SIGNAL，如果是，是说明此节点已经将状态设置-如果锁释放，则应当通知它，所以它可以安全的阻塞了，返回true

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) { 
      int ws = pred.waitStatus; //前继节点的状态
      if (ws == Node.SIGNAL)//如果是SIGNAL状态，意味着当前线程需要被unpark唤醒
           return true;
    如果前节点的状态大于0，即为CANCELLED状态时，则会从前节点开始逐步循环找到一个没有被“CANCELLED”节点设置
    为当前节点的前节点，返回false。在下次循环执行shouldParkAfterFailedAcquire时，返回true。这个操作实
    际是把队列中CANCELLED的节点剔除掉。
      if (ws > 0) { // 如果前继节点是“取消”状态，则设置 “当前节点”的 “当前前继节点” 为 “‘原前继节
    点'的前继节点”。
      
        do { 
          node.prev = pred = pred.prev;
       } while (pred.waitStatus > 0);
        pred.next = node;
     } else {  // 如果前继节点为“0”或者“共享锁”状态，则设置前继节点为SIGNAL状态。
        /* * waitStatus must be 0 or PROPAGATE. Indicate that we * need a signal, but don't park yet. Caller will need to * retry to make sure it cannot acquire before parking. */
        compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
     }
      return false;
    }

解读：假如有t1,t2两个线程都加入到了链表中

如果head节点位置的线程一直持有锁，那么t1和t2就是挂起状态，而HEAD以及t1的的awaitStatus都是SIGNAL，在多次尝试获取锁失败以后，就会通过下面的方法进行挂起（这个地方就是避免了惊群效应，每个节点只需要关心上一个节点的状态即可）

*  SIGNAL：值为-1，表示当前节点的的后继节点将要或者已经被阻塞，在当前节点释放的时候需要unpark后继节点；
 *  CONDITION：值为-2，表示当前节点在等待condition，即在condition队列中；
 *  PROPAGATE：值为-3，表示releaseShared需要被传播给后续节点（仅在共享模式下使用）；

**parkAndCheckInterrupt**

如果shouldParkAfterFailedAcquire返回了true，则会执行：“parkAndCheckInterrupt()”方法，它是通过LockSupport.park(this)将当前线程挂起到WATING状态，它需要等待一个中断、unpark方法来唤醒它，通过这样一种FIFO的机制的等待，来实现了Lock的操作

private final boolean parkAndCheckInterrupt() { 
      LockSupport.park(this);// LockSupport提供park()和unpark()方法实现阻塞线程和解除线程阻塞
      return Thread.interrupted();
    }

#### 5.ReentrantLock unLock解锁原理 ####

加锁的过程分析完以后，再来分析一下释放锁的过程，调用release方法，这个方法里面做两件事:

*  1.释放锁
 *  2.唤醒park的线程

**release方法**

public final boolean release(int arg) { 
            if (tryRelease(arg)) { 
                Node h = head;
                if (h != null && h.waitStatus != 0)
                    unparkSuccessor(h);
                return true;
            }
            return false;
        }

**tryRelease方法**

protected final boolean tryRelease(int releases) { 
      int c = getState() - releases; // 这里是将锁的数量减1
      
      if (Thread.currentThread() != getExclusiveOwnerThread())// 如果释放的线程和获取锁的线程不是同一个，抛出非法监视器状态异常
    	throw new IllegalMonitorStateException();
    	
      boolean free = false;
      if (c == 0) { 
    	// 由于重入的关系，不是每次释放锁c都等于0，
        // 直到最后一次释放锁时，才会把当前线程释放
        free = true;
        setExclusiveOwnerThread(null);
     }
      setState(c);
      return free;
    }

#### 6.公平锁和飞公平锁的区别 ####

锁的公平性是相对于获取锁的顺序而言的，如果是一个公平锁，那么锁的获取顺序就应该符合请求的绝对时间顺序，也就是FIFO。 在上面分析的例子来说，只要CAS设置同步状态成功，则表示当前线程获取了锁，而公平锁则不一样，差异点有两个：

##### 6.1 不同点一、lock方法 #####

非公平锁在获取锁的时候，会先通过CAS进行抢占，而公平锁则不会,如下代码

//公平锁的lock方法
    		final void lock() { 
                acquire(1);
            }
            //非公平锁的lock方法
    		final void lock() { 
                if (compareAndSetState(0, 1))
                    setExclusiveOwnerThread(Thread.currentThread());
                else
                    acquire(1);
            }

##### 6.1 不同点二、tryAcquire方法 #####

这个方法与nonfairTryAcquire(int acquires)比较，不同的地方在于判断条件多了hasQueuedPredecessors()方法，也就是加入了\[同步队列中当前节点是否有前驱节点\]的判断，如果该方法返回true，则表示有线程比当前线程更早地请求获取锁，因此需要等待前驱线程获取并释放锁之后才能继续获取锁。

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;
    }

#### 总结： ####

在获取同步状态时，同步器维护一个同步队列，获取状态失败的线程都会被加入到队列中并在队列中进行自旋；移出队列（或停止自旋）的条件是前驱节点为头节点且成功获取了同步状态。在释放同步状态时，同步器调用tryRelease(int arg)方法释放同步状态，然后唤醒头节点的后继节点。

### 二、LockSupport ###

LockSupport类是Java6引入的一个类，提供了基本的线程同步原语。LockSupport实际上是调用了Unsafe类里的函数，归结到Unsafe里，只有两个函数：

public native void unpark(Thread jthread); 
    public native void park(boolean isAbsolute, long time);

unpark函数为线程提供“许可(permit)”，线程调用park函数则等待“许可”。这个有点像信号量，但是这个“许可”是不能叠加的，“许可”是一次性的。

permit相当于0/1的开关，默认是0，调用一次unpark就加1变成了1.调用一次park会消费permit，又会变成0。 如果再调用一次park会阻塞，因为permit已经是0了。直到permit变成1.这时调用unpark会把permit设置为1.每个线程都有一个相关的permit，permit最多只有一个，重复调用unpark不会累积.  
  在使用LockSupport之前，我们对线程做同步，只能使用wait和notify，但是wait和notify其实不是很灵活，并且耦合性很高，调用notify必须要确保某个线程处于wait状态，而park/unpark模型真正解耦了线程之间的同步，先后顺序没有没有直接关联，同时线程之间不再需要一个Object或者其它变量来存储状态，不再需要关心对方的状态。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDc5Mjg3OA_size_16_color_FFFFFF_t_70]: /images/20220326/21c1e987ebf6485b991714293745f4d8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDc5Mjg3OA_size_16_color_FFFFFF_t_70 1]: /images/20220326/52f3477ed2474a82950eb7f8db3c3fe5.png
[20190119103452383.png]: /images/20220326/e60b7f0eed3c4b47934e170d57339d09.png
[2019011910394077.png]: /images/20220326/69b62bc65f7a4552baea90380c92b9ec.png