当前位置: 首页 > 工具软件 > Java-monitor > 使用案例 >

java的锁池和等待池

贲招
2023-12-01

谢邀。不知道题中的一段文字出自何处。“锁池”和“等待池”这种翻译我还是头一回见。不过,题主的思路已经对了,即不拘泥于文字,而是在考虑这两个东西在锁的调度(即决定哪个线程可以获得锁的过程)中起到什么作用。

 

Java平台中,每个对象都有一个唯一与之对应的内部锁(Monitor)。Java虚拟机会为每个对象维护两个“队列”(姑且称之为“队列”,尽管它不一定符合数据结构上队列的“先进先出”原则):一个叫Entry Set(入口集),另外一个叫Wait Set(等待集)。对于任意的对象objectX,objectX的Entry Set用于存储等待获取objectX对应的内部锁的所有线程。objectX的Wait Set用于存储执行了objectX.wait()/wait(long)的线程。

 

设objectX是任意一个对象,monitorX是这个对象对应的内部锁,假设有线程A、B、C同时申请monitorX,那么由于任意一个时刻只有一个线程能够获得(占用/持有)这个锁,因此除了胜出(即获得了锁)的线程(这里假设是B)外,其他线程(这里就是A和C)都会被暂停(线程的生命周期状态会被调整为BLOCKED)。这些因申请锁而落选的线程就会被存入objectX对应的Entry Set(以下记为entrySetX)之中。当monitorX被其持有线程(这里就是B)释放时,entrySetX中的一个任意(注意是“任意”,而不一定是Entry Set中等待时间最长或者最短的)线程会被唤醒(即线程的生命周期状态变更为RUNNABLE)。这个被唤醒的线程会与其他活跃线程(即不处于Entry Set之中,且线程的生命周期状态为RUNNABLE的线程)再次抢占monitorX。这时,被唤醒的线程如果成功申请到monitorX,那么该线程就从entrySetX中移除。否则,被唤醒的线程仍然会停留在entrySetX,并再次被暂停,以等待下次申请锁的机会。

 

如果有个线程执行了objectX.wait(),那么该线程就会被暂停(线程的生命周期状态会被调整为WAITTING)并被存入objectX的Wait Set(以下记为waitSetX)之中。此时,该线程就被称为objectX的等待线程。当其他线程执行了objectX.notify()/notifyAll()时,waitSetX中的一个(或者多个,取决于被调用的是notify还是notifyAll方法)任意(注意是“任意”,而不一定是Entry Set中等待时间最长或者最短的)等待线程会被唤醒(线程的生命周期状态变更为RUNNABLE)。这些被唤醒的线程会与entrySetX中被唤醒的线程以及其他(可能的)活跃线程共同参与抢夺monitorX。如果其中一个被唤醒的等待线程成功申请到锁,那么该线程就会从waitSetX中移除。否则,这些被唤醒的线程仍然停留在waitSetX中,并再次被暂停,以等待下次申请锁的机会。

 

@刘方外

我理解调用对象的 notifyAll方法后,waitSet 上的线程都会加入到 entrySet 中的吧?在一个持有锁的线程释放锁后,应该只有 entrySet 队列的线程可能获取锁,那这个通知是 park 来实现的吗?是否有保证获取锁公平性的相关设置?

1、从Java虚拟机性能的角度来说,Java虚拟机没有必要在notifyAll调用之后“将Wait Set中的线程移入Entry Set”。首先,从一个“队列”移动到另外一个“队列”是有开销的,其次,虽然notifyAll调用后Wait Set中的多个线程会被唤醒,但是这些被唤醒的线程极端情况下可能没有任何一个能够获得锁(比如被其他活跃线程抢先下手了)或者即便可以获得锁也可能不能继续运行(比如这些等待线程所需的等待条件又再次不成立)。那么这个时候,这些等待线程仍然需要老老实实在wait set中待着。因此,如果notifyAll调用之后就将等待线程移出wait set会导致浪费(白白地进出“队列”)。这点可以参考显式锁的实现:

java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(Node, int)

 /**
     * Acquires in exclusive uninterruptible mode for thread already in
     * queue. Used by condition wait methods as well as acquire.
     *
     * @param node the node
     * @param arg the acquire argument
     * @return {@code true} if interrupted while waiting
     */
    final boolean acquireQueued(final Node node, int arg) {
        boolean failed = true;
        try {
            boolean interrupted = false;
            for (;;) {
                final Node p = node.predecessor();
                if (p == head && tryAcquire(arg)) {
                    setHead(node);
                    p.next = null; // help GC
                    failed = false;
                    return interrupted;
                }
                if (shouldParkAfterFailedAcquire(p, node) &&
                    parkAndCheckInterrupt())
                    interrupted = true;
            }
        } finally {
            if (failed)
                cancelAcquire(node);
        }
    }

从上面的代码可以看出,(使用显式锁时)被唤醒的线程获得锁(tryAcquire调用返回true)之后才被从wait set中移出(setHead调用)。

2、内部锁仅仅支持非公平锁调度。显式锁既支持公平锁又支持非公平锁。

LockSupport.park/upark是在jdk1.5开始引入的,显式锁的在实现线程的暂停和唤醒的时候会用到这个两个方法。而内部锁是在jdk1.5之前就已经存在的。

【参考资料】

1、黄文海.Java多线程编程实战指南(核心篇).电子工业出版社,2017

2、Inside the Java Virtual Machine: Thread Synchronization and the Java Monitor

3、Thread.State (Java Platform SE 7 )

转载于:https://www.cnblogs.com/tiancai/p/9371655.html

 类似资料: