java并发包-Reentrantlock(二):tryLock与lockInterruptibly

（本文源代码完全来自openjdk1.8,欢迎对文中内容进行讨论指正）

1. lock.lockInterruptibly()

上一篇文章揭示了lock.lock()方法的工作原理，它在acquireQueued方法中设置了一个死循环，当线程从阻塞解除时，首先判断线程是否该竞争锁，如果是，则去竞争锁。竞争失败或者其它唤醒方式（如线程被中断）都会导致线程重新阻塞，这意味着lock方法屏蔽了中断，无法对其相应。lockInterruptibly的实现非常类似于上述方法，只是在由lockInterruptibly方法调用的的doAcquireInterruptbly()方法中,不再屏蔽中断，检测到中断则抛出中断异常，使方法能够从死循环中退出，代码如下:

//这个方法干的工作与acquireQueued非常类似，可以参见上一篇文章
private void doAcquireInterruptibly(int arg)
        throws InterruptedException {
        final Node node = addWaiter(Node.EXCLUSIVE);
        boolean failed = true;
        try {
            for (;;) {
                final Node p = node.predecessor();

//如果头结点是自己的前继节点，就参与竞争锁(FIFO,轮到自己了)
//但是在非公平锁的实现中有插队行为，因此只能是竞争而不能保证获得
//即使是公平锁的实现，也有被tryLock()方法插队的可能,下面会分析此方法
                if (p == head && tryAcquire(arg)) {
                    setHead(node);
                    p.next = null; // help GC
                    failed = false;
                    return;
                }
 //parkAndCheckInterrupt方法放回当前线程是否被中断了
 //acquireQueued方法仅仅是注册一个变量记录是否中断，之后仍需回归死循环重新阻塞
 //但在此处将会抛出一个中断异常，提供另一条离开死循环的方式
                if (shouldParkAfterFailedAcquire(p, node) &&
                    parkAndCheckInterrupt())
                    throw new InterruptedException();
            }
        } finally {
//如果线程尚未获取到锁，那么将线程的排队状态取消
            if (failed)
                cancelAcquire(node);
        }
    }

像这样，lockInterruptbily提供了两条解除阻塞的方式，一是线程正常获取锁，正常返回；二是线程在排队时被中断了，线程抛出异常离开阻塞代码.

2.lock.tryLock()

tryLock方法不会阻塞，只会做一次获取锁的尝试，如果当前能够获取锁返回true，否则返回false，因此tryLock必定是一次插队行为（不然就意味着排队，就需要阻塞，与tryLock方法需要实现的要求不符合）,由此不难想到tryLock方法会调用一次非公平tryAcquire(),查看源代码，也确实如此,到了这里我们也可以明白以下这几个方法为什么会这样实现:
Sync实现nonfairTryAcquire方法,FairSync实现自己的tryAcquire方法，而NonFairSync实现的tryAcquire方法只有一个逻辑就是调用Sync的nonfairTryAcquire方法。
这是因为在公平锁的实现中，也允许插队行为（tryLock方法导致插队），如果nonFairTryAcquire写在NonFairSync类中，那么FairSync的实现中不得不添加与其完全一样的代码以实现tryLock的插队行为.

//如下，tryLock方法进行一次插队测试，返回此次插队抢占锁是否成功
public boolean tryLock() {
        return sync.nonfairTryAcquire(1);
    }

3.boolean tryLock(long time, TimeUnit unit) throws InterruptedException;

这个方法在指定时间内等待获取锁，与tryLock非常类似，来看它在jdk源码中的实现:

  public boolean tryLock(long timeout, TimeUnit unit)
            throws InterruptedException {
        return sync.tryAcquireNanos(1, unit.toNanos(timeout));
    }

同样是将行为代理给了内部类对象sync，sync对象将会调用父类AQS中的方法tryAcquireNanos()

public final boolean tryAcquireNanos(int arg, long nanosTimeout)
            throws InterruptedException {
        if (Thread.interrupted())
            throw new InterruptedException();
        return tryAcquire(arg) ||
            doAcquireNanos(arg, nanosTimeout);
    }

