问题描述
今天我接受了一次采访,我问候选人非常平常和基本的问题,关于 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:
所以 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 say1) what may have been in place and expected at the time the Thread class was first specified that way.and2) If that assertion works for every platform one may have ever wanted to implement a JVM on.
这篇关于Thread.sleep()实现的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!