Thread.sleep（）实现 [英] Thread.sleep() implementation
问题描述
今天我接受了一次采访，我问候选人非常平常和基本的问题，关于 Thread.sleep（）和 Object.wait之间的区别（）。我希望他回答像这样的问题，但他说这些方法基本上都是同样的事情，并且很可能 Thread.sleep 在其中使用 Object.wait（）但是 sleep 本身不需要外部锁定。这不是一个正确的答案，因为在JDK 1.6中，此方法具有以下签名。
Today I had an interview on which I asked candidate quite usual and basic question about the difference between Thread.sleep() and Object.wait(). I expected him to answer something like like this, but he said these methods basically are the same thing, and most likely Thread.sleep is using Object.wait() inside it, but sleep itself doesn't require external lock. This is not exactly a correct answer, because in JDK 1.6 this method have following signature.
public static native void sleep(long millis) throws InterruptedException;
但我的第二个想法是，这并不是那么荒谬。可以使用定时等待来实现相同的效果。看一下下面的代码片段：
But my second thought was that it's not that ridiculous. It's possible to use timed wait to achieve the same effect. Take a look at the following code snippet:
public class Thread implements Runnable {
private final Object sleepLock = new Object();
// other implementation details are skipped
public static void sleep(long millis) throws InterruptedException {
synchronized (getCurrentThread().sleepLock){
getCurrentThread().sleepLock.wait(millis);
}
}
在这种情况下 sleepLock 是一个对象，特别用于 sleep 方法中的同步块。我假设Sun / Oracle工程师知道Occam的剃须刀，所以 sleep 有故意本地实现，所以我的问题是为什么它使用本机调用。
In this case sleepLock is an object which is used particularly for the synchronization block inside sleep method. I assume that Sun/Oracle engineers are aware of Occam's razor, so sleep has native implementation on purpose, so my question is why it uses native calls.
我想出的唯一想法是假设某人可能会找到有用的调用，例如 Thread.sleep（0）。根据这篇文章：
The only idea I came up with was an assumption that someone may find useful invocation like Thread.sleep(0). It make sense for scheduler management according to this article:
这具有清除当前线程的量子并将其置于队列末尾以获得其优先级的特殊效果。换句话说，所有具有相同优先级的可运行线程（以及具有更高优先级的线程）将有机会在下一个给定CPU时间产生线程之前运行。
This has the special effect of clearing the current thread's quantum and putting it to the end of the queue for its priority level. In other words, all runnable threads of the same priority (and those of greater priority) will get a chance to run before the yielded thread is next given CPU time.
所以 synchronized 块将带来不必要的开销。
So a synchronized block will give unnecessary overhead.
您是否知道在 Thread.sleep（）实施中不使用定时等待的其他原因？
Do you know any other reasons for not using timed wait in Thread.sleep() implementation?
推荐答案
人们可以很容易地说Occam的Razor会削减其他方式。假定JDK底层的JVM的正常/预期实现在大多数情况下将java'threads'绑定到本机线程，并且将线程置于休眠状态是底层平台的基本功能。如果线程代码本来是原生的，为什么要在java中重新实现呢？最简单的解决方案是使用已存在的函数。
One could easily say Occam's Razor cuts the other way. The normal/expected implementation of the JVM underlying JDK is assumed to bind java 'threads' onto native threads most of the time, and putting a thread to sleep is a fundamental function of the underlying platform. Why reimplement it in java if thread code is going to be native anyway? The simplest solution is use the function that's already there.
其他一些注意事项：
现代JVM中无可争议的同步可以忽略不计，但并非总是如此。它曾经是一个相当昂贵的操作来获取该对象监视器。
Some other considerations: Uncontested synchronization is negligible in modern JVMs, but this wasn't always so. It used to be a fairly "expensive" operation to acquire that object monitor.
如果你在java代码中实现线程休眠，你实现它的方式也不会绑定对于本机线程等待，操作系统必须保持调度该线程，以便运行检查是否有时间唤醒的代码。正如评论中所说的那样，对于你在现代JVM上的例子来说显然不是这样，但是很难说
1）在Thread类首次被指定时可能已经存在和期望的那些办法。
和
2）如果该断言适用于每个平台，则可能曾经想要实现JVM。
If you implement thread sleeping inside java code, and the way you implement it does not also bind to a native thread wait, the operating system has to keep scheduling that thread in order to run the code that checks if it's time to wake up. As hashed out in the comments, this would obviously not be true for your example on a modern JVM, but it's tough to say 1) what may have been in place and expected at the time the Thread class was first specified that way. and 2) If that assertion works for every platform one may have ever wanted to implement a JVM on.
这篇关于Thread.sleep（）实现的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
