五、详解ReentrantLock

目录

死锁

ReentrantLock与Synchronized对比

源码分析

Lock接口

lock()实现

NonfairSync

tryAcquire()

addWaiter()

acquireQueued()

FairSync

tryAcquire()

NonfairSync和FairSync的本质区别

tryLock()实现

unlock()实现

Condition实现

await()

signal()和signalAll()


死锁

死锁是指两个或多个线程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力干涉,它们都将无法继续执行下去。最经典的问题就是哲学家就餐问题:

假设有五位哲学家围坐在圆桌旁,进行思考和进餐。每位哲学家面前都有一碗面条,而吃面条需要用到两只筷子。每位哲学家的左右两边各有一只筷子,总共就是五只筷子。

哲学家只有在拿到左右两边的筷子后才能吃面,吃完后再把筷子放下,继续思考。  这个问题的关键在于,如果每位哲学家都先拿起自己左边的筷子,然后等待右边的筷子,那么就会出现死锁的情况,因为每位哲学家都在等待别人放下筷子,但是没有人会放下筷子。

解决死锁问题的方法有以下几种:

1、按照顺序加锁:可以针对筷子进行编号,所有哲学家必须按照编号从小到大获取筷子。

2、尝试加锁:利用trylock的思想,先拿起一根筷子,然后尝试拿下一个筷子,如果拿到了就吃饭,如果拿不到,就释放所有的筷子。

3、超时机制:让线程不要一直等待,一段时间内不能满足要求,则放弃所有的资源。

ReentrantLock与Synchronized对比

Synchronized详细看:三、详解Synchronized-CSDN博客

ReentrantLock是Java并发包java.util.concurrent.locks中的一个类,它实现了Lock接口,提供了与synchronized关键字类似的互斥锁功能。ReentrantLock的名字来源于它是一个可重入锁,也就是说,一个线程可以多次获取同一个ReentrantLock锁,每次获取锁时,计数器会递增,每次释放锁时,计数器会递减,当计数器为0时,锁被释放。

ReentrantLock相比于synchronized关键字,提供了更高的灵活性和更多的功能,例如:  

1. 可以显式地获取和释放锁,这使得锁的范围更加灵活,可以跨越多个方法或代码块。

2. 支持公平锁和非公平锁。公平锁是指等待时间最长的线程将优先获得锁,非公平锁则没有这个限制。默认情况下,ReentrantLock是非公平锁,但可以在构造函数中传入参数true来创建公平锁。

3. 提供了tryLock()方法,可以尝试获取锁,如果获取不到锁,线程可以继续执行其他任务,而不是一直等待。

4. 支持中断。当一个线程在等待锁时,可以被其他线程中断,这样可以避免死锁问题。

一个使用ReentrantLock的使用demo:

import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

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

    public void method1() {
        lock.lock(); // 获取锁, 此时当前线程会一直等待,直到获取锁为止
        try {
            // 临界区代码
        } finally {
            lock.unlock(); // 释放锁
        }
    }

    public void method2() {
        if (lock.tryLock()) { // 尝试获取锁,可能成功,也可能失败
            try {
                // 临界区代码
            } finally {
                lock.unlock(); // 释放锁
            }
        } else {
            // 未获取到锁,执行其他任务
        }
    }
}

源码分析

Lock接口

想要学习ReentrantLock的源码,就必须先搞明白ReentrantLock类的继承关系。在idea上查看继承关系如下:

五、详解ReentrantLock_第1张图片

从继承关系上来看,ReentrantLock也就是简单的实现了Lock接口。那我们就先看一下这个Lock接口到底都包含啥:

public interface Lock {

    /**
     加锁
     */
    void lock();

    /**
      可打断加锁
     */
    void lockInterruptibly() throws InterruptedException;

    /**
     尝试加锁
     */
    boolean tryLock();

    /**
     在一定时间范围内尝试加锁
     */
    boolean tryLock(long time, TimeUnit unit) throws InterruptedException;

    /**
     解锁
     */
    void unlock();

    /**
     返回一个锁的条件
     */
    Condition newCondition();
}

从上面的代码来看,Lock的接口提供的功能非常简单就是加锁、解锁、还有一个类似于wait方法的条件。

