Реализация Thread.sleep ()

Сегодня у меня было интервью, на котором я задал кандидату довольно обычный и основной вопрос о разнице между Thread.sleep () и ] Object.wait () . Я ожидал, что он ответит что-то вроде вроде этого , но он сказал, что эти методы в основном одно и то же, и, скорее всего, Thread.sleep использует Object.wait () внутри него, но сам спящий режим не требует внешней блокировки. Это не совсем правильный ответ, потому что в 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 знают о бритве Оккама, поэтому sleep специально имеет встроенную реализацию, поэтому у меня вопрос, почему он использует встроенные вызовы.

Единственная идея, которую я придумал, заключалась в предположении, что кто-то может найти полезный вызов вроде Thread.sleep (0) . Это имеет смысл для управления планировщиком согласно в этой статье:

Это имеет специальный эффект очистки кванта текущего потока и помещения его в конец очереди для его уровня приоритета. Другими словами, все выполняемые потоки с одинаковым приоритетом (и с более высоким приоритетом) получат возможность работать до того, как полученному потоку в следующий раз будет предоставлено процессорное время.

Таким образом, блок synchronized приведет к ненужным накладным расходам.

Знаете ли вы какие-либо другие причины отказа от использования ожидания по времени в реализации Thread.sleep () ?