ReentrantLock从结构底层到原理一篇讲清

ReentrantLock

1.是什么

Reetrantlock是一个可以重复获得锁的一个互斥锁,它的加锁与解锁都是需要手动执行,也可以多次加锁,同时它还可以指定是由公平锁还是非公平锁实现。

2.内部实现

构造方法:

public ReentrantLock() {
          
   
        sync = new NonfairSync();
    }

public ReentrantLock(boolean fair) {
          
   
        sync = fair ? new FairSync() : new NonfairSync();
    }

由构造方法可知,reentrantlock是由公平锁和非公平锁实现的,而公平锁和非公平锁都是继承实现AQS(AbstractQueuedSynchronizer)的模板方法和底层原理得以实现

AbstractQueuedSynchronizer(AQS)

//节点元素node的构成:
volatile Node prev; //指向前一个结点的指针
volatile Node next; //指向后一个结点的指针
volatile Thread thread; //当前结点代表的线程
volatile int waitStatus; //等待状态

//AQS其他的数据结构
private volatile int state;//Reentratlock中表示锁被同一个线程重入的次数
private transient Thread exclusiveOwnerThread;//标识锁是由哪个线程拥有

这里的头指针的头结点表示当前获得这个锁的线程,后面的节点表示想要获得这个锁的线程。这是一个先进先出的同步队列,获取锁失败的线程将构造自己的节点并追加到队列的尾部,并且阻塞自己,而当线程释放锁之后,也将尝试唤醒后续节点中处于阻塞状态的线程。

AQS的底层结构式lock实现的重要基础,对于公平锁和非公平锁来说,只是方法执行逻辑不同。

非公平锁NonfairSync

继承Sync,实现了lock和tryAcquire方法

final void lock() {
          
   
            if (compareAndSetState(0, 1))
                setExclusiveOwnerThread(Thread.currentThread());
            else
                acquire(1);
        }

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

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


 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;
        }

lock方法是默认去用cas的方式去更新state和当前持有线程,如果AQS中state为0,也就是队列为空,那么设置state和当前线程就可以,如果不成功,就加入队列。

Reentratlock非公平锁的加锁流程

1.1,尝试获取锁首先获取AQS中state的值,如果为0,表示当前锁没有被任何线程持有,以cas的方式设置state的值,以获取锁,并设置exclusiveOwnerThread标识这个锁由哪个线程拥有

1.2 如果state值不为0,则看当前锁的持有线程是否是自己,如果是,就可以重入了,对state加1 就可以了,获取锁也成功,如果持有线程不是自己,返回失败,

2,线程获取锁失败以后,就会为当前线程创建一个新的节点,判断tail尾指针是否为空,如果为空,构建新的节点同时设置为首尾指针,如果不是也就是队列不为空,那么就要以尾插方式放入队列尾部。

//先将新建节点前置节点置为尾节点,然后以cas的方式更新tail指针,最后新建节点入队
node.prev = t;
   if (compareAndSetTail(t, node)) {
          
   
        t.next = node;
        return t;
   }

3,将新建的节点入队后,进入一个死循环,只有新建节点的前节点是头节点并且自己获取锁成功以后,将头结点设置为自己以后才能跳出循环,否者的话就要,并将前置节点置为SIGNAL阻塞(调用LockSupport方法)当前线程。

4,随着队列不断的出队,后面的节点的前节点总会是头结点,而自己也会获得锁,那么他也会被唤醒。

ReentratLock的解锁过程

public void unlock() {
          
   
    sync.release(1);
}

public final boolean release(int arg) {
          
   
        if (tryRelease(arg)) {
          
   //将state减1,如果减1后为0,返回true
            Node h = head;
    //防止队列为空,唤醒前节点必须是阻塞的,而节点阻塞前要设置前节点为SIGNAL
            if (h != null && h.waitStatus != 0)
               //唤醒线程
                unparkSuccessor(h);
            return true;
        }
        return false;
    }