那么接下来看一下,在ReentrantLock中,是如何实现这个Lock接口的。

lock()实现

首先看一下核心的lock()方法是如何实现的呢?我们定位到ReentrantLock的lock()方法:

public void lock() {
        sync.acquire(1);
}

发现内部实际上是调用了一个变量sync的acquire方法。那么这个sync变量是啥呢?什么时候给赋值的呢?

跟踪代码,看到sync是ReentrantLock类中的一个属性变量,而属性变量一般都会在构造方法中赋值,因此,查看ReentrantLock的构造方法:

    /**
     *返回一个非公平锁
     */
    public ReentrantLock() {
        sync = new NonfairSync();
    }

    /**
     *返回公平锁或者非公平锁
     */
    public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
    }

这里可以看出来,当我们执行构造方法时,默认创建了一个NonfairSync对象。也就是非公平锁,

那么具体什么是公平锁,什么是非公平锁,这里简单描述就是:公平指的是先来的线程先获取到锁,后来的线程后获取到锁。而非公平指的是不管先来后来,后来的锁也可以先获取到锁。后面我们详细解释是如何做到的。

好了,从上面的构造函数来看,有多了 FairSync和NonfairSync这个两个类。我们还是先看一下这个两个类的继承结构。

FairSync:

五、详解ReentrantLock_第2张图片

NonfairSync:

五、详解ReentrantLock_第3张图片

从图上看,这个两个类的继承关系一样,那么为什么需要设置两个类呢?这个两个类到底哪些地方不同呢?

NonfairSync

我们先来分析一下非公平锁,这个也是ReentrantLock默认的实现。当调用lock()方法的时候,实际上是调用了NonfairSync.acquire()

具体看NonfairSync.acquire() 是什么逻辑,这个acquire在NonfairSync类中本身是没有提供的,但是由于他继承了父类,那么acquire肯定在其父类AbstractQueueSynChronizer。

public final void acquire(int arg) {
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
}

在这个方法中,有三个重要的方法: 

1、tryAcquire :尝试去获取, 如果为true,则直接返回,那就意味着lock方法返回,继续执行,

如果为false,那么执行addWaiter方法

2、addWaiter:将线程添加到同步

3、acquireQueued:从同步队列中获取一个线程来执行

tryAcquire()

那么我们先看tryAcquire是干啥的,继续跟踪,发现这个方法居然是protected的,这就意味着这个方法应该交由子类实现

 protected boolean tryAcquire(int arg) {
        throw new UnsupportedOperationException();
}

而当前AQS的子类就是我们的NonfairSync。那么就看一下NonfairSync中的tryAcquire到底是干啥呢?

protected final boolean tryAcquire(int acquires) {
     return nonfairTryAcquire(acquires);
}

final boolean nonfairTryAcquire(int acquires) {
     final Thread current = Thread.currentThread();
     int c = getState();
      if (c == 0) {
          if (compareAndSetState(0, acquires)) {
              setExclusiveOwnerThread(current);
              return true;
          }
       }
       else if (current == getExclusiveOwnerThread()) {
           int nextc = c + acquires;
           if (nextc < 0) // overflow
                throw new Error("Maximum lock count exceeded");
           setState(nextc);
           return true;
       }
       return false;
}

我们尝试理解一下这段逻辑:

1、获取当前执行的线程,这个线程就是一开始调用lock.lock()那个线程。

2、获取状态,

3、如果状态为0, 那么就尝试利用cas的方式将0设置为acquire,这里acquire就是1(画外音:利用state为0表示无锁,<0表示有锁。)

4、如果说cas成功,那么就设置ExclusiveOwnerThread为自己当前线程,然后返回true。(画外音:如果cas成功,那么意味加锁成功,并且将【持有锁线程】设置为当前线程,然后返回true)

