Дрейф nanoTime против currentTimeMillis

Измерения времени относительно начальной точки, взятой с помощью nanoTime, и currentTimeMillis расходятся максимум через три минуты.

Это касается реализаций JDK11++ для Windows, возможно, более ранних. Linux, похоже, не затронут. Поскольку наиболее вероятным виновником является Windows, и я считаю, что currentTimeMillis является стабильной функцией времени, пока nanoTime выключен, я хотел бы знать, как Java получает эти временные метки.

В Linux мы видим различия, связанные с тем, как мы масштабируем милли до нано. Различия хорошо заметны и находятся в пределах миллисекундной точности.

Поскольку оба значения вычисляются относительно соответствующих им начальных точек, взятых с разницей в несколько микросекунд, можно было бы подумать, что они остаются в пределах миллисекундной точности, как это происходит в Linux. Любые отклонения в такте таймера не должны иметь значения, поскольку таймер служит только для обеспечения медленной, читаемой последовательности измерений, где точное время не имеет значения.

import java.text.*;
import java.util.*;
import java.util.concurrent.*;

public class ClockWatch {

    static final long StartNS = System.nanoTime();
    static final long StartMS = System.currentTimeMillis();

    public static void main(String[] args) {
        NumberFormat nf = NumberFormat.getNumberInstance( Locale.US);
        nf.setMaximumFractionDigits( 3);
        nf.setGroupingUsed( true);

        DateFormat df = new SimpleDateFormat( "HH:mm:ss");
        df.setTimeZone( TimeZone.getTimeZone( "GMT"));
        ScheduledExecutorService ses = new ScheduledThreadPoolExecutor( 1);

        Runnable compareJob = () -> {
            long nowNS = System.nanoTime() - StartNS;
            long nowMS = System.currentTimeMillis() - StartMS;
            long tookNS = ( System.nanoTime() - StartNS) - nowNS;
            long diffNS = 1_000_000 * nowMS - nowNS;
            double driftPercent = 100.0 * diffNS / nowNS;
            System.out.println( df.format( new Date( nowMS))
                + " currentTimeMillis is "
                + ( diffNS < 0 ? "" : " ")
                + nf.format( 1e-6 * diffNS)
                + " ms faster than nanoTime, took "
                + nf.format( tookNS) + " ns, drift "
                + nf.format( driftPercent) + " % since start"
            );
        };
        ses.scheduleAtFixedRate( compareJob, 1, 3, TimeUnit.SECONDS);
    }
}

Причина, по которой меня это беспокоит, заключается в том, что я хочу повторно использовать существующую временную метку nano и преобразовать ее в эквивалент currentTimeMillis, не вызывая последнюю. Я знаю, под Windows на последнем оборудовании это занимает всего 4 нс.

Возможно, мне следует предоставить дополнительную информацию после прочтения комментариев. Я знаю о причудах nanoTime и currentTimeMillis. Возможно, я избавлюсь от обоих в пользу Instant.now, так что спасибо, что напомнили. Моя основная причина заключалась в том, что я хотел регистрировать события, используя log4j2 (настроенный с полной меткой времени). В один и тот же файл асинхронно входит множество потоков. Это одна из самых больших машин. При определенных обстоятельствах потоки журналирования могут засоряться, поскольку log4j не успевает за ними, тем самым замедляя потоки журналирования. Чтобы избежать этой проблемы, я переместил вызовы log4j в очередь, обслуживаемую другим потоком. Поскольку теперь я ожидал, что этот поток будет вызывать задержки в очереди, я хотел добавить к этим сообщениям журнала еще одну временную метку, отражающую время, когда они были добавлены в очередь журнала. Для этой внутренней временной метки у меня есть существующая нано-метка времени, которую я хотел повторно использовать таким образом, чтобы она соответствовала временной метке log4j как части шаблона сообщения журнала.

С тех пор я решил эту проблему, получив еще одну временную метку currentTimeMillis, но это потребовало добавления еще одного длинного поля и еще одного измерения, чего мне хотелось бы избежать. Поскольку мне нужно, чтобы мои измерения были совместимы с тем, что использует log4j, похоже, мне нужно поэкспериментировать с Instant.now прямо сейчас.