本文链接：https://blog.csdn.net/architect_cloud/article/details/104310782

最近在使用springboot2.x 时遇到了一个很奇怪的问题，一段时间内不使用redis连接和HikariPool连接池控制台会显示超时，重新连接，影响应用的正常访问。

HikariPool连接池超时问题

错误如下：
HikariPool-1 - Connection is not available, request timed out after XXXms.

出现问题的第一时间，我找度娘查了一下，网上给出的问题以及解决方案如下：

检查连接池泄漏
在数据源配置时缺少配置validationTimeout属性，或者validationTimeout属性值配置过大
idleTimeout，minimumIdle，maxLifetime的设置问题
docker 容器的连接通讯问题

带着以上解决方案，我检查了代码，发现没有连接池泄漏，validationTimeout，minimumIdle，maxLifetime 也都按照网上的配置了，但是依然会出问题，出问题的频率大概几分钟就会出现。再看下我的配置，看起来都是默认配置，似乎没太大问题。在这里插入描述
让我们回过头来，再看下错误信息： Connection is not available, request timed out after XXXms. 为什么会存在不可用的连接尼？如果上面的解决方案无法找出问题，我们能否使用另一个纬度来解决问题尼？能否通过连接池的配置让不可用的连接失效尼？带着疑问我访问了github上面的HikariCP 项目。
地址为： https://github.com/brettwooldridge/HikariCP
其中有一个配置：
在这里插入图片描述
我引一下chrome上面的中文翻译：
此属性控制池中连接的最大生存期。使用中的连接永远不会停止，只有关闭连接后，连接才会被移除。在逐个连接的基础上，应用较小的负衰减以避免池中的质量消灭。 我们强烈建议设置此值，它应该比任何数据库或基础结构施加的连接时间限制短几秒钟。 值0表示没有最大寿命（无限寿命），当然要遵守该idleTimeout设置。默认值：1800000（30分钟）

重点部分已被我加粗。
我的数据库是用docker 搭建的，版本是mysql8，在腾讯云主机上面。mysql的默认连接时间是8小时，我在本地的数据库上面竟然没有出现这个问题，但是在远程的数据库上面有这个问题。于是我开始怀疑是docker本身的问题，使得mysql的连接提前被断开了，但是HikariCP这边却依然认为连接是可用的。

好吧，既然maxLifetime可以控制连接的生命周期，我们就修改它吧，按照HikariCP作者的描述maxLifetime的时间应该比任何数据库或基础结构施加的连接时间限制短几秒钟，经过一番测试我决定把maxLifetime的时间修改为60秒，也就是尽量抢在在docker mysql断开之前。在这里插入图片描述
修改完之后，连接池的问题暂时解决了。

redis连接池超时问题

springboot2以后官方使用了Lettuce连接池，Lettuce的优点这里不必多说，但是却引发了一段时间不用连接池超时的问题。先贴上我的配置，都是官方默认的：在这里插入图片描述
比较巧的是我的redis，也是外网上面docker 搭建的，最新的5.X版本，出现问题我第一反应是redis连接不能访问了，经测试，正常访问。
网上有些避重就轻的解决方法：如更换Lettuce为jedis，确实更换后，确实也能解决问题，但是这等于说把官方推荐的东西，又打回以前，而且也需要一些成本。还有写一个定时器之类的，对redis的连接做心跳检测。难道就没有一个既不更换连接池，又不修改代码的方法来解决吗？肯定有的。

很明显redis也出现了HikariCP 类似的问题，程序中redis的连接池，显示可用，但是实际上连接已经断了。那我们能否修改redis配置，让连接断开之前，发送心跳给客户端，使其连接保活。我先查找了spring中redis的配置并没有发现类似HikariCP的maxLifetime属性，但是在redis.conf配置里面却发现了一个tcp-keepalive的属性，看下官方的描述：
在这里插入图片描述
大致的意思说服务端会每隔一段时间向客户端发送心跳检测，来确保客户端的连接保活。默认5分钟，这里我设置为60秒。
设置完毕后，重启redis，发现项目已经正常了。