9.Lock锁接口实现

1. Lock的核心API

• lock 获取锁的方法，若锁被其他线程获取，则等待(阻塞)
• lockInterruptibly 在锁的获取过程中可以中断当前线程
• tryLock 尝试非阻塞的获取锁，立即返回
• unlock 释放锁
• 根据Lock接口的源码注释，Lock接口的实现，具备和同步关键字同样的内存语义，只不过可定制性更强大

2. ReentrantLock
   独享锁、支持公平锁、非公平锁两种模式；可重入锁

   
   
   5.png

import java.util.concurrent.locks.ReentrantLock;

public class ReentrantDemo1 {
    //可重入锁：同一个线程和多次进入，加锁
    private static final ReentrantLock lock=new ReentrantLock();

    public static void main(String[] args) {
        lock.lock();
        try{
            System.out.println("第一次获取锁");
            System.out.println("当前线程获取锁的次数"+lock.getHoldCount());
            lock.lock();
            System.out.println("第二次获取锁");
            System.out.println("当前线程获取锁的次数"+lock.getHoldCount());
        }finally {
            lock.unlock();
        }
        System.out.println("当前线程获取锁的次数"+lock.getHoldCount());

        new Thread(()->{
            System.out.println(Thread.currentThread()+"期望抢到锁");
            lock.lock();
            System.out.println(Thread.currentThread()+"线程拿到锁");
        }).start();
    }
}
/**
 * 第一次获取锁
 * 当前线程获取锁的次数1
 * 第二次获取锁
 * 当前线程获取锁的次数2
 * 当前线程获取锁的次数1
 * Thread[Thread-0,5,main]期望抢到锁
 */

说明：执行输出到这里就等待着，程序不结束，可重入锁必须加锁次数和解锁次数相同，否则其他线程拿不到锁

3. ReadWriteLock
   维护一堆关联锁，一个用于只读操作，一个用于写入；读锁可以由多个线程同时持有，写锁是排他的。
   适合读取线程比写入线程多的场景，改进互斥锁的性能，示例：缓存组件、集合的并发线程安全性改造。

锁降级指的是写锁降级成读锁,把持住当前拥有的写锁的同时，再获取读锁，随后释放写锁的过程。
写锁是线程独占，读锁是共享，所以写-》读是降级。(读-》写，是不能实现的)

import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.locks.ReadWriteLock;
import java.util.concurrent.locks.ReentrantReadWriteLock;

public class CacheDemo {
    private Map map=new HashMap<>();
    private static ReadWriteLock rwl=new ReentrantReadWriteLock();
    public Object get(String id) {
        Object value=null;
        //首先开启读锁，从缓存中去取
        rwl.readLock().lock();
        try{
            if (map.get(id)==null) {
                //必须释放读锁-读锁全部释放了，才能下面加上写锁
                rwl.readLock().unlock();
                //如果不加写锁，所有请求全部去查询数据库，就崩溃了
                rwl.writeLock().lock();
                try{
                    //双重检查，防止已经有线程改变了当前的只，从而出现重复处理的情况
                    if (map.get(id)==null) {
                        //如果没有缓存，就去数据库里面读取
                    }
                    rwl.readLock().lock();
                    //加读锁把写锁降级为读锁，这样就不会有其他线程能够修改找个值，保证了数据一致性
                    //因为此处加了一把读锁，只要有任何一把读锁没释放，就永远不可能有其他线程拿到写锁，也就没法修改数据
                }finally {
                    rwl.writeLock().unlock();//释放写锁
                }
            }
        }finally {
            rwl.readLock().unlock();
        }
        return value;
    }
    public static void main(String[] args) {

    }
}

4. Condition
   用于替换wait/notify；Object中的wait(),notify(),notifyAll()方法是和synchronized配合使用的，可以唤醒一个或者全部(单个等待集);
   Condition是需要与Lock配合使用的，提供多个等待集合，更精确的控制(底层是park/unpark机制)

   
   
   6.png

class BoundedBuffer {
     final Lock lock = new ReentrantLock();
     final Condition notFull  = lock.newCondition(); 
     final Condition notEmpty = lock.newCondition(); 
  
     final Object[] items = new Object[100];
     int putptr, takeptr, count;
  