5、如果说状态不是0,那么判断ExclusiveOwnerThread是否为自己,如果是自己那么就将状态值加1 (画外音:如果现在已经有别的线程加了锁,那么先判断一下,【持有锁线程】是否为自己,如果为自己,那么就将state累计加1,表示当前线程重入的次数

6、如果上述都不满足则返回false。(画外音:如果有线程加锁,而且加锁的线程不是当前线程,那么就返回false)

addWaiter()

接下来看一下addWaiter方法。

private Node addWaiter(Node mode) {
        Node node = new Node(mode);

        for (;;) {
            Node oldTail = tail;
            if (oldTail != null) {
                node.setPrevRelaxed(oldTail);
                if (compareAndSetTail(oldTail, node)) {
                    oldTail.next = node;
                    return node;
                }
            } else {
                initializeSyncQueue();
            }
        }
    }

尝试分析:

1、先创建一个node

2、不断死循环,判断同步队列是否有一个队尾,如果有,则利用cas将当前的node插入到同步队列,之后break。

3、如果原始同步队列没有队尾,那么就初始化一个队列,然后再次进入循环。

好,到此为止,我们整理一下,lock方法到底干了啥:

1、先尝试加锁,也就是cas去设置state,如果加锁成功,那么就执行lock之后的代码,如果加锁失败,则创建一个node,并加入到同步队列。

acquireQueued()

最后一步,执行acquireQueued(), 继续跟踪这个方法的逻辑:

final boolean acquireQueued(final Node node, int arg) {
        boolean interrupted = false;
        try {
            for (;;) {
                final Node p = node.predecessor();
                if (p == head && tryAcquire(arg)) {
                    setHead(node);
                    p.next = null; // help GC
                    return interrupted;
                }
                if (shouldParkAfterFailedAcquire(p, node))
                    interrupted |= parkAndCheckInterrupt();
            }
        } catch (Throwable t) {
            cancelAcquire(node);
            if (interrupted)
                selfInterrupt();
            throw t;
        }
    }

继续分析:

1、进入一个死循环

2、获取到刚刚新创建的node的前驱节点。如果说前驱节点为head,那么就去再次执行tryAcquire()。(画外音:如果前驱节点为head,那就意味着当前新创建的node前面没有任何被阻塞的节点了,那么当前线程就应该去继续尝试加锁)

3、如果加锁成功了,则把当前node设置为head,然后返回。注意这里的返回,意味着lock方法已经结束了,可以执行lock里面的临界区代码了

4、如果说当前node的前驱节点不是head,那么当前线程就会被park住,等待。这就意味着lock方法被阻塞,线程等待锁。

到此,应该彻底明白了lock方法到底都干啥了:

1、尝试加锁(tryAcquire),如果成功,则直接返回,执行lock后面的代码。

2、如果失败,将node添加到同步队列(addWaiter)

3、之后当前线程一直死循环去判断当前node是否为head,如果为head,继续尝试加锁(tryAcquire),如果成功则直接返回,执行lock后面代码。如果失败,那么就被park,等待其他线程唤醒。

FairSync

上面分析了非公平锁的加锁逻辑,现在看看公平锁的加锁逻辑,到底是如何做到公平的。

tryAcquire()

跟踪一下这个公平的锁tryAcquire()

protected final boolean tryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
                if (!hasQueuedPredecessors() &&
                    compareAndSetState(0, acquires)) {
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) {
                int nextc = c + acquires;
                if (nextc < 0)
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
        }

继续分析:

1、获取当前线程

2、是否有锁,如果没有锁,先判断当前等待队里中是否已经有了node。如果说有了node,那么就直接返回加锁失败,如果之前没有node,则尝试加锁,并设置【锁持有线程】

3、如果有锁,判断【持有锁的线程】是否为当前线程,如果是,则state加1,返回加锁成功

4、如果有锁且不是当前线程持有锁,那么返回加锁失败。

NonfairSync和FairSync的本质区别

对比两个类的traAcquire方法可以看出来,当发现state=0(没有锁的时候),两个类的加锁方式不同:
1、非公平:当前线程直接尝试加锁

2、公平:先看一下,同步队列中是否已经有其他线程在等待锁,如果有,那么当前线程放弃加锁,直接去排队。如果没有,才开始加锁。

tryLock()实现

tryLock和lock本质的区别就是:trylock一次尝试加锁,不论成功与否就直接返回了,而lock多次加锁,成功就返回,失败了就死循环一个尝试。

public boolean tryLock() {
        return sync.nonfairTryAcquire(1);
}

final boolean nonfairTryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
                if (compareAndSetState(0, acquires)) {
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) {
                int nextc = c + acquires;
                if (nextc < 0) // overflow
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
}

可以看到tryLock的方法中直接就调用了tryAcquire,而不需要调用addWaiter和accquireQueued。因此改方法成功与否都会直接返回。

unlock()实现

unlock方法就是解锁,解锁的话就不需要区分公平不公平了,因为执行解锁的线程就是当前持有锁的线程。

public final boolean release(int arg) {
        if (tryRelease(arg)) {
            Node h = head;
            if (h != null && h.waitStatus != 0)
                unparkSuccessor(h);
            return true;
        }
        return false;
}

尝试分析一下:

1、调用tryRelease方法。这个方法也是一个需要被子类实现的方法。这个道理很简单,因为tryAcquire方法是子类实现的,那么解锁的tryRelease的方法也应该是子类实现。因为不通子类加锁和解锁的逻辑是不一样的。

2、获取到head节点,unpark等待的其他线程。

看一下是如何进行tryRelease的:

protected final boolean tryRelease(int releases) {
            int c = getState() - releases;
            if (Thread.currentThread() != getExclusiveOwnerThread())
                throw new IllegalMonitorStateException();
            boolean free = false;
            if (c == 0) {
                free = true;
                setExclusiveOwnerThread(null);
            }
            setState(c);
            return free;
}

分析:

1、将锁的重入次数减去release,当前release=1。意味着当前持有线程的重入减1

2、判断当前【锁持有线程】是否和当前线程一样,如果不一样那就报错,这里一般来说肯定是一样的,因为只有lock加锁成功的线程才会向下执行,才会执行到unlock方法。

3、如果state=0,将【锁持有线程】设置为null。意味着没有锁了

4、之后直接setState,这里没有用cas,因为解锁的逻辑只有一个线程执行,不会冲突。

当前线程解锁之后,如何通知其他等待的线程继续来抢锁呢?答案就是在unparkSuccessor方法中。

private void unparkSuccessor(Node node) {
    
    int ws = node.waitStatus;
    if (ws < 0)
        node.compareAndSetWaitStatus(ws, 0);
    //知道这里为什么唤醒的node.next吗,因此node是当前线程,next才是要被唤醒的线程。
    //具体可以看一下,addWaiter()方法,初始的时候head是一个dummyNode, 
    Node s = node.next;
    if (s == null || s.waitStatus > 0) {
        s = null;
        for (Node p = tail; p != node && p != null; p = p.prev)
            if (p.waitStatus <= 0)
                s = p;
    }
    if (s != null)
        LockSupport.unpark(s.thread);
}

核心的逻辑就是LockSupport.unpark()。 当此行代码执行,那么在同步队列中等待的第一个node中的线程将被唤醒,然后执行accquireQueued中的那个死循环。

到此为止,ReentrantLock的加锁和解锁就讲完了。总结:

1、ReentrantLock中有两种锁,一种公平,一种非公平,默认是非公平。两者的区别就是在加锁的时候判断是否需要排队。

2、加锁的时候,利用cas将一个state变量设置为1,然后将【锁持有线程】设置为自己。重入的时候,将state累计加1.

3、加锁失败了之后,会封装成一个node,然后将node插入到同步队列的尾部。之后执行for循环,一直不断地尝试加锁,如果加锁失败,则park住,让出cpu。

4、解锁流程就是将state不断地减1,一旦state减为0,那就意味着线程所有重入逻辑结束,直接释放【锁持有线程】,并唤醒同步队列中的其他线程。

Condition实现

Condition是一个接口主要包含了一下几个方法:
 

public interface Condition {

    /**
     等待
     */
    void await() throws InterruptedException;
    /**
     打断等待
     */
    void awaitUninterruptibly();

    /**
     超时等待
     */
    long awaitNanos(long nanosTimeout) throws InterruptedException;

    /**
     超时等待
     */
    boolean await(long time, TimeUnit unit) throws InterruptedException;

    /**
     唤醒
     */
    void signal();

    /**
     全部唤醒
     */
    void signalAll();
}

这个方法用于使当前线程等待,直到它被其他线程唤醒,或者被中断。

常见的方法为 await()和signal()。在调用await()方法之前,线程必须持有与Condition相关联的Lock。调用await()方法后,线程会释放这个锁,并进入等待状态。当其他线程调用Condition的signal()或signalAll()方法时,等待的线程之一会被唤醒并重新获取锁。

下面给一个简单demo:
 

Lock lock = new ReentrantLock();
Condition condition = lock.newCondition();

lock.lock();
try {
    while (!conditionMet()) {
        condition.await(); //等待
    }
    // 执行一些操作
} catch (InterruptedException e) {
    // 处理中断
} finally {
    lock.unlock();
}

await()

我们首先分析一下await方法输入

public final void await() throws InterruptedException {
    if (Thread.interrupted())
        throw new InterruptedException();
    //将当前节点加入到等待队里
    Node node = addConditionWaiter();
    //释放当前线程的所有锁资源
    int savedState = fullyRelease(node);
    int interruptMode = 0;
    while (!isOnSyncQueue(node)) {
        //挂起当前线程
        LockSupport.park(this);
        if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
            break;
    }

    //当线程被唤醒之后,开始尝试获取锁,进行重新加锁
    if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
        interruptMode = REINTERRUPT;
    if (node.nextWaiter != null) // clean up if cancelled
        unlinkCancelledWaiters();
    if (interruptMode != 0)
        reportInterruptAfterWait(interruptMode);
}

分析这段逻辑:

1、先将自己的node加入到等待队列中。这里流程和链表添加node一样,不需要加锁,因为此时只有持有锁的线程才会执行到这一步

2、释放当前线程的所有锁资源。在这里,释放资源之后,会唤醒其他同步队里的线程。

3、将当前线程park住

4、如果当前线程被其他线程unpark,则开始重新尝试加锁(acquireQueued方法)

这里有几个细节需要注意:

1、当线程被唤醒之后,为什么没有看到 addWaiter()这一步呢。acquireQueued方法只是循环去判断当前node是否为head,但是什么时候node被迁移到同步队列中去的呢?答案在signal中。

2、当fullyRelease(node)返回了savedState表示当前线程重入了几次。当释放完所有资源之后,state=0,唤醒其他线程去抢锁。当当前线程被唤醒之后,去重新加锁的时候将savedState传递给了acquireQueued方法,使得state又变成了原来的数值

signal()和signalAll()

这两个方法的本质区别在于是唤醒一个线程,还是唤醒所有线程。

        private void doSignal(Node first) {
            do {
                if ( (firstWaiter = first.nextWaiter) == null)
                    lastWaiter = null;
                first.nextWaiter = null;
            } while (!transferForSignal(first) &&
                     (first = firstWaiter) != null);
        }


        private void doSignalAll(Node first) {
            lastWaiter = firstWaiter = null;
            do {
                Node next = first.nextWaiter;
                first.nextWaiter = null;
                transferForSignal(first);
                first = next;
            } while (first != null);
        }

对比两者之间的逻辑:

singalAll:先唤醒当前node,然后while里面在唤醒next,一直循环,直到队尾

signal:先将当前节点和队列断开,然后去唤醒,如果唤醒成功,则直接break这个while。如果唤醒失败,那么继续唤醒等待队列中的下一个节点,直到成功唤醒一个节点或等待队列为空。

重点看一下这个transferForSignal方法:

final boolean transferForSignal(Node node) {
        
        if (!node.compareAndSetWaitStatus(Node.CONDITION, 0))
            return false;

        //这一步解决之前的疑问,signal的时候不单单去执行唤醒,还执行插入同步队列
        Node p = enq(node); 
        int ws = p.waitStatus;
        if (ws > 0 || !p.compareAndSetWaitStatus(ws, Node.SIGNAL))
            LockSupport.unpark(node.thread); //唤醒当前线程
        return true; 
    }

这个方法先利用循环cas的方式将node迁移到同步队列中,然后再唤醒当前线程。之后线程的执行逻辑就是从await方法的park函数返回,执行加锁逻辑。

你可能感兴趣的:(并发编程,java,开发语言)