【漫画】JAVA并发编程 J.U.C Lock包之ReentrantLock互斥锁

在如何解决原子性问题的最后，咱们卖了个关子，互斥锁不只仅只有synchronized关键字，还能够用什么来实现呢？
J.U.C包中还提供了一个叫作Locks的包，我好歹英语过了四级，听名字我就能立刻大声的说：Locks包必然也能够用做互斥！

ReentrantLock

咱们能够经过从具体到抽象的方法来揭开Locks包的神秘面试。

从图中能够看出，有个叫作ReentrantLock实现了Lock接口，那么就从它入手吧！

顾名思义，ReentrantLock叫作可重入锁，所谓可重入锁，顾名思义，指的是线程能够重复获取同一把锁。

ReentrantLock也是互斥锁，所以也能够保证原子性。

先写一个简单的demo上手吧，就拿原子性问题中两个线程分别作累加的demo为例，如今使用ReentrantLock来改写：

private void add10K() {
        // 获取锁
        reentrantLock.lock();
        try {
            int idx = 0;
            while (idx++ < 10000) {
                count++;
            }
        } finally {
            // 保证锁能释放
            reentrantLock.unlock();
        }

    }

ReentrantLock在这里能够达到和synchronized同样的效果，为了方便你回忆，我再次把synchronized实现互斥的代码贴上来：

private synchronized void add10K(){
        int start = 0;
        while (start ++ < 10000){
            this.count ++;
        }
    }

因为它俩都算互斥锁，因此你们都喜欢拿它们作比较，咱们来看看究竟有什么区别吧

ReentrantLock与synchronized的区别

一、重入
synchronized可重入，由于加锁和解锁自动进行，没必要担忧最后是否释放锁；ReentrantLock也可重入，但加锁和解锁须要手动进行，且次数需同样，不然其余线程没法得到锁。

二、实现
synchronized是JVM实现的、而ReentrantLock是JDK实现的。说白了就是，是操做系统来实现，仍是用户本身敲代码实现。

三、性能
在 Java 的 1.5 版本中，synchronized 性能不如 SDK 里面的 Lock，但 1.6 版本以后，synchronized 作了不少优化，将性能追了上来。

四、功能
ReentrantLock锁的细粒度和灵活度，都明显优于synchronized ，毕竟越麻烦使用的东西确定功能越多啦！

特有功能一：可指定是公平锁仍是非公平锁，而synchronized只能是非公平锁。

公平的意思是先等待的线程先获取锁。能够在构造函数中指定公平策略。

// 分别测试为true 和 为false的输出。为true则输出顺序必定是A B C 可是为false的话有可能输出A C B
    private static final ReentrantLock reentrantLock = new ReentrantLock(true);
    public static void main(String[] args) throws InterruptedException {
        ReentrantLockDemo2 demo2 = new ReentrantLockDemo2();
        Thread a = new Thread(() -> { test(); }, "A");
        Thread b = new Thread(() -> { test(); }, "B");
        Thread c = new Thread(() -> { test(); }, "C");
        a.start();b.start();c.start();

    }
    public static void test() {
        reentrantLock.lock();
        try {
            System.out.println("线程" + Thread.currentThread().getName());
        } finally {
            reentrantLock.unlock();//必定要释放锁
        }
    }

在原子性文章的最后，咱们还卖了个关子，以转帐为例，说明synchronized会致使死锁的问题，即两个线程你等个人锁，我等你的锁，两方都阻塞，不会释放！为了方便，我再次把代码贴上来：

static void transfer(Account source,Account target, int amt) throws InterruptedException {
        // 锁定转出帐户  Thread1锁定了A Thread2锁定了B
        synchronized (source) {
            Thread.sleep(1000);
            log.info("持有锁{} 等待锁{}",source,target);
            // 锁定转入帐户  Thread1须要获取到B,但是被Thread2锁定了。Thread2须要获取到A，但是被Thread1锁定了。因此互相等待、死锁
            synchronized (target) {
                if (source.getBalance() > amt) {
                    source.setBalance(source.getBalance() - amt);
                    target.setBalance(target.getBalance() + amt);
                }
            }
        }
    }

