LockSupport

  • 时间:
  • 浏览:0

park最好的最好的办法 还都不能 在可是 任哪年间“毫无理由”地返回,否则 通常都不能在重新检查返回条件的循环里调用此最好的最好的办法 。从你这种 意义上说,park 是“忙碌等待时间”的并全是优化,它不不浪费没法 多的时间进行自旋,否则 都不能将它与unpark配对使用才更高效。

否则 线程的permit所处,没法 线程不不被挂起,立即返回;否则 线程的permit不所处,认为线程缺少permit,可是 都不能挂起等待时间permit。

挂起与阻塞主要的区别应该说是它们面向的对象不同。对线程来说, LockSupport的park/unpark更符合阻塞和唤醒的语义,我们都以“线程”作为最好的最好的办法 的参数,语义更清晰,使用起来也更方便。而wait/notify使“线程”的阻塞/唤醒对线程并全是来说是被动的,要准确的控制哪个线程、哪几个刚刚阻塞/唤醒是很困难的,可是 是要么随机唤醒1个 线程(notify)要么唤醒所有的(notifyAll)。

从上端表格都不能 看出,park支持blocker对象作为参数。此blocker对象在线程受阻塞时被记录,可是 监视工具和诊断工具就都不能 选取线程受阻塞的原困 。建议最好使用哪几个带blocker的最好的最好的办法 版本,而全是不带blocker参数的最好的最好的办法 。

以下伪代码是pack的常用模型。

指定了1个 挂起时间(相对于当前的时间),时间到后自动被唤醒;类似50纳秒后自动唤醒

park()

park和unpark最好的最好的办法 不什么都没法先Thread.suspend和Thread.resume的死锁现象。这有无则 许可的所处,调用park的线程和可是 试图将其unpark的线程之间的将没法 竞争关系。此外,否则 线程被中断否则 超时,则park将返回。

parkNanos(Object, long)

和park(Object)相比少了挂起前为线程设置blocker、被唤醒后清理blocker的操作。

parkUntil(long)

Basic thread blocking primitives for creating locks and other synchronization classes.

指定1个 挂起时间(绝对时间),时间到后自动被唤醒;类似2018-02-12 21点整自动被唤醒。

和parkUntil(Object, long)类似,仅少了blocker相关的操作

否则 许可所处,没法 将你这种 许可使用掉,否则 立即返回。否则 许可不所处,没法 挂起当前线程,直到以下任意一件事情所处:

parkUntil(Object, long)

LockSupport是用于创建锁和可是 同步类的阻塞原语。以下是jdk对LockSupport的描述。

主要功能:

设置线程许可为可用。

否则 线程的permit不所处,没法 释放1个 permit。否则 有permit了,可是 否则 线程所处挂起情況,没法 此线程会被线程调度器唤醒。否则 线程的permit所处,permit可是 会累加,看起来想哪几个事都没做一样。注意你这种 点和Semaphore是不同的。

以下是ReentrantLock中pack的使用代码

LockSupport通过许可(permit)实现挂起线程、唤醒挂起线程功能。都不能 按照以下逻辑理解:

在《ReentrantLock详解》(地址:https://yq.aliyun.com/articles/450711)中分析源码的刚刚,我们都就否则 多次提到使用LockSupport的pack挂起线程,unpack唤醒被挂起的线程,此博客将详述LockSupport的原理以及实现。

和parkNanos(Object, long)类似,仅少了blocker相关的操作

park(Object)

挂起当前线程,具体见上端pack的源码分析

LockSupport中pack有多个版本,如下所示:

parkNanos(long)