• java的锁池和等待池


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

    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 )

  • 相关阅读:
    个人期末总结
    团队冲刺第二阶段10
    团队冲刺第二阶段9
    团队冲刺第二阶段8
    团队冲刺第二阶段7
    团队冲刺第二阶段6
    数据分析之例题
    数据分析之数据操作
    数据分析之Matplotlib可视化
    数据分析之Pandas
  • 原文地址:https://www.cnblogs.com/tiancai/p/9371655.html
Copyright © 2020-2023  润新知