Не знаю, применимо ли это, но ...
Проблема с Windows заключается в том, что если вы измените разрешение таймера с помощью timeBeginPeriod () , часы будут дрейфовать.
На самом деле, существует ошибка в реализации Java-функции Thread wait()
(и os::sleep()
) для Windows, которая вызывает такое поведение. Он всегда устанавливает разрешение таймера равным 1 мс перед ожиданием, чтобы быть точным (независимо от продолжительности ожидания), и восстанавливает его сразу после завершения, если другие потоки еще не спят. Этот набор / сброс затем запутает часы Windows, которые ожидают, что квант времени Windows будет довольно постоянным.
Sun фактически знает об этом с 2006 года и не исправил это, УЖАС!
Из-за этого у нас на самом деле часы шли в два раза быстрее! Простая Java-программа, которая спит 1 миллисекунд в цикле, демонстрирует это поведение.
Решение состоит в том, чтобы установить временное разрешение самостоятельно на что-то низкое и сохранять его там как можно дольше. Используйте timeBeginPeriod () для управления этим. (Мы установили его на 1 мс без каких-либо побочных эффектов.)
Для тех, кто занимается кодированием на Java, проще всего это исправить, создав поток, который спит до тех пор, пока приложение живет.
Обратите внимание, что это решит эту проблему на машине в целом, независимо от того, какое приложение является фактическим виновником.