在HikariCP的官方文档上，记载了关于对比主流数据库连接池数据库中断的测试情况，这是针对各种数据库连接池都提供的超时功能的测试对比。

这个测试实验模拟了这样一个场景，将数据库连接池执行getConnection()在5秒的调用后超时，应用程序应在指定时间内获得连接异常。该实验设置了一个测试，可以针对远程MySQL服务器配置4个池（HikariCP、c3p0、DBCP2、Vibur）。每隔2秒getConnection()调用一次，执行查询，然后关闭连接（返回池）。

每个连接池都如表所示进行了配置，来验证check-out时的连接。

每种数据库连接池超时配置如表所示。

然后开始运行测试内容，所有的数据库连接池都没有问题，但是MySQL服务器网络电缆突然故意断开，则出现了如下现象。

• HikariCP：等待5秒，若连接未恢复，抛出SQLExceptions异常，后续getConnection()同样处理。
• c3p0：完全无反应且无提示，也不会在CheckoutTimeout配置的时长超时后给调用者任何通知。等待2分钟后才醒来，返回一个error。
• Tomcat：返回一个connection，若调用者如果利用这个无效的connection执行SQL语句，结果可想而知。大约55秒之后醒来，此时getConnection()返回一个error，但未像参数配置的那样等待5秒钟，而是立即返回error。
• BoneCP：与Tomcat类似，也是约55秒后醒来，有正常反应，且最终等5秒钟后返回error。

可见，HikariCP的处理方式是最合理的。根据这个测试结果，对于各个CP处理数据库中断的情况，评分如表所示。

注意 这是使用JDBC 4.1驱动程序获得的结果，结果可能因新旧驱动程序的差异而有所不同。
除了数据库中断以外，HikariCP在其他方面还有很多值得称赞的地方：

• 连接的测试在getConnection时同步进行，并有独特的优化。
• 在自己的事务中封装内部池的查询，含testQuery一级initSQLQuery。
• 当连接Connections归还给连接池的时候，执行rollback操作。
• 在Connection.close的时候，跟踪并关闭废弃语句Statements。
• 在将Connection连接归还到客户端之前清除SQL警告。
• 默认参数支持自动提交、事务隔离级别、catalog和只读状态。
• 对于一些诸如“SQLException对象是否存在断开连接错误”等陷阱进行检查。