常遇到的几种错误

Possibly consider using a shorter maxLifetime value

SpringCloud 中使用HikariPool 报错Possibly consider using a shorter maxLifetime value

HikariPool-1 - Failed to validate connection 
com.mysql.cj.jdbc.ConnectionImpl@115a8473 (No operations allowed after connection closed.). 
Possibly consider using a shorter maxLifetime value

Connection is not available, request timed out after xxxxxms

Connection is not available, request timed out after 59089ms

No operations allowed after connection closed

com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after connection closed

对于以上几种错误，我经过查阅，众说纷纭，大部分解决了的都是（并不是长久之计）

• 按照提示缩短了maxLifetime到5分钟
• 增加测试查询语句connection-test-query

来解决问题，并没有实际的分析问题根源或者优化其他配置项，经过查询相关文档、尝试、观察、测试，得出以下结论，给大家讲解，急于处理问题的可以参考下面的配置进行调整，注意标明的注释，可做适当调整，后文我将对常用的配置项进行讲解

常见配置及注释说明，可以使用并根据说明调整

spring:
  datasource:
    hikari: # 时间单位均为ms
      minimum-idle: 5 # 建议不设置，但如使用idle-timeout，该值需要小于maximum-pool-size
      maximum-pool-size: 10 # hikari做过测试根据CPU计算最优最大连接池，如下
      # connections = ((cpu_core_count * 2) + effective_spindle_count)
      # 如4-Core i7，公式为9 = ((4 * 2) + 1)，最后一个是有效的主核心数
      auto-commit: true # 默认
      idle-timeout: 300000 # 该值建议小于max-lifetime
      max-lifetime: 600000 # 该值建议小于数据库的连接关闭等待时间，详细的看下面分析
      connection-timeout: 30000 # 默认30s，连接超时会报异常
      # Connection is not avaitabte, request timed out after 59089ms
      validation-timeout: 5000 # 支持JDBC4的是isValid超时时间，不支持的是testQuery超时时间
      connection-test-query: 'SELECT 1' # 支持JDBC4的不建议使用，因为JDBC4的isValid方法效率更高

详细分析

HikariCP官方说明文档

首先确认网络问题

将数据库连接到本地（注意需要保持数据库的配置和线上一致，否则没有可比性，无法得出结论），并进行长时间运行测试，如果没有问题，则是由于网络原因链接超时，造成了关闭的连接本地调用失败、或创建连接超时无法使用，这种情况优化网络配置、增加带宽、将服务和数据库部署在同一网络下等方案即可

maximum-pool-size建议值

HikariCP对Pool-Sizing的论证及建议

hikari做过测试根据CPU计算最优最大连接池，详细的可以看链接的官方讲解，比较长，总结如下

• connections = ((cpu_core_count * 2) + effective_spindle_count)
• 如4-Core i7，公式为9 = ((4 * 2) + 1)，最后一个是有效的主核心数

minimum-idle

该值HikariCP建议不设置，就使用默认的，也就是同maximum-pool-size一边大，但是实际应用中可能需要保留少一些，随着业务的增加变到maximum-pool-size，而不是长期占用maximum-pool-size这么多的连接数。

• 所以可以设置一个比较小的、或者常态化下使用的连接量即可，建议5-10即可，不可大于maximum-pool-size

idle-timeout

连接允许在池中闲置的最长时间，默认为600000，即10分钟。只有当minimum-idle小于maximum-pool-size时，这个参数才生效，当空闲连接数超过minimum-idle，而且连接空闲时间超过idle-timeout，则会被移除。

• 设置时，该值建议小于max-lifetime

max-lifetime

官方建议是比数据库的wait_timeout小几秒，但是MySQL默认一般都是8小时，28800s（数据库单位是s秒），如下图

# 查看数据库的wait_timeout、interactive_timeout
show variables like '%timeout%';

所以设置有几种方式

• 根据数据的超时时长，减少一些时间，然后变为毫秒数，配置该值
• 使用默认值
• 使用小于默认值的，如5分钟、10分钟、15分钟等

但是该值一定要大于idle-timeout。

connection-timeout

连接池等待连接的最大毫秒数，默认为30000ms，也就是30s，允许最小时间是250毫秒，如果小于250毫秒，则被重置回30秒。

• 根据网络情况，处理器性能，服务可接受超时时长，配置合理的值即可
• 一般设置短一点，提高程序的响应速度，但是要大于网络的平均响应时长，否则全会连接超时
• 小于idle-timeout

# 出现这种错误一般就是连接超时了，检查网络响应时间、网络状态等
Connection is not avaitabte, request timed out after 59089ms

validation-timeout

支持JDBC4的驱动，是调用isValid验证连接池中连接有效性的超时时间
不支持JDBC4的驱动，是调用testQuery的超时时间

• 该值尽量小一些，使用默认值即可，但是要小于connection-timeout

connection-test-query

支持JDBC4的不建议使用，因为JDBC4的驱动有isValid方法，是通过发送数据包验证连接，效率更高
不支持JDBC4的驱动，是执行该配置的SQL，比较重，效率不好

• 如果没有配置该值，而且驱动不支持JDBC4，会有错误提示，所以没有配置，也没有提示isValid相关错误，即表示支持