HikariPool-1 - Thread starvation or clock leap detected与Hikari数据源配置

大家好，又见面了，我是你们的朋友全栈君。

目录

一、日志信息

二、Hikari

1）概述

2）数据源修改

3）pom.xml引用

4）yml数据源配置

5）运行正常

三、其他

一、日志信息
2019-02-04 12:10:51.494  WARN 14480 --- [l-1 housekeeper] com.zaxxer.hikari.pool.HikariPool        : HikariPool-1 
- Thread starvation or clock leap detected (housekeeper delta=7m48s317ms362µs591ns).
2019-02-04 12:48:17.254  WARN 14480 --- [l-1 housekeeper] com.zaxxer.hikari.pool.HikariPool        : HikariPool-1 
- Thread starvation or clock leap detected (housekeeper delta=7m25s798ms90µs273ns).
2019-02-04 13:19:38.276  WARN 14480 --- [l-1 housekeeper] com.zaxxer.hikari.pool.HikariPool        : HikariPool-1 
- Thread starvation or clock leap detected (housekeeper delta=1m21s77ms385µs775ns).
2019-02-04 14:05:35.244  WARN 14480 --- [l-1 housekeeper] com.zaxxer.hikari.pool.HikariPool        : HikariPool-1 
- Thread starvation or clock leap detected (housekeeper delta=4m27s7ms106µs449ns).
直译：HikariPool-1-检测到线程不足或时钟跳跃。

人话：检测到等待连接的时间过长，造成线程不足；或者检查测时钟跳跃

情况：

调试的时候，在定时任务中设了断点，停留时间较长，所以出现Thread starvation or clock leap detected，

直接搜索关键字Hikari、HikariPool

二、Hikari

1）概述

SpringBoot2中默认的数据已经更改为hikari，据说性能很高，有兴趣的可以进行测试。
目前使用最广泛的druid基础数组实现，而hikari则是基于threadlocal +CopyOnWriteArrayList实现。

2）数据源修改

查看官方文档，发现默认数据源修改了

3）pom.xml引用
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-jdbc</artifactId>
		</dependency>
4）yml数据源配置

添加：
type: com.zaxxer.hikari.HikariDataSource
spring:
  #数据源配置
  datasource:
    type: com.zaxxer.hikari.HikariDataSource
    url: jdbc:mysql://127.0.0.1:3306/dmw?createDatabaseIfNotExist=true&autoReconnect=true&default-character-set=utf8&&useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=GMT%2B8
    username: root
    password: root
    driver-class-name: com.mysql.cj.jdbc.Driver
  servlet:
    multipart:
      max-file-size: 50MB
      max-request-size: 100MB
  redis:
    # Redis数据库索引（默认为0）
    database: 6
    # Redis服务器地址
5）运行正常

三、其他

它在管家线程上运行，该线程每30秒执行一次。如果在Mac OS X上，clockSource是System.currentTimeMillis（），则任何其他平台上的clockSource是System.nanoTime（）。从理论上讲，两者都在单调增加，但是诸如NTP服务器之类的各种因素都可能影响到这一点。大多数操作系统旨在处理向后NTP时间调整，以保留对时间的前向错觉的幻想。

这段代码说的是，如果时间倒退（现在<以前），或者如果时间“跳跃”了两个以上的内务处理周期（超过60秒），那么可能会发生一些奇怪的事情。

可能正在发生一些事情：

您可能正在某个虚拟容器（VMWare，AWS等）中运行，由于某种原因，该容器在维持时间上的错觉方面做得特别差。

由于管家线程中发生了其他事情-特别是关闭空闲连接-出于某种原因，关闭连接可能会阻塞管家线程两个以上的维护周期（60秒）。

服务器太忙了，所有CPU都挂在了一起，以致发生线程不足，这导致管家线程无法运行两个以上的管家周期。

有用请点赞，养成良好习惯！

疑问、交流、鼓励请留言！