Java高级上锁机制:显式锁 ReentrantLock

Java 5.0 加入了新的上锁工作:ReentrantLock,它和同步(Synchronized)方法的内置锁不同,这是一种显式锁。显式锁作为一种高级的上锁工作, 是同步方法的一种补充和扩展,用来实现同步代码块无法完成的功能。

1 Lock和ReentrantLock

Lock作为显式锁,其提供了一种无条件的、可轮询和定时的、可中断的锁操作,其获得锁和释放锁的操作都是显示。

Lock是Java 5.0 中加入的接口,表示显式锁的功能,其接口定义如下:

public interface Lock {
    void lock(); //获取锁
    void lockInterruptibly() throws InterruptedException; //可中断的获取锁操作
    boolean tryLock(); //尝试获取锁,不会被拥塞,如果失败立刻返回
    boolean tryLock(long time, TimeUnit unit) throws InterruptedException; //在一定时间内尝试获得锁,如果超时则失败
    void unlock(); // 释放锁
    Condition newCondition();
}

前文中,我们已经讨论过,显式锁和同步代码块中的内置锁有着相同的互斥性和内存可见性。ReentrantLockLock的一种实现,提供对于线程的重入机制。和同步方法(Synchronized)相比,有着更强性能和灵活性。

虽然同步方法的内置锁已经很强大和完备了,但是在功能上还有一定的局限性:不能实现非拥塞的锁操作。比如不能提供响应中断的获得锁操作,不能提供支持超时的获得锁操作等等。因此,在某些情况下需要使用更为灵活的加锁方式,也就是显式锁。

在Java官方的注解中,给出了这样的代码示例:

 Lock l = new ReentrantLock();
 l.lock();
 try {
   // access the resource protected by this lock
 } finally {
   l.unlock();
 }

显式锁需要在手动调用lock方法来获得锁,并在使用后在finally代码块中调用unlock方法释放锁,以保证无论操作是否成功都能释放掉锁。

显式锁支持非拥塞的锁操作,具体的功能有:支持可轮询和定时的、以及可中断的锁获得操作。

1.1 轮询锁和定时锁

使用tryLock方法可以用于实现轮询锁定时锁。和无条件的获得锁操作相比,tryLock方法具有更完善的错误恢复机制,可以避免死锁的放生。相比之下,同步方法发生死锁,其恢复方法就只能重新启动程序。

避免死锁的方式之一为打破“请求与保持条件”(死锁的四个条件),比如在要获得多个锁才能工作的情况下,如果不能获得全部的锁,就会释放掉已经持有的锁,一段时间之后再去重新尝试获得所有的锁。也就是说要么获得所有锁,要么一个锁都不占有

下面的代码中以转账为例,演示了轮询锁的工作机制。

public class DeadlockAvoidance {
    private static Random rnd = new Random();

    // 转账
    public boolean transferMoney(Account fromAcct, //转出账户
                                 Account toAcct, //转入账户
                                 DollarAmount amount, //金额
                                 long timeout, //超时时间
                                 TimeUnit unit) 
            throws InsufficientFundsException, InterruptedException {
        long fixedDelay = getFixedDelayComponentNanos(timeout, unit);
        long randMod = getRandomDelayModulusNanos(timeout, unit);
        long stopTime = System.nanoTime() + unit.toNanos(timeout);

        while (true) {
            // 尝试获得fromAcct的锁
            if (fromAcct.lock.tryLock()) {
                try {
                    // 尝试获得toAcct的锁
                    if (toAcct.lock.tryLock()) {
                        try {
                            if  (fromAcct.getBalance().compareTo(amount) < 0) //余额不足
                                throw new InsufficientFundsException();
                            else { // 余额满足,转账
                                fromAcct.debit(amount);
                                toAcct.credit(amount);
                                return true;
                            }
                        } finally { //释放toAcct锁
                            toAcct.lock.unlock();
                        }
                    }
                } finally { //释放fromAcct锁
                    fromAcct.lock.unlock();
                }
            }
            // 获得锁失败
            // 判断是否超时 如果超时则立刻失败
            if (System.nanoTime() < stopTime)
                return false;

            // 如果没有超时,随机睡眠一段时间
            NANOSECONDS.sleep(fixedDelay + rnd.nextLong() % randMod);
        }
    }


