关于java:啃碎JDK源码八ReentrantLock

40次阅读

共计 4447 个字符,预计需要花费 12 分钟才能阅读完成。

前言

上一次咱们曾经讲了 AQS,如果对其不相熟的话倡议先去看看其实现原理,看完再来看ReentrantLock 就很简略了。

啃碎 JDK 源码 (一):String
啃碎 JDK 源码 (二):Integer
啃碎 JDK 源码 (三):ArrayList
啃碎 JDK 源码 (四):HashMap
啃碎 JDK 源码 (五):ConcurrentHashMap
啃碎 JDK 源码 (六):LinkedList
啃碎 JDK 源码(七):AbstractQueuedSynchronizer(AQS)

ReentrantLockSynchornized 在面试中常常被用来比拟,如果想理解 Synchronized 的话能够看我另外一篇文章: 死磕 Synchronized

注释

先来理解一下一些外围属性:

public class ReentrantLock implements Lock, java.io.Serializable {
// 实现 AQS 的外部类
private final Sync sync;
  ......
}

没错,ReentrantLock没有什么值得注意的属性,因为曾经在 AQS 中定义好了,咱们只须要继承它而后进行简略的实现即可。

先看下 ReentrantLock 的用法:

  public static void main(String[] args) {Lock lock = new ReentrantLock();
        lock.lock();
        try {
            // 执行业务
            Thread.sleep(1000);
        } catch (Exception e) {e.printStackTrace();
        } finally {lock.unlock();
        }
    }

只有调用 lock 办法就能够进行加锁操作,示意接下来的这段代码曾经被以后线程锁住,其余线程须要执行时须要拿到这个锁能力执行,而以后线程在执行完之后要显式的调用 unlock 开释锁。

留神:看源码之前你必须要对 AQS 比拟相熟才行,能够参考我上一篇博客:
啃碎 JDK 源码(七):AbstractQueuedSynchronizer(AQS)

咱们来跟进源码看一下,先来看咱们的加锁 lock 办法:

  public void lock() {sync.lock();
  }
  
  // Sync 继承了 AQS
  abstract static class Sync extends AbstractQueuedSynchronizer {abstract void lock();
     ......
  }
  

能够看到是调用外部类的 lock 办法,而它是一个形象办法,咱们看下谁继承了这个形象接口:

FairSyncNonfairSyncReentrantLock 的另外两个外部类。顾名思义一个是偏心锁,一个是非偏心锁。(偏心锁就是永远都是队列的第一位能力失去锁

AQS 有一个 同步队列 (CLH),是一种 先进先出队列 。偏心锁的意思就是 严格依照这个队列的程序来获取锁,非偏心锁的意思就是不肯定依照这个队列的程序来。

在 new 对象的时候便会对 sync 初始化,如下:

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

能够看出默认是非偏心锁,如果传 true 则初始化为偏心锁。

那咱们首先来看看非偏心锁:

  static final class NonfairSync extends Sync {
        private static final long serialVersionUID = 7316153563782823691L;

        final void lock() {
            // CAS 批改状态
            if (compareAndSetState(0, 1))
                // 设置独占线程
                setExclusiveOwnerThread(Thread.currentThread());
            else
                // 进入队列期待
                acquire(1);
        }
        // tryAcquire 是 AQS 的形象办法,咱们这里对其实现
        protected final boolean tryAcquire(int acquires) {return nonfairTryAcquire(acquires);
        }
    }    

首先用 compareAndSetState 办法应用 CAS 批改 state 状态变量的值,如果批改胜利的话应用 setExclusiveOwnerThread(Thread.currentThread()) 办法将以后线程设置为独占锁的持有线程,否则调用 AQS 的 acquire 办法进去队列期待解决。

接下来看一下 acquire 办法:

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

该办法是 AQS 里的办法,咱们上次曾经介绍过了,这里间接截过去看下:

这次咱们次要关注由子类 ReentrantLock 实现的 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");
                // 间接批改 state 遍历,因为曾经持有锁,不须要用 CAS 去批改
                setState(nextc);
                return true;
            }
            return false;
        }

下面代码和咱们在上次手动实现一个可重入锁的代码差不多,这里就不再开展。

那接下来看一下 unlock 办法:

   public void unlock() {sync.release(1);
   }
   
   public final boolean release(int arg) {
        // 尝试开释锁
        if (tryRelease(arg)) {
            Node h = head;
            if (h != null && h.waitStatus != 0)
                unparkSuccessor(h);
            return true;
        }
        return false;
    }

release 办法在 AQS 类中定义好了,咱们子类次要实现 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;
        }

这段代码上篇文章咱们也曾经讲过了,如果遗记的同学能够回头看看。

看完非偏心锁的最初来看看偏心锁的加锁办法:

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

其实代码根本和后面一样,只是多了 hasQueuedPredecessors 办法用来判断是否存在比期待更久的线程,因为要依照等待时间程序获取资源,其它的这里就不再细说了。

其它疑难

以下问题来自 从源码角度了解 ReentrantLock

为什么基于 FIFO 的同步队列能够实现非偏心锁?

由 FIFO 队列的个性知,先退出同步队列期待的线程会比后退出的线程更凑近队列的头部,那么它将比后者更早的被唤醒,它也就能更早的失去锁。从这个意义上,对于在同步队列中期待的线程而言,它们取得锁的程序和退出同步队列的程序统一,这显然是一种偏心模式。然而,线程并非只有在退出队列后才有机会取得锁,哪怕同步队列中已有线程在期待,非偏心锁的不偏心之处就在于此。回看下非偏心锁的加锁流程,线程在进入同步队列期待之前有两次抢占锁的机会:

  • 第一次是应用 compareAndSetState 办法尝试批改 state 变量,只有在以后锁未被任何线程占有 (包含本身) 时能力胜利。
  • 第二次是在进入同步队列前应用 tryAcquire(arg) 尝试获取锁。

只有这两次获取锁都失败后,线程才会结构结点并退出同步队列期待。而线程开释锁时是先开释锁 (批改 state 值),而后才唤醒后继结点的线程的。试想下这种状况,线程 A 曾经开释锁,但还没来得及唤醒后继线程 C,而这时另一个线程 B 刚好尝试获取锁,此时锁恰好不被任何线程持有,它将胜利获取锁而不必退出队列期待。线程 C 被唤醒尝试获取锁,而此时锁曾经被线程 B 抢占,故而其获取失败并持续在队列中期待。
那咱们在开发中为什么大多应用非偏心锁?很简略,因为它性能好啊。

为什么非偏心锁性能好

  1. 线程不用退出期待队列就能够取得锁,不仅 免去了结构结点并退出队列的繁琐操作,同时也节俭了线程阻塞唤醒的开销,线程阻塞和唤醒波及到线程上下文的切换和操作系统的零碎调用,是十分耗时的。。
  2. 缩小 CAS 竞争。如果线程必须要退出阻塞队列能力获取锁, 那入队时 CAS 竞争将变得异样强烈,CAS 操作尽管不会导致失败线程挂起,但一直失败重试导致的对 CPU 的节约也不能漠视。

总结

无关 ReentrantLock的常识就介绍到这里了,有什么不对的中央请多多指教。

正文完
 0