日志警告：检测到线程饥饿或时钟跳变（管家增量=springHikariConnectionPool）

Question

我正在使用 HikariCP 2.4.6，在 Tomcat 8 启动时，我收到一条警告消息：

01-Aug-2016 11:18:01.599 INFO [RMI TCP Connection(4)-127.0.0.1] org.apache.catalina.core.ApplicationContext.log Initializing Spring FrameworkServlet 'Spring MVC Dispatcher Servlet'
[2016-08-01 11:18:01,654] Artifact blueberry:war exploded: Artifact is deployed successfully
[2016-08-01 11:18:01,655] Artifact blueberry:war exploded: Deploy took 33,985 milliseconds
Aug 01 2016 11:26:52.802 AM [DEV] (HikariPool.java:614)
WARN : com.zaxxer.hikari.pool.HikariPool - 9m13s102ms - Thread starvation or clock leap detected (housekeeper delta=springHikariConnectionPool).

我没有从数据库中看到任何其他错误或问题 reading/writing。这有什么值得担心的吗？我试着四处寻找，但没有运气。

我们还在 MySQL 5 上使用 Hibernate 4.3.8.Final，MySQL 5.1.39 连接器与 Spring 4.1.0.RELEASE。我们正在努力升级到 Hibernate 5，看看这是否会消失，但不知道这是否重要。

Answer 1

有一个很好的 rundown 时钟跳跃检测可能合法发生的原因。引用 Brett Woolridge 的外部 link：

This runs on the housekeeper thread, which executes every 30 seconds. If you are on Mac OS X, the clockSource is System.currentTimeMillis(), any other platform the clockSource is System.nanoTime(). Both in theory are monotonically increasing, but various things can affect that such as NTP servers. Most OSes are designed to handle backward NTP time adjustments to preserve the illusion of the forward flow of time.

This code is saying, if time moves backwards (now < previous), or if time has "jumped forward" more than two housekeeping periods (more than 60 seconds), then something strange is likely going on.

A couple of things might be going on:

You could be running in a virtual container (VMWare, AWS, etc.) that for some reason is doing a particularly poor job of maintaining the illusion of the forward flow of time.

Because other things occur in the housekeeper thread -- specifically, closing idle connections -- it is possible that for some reason closing connections is blocking the housekeeper thread for more than two housekeeping periods (60 seconds).

The server is so busy, with all CPUs pegged, that thread starvation is occurring, which is preventing the housekeeper thread from running for more than two housekeeping periods.

Considering these, maybe you can provide additional context.

EDIT: Note that this is based on HikariCP 2.4.1 code. Make sure you are running the most up-to-date version available.

（貌似在最新代码的警告语句中更新了参数。）

Answer 2

另一个原因是，如果您运行在本地应用程序并且计算机进入睡眠状态，就会发生这种情况。在这种情况下，您不需要做任何明智的配置。

Answer 3

我在 AWS T2 micro 1GB RAM 实例中 spring 启动 MySQL 时遇到了这个问题。经过一个小时的努力，没有任何进展，观察到 CPU 使用率接近 100%。然后我制作了具有 4 GB RAM 和 2 vCPUs 的实例 T2 介质。之后我没遇到任何问题

Answer 4

当我在 Linux 机器上运行我的带有微服务的 spring 引导应用程序时，我遇到了同样的问题。经过一番调查发现，服务器只有8GB内存。将内存 (RAM) 增加到 16GB 解决了我的问题。

Answer 5

我遇到这个问题是因为实体的 hashCode 方法中存在无限循环。

两个实体有 OneToMany 关系，我正在使用 lombok @Data 注释，它通过为每个实体调用 hashCode() 方法来生成 equals 和 hashcode 实现本身导致无限循环的属性。

Answer 6

发生这种情况的另一个原因是 过度垃圾收集 ，而 垃圾收集 运行时间更长内务处理线程两次执行中的时间，试图释放一些内存（例如，恰好在应用程序线程是运行一个 'select' 查询时）。由于 GC 阻塞了包括管家线程在内的所有应用程序线程，因此我怀疑时钟因此而“跳跃”。

Answer 7

如果在您的 spring-boot 应用程序启动时发生这种情况

org.springframework.data.repository.config.RepositoryConfigurationDelegate : 
Bootstrapping Spring Data JPA repositories in DEFERRED mode.

然后运行您的应用程序具有以下程序参数

--spring.data.jpa.repositories.bootstrap_mode=default

日志警告：检测到线程饥饿或时钟跳变（管家增量=springHikariConnectionPool）

Log warning: Thread starvation or clock leap detected (housekeeper delta=springHikariConnectionPool)

hikaricp