    class Account {
        //显示锁
        public Lock lock;

        void debit(DollarAmount d) {
        }

        void credit(DollarAmount d) {
        }

        DollarAmount getBalance() {
            return null;
        }
    }

    class InsufficientFundsException extends Exception {
    }
}

只有同时获得转出账户和转入账户的锁后,才会进行转账。如果不能同时获得两个锁,就释放掉已经获得的锁,并随机随眠一段时间,再去尝试获得全部的锁,循环这个过程直到超时。

除了轮询申请获得锁之外,也可以使用带有时间限制的定时锁操作,即获得锁的操作具有时间限制,超过一定时间后仍没有获得锁就会返回失败。示例如下:

public class TimedLocking {
    private Lock lock = new ReentrantLock();

    public boolean trySendOnSharedLine(String message,
                                       long timeout, TimeUnit unit)
            throws InterruptedException {
        // 设定超时时间
        long nanosToLock = unit.toNanos(timeout)
                - estimatedNanosToSend(message);
        // 在规定时间内等待锁 否者就会返回false
        if (!lock.tryLock(nanosToLock, NANOSECONDS))
            return false;
        try {
            return sendOnSharedLine(message);
        } finally {
            lock.unlock();
        }
    }

    private boolean sendOnSharedLine(String message) {
        /* send something */
        return true;
    }

    long estimatedNanosToSend(String message) {
        return message.length();
    }
}

1.2 中断锁

如果要将显式锁应用到可以取消的任务重,就需要让获得锁的操作是支持中断。 lockInterruptibly方法可以应用到这样情况中,其不仅能获得锁,还能保持对于中断的响应。

public class InterruptibleLocking {
    private Lock lock = new ReentrantLock();

    public boolean sendOnSharedLine(String message)
            throws InterruptedException {
        // 可以响应中断的锁
        lock.lockInterruptibly();
        try {
            return cancellableSendOnSharedLine(message);
        } finally {
            lock.unlock();
        }
    }

    // 可能会抛出中断异常
    private boolean cancellableSendOnSharedLine(String message) throws InterruptedException {
        /* send something */
        return true;
    }

}

1.3 非块结构的加锁

在内置锁中,锁的获得和锁的释放都是在同一块代码的,这样简洁清楚还便于使用,不用考虑如何退出代码块。但是加锁的位置不一定只有代码块,比如之前谈过的分段锁ConcurrentHashMap中利用了分段锁对散列表中的元素分段上锁,实现了并发访问容器元素的功能。如果是这种非块结构的加锁,就不能应用内置锁,而是需要使用显式锁控制。同样,链表类的容器可以应用分段锁,来支持并发访问不同链表元素。

2 性能因素考虑

前文中曾经提过,ConcurrentHashMap和同步的HashMap相比,其性能优势在于利用了分段锁对散列表中的元素分段上锁,故而支持并发访问容器中不同的元素。同理,和内置锁相比,显式锁都优势在于更好的性性。锁的实现方式越好,就越可以避免不必要的系统调用和上下文切换,以提高效率。

线程间的切换,涉及线程挂起和恢复等一系列操作,这样的线程上下文的切换很是消耗性能,所以要避免不必要的线程切换。

Java 6中对内置锁的进行了优化,现在内置锁和显式锁相比性能已经很接近,只略低一些。

3. 公平锁

ReentrantLock的构造函数中提供两种锁的类型:

  • 公平锁:线程将按照它们请求锁的顺序来获得锁;
  • 非公平锁:允许插队,如果一个线程请求非公平锁的那个时刻,锁的状态正好为可用,则该线程将跳过所有等待中的线程获得该锁。

