在文章https://chronicle.software/unique-timestamp-identifiers/之后,我检查了DistributedUniqueTimeProvider.currentTimeNanos方法的实现。
long time = provider.currentTimeNanos();
long time0 = bytes.readVolatileLong(LAST_TIME);
long timeN = timestampFor(time) + hostId;
if (timeN > time0 && bytes.compareAndSwapLong(LAST_TIME, time0, timeN))
return timeN;
return currentTimeNanosLoop();
默认情况下,它使用SystemTimeProvider
如果我们查看net.openhft.历史记录.核心.时间.系统时间提供者#当前时间纳米
long nowNS = System.nanoTime();
long nowMS = currentTimeMillis() * NANOS_PER_MILLI;
long estimate = nowNS + delta;
if (estimate < nowMS) {
delta = nowMS - nowNS;
return nowMS;
} else if (estimate > nowMS + NANOS_PER_MILLI) {
nowMS += NANOS_PER_MILLI;
delta = nowMS - nowNS;
return nowMS;
}
return estimate;
我们可以看到它使用了非易失性、非原子变量
private long delta = 0;
所以问题是:DistributedUniqueTimeProvider.currentTimeNanos到底是线程安全的吗?如果是,为什么?
1条答案
按热度按时间bzzcjhmw1#
值
delta
是挂钟和单调时钟之间差值的估计值。在最坏的情况下,在不同的线程中,这可能高达1 ms,因为总是至少有一次毫秒对纳秒的检查。但是,当与DistributedUniqueTimeProvider
一起使用时,DistributedUniqueTimeProvider
具有完整的内存屏障,并且它自己强制执行单调递增的值,它不会很明显放弃此内存屏障检查的原因是为了将此操作的成本降低约20%