Lock接口读写锁原理介绍

一、线程间通信的方式

首先，介绍以下几种线程间的通信方式：

协作方式 死锁方式1(通过主动加把锁) 死锁方式1(先唤醒再挂起) 备注 suspend/resume 死锁 死锁 弃用 wait/notify 不死锁 死锁 只能在synchronized关键字中用,基于对象监视器 park/unPark 死锁 不死锁 用LockSupport，令牌机制 condition的await/signal 不死锁 死锁 只能在ReentrantLock中用

二、Synchronized与Lock的对比

（1）Synchronized优点：使用简单；由JVM提供，包括了多种优化方式(锁升级，具体可看我Synchronized原理的)；锁的释放不用人工干预，由JVM释放，降低了死锁的可能性。

（2）Synchronized缺点：无法使用锁的高级功能，如读写锁等，使用不灵活。

（3）Lock优点：所有Synchronized的缺点，Lock都可以解决。

（4）Lock缺点：需要手动释放锁调用unLock()方法，使用不当可能造成死锁。

三、Lock接口读写锁原理介绍

读写锁维护了一对关联锁，读锁只用于读操作，可同时被多个线程持有；写锁只用于写操作，同时只能被一个线程持有；并且在同一时间读锁和写锁也不能被同时持有，它适合读多写少的情况。读写锁的API如下：

public class ReadWriteLockTest {
    volatile long i = 0;
    //读写锁
    ReadWriteLock rwLock = new ReentrantReadWriteLock();
    //读方法
    public void read() {
        rwLock.readLock().lock();//加读锁
        long iValue = i;
        rwLock.readLock().unlock();//释放读锁
    }
    //写方法
    public void write() {
        rwLock.writeLock().lock();//加写锁
        i++;
        rwLock.writeLock().unlock();//加写锁
    }
    public static void main(String[] args) throws InterruptedException {
        final ReadWriteLockTest demo = new ReadWriteLockTest();
        long startTme = System.currentTimeMillis();
        for (int i=0;i<=30; i++){
            int n = i;
            new Thread(new Runnable() {
                @Override
                public void run() {
                    long starttime = System.currentTimeMillis();
                    for (int j=0; j<400000; j++){
                        if (n==0) demo.write();//写少
                        else demo.read();//读多
                    }
                }
            }).start();
        }
        long endTime = System.currentTimeMillis();
        System.out.println("耗时："+ (endTime - startTme));
    }
}
123456789101112131415161718192021222324252627282930313233343536

读写锁的原理图如下：

读写锁中包含了四个部分：

（1）watiers：等待队列，没有抢到读/写锁的线程被放入此队列等待抢锁；

（2）owner：标记写锁是被那个线程持有的，同一时间只能有一个线程持有写锁；

（3）writeCount：标记写锁（被同一个线程）重入的次数；

（4）readCount：标记读锁（共享锁）被几个线程占用。

由于动图不会搞━━(￣ー￣*|||━━，接下来我来用文字讲解读写锁的争抢过程：

<1>线程t1来抢“写锁”，首先判断readCount是否为0（因为读/写锁互斥，不为0说明读锁被占了，t1不能抢写锁），若readCount=0，则t1可以抢写锁，t1抢到了写锁，对writeCount做CAS操作加1，此时writeCount=1，owner=t1；

<2>同样的，t1又去抢“写锁”，先判断readCount是否为0，再判断writeCount是否为0，目前writeCount=1，owner=t1，因为owner=t1，所以t1又抢到了写锁，此时writeCount=2，owner=t1；

<3>t2线程来抢“写锁”，先判断readCount是否为0，再判断writeCount是否为0，目前writeCount=2，owner=t1，t2抢不到写锁，t2进入watiers等待队列；

<4>t1释放一次写锁，此时writeCount=1，owner=t1，再释放一次写锁，此时writeCount=0，owner=null，那么此时在等待队列中的t2就能抢到写锁，此时writeCount=1，owner=t2；

<5>t3线程来抢“读锁”，先判断writeCount是否为0，此时writeCount=1，即t2占用了写锁，而读锁与写锁互斥，所以t3抢不到读锁，t3进入等待队列；

<6>同样的t4，t5也来抢“读锁”，都抢不到，t4，t5进入等待队列；

<7>t2释放了写锁，此时writeCount=0，owner=null，t3被唤醒，出等待队列，重新去抢“读锁”，先判断writeCount是否为0，发现writeCount=0，抢成功读锁，对readCount做CAS操作加1，此时readCount=1；

<8>t4，t5经历同样的操作，此时readCount=3；

<9>此时t6线程又来抢“写锁”，发现readCount=3，抢写锁失败，进入等待队列；

<10>当t3，t4，t5都释放了读锁，此时readCount=0，等待队列中的t6线程就又能来抢写锁了。

以上就是我用文字描述的读写锁争抢的全过程，不止各位看官是否看懂了呢︿(￣︶￣)︿