Сегодня у меня было интервью, на котором я задал кандидату довольно обычный и основной вопрос о разнице между Thread.sleep() и Object.wait(). Я ожидал, что он ответит на что-то вроде как это, но он сказал, что эти методы в основном одно и то же, и, скорее всего, Thread.sleep использует Object.wait() внутри него, но sleep сам по себе не требует внешней блокировки. Это не совсем правильный ответ, потому что в JDK 1.6 этот метод имеет следующую подпись.
public static native void sleep(long millis) throws InterruptedException;
Но моя вторая мысль заключалась в том, что это не так уж смешно. Для достижения такого же эффекта можно использовать временное ожидание. Взгляните на следующий фрагмент кода:
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 имеет встроенную реализацию специально, поэтому мой вопрос в том, почему он использует собственные вызовы.
Единственная идея, которую я придумал, - это предположение, что кто-то может найти полезный вызов, например Thread.sleep(0). Это имеет смысл для управления планировщиком в соответствии с в этой статье:
Это имеет особый эффект очистки текущего кванта потока и перевода его в конец очереди на уровень приоритета. Другими словами, все запущенные потоки с одним и тем же приоритетом (и с более высоким приоритетом) получат возможность запускать до того, как заданный поток станет следующим заданным временем процессора.
Таким образом, блок synchronized даст ненужные накладные расходы.
Знаете ли вы какие-либо другие причины не использовать время ожидания в Thread.sleep() реализации?