     public void put(Object x) throws InterruptedException {
       lock.lock();
       try {
         while (count == items.length)
           notFull.await();
         items[putptr] = x;
         if (++putptr == items.length) putptr = 0;
         ++count;
         notEmpty.signal();
       } finally {
         lock.unlock();
       }
     }
  
     public Object take() throws InterruptedException {
       lock.lock();
       try {
         while (count == 0)
           notEmpty.await();
         Object x = items[takeptr];
         if (++takeptr == items.length) takeptr = 0;
         --count;
         notFull.signal();
         return x;
       } finally {
         lock.unlock();
       }
     }
   }

5. ReentrantLock的lock和lockInterruptibly的区别
   ReentrantLock的加锁方法Lock()提供了无条件地轮询获取锁的方式，lockInterruptibly()提供了可中断的锁获取方式。这两个方法的区别在哪里呢？通过分析源码可以知道lock方法默认处理了中断请求，一旦监测到中断状态，则中断当前线程；而lockInterruptibly()则直接抛出中断异常，由上层调用者区去处理中断。

• lock操作
  lock获取锁过程中，忽略了中断，在成功获取锁之后，再根据中断标识处理中断，即selfInterrupt中断自己。 acquire操作源码如下：

/**
  *默认处理中断方式是selfInterrupt
 */  

public final void acquire(int arg) {  

if (!tryAcquire(arg) &&  

        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))  
        selfInterrupt();  
}  

acquireQueued，在for循环中无条件重试获取锁，直到成功获取锁，同时返回线程中断状态。该方法通过for循正常返回时，必定是成功获取到了锁。

/**

 *无条件重试,直到成功返回，并且记录中断状态

 */  

final boolean acquireQueued(final Node node, int arg) {  

boolean failed = true;  

try {  

boolean interrupted = false;  

for (;;) {  

final Node p = node.predecessor();  

if (p == head && tryAcquire(arg)) {  

                setHead(node);  

p.next =null; // help GC  

failed =false;  

return interrupted;  

            }  

if (shouldParkAfterFailedAcquire(p, node) &&  

                parkAndCheckInterrupt())  

interrupted =true;  

        }  

}finally {  

if (failed)  

            cancelAcquire(node);  

    }  

}  

• lockInterruptibly操作

可中断加锁，即在锁获取过程中不处理中断状态，而是直接抛出中断异常，由上层调用者处理中断。源码细微差别在于锁获取这部分代码，这个方法与acquireQueue差别在于方法的返回途径有两种，一种是for循环结束，正常获取到锁；另一种是线程被唤醒后检测到中断请求，则立即抛出中断异常，该操作导致方法结束。

/**

     * Acquires in exclusive interruptible mode.

     * @param arg the acquire argument

     */  

private void doAcquireInterruptibly(int arg)  

throws InterruptedException {  

final Node node = addWaiter(Node.EXCLUSIVE);  

boolean failed = true;  

try {  

for (;;) {  

final Node p = node.predecessor();  

if (p == head && tryAcquire(arg)) {  

                    setHead(node);  

p.next =null; // help GC  

failed =false;  

return;  

                }  

if (shouldParkAfterFailedAcquire(p, node) &&  

                    parkAndCheckInterrupt())  

throw new InterruptedException();  

            }  

}finally {  

if (failed)  

                cancelAcquire(node);  

        }  

    }  

结论：ReentrantLock的中断和非中断加锁模式的区别在于：线程尝试获取锁操作失败后，在等待过程中，如果该线程被其他线程中断了，它是如何响应中断请求的。lock方法会忽略中断请求，继续获取锁直到成功；而lockInterruptibly则直接抛出中断异常来立即响应中断，由上层调用者处理中断。

那么，为什么要分为这两种模式呢？这两种加锁方式分别适用于什么场合呢？根据它们的实现语义来理解，我认为lock()适用于锁获取操作不受中断影响的情况，此时可以忽略中断请求正常执行加锁操作，因为该操作仅仅记录了中断状态（通过Thread.currentThread().interrupt()操作，只是恢复了中断状态为true，并没有对中断进行响应,也就是说继续参与锁竞争)。如果要求被中断线程不能参与锁的竞争操作，则此时应该使用lockInterruptibly方法，一旦检测到中断请求，立即返回不再参与锁的竞争并且取消锁获取操作（即finally中的cancelAcquire操作）