非公平锁在线程间竞争锁资源激烈的情况下,性能更高,这是由于:在恢复一个被挂起线程与该线程真正开始运行之间,存在着一个很严重的延迟,这是由于线程间上下文切换带来的。正是这个延迟,造成了公平锁在使用中出现CPU空闲。非公平锁正是将这个延迟带来的时间差利用起来,优先让正在运行的线程获得锁,避免线程的上下文切换。

如果每个线程获得锁的时间都很长,或者请求锁的竞争很稀疏或不频繁,则公平锁更为适合。

内置锁和显式锁都是默认使用非公平锁,但是显式锁可以设置公平锁,内置锁无法做到。

4. 同步方法和显式锁的选择

显式锁虽然更为灵活,提供更为丰富的功能,且性能更好,但是还是推荐先使用同步(Synchronized)方法,这是因为同步方法的内置锁,使用起来更为方便,简洁紧凑 ,还便于理解,也更为开发人员所熟悉。

建议只有在一些内置锁无法满足的情况下,再将显式锁ReentrantLock作为高级工具使用,比如要使用轮询锁、定时锁、可中断锁或者是公平锁。除此之外,还应该优先使用synchronized方法。

5. 读-写锁

无论是显式锁还是内置锁,都是互斥锁,也就是同一时刻只能有一个线程得到锁。互斥锁是保守的加锁策略,可以避免“写-写”冲突、“写-读”冲突”和"读-读"冲突。但是有时候不需要这么严格 ,同时多个任务读取数据是被允许,这有助于提升效率,不需要避免“读-读”操作。为此,Java 5.0 中出现了读-写锁ReadWriteLock

ReadWriteLock可以提供两种锁:

  • 读锁readLock:允许多个线程同时执行读操作,但是同时只能有一个线程执行写操作;
  • 写锁writeLock:正常的互斥锁,同一时刻只能有一个线程执行读写操作。

ReentrantReadWriteLock是读写锁支持重入的实现,下面的例子中利用读写锁实现了支持并发读取元素的多线程安全Map:

public class ReadWriteMap <K,V> {
    private final Map<K, V> map;
    // 读写锁
    private final ReadWriteLock lock = new ReentrantReadWriteLock();
    // 读锁
    private final Lock r = lock.readLock();
    // 写锁
    private final Lock w = lock.writeLock();

    public ReadWriteMap(Map<K, V> map) {
        this.map = map;
    }

    public V put(K key, V value) {
        w.lock();
        try {
            return map.put(key, value);
        } finally {
            w.unlock();
        }
    }
    
    public V get(Object key) {
        r.lock();
        try {
            return map.get(key);
        } finally {
            r.unlock();
        }
    }
    .....
}

不过需要注意的是,虽然读写锁的出现是为了提高效率,但只适用于对多线程频繁并发执行读操作的情况。如果是在正常的情况下使用读写锁,反而会降低效率,因为ReadWriteLock需要额外的开销维护分别维护读锁和写锁,得不偿失。

扩展阅读:

  1. 多线程安全性:每个人都在谈,但是不是每个人都谈地清
  2. 对象共享:Java并发环境中的烦心事
  3. 从Java内存模型角度理解安全初始化
  4. 从任务到线程:Java结构化并发应用程序
  5. 关闭线程的正确方法:“优雅”的中断
  6. 驾驭Java线程池:定制与扩展
  7. 探秘Java并发模块:容器与工具类
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,829评论 1 331
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,603评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,846评论 0 226
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,600评论 0 191
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,780评论 3 272
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,695评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,136评论 2 293
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,862评论 0 182
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,453评论 0 229
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,942评论 2 233
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,347评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,790评论 2 236
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,293评论 3 221
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,839评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,448评论 0 181
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,564评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,623评论 2 249

推荐阅读更多精彩内容