java线程Hibernate解析和等待同步块

Question

我想更多地了解线程睡眠解析是如何工作的，以及它与睡眠（）解析之外的内容有什么联系。

我知道它是由操作系统定义的，而在Windows上通常是15ms。我最近环顾四周无法确认这一点，但我依稀记得这个15ms是由操作系统循环的，并且对所有线程都是“全局的”，这意味着15ms不是线程可以Hibernate的最短时间，而是最大Hibernate时间（1）。对吗？所有操作系统都一样吗（超过持续时间）？

我想不出这很重要的情况，但是线程的虚假唤醒是否总是发生在这个睡眠周期的动作点，或者它可能随时发生？

在同步块上，等待线程是否在每个周期有效地Hibernate（1）并检查锁，或者退出块的线程是否立即唤醒等待线程？这对所有操作系统都一样吗？

当线程在 wait（） 之后被 notify（）-ed 时，在等待锁定时，它会以与上面相同的方式处理，还是以不同的方式处理？

从性能角度来看，15ms循环是否还有其他时间是相关的？

Answer 1

< code>Thread.sleep()的实现取决于操作系统。

睡眠的粒度通常受到线程调度器的中断周期的限制。在Linux中，这个中断周期在最近的内核(2.6.8以后)中通常是1ms。在Windows中，调度程序的中断周期通常在10或15毫秒左右(我相信这是由处理器决定的)，但是在软件中可以请求更长的周期，Hotspot JVM会在它认为必要时这样做。

Answer 2

您需要对多线程内核进行一些研究。

线程的虚假唤醒会一直发生在这个睡眠周期的动作点，还是会随时发生？

没有虚假的sleep()唤醒或者任何内核同步对象在Windows上等待——根本没有。任何这样的趋势都已经在内核中设计好了，不会传播到用户线程。

如果线程正在Hibernate或等待某个同步对象（如互斥锁或信号量锁），则它根本不会运行 - 它只是内核中队列上的死“线程描述符对象”，因此所有与线程相关的东西，堆栈的数据空间等。在睡眠的情况下，TDO 位于所有超时线程的“增量队列”上，按唤醒时间排序，操作系统每 15 毫秒检查一次此队列开头的项目。在定时锁定等待的情况下，TDO 位于两个队列上 - 超时队列和锁拥有的队列。TDO 将到达计时器队列的头部并在其间隔结束时准备就绪，或者另一个线程将释放锁并使线程准备就绪。无论哪个先到达那里，都会获胜，并且TDO将从另一个队列中删除。然后，新就绪的线程将加入就绪线程集，如果内核可用或可以抢占优先级较低的线程，则将新就绪的线程调度到内核上。

因此，Windows上的“15毫秒”是由所有线程共享的。Windows是一个桌面操作系统，15毫秒超出了人类的直接感知，因此99.9%的家庭线程都不在乎，因为它们只需要很长的超时，正在等待I/O，正在等待一些线程间通信锁或它们的某种组合。

“从性能的角度来看，15ms循环还有其他时间吗？”

不多。计时器重新安排的副作用是，如果最高优先级的可运行线程集大于可用于运行它们的内核数，则该集以循环方式运行，因为这些线程的列表是轮换的。这仅与定期过载的机器相关，并且大多数线程仅使用计时器间隔来超时其他阻塞系统调用。