并发包学习之LockSupport，Condition,Object的notify

最新推荐文章于 2024-04-20 22:37:28 发布

hq091117

最新推荐文章于 2024-04-20 22:37:28 发布

阅读量325

点赞数

分类专栏： java并发编程文章标签：并发编程多线程

原文链接：https://blog.csdn.net/fcs_learner/article/details/83547908

版权

java并发编程专栏收录该内容

13 篇文章 0 订阅

订阅专栏

最近看了LockSupport，和condition，发现其作用好像都是用于线程阻塞唤醒，所以想整理下他们的区别

先说LockSupport特点

1，LockSupport定义了一组的公共静态方法，这些方法提供了最基本的线程阻塞和唤醒功能，而LockSupport也成为构建同步组件的基础工具。

2，LockSupport主要是有一组以park开头的方法用来阻塞当前线程，以及unpark(Thread thread)方法来唤醒一个被阻塞的线程。

3，LockSupport底层是用Usafe本地方法来实现阻塞与唤醒，LockSupport阻塞和唤醒线程直接操作的就是线程

4，不需要依赖监视器，与wait/notify没有交集，使用起来更加灵活方便

Object的唤醒与阻塞

1，任意一个Java对象，都拥有一组监视器方法（定义在java.lang.Object上），主要包括wait()、wait(long timeout)、notify()以及notifyAll()方法，这些方法与synchronized同步关键字配合，可以实现等待/通知模式。

Condition的阻塞与唤醒

1，Condition接口也提供了类似Object的监视器方法，与Lock配合可以实现等待/通知模式

2，ConditionObject是同步器AbstractQueuedSynchronizer的内部类，因为Condition的操作需要获取相关联的锁，所以作为同步器的内部类也较为合理。每个Condition对象都包含着一个队列（以下称为等待队列），该队列是Condition对象实现等待/通知功能的关键。

LockSupport与Object

Object类的wait/notify机制相比，park/unpark有两个优点：

以thread为操作对象更符合阻塞线程的直观定义
操作更精准，可以准确地唤醒某一个线程（notify随机唤醒一个线程，notifyAll唤醒所有等待的线程），增加了灵活性。

Condition与Object

condition需要与Lock配合，Object需要与synchronsized配合使用(不同点)
condition也属于监视器，Object的notify等方法也属于监视器(相同点)
condition是基于同步器实现的，Object是底层native本地方法

LockSupport与Condition

LockSupport一组静态方法，无需监视器，Condition是接口，依赖lock锁
Condition底层实现是同步器，也依赖了LockSupport和usafe

//condition的await方法
 public final void await() throws InterruptedException {
            if (Thread.interrupted())
                throw new InterruptedException();
            Node node = addConditionWaiter();
            int savedState = fullyRelease(node);
            int interruptMode = 0;
            while (!isOnSyncQueue(node)) {
//有用到LockSupport
                LockSupport.park(this);
                if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
                    break;
            }
            if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
                interruptMode = REINTERRUPT;
            if (node.nextWaiter != null) // clean up if cancelled
                unlinkCancelledWaiters();
            if (interruptMode != 0)
                reportInterruptAfterWait(interruptMode);
        }

具体的原理使用：

LockSupport：https://blog.csdn.net/z69183787/article/details/90676408

LockSupport：https://blog.csdn.net/z69183787/article/details/91825069

https://blog.csdn.net/fcs_learner/article/details/83547908