переход в спящий режим с использованием java.time.Продолжительность

#java-8

Вопрос:

Я работаю в java8 и хотел бы использовать class java.time.Duration для настройки времени ожидания. Как я понимаю, продолжительность состоит из секунд и наносекунд. Таким образом, время ожидания должно быть эквивалентно ожиданию:

 java.util.concurrent.TimeUnit.SECONDS.sleep(long);
java.util.concurrent.TimeUnit.NANOSECONDS.sleep(long);

Правильно ли мое занижение?

1. Не имеет значения, из чего Duration состоит объект, если он поддерживает удобные методы преобразования для любых целей. Таким образом, вы можете использовать, например, один LockSupport.parkNanos(duration.toNanos());

Ответ №1:

Функциональность TimeUnit.sleep обеспечивает только миллисекундную детализацию для перехода в спящий режим. Он перенаправляет на Thread.sleep, и наносекунды игнорируются.

     public static void sleep(long millis, int nanos)
    throws InterruptedException {
        if (millis < 0) {
            throw new IllegalArgumentException("timeout value is negative");
        }

        if (nanos < 0 || nanos > 999999) {
            throw new IllegalArgumentException(
                                "nanosecond timeout value out of range");
        }

        if (nanos >= 500000 || (nanos != 0 amp;amp; millis == 0)) {
            millis  ;
        }

        sleep(millis);
    }

Если вам нужно что-то более надежное, взгляните на LockSupport.parkNanos . Вы должны быть в состоянии получить что-то вроде детализации 50us для вашего сна в Linux.

https://hazelcast.com/blog/locksupport-parknanos-under-the-hood-and-the-curious-case-of-parking/

1. Если вы действительно сумасшедший или у вас был учитель-садист, вы можете рассчитать временную задержку непосредственно в результате количества инструкций, их количества циклов и тактовой частоты вашего процессора / ipc

2. @Rogue и затем происходит переключение задач, из-за чего ваш поток выполняется намного позже, чем рассчитано. Или parkNanos возвращается раньше без причины, как это разрешено, но проверка фактического прошедшего времени займет больше циклов, чем разница с предполагаемым временем ожидания…

3. Проверка наносекундного времени будет составлять от 15 до 30 мс.

4. Вы можете использовать привязку к процессору, чтобы контролировать, какие потоки выполняются на каких ядрах. Если вы хотите, вы даже можете изолировать ядра от общего использования ОС. github.com/OpenHFT/Java-Thread-Affinity Это предотвратило бы / уменьшило бы нежелательные переключения контекста.

5. Но тогда у вас все еще нет реального контроля над временем выполнения кода Java, который подлежит JIT-компиляции и оптимизации во время выполнения. Чем больше усилий вы тратите на повышение точности, тем меньше фактический выигрыш.