Java时间不同步

Question

最近，我遇到了一个非常奇怪的错误，我无法在本地重现。它发生在 Spring Boot 应用程序内的服务器 (CentOS) 上。

调用 new Date() (java.util.Date) 产生错误的时间。而且我不是在谈论由于不同时区而导致的小时差异。日期时间偏离 X 分钟。似乎在现在的时代后头，也渐渐开始缺乏了。

当获取当前系统时钟时间时，它似乎是正确的，但 Java 时间正在逐渐增加差异(不是每分钟增加一分钟，而是更慢)。几乎就像 JVM 存在于具有不同时间法则的某个时间泡中。

在长时间运行没有任何问题后，今天意外开始出现此问题。

有人可以建议我应该尝试调试这个问题吗？我一无所知，无法在本地复制这个问题(一切都在本地机器上运行)。

编辑:正如我刚刚发现的那样，服务器正在虚拟化 VM 堆栈上运行。不过，我不确定具体的硬件配置。

EDIT2:我想我发现了有问题的部分。导致此问题的组件在线程池中运行，因此我怀疑池中的所有线程都很忙并且请求排队，因此处理我正在设置当前时间戳的请求的时间逐渐增加。

例子:

@Async
public Date sendTimeToOtherServer() {
  Date date = new Date()
  // code that sends the date to different server
}

Answer 1

Java 通过系统调用从操作系统获取时间。这应该反过来从硬件时钟获取时间。

现在硬件时钟可以漂移。当您运行虚拟机时，硬件时钟可能会被虚拟框架模拟，并且可能会比您预期的漂移更多。这可能取决于您的 VM 上的负载……或来自您的 VM 的虚拟机管理程序的负载以及计算硬件上的其他负载。

但解决方案可能是使用 NTP 实用程序将 VM 的系统时钟与可靠的离线时间服务同步。

I increased the thread pool size and it started acting correctly so it must be this bottleneck in the thread pool

您可能过早地在这里下结论。 FWIW，我从未听说过时钟精度取决于 Java 线程池的大小。

---

What I meant is, that it probably took some time for the thread pool to be ready to provide some thread to handle my task in which I was calling new Date().

啊。我懂了。好吧，如果您在工作线程中捕获请求开始时间并且池中没有足够的线程，那么您使用 new Date() 得到的很可能是准确的 时间戳(相对于系统时钟)；即时间不会不同步。

但问题是在这种情况下增加线程池大小是否是一件好事。请求开始时间延迟是因为工作人员太少还是请求率太高？

• 在前一种情况下，增加池大小是正确的做法。

• 在后一种情况下，它不会有太大帮助，而且可能会使事情变得更糟。

吞吐量的最终限制因素将是核心数量、内存大小、数据库性能、网络带宽等因素。增加线程池可能允许并行处理更多请求。但是，如果您已经资源匮乏，这不会增加请求处理率。事实上，过多的工作线程会导致:

• 增加内存使用和 GC 负载，以及
• 个别请求花费的时间太长，以至于客户端超时。