Chaos Monkey延迟测试导致tomcat-jdbc连接池获取连接严重延迟求助

• 连接泄漏：这是连接池等待队列增长最常见的诱因。如果代码中存在未正确释放数据库连接的情况（比如异常分支未关闭连接、未使用try-with-resources语法），会导致连接被长期占用，即便调大MaxActive，最终也会被泄漏的连接占满。此时新请求只能等待连接释放，叠加Chaos Monkey引入的2秒延迟，等待时间会被大幅放大。可以开启tomcat-jdbc的removeAbandoned参数（设置removeAbandoned="true"和removeAbandonedTimeout），开启后会自动回收超时未释放的连接，同时查看日志中是否有连接被标记为abandoned的记录，定位泄漏点。

• 连接池等待超时参数配置不合理：tomcat-jdbc的maxWait参数默认值为-1（无限等待）。当连接池耗尽时，新请求会一直阻塞等待可用连接，而每个被占用的连接因为Chaos Monkey的延迟，占用时间变长，后续请求的等待时间会累积成几十秒。建议将maxWait设置为合理的值（比如5000ms），避免请求无限期等待，同时结合业务超时逻辑，快速失败而非长时间阻塞。

• 连接验证机制开销过大：如果开启了testOnBorrow（默认开启），每次获取连接时都会执行验证操作（比如SELECT 1），如果数据库端响应变慢，或者验证逻辑本身耗时，会增加连接获取的总耗时，导致连接池的周转效率下降。可以考虑将验证方式改为testWhileIdle（后台定时验证空闲连接），同时调整timeBetweenEvictionRunsMillis参数控制验证频率，减少对正常请求的影响。

• 连接池参数与请求模式不匹配：

  • 若minIdle设置过低，空闲连接会被连接池主动回收，当请求量突增时，需要重新创建新连接，而创建连接的耗时（加上Chaos Monkey延迟）会让请求等待时间变长；
  • 若maxIdle设置过小，空闲连接被过早销毁，池内可用连接无法应对短时间的请求高峰，导致等待队列增长。建议根据业务请求量调整minIdle等于InitialSize，同时设置合理的maxIdle值（不小于minIdle）。

• 数据库端瓶颈：虽然问题表现为连接池等待，但根源可能在数据库侧。Chaos Monkey的延迟可能导致数据库事务处理时间变长（比如锁等待、慢查询），进而让连接被占用的时间远超预期，连接池无法及时回收连接供新请求使用。可以排查数据库的慢查询日志、锁等待情况，确认是否存在数据库端的性能瓶颈。

• 公平队列的累积效应：tomcat-jdbc的fairQueue参数默认是true，连接池会按FIFO顺序分配连接。当存在大量长耗时请求（因Chaos Monkey延迟）时，后续请求会排队等待，等待时间会叠加前面所有长耗时请求的处理时间，最终导致总响应时间飙升。可以尝试将fairQueue设为false，使用非公平锁分配连接，一定程度上缓解排队累积的问题，但这需要结合实际业务场景评估是否适用。

内容的提问来源于stack exchange，提问作者Kumar