这个方法第一步检查当前线程是否中断了，如果是，就抛出一个中断异常，客户程序员可以处理此异常，否则，先tryAcquire()一次（如果是公平锁，判断自己是否有资格竞争锁再去竞争，非公平锁直接尝试抢占一次）,如果锁获取成功，就能够返回true;否则执行doAcquireNanos()方法

private boolean doAcquireNanos(int arg, long nanosTimeout)
        throws InterruptedException {
        long lastTime = System.nanoTime();
        final Node node = addWaiter(Node.EXCLUSIVE);
        boolean failed = true;
        try {
            for (;;) {
                final Node p = node.predecessor();
                if (p == head && tryAcquire(arg)) {
                    setHead(node);
                    p.next = null; // help GC
                    failed = false;
                    return true;
                }
                if (nanosTimeout <= 0)//超时了
                    return false;
                if (shouldParkAfterFailedAcquire(p, node) &&
                    nanosTimeout > spinForTimeoutThreshold)//是否大于自旋时间
                    LockSupport.parkNanos(this, nanosTimeout);
                long now = System.nanoTime();
                nanosTimeout -= now - lastTime;
                lastTime = now;
                if (Thread.interrupted())
                    throw new InterruptedException();
            }
        } finally {
            if (failed)
                cancelAcquire(node);
        }
    }

上述代码与acquireQueued方法以及doAcquireInterruptibly方法干着几乎同样的逻辑，不再赘述,只是多了一项时间判断罢了。可能比较难以理解的是这么一个判断:
nanosTimeout > spinForTimeoutThreshold
判断获取时间是否大于自旋时间。这说明在限时版本tryLock方法实现了自旋锁。
先查看该变量定义:
static final long spinForTimeoutThreshold = 1000L;
默认自旋时间为1000ms.那么，自旋锁是什么？
通常情况下，当一个线程竞争锁失败的时候，它将会被挂起,操作系统会为其保存相应的值,待到锁被释放，它将被唤醒重新占据cpu运行，线程间的切换需要较大的时空资源耗费。而且比较糟糕的情况可能是线程刚被挂起就被唤醒，线程的切换造成了浪费。自旋锁意味着在线程获取锁失败时,并不挂起，而是继续占据cpu运行（可以通过运行一些无意义的指令或是循环），然后轮询锁是否被占据，如果锁在此时被释放，那么该线程可以立即竞争锁，少去了线程挂起，唤醒的开销。当某个方法占据锁时间比较短就释放时，自旋锁无疑能提供很好的性能。
在此处代码，线程将在规定的时间内使用自旋(也有自旋一定次数的实现)，（上述比较返回false，线程不会进入LockSupport.parkNanos阻塞，而是因为死循环回归是否获取锁并竞争锁的判断，直至超过自旋要求的时间），超时的时候则需要将线程挂起。最后该方法返回是否获取到锁或者抛出一个中断异常表示在此过程中被人中断.

4.lock系列方法小结

本篇所描述的lockInterruptibly,trylock,定时trylock方法与上篇的lock实现的思想基本一致,但需要注意的有：
1.可中断的lockInterruptibly实际上只是在死循环中增加了一条抛出中断异常的跳出路径来响应中断请求，普通的lock只能通过获取锁而解除阻塞(或者发生上一篇所描述的奇怪情况？比如虚拟机抛个exception或error?),从而屏蔽中断
2.无论ReenTrantlock是公平的还是非公平的，tryLock方法都会使用不公平的抢占锁的方式
3.限时版的tryLock并不是在一段时间内循环调用普通的tryLock。首先，它会受到公平或不公平锁的影响，从而进行一次公平/非公平的抢占，之后将会按照FIFO顺序等到自己变成队列头来竞争锁,在规定时间内优先自旋，超过自旋时间将会被挂起。
理解了上篇的lock()方法实现，这3个方法可谓是手到擒来。