private void unparkSuccessor(Node node) {
          
   
        /*
         * If status is negative (i.e., possibly needing signal) try
         * to clear in anticipation of signalling.  It is OK if this
         * fails or if status is changed by waiting thread.
         */
        int ws = node.waitStatus;
        if (ws < 0)
            compareAndSetWaitStatus(node, ws, 0);

        /*
         * Thread to unpark is held in successor, which is normally
         * just the next node.  But if cancelled or apparently null,
         * traverse backwards from tail to find the actual
         * non-cancelled successor.
         */
        Node s = node.next;
        if (s == null || s.waitStatus > 0) {
          
   
            s = null;
            for (Node t = tail; t != null && t != node; t = t.prev)
                if (t.waitStatus <= 0)
                    s = t;
            //从为节点开始遍历,找到离头节点最近且节点状态为SIGNAL的节点
        }
        if (s != null)
            //使用LockSupport唤醒线程
            LockSupport.unpark(s.thread);
    }

当前线程将state值减1,减少为0后,就表示线程释放了锁,就要唤醒后继节点,使得他可以获得锁,而这个后继节点的状态waitStatus小于0时才可以被唤醒

公平锁FairSync

Reentratlock公平锁的加锁流程

final void lock() {
          
   
            acquire(1);
        }

        /**
         * Fair version of tryAcquire.  Dont grant access unless
         * recursive call or no waiters or is first.
         */
        protected final boolean tryAcquire(int acquires) {
          
   
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
          
   
  //相比较而言,公平锁的流程在cas更新state前多了一个判断队列中是否有更高优先级的节点
                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,在lock方法中少了一步直接cas更新state的方法

2,在tryAcquire方法中加入了hasQueuedPredecessor判断

hasQueuedPredecessor判断如下

public final boolean hasQueuedPredecessors() {
          
   
        // The correctness of this depends on head being initialized
        // before tail and on head.next being accurate if the current
        // thread is first in queue.
        Node t = tail; // Read fields in reverse initialization order
        Node h = head;
        Node s;
        return h != t &&
            ((s = h.next) == null || s.thread != Thread.currentThread());
    }

这里的判断判断了两种情况

1,头节点的后续节点为空

2,AQS的持有锁线程不是当前线程

为第一种要判断呢??因为当一个节点要加入队列时有三步:

待插入节点pre指针指向尾节点 cas方式更新AQS尾指针 原尾节点的next指向新插入节点

第一个判断是为了排除前两步执行完成,但是第三步没完成的情况,也就是队列中除了头节点外,还有后续的第二个节点,它应该第二个获得锁,这种情况下,当前线程应该入队,等待锁。

第二个判断就是队列中有第二个节点且AQS持有锁的线程为其他线程

所以这个判断就是为了判断队列中是否有第二个节点,这个节点获取锁的优先级最高,应该让他先获得锁。

为什么要对第二节点做判断

由于底层实现为同步队列,队列也就是先进先出,越早进入队列的线程应该越先获得锁,这样才是公平合理的,但是在非公平模式下,我们知道它有两次cas方式去更新state值和更新AQS持有线程

在lock方法中首先就尝试去cas更新state值,更新成功的话,那么就获得锁成功 在nonfairTryAcquire方法中也有对state值cas方式去更新值的判断

那么这两次判断真的能获得锁吗?

在释放锁的流程中,线程将state更新为0,然后去唤醒后续节点,就是(LockSupport.unpark(s.thread))找到符合条件的节点解锁。

这就是两步,那么在多线程条件下,第一步执行完之后,此时恰好另外一个线程进入,看到state值为0,那么就可直接获得锁,更新完state和AQS持有线程后,就获得了锁。而这时刚刚解锁完的节点去唤醒的节点获取state值时发现不为0,继续阻塞等待,这也就造成了不公平。等的时间长不如进来的时间巧。从流程来说就是如下

那么在公平锁模式下,只要有第二节点的存在,后面进行的线程就必须要加入队列,而不能直接去cas的方式更新state值,对于多线程来说就是按加入时间长短来获取锁,也就实现了公平。

经验分享 程序员 微信小程序 职场和发展