而ReentrantLock能够完美避免死锁问题，由于它能够破坏死锁四大必要条件之一的：不可抢占条件。这得益于它这么几个功能：

特有功能二：非阻塞地获取锁。若是尝试获取锁失败，并不进入阻塞状态，而是直接返回false，这时候线程不用阻塞等待，能够先去作其余事情。因此不会形成死锁。

// 支持非阻塞获取锁的 API 
boolean tryLock();

如今咱们用ReentrantLock来改造一下死锁代码

static void transfer(Account source, Account target, int amt) throws InterruptedException {
        Boolean isContinue = true;
        while (isContinue) {
            if (source.getLock().tryLock()) {
                log.info("{}已获取锁 time{}", source.getLock(),System.currentTimeMillis());
                try {
                    if (target.getLock().tryLock()) {
                        log.info("{}已获取锁 time{}", target.getLock(),System.currentTimeMillis());
                        try {
                            log.info("开始转帐操做");
                            source.setBalance(source.getBalance() - amt);
                            target.setBalance(target.getBalance() + amt);
                            log.info("结束转帐操做 source{} target{}", source.getBalance(), target.getBalance());
                            isContinue=false;
                        } finally {
                            log.info("{}释放锁 time{}", target.getLock(),System.currentTimeMillis());
                            target.getLock().unlock();
                        }
                    }
                } finally {
                    log.info("{}释放锁 time{}", source.getLock(),System.currentTimeMillis());
                    source.getLock().unlock();
                }
            }
        }
    }

tryLock还支持超时。调用tryLock时没有获取到锁，会等待一段时间，若是线程在一段时间以内仍是没有获取到锁，不是进入阻塞状态，而是throws InterruptedException，那这个线程也有机会释放曾经持有的锁，这样也能破坏死锁不可抢占条件。
boolean tryLock(long time, TimeUnit unit)

特有功能三：提供可以中断等待锁的线程的机制

synchronized 的问题是，持有锁 A 后，若是尝试获取锁 B 失败，那么线程就进入阻塞状态，一旦发生死锁，就没有任何机会来唤醒阻塞的线程。

但若是阻塞状态的线程可以响应中断信号，也就是说当咱们给阻塞的线程发送中断信号的时候，可以唤醒它，那它就有机会释放曾经持有的锁 A。这样就破坏了不可抢占条件了。ReentrantLock能够用lockInterruptibly方法来实现。

public static void main(String[] args) throws InterruptedException {
        ReentrantLockDemo5 demo2 = new ReentrantLockDemo5();
        Thread th1 = new Thread(() -> {
            try {
                deadLock(reentrantLock1, reentrantLock2);
            } catch (InterruptedException e) {
                System.out.println("线程A被中断");
            }
        }, "A");
        Thread th2 = new Thread(() -> {
            try {
                deadLock(reentrantLock2, reentrantLock1);
            } catch (InterruptedException e) {
                System.out.println("线程B被中断");
            }
        }, "B");
        th1.start();
        th2.start();
        th1.interrupt();

    }


    public static void deadLock(Lock lock1, Lock lock2) throws InterruptedException {
        lock1.lockInterruptibly(); //若是改为用lock那么是会一直死锁的
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        lock2.lockInterruptibly();
        try {
            System.out.println("执行完成");
        } finally {
            lock1.unlock();
            lock2.unlock();
        }

    }

特有功能4、能够用J.U.C包中的Condition实现分组唤醒须要等待的线程。而synchronized只能notify或者notifyAll。这里涉及到线程之间的协做，在后续章节会详细讲解，敬请关注公众号【胖滚猪学编程】。

文中代码github地址：

本文转载自公众号【胖滚猪学编程】 用漫画让编程so easy and interesting！欢迎关注！形象来源于微信表情包【胖滚家族】喜欢能够下载哦~