lock锁的底层实现

       上一篇博文中我大致讲解了一下lock锁与sychronized的区别及它们各自的应用优劣,那么是什么造成它们各自应用上的偏向呢,这当然取决于它们的底层实现,所以今天我们就先来看一下lock锁的底层原理吧,因为lock锁的底层实现这块内容比较多,所以sychronized我会再写一篇博文和大家分享~

       Lock锁通过Java编写,与JVM实现无关。

       在J.U.C.locks包中有很多lock的实现类,常用的有重入锁ReentrantLock,读写锁ReadWriteLock,它们的实现都依赖于都依赖java.util.concurrent.AbstractQueuedSynchronizer类,它们的实现过程相差不多,首先我们来看一下ReentrantLock是怎样实现的。

       经过观察ReentrantLock把所有Lock接口的操作都委派到一个Sync类上,该类继承了AbstractQueuedSynchronizer

static abstract class Sync extends AbstractQueuedSynchronizer  

       Sync又有两个子类:

//公平锁与非公平锁
final static class NonfairSync extends Sync  
final static class FairSync extends Sync  

       我们来通过源码看一下ReentrantLock的调用过程,首先来看一下它的构造方法:

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

       很简单,次构造方法是对非公平锁构造器的引用,这也说明了ReentrantLock默认是非公平锁的,再来看一下非公平锁:

static final class NonfairSync extends Sync {
        private static final long serialVersionUID = 7316153563782823691L;
        final void lock() {
            if (compareAndSetState(0, 1))
                setExclusiveOwnerThread(Thread.currentThread());
            else
                acquire(1);
        }
        protected final boolean tryAcquire(int acquires) {
            return nonfairTryAcquire(acquires);
        }
    }
       NonfairSync是一个静态内部类,ReentrantLock.lock函数中,会调用到NonfairSync.lock方法,首先会通过CAS方法,尝试将当前的AQS中的state字段改成从0改成1,如果修改成功的话,说明原来的状态是0,并没有线程占用锁,而且成功的获取了锁,只需要调用setExclusiveOwnerThread函将当前线程设置成持有锁的线程即可。否则,CAS操作失败之后,和普通锁一样,调用acquire(1)函数尝试获取锁。而在试图获取锁的方法中,nonfairTryAcquire方法被调用,该方法会首先判断当前状态,如果c==0说明没有线程正在竞争该锁,如果不c !=0 说明有线程正拥有了该锁。如果发现c==0,则通过CAS设置该状态值为acquires,acquires的初始调用值为1,每次线程重入该锁都会+1,每次unlock都会-1,但为0时释放锁。如果CAS设置成功,则可以预计其他任何线程调用CAS都不会再成功,也就认为当前线程得到了该锁,也作为Running线程,很显然这个Running线程并未进入等待队列。如果c !=0 但发现自己已经拥有锁,只是简单地++acquires,并修改status值,但因为没有竞争,所以通过setStatus修改,而非CAS,也就是说这段代码还实现了偏向锁的功能,下面是该方法的源码:
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;
        }
       了解了这些,我们再来看一下Reentrant.lock()方法的调用过程:


       上面我们讲了tryAcquire()方法,接下来我们在看一下addWaiter的实现:

private Node addWaiter(Node mode) {
        Node node = new Node(Thread.currentThread(), mode);
        // Try the fast path of enq; backup to full enq on failure
        Node pred = tail;
        if (pred != null) {
            node.prev = pred;
            if (compareAndSetTail(pred, node)) {
                pred.next = node;
                return node;
            }
        }
        enq(node);
        return node;
    }

       addWaiter方法负责把当前无法获得锁的线程包装为一个Node添加到队尾,其中参数mode是独占锁还是共享锁,默认为null,独占锁。追加到队尾的动作分两步:
1)如果当前队尾已经存在(tail!=null),则使用CAS把当前线程更新为Tail
2)如果当前Tail为null或则线程调用CAS设置队尾失败,则通过enq方法继续设置Tail
       下面是enq方法:

private Node enq(final Node node) {
        for (;;) {
            Node t = tail;
            if (t == null) { // Must initialize
                if (compareAndSetHead(new Node()))
                    tail = head;
            } else {
                node.prev = t;
                if (compareAndSetTail(t, node)) {
                    t.next = node;
                    return t;
                }
            }
        }
    }

        该方法就是循环调用CAS,即使有高并发的场景,无限循环将会最终成功把当前线程追加到队尾(或设置队头)。总而言之,addWaiter的目的就是通过CAS把当前线程追加到队尾,并返回包装后的Node实例把线程包装为Node对象的主要原因,除了用Node构造供虚拟队列外,还用Node包装了各种线程状态,这些状态被精心设计为一些数字值:

  • SIGNAL(-1) :线程的后继线程正/已被阻塞,当该线程release或cancel时要重新这个后继线程(unpark)
  • CANCELLED(1):因为超时或中断,该线程已经被取消
  • CONDITION(-2):表明该线程被处于条件队列,就是因为调用了Condition.await而被阻塞
  • PROPAGATE(-3):传播共享锁
  • 0:0代表无状态

       简单说来,AbstractQueuedSynchronizer会把所有的请求线程构成一个CLH队列,当一个线程执行完毕(lock.unlock())时会激活自己的后继节点,但正在执行的线程并不在队列中,而那些等待执行的线程全部处于阻塞状态,经过调查线程的显式阻塞是通过调用LockSupport.park()完成,而LockSupport.park()则调用sun.misc.Unsafe.park()本地方法,再进一步,HotSpot在Linux中中通过调用pthread_mutex_lock函数把线程交给系统内核进行阻塞。

       CLH队列实现加锁的过程示意图如下:

       与synchronized相同的是,这也是一个虚拟队列,不存在队列实例,仅存在节点之间的前后关系。令人疑惑的是为什么采用CLH队列呢?原生的CLH队列是用于自旋锁,但Doug Lea把其改造为阻塞锁。当有线程竞争锁时,该线程会首先尝试获得锁,这对于那些已经在队列中排队的线程来说显得不公平,这也是非公平锁的由来,与synchronized实现类似,这样会极大提高吞吐量。如果已经存在Running线程,则新的竞争线程会被追加到队尾,具体是采用基于CAS的Lock-Free算法,因为线程并发对Tail调用CAS可能会导致其他线程CAS失败,解决办法是循环CAS直至成功。

    至此我们已经从源码的角度对Lock锁的实现依次进行了分析,希望大家都能对Lock锁有更深的了解,这样我们不仅可以在面试中应对自如,而且对我们在日常学习中解决高并发问题也会有很大的帮助~

阅读更多
文章标签: Lock锁的底层实现
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

不良信息举报

lock锁的底层实现

最多只允许输入30个字

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