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

原创声明:本文来源于公众号【胖滚猪学编程】 转载请注明出处

JAVA并发编程 如何解决原子性问题 的最后,我们卖了个关子,互斥锁不仅仅只有synchronized关键字,还可以用J.U.C中的Locks的包来实现,并且它非常强大!今天就来一探究竟吧!

_1

image

ReentrantLock

顾名思义,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 ++;
        }
    }
_2

ReentrantLock与synchronized的区别

1、重入
synchronized可重入,因为加锁和解锁自动进行,不必担心最后是否释放锁;ReentrantLock也可重入,但加锁和解锁需要手动进行,且次数需一样,否则其他线程无法获得锁。

2、实现
synchronized是JVM实现的、而ReentrantLock是JDK实现的。说白了就是,是操作系统来实现,还是用户自己敲代码实现。

3、性能
在 Java 的 1.5 版本中,synchronized 性能不如 SDK 里面的 Lock,但 1.6 版本之后,synchronized 做了很多优化,将性能追了上来。

4、功能
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();
        }

    }

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

ReentrantLock如何保证可见性

刚刚我们证明了ReentrantLock能保证原子性,那可以保证可见性吗?答案是必须的。

回忆下JAVA并发编程 如何解决可见性和有序性问题。我们说 Java 里多线程的可见性是通过 Happens-Before 规则保证的,比如 synchronized 之所以能够保证可见性,也是因为有一条 synchronized 相关的规则:synchronized 的解锁 Happens-Before 于后续对这个锁的加锁。

那 Java SDK 里面 Lock 靠什么保证可见性呢?Java SDK 里面锁的实现非常复杂,但是原理还是需要简单介绍一下:它是利用了 volatile 相关的 Happens-Before 规则。

ReentrantLock的同步其实是委托给AbstractQueuedSynchronizer的。加锁和解锁是通过改变AbstractQueuedSynchronizer的state属性,这个属性是volatile的。

image

获取锁的时候,会读写 state 的值;解锁的时候,也会读写 state 的值。类比volatile是如何保证可见性的就可以解决这个问题了!如果不清楚可以回顾一下【漫画】JAVA并发编程 如何解决可见性和有序性问题

总结

synchronized 在JVM层面实现了对临界资源的同步互斥访问,但 synchronized 粒度有些大,在处理实际问题时存在诸多局限性,比如响应中断等。

Lock 提供了比 synchronized更广泛的锁操作,它能以更优雅更灵活的方式处理线程同步问题。

我们以ReentrantLock为例子进入了Lock的世界,**最重要的是记住ReentrantLock的特有功能,比如中断、超时、非阻塞锁等。当你的需求符合这些特有功能的时候,那你只能选择Lock而不是synchronized **

附文中代码github地址:https://github.com/LYL41011/java-concurrency-learning

原创声明:本文来源于公众号【胖滚猪学编程】 转载请注明出处

本文转载自公众号【胖滚猪学编程】 用漫画让编程so easy and interesting!欢迎关注!

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,378评论 6 481
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,356评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 152,702评论 0 342
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,259评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,263评论 5 371
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,036评论 1 285
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,349评论 3 400
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,979评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,469评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,938评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,059评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,703评论 4 323
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,257评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,262评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,485评论 1 262
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,501评论 2 354
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,792评论 2 345