ReentrantLock详解

本文详细解析了Java并发包中ReentrantLock的实现,包括其可重入性、公平性和非公平性,以及显式锁操作和条件变量的使用。通过实例展示了公平锁和非公平锁在多线程环境中的行为差异。
摘要由CSDN通过智能技术生成

ReentrantLock 是 Java 并发包(java.util.concurrent.locks)中的一个可重入锁实现,它提供了比 synchronized 关键字更灵活、功能更丰富的线程同步机制。ReentrantLock类内部总共存在Sync、NonfairSync、FairSync三个类,NonfairSync(非公平锁)与FairSync(公平锁)类继承自Sync类,Sync类继承自AbstractQueuedSynchronizer抽象类。

可重入性

,ReentrantLock 是一种可重入锁。这意味着持有锁的线程可以再次获取该锁,而不会发生死锁。每次成功获取锁都会增加锁的持有计数,相应的释放锁操作会减少计数。当计数降至零时,锁才会真正释放给其他等待的线程。这种特性使得在递归调用或嵌套同步块中使用同一线程多次获取同一锁成为可能。

公平性

ReentrantLock 默认实现的是非公平锁。同时,ReentrantLock 提供了公平锁和非公平锁两种模式。在构造时可以通过传递布尔参数指定:

  • 公平锁(true):按照线程请求锁的顺序进行排队,先请求的线程优先获得锁。公平锁倾向于减少线程饥饿现象,但可能降低系统的整体吞吐量。
  • 非公平锁(默认,false):不保证按照线程请求锁的顺序分配锁,允许后来的线程“插队”获取锁。非公平锁在某些场景下可能提供更高的性能,但可能增加线程饥饿的风险。

显式锁操作

与 synchronized 关键字不同,ReentrantLock 需要显式地调用方法来获取和释放锁:

  • lock():尝试获取锁。如果锁不可用,当前线程将被阻塞直到锁变得可用。
  • tryLock():尝试非阻塞地获取锁。如果锁可用,立即返回 true;否则返回 false。
  • tryLock(long timeout, TimeUnit unit):尝试在指定时间内获取锁。如果在超时时间内锁不可用,返回 false。
  • unlock():释放锁。必须确保在持有锁的线程中正确调用此方法,否则可能导致死锁或其他同步问题。

条件变量(Condition)

ReentrantLock 还支持条件变量,通过 newCondition() 方法创建 Condition 对象。条件变量允许线程在满足特定条件时等待,直到其他线程通知它们条件已发生变化。与 Object 类的 wait()、notify() 和 notifyAll() 方法相比,条件变量提供了更精细的线程同步控制:

  • await():当前线程进入等待状态,释放锁,并在其他线程调用对应 Condition 对象的 signal() 或 signalAll() 方法时唤醒。
  • signal():唤醒一个等待在该 Condition 上的线程,但不释放锁。
  • signalAll():唤醒所有等待在该 Condition 上的线程,但不释放锁。

ReentrantLock使用

public static void main(String[] args) throws InterruptedException {
        List<Thread> threads = new ArrayList<>();

        // 创建5个线程共享公平锁
        for (int i = 0; i < 5; i++) {
            Thread thread = new Thread(() -> testLock(fairLock, "FairLock"));
            threads.add(thread);
            thread.start();
        }

        // 创建5个线程共享非公平锁
        for (int i = 0; i < 5; i++) {
            Thread thread = new Thread(() -> testLock(nonFairLock, "NonFairLock"));
            threads.add(thread);
            thread.start();
        }

        // 等待所有线程执行完毕
        for (Thread thread : threads) {
            thread.join();
        }
    }

testLock方法:

private static void testLock(Lock lock, String lockType) {
        for (int i = 0; i < 10; i++) {
            // 尝试获取锁
            lock.lock();
            try {
                System.out.println(Thread.currentThread().getName() + " acquired " + lockType + ", iteration: " + i);
                // 模拟耗时操作
                Thread.sleep(50);
            } catch (InterruptedException e) {
                e.printStackTrace();
            } finally {
                // 释放锁
                lock.unlock();
            }
        }
    }

当运行这个程序时,您应该能看到公平锁和非公平锁在多线程竞争下的差异。公平锁倾向于按照线程请求锁的顺序给予锁,而非公平锁可能会让后来的线程“插队”获取锁:
在这里插入图片描述

FairSync公平锁代码分析

 static final class FairSync extends Sync {
        private static final long serialVersionUID = -3000897897090466540L;

        /**
         * Acquires only if reentrant or queue is empty.
         */
        final boolean initialTryLock() {
            Thread current = Thread.currentThread();
            //当state为0时,表示锁未被任何线程持有;若为正整数,表示锁被某个线程持有,数值表示该线程的重入次数。
            int c = getState();
            if (c == 0) {
            //检查等待队列中是否有其他线程正在等待。
            //如果!hasQueuedThreads()返回true,表示当前没有其他线程在等待队列中。
            //调用compareAndSetState(0, 1)尝试原子性地将state从0改为1,这一步相当于尝试获取锁。如果该操作成功,说明当前线程成功获得了锁。
                if (!hasQueuedThreads() && compareAndSetState(0, 1)) {
                //设置独占线程
                    setExclusiveOwnerThread(current);
                    return true;
                }
                //如果state不为0(即锁已被持有),则检查当前持有锁的线程是否就是当前线程。
                //如果是,说明当前线程正在尝试重入获取锁。
            } else if (getExclusiveOwnerThread() == current) {
            	//发生溢出
                if (++c < 0) // overflow
                    throw new Error("Maximum lock count exceeded");
                setState(c);
                return true;
            }
            return false;
        }

当资源空闲时,它总是会先判断sync队列(AbstractQueuedSynchronizer中的数据结构)是否有等待时间更长的线程,如果存在,则将该线程加入到等待队列的尾部,实现了公平获取原则。

NonfairSync 非公平锁代码分析

final boolean initialTryLock() {
            Thread current = Thread.currentThread();
            // 比较并设置状态成功,状态0表示锁没有被占用
            if (compareAndSetState(0, 1)) { // first attempt is unguarded
             把当前线程设置独占了锁
                setExclusiveOwnerThread(current);
                return true;
            } else if (getExclusiveOwnerThread() == current) {
                int c = getState() + 1;
                if (c < 0) // overflow
                    throw new Error("Maximum lock count exceeded");
                setState(c);
                return true;
            } else
                return false;
        }

从lock方法的源码可知,每一次都尝试获取锁,而并不会按照公平等待的原则进行等待,让等待时间最久的线程获得锁。

  • 18
    点赞
  • 28
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

π克

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值