使用HikariCP连接MariaDB：线程池该由谁管理？

场景概述 #

运行2个Java应用实例，每个实例使用HikariCP且最大连接池大小设为30，连接到单个配置了thread_handling = pool-of-threads的MariaDB数据库。当数据库并发读请求量较高时，HikariCP出现连接超时问题，仅执行基于主键查询单条数据的简单操作。

日志现象 #

日志显示查询耗时逐渐飙升，最终HikariCP触发30秒超时，请求量回落之后查询耗时恢复正常：

2024-03-20 00:09:17.551, qtp1047503754-22 , [DEBUG] Get team query time, 8ms
2024-03-20 00:09:18.432, pool-3-thread-3 , [DEBUG] Get team query time, 5ms
2024-03-20 00:09:52.305, qtp1047503754-29 , [DEBUG] Get team query time, 6ms
2024-03-20 00:09:56.720, qtp1047503754-27 , [DEBUG] Get team query time, 5ms
2024-03-20 00:10:00.232, qtp1047503754-24 , [DEBUG] Get team query time, 4ms
2024-03-20 00:10:01.329, pool-3-thread-4 , [DEBUG] Get team query time, 4ms
2024-03-20 00:10:04.553, qtp1047503754-25 , [DEBUG] Get team query time, 4ms
2024-03-20 00:10:05.787, pool-3-thread-3 , [DEBUG] Get team query time, 6ms
2024-03-20 00:10:06.353, pool-3-thread-4 , [DEBUG] Get team query time, 3ms
2024-03-20 00:10:14.178, qtp1047503754-22 , [DEBUG] Get team query time, 293ms
2024-03-20 00:10:14.184, qtp1047503754-27 , [DEBUG] Get team query time, 953ms
2024-03-20 00:10:14.185, qtp1047503754-29 , [DEBUG] Get team query time, 739ms
2024-03-20 00:10:14.197, qtp1047503754-24 , [DEBUG] Get team query time, 523ms
2024-03-20 00:10:14.201, qtp1047503754-28 , [DEBUG] Get team query time, 92ms
2024-03-20 00:10:15.414, qtp1047503754-25 , [DEBUG] Get team query time, 861ms
2024-03-20 00:10:15.425, qtp1047503754-167 , [DEBUG] Get team query time, 417ms
2024-03-20 00:10:16.177, qtp1047503754-26 , [DEBUG] Get team query time, 1838ms

核心疑问 #

是否应该让HikariCP负责连接池管理，将MariaDB的线程处理模式改为thread per connection，还是需要匹配两者的池大小？

解决方案建议 #

1. 优先将MariaDB线程处理模式改为thread_per_connection #

当前pool-of-threads是MariaDB侧的线程池模式，和应用层HikariCP的连接池形成双层池化结构，容易引发资源竞争和调度延迟。当应用侧总连接数打满（2*30=60），若数据库侧线程池容量不足，会导致请求排队，进而出现查询耗时飙升、连接超时。

改为thread_per_connection后，数据库会为每个连接创建独立线程，连接的生命周期完全由HikariCP管控，避免双层池化的调度冲突。对于当前简单主键查询的场景，这种模式的性能开销完全可控。

2. 无需严格匹配池大小，但要控制总连接数上限 #

如果坚持使用pool-of-threads模式，不需要刻意对齐HikariCP和MariaDB的池大小，但必须确保MariaDB的thread_pool_size不小于应用侧总连接数（60），同时预留数据库自身的线程资源。不过这种方式仍存在双层池化的调度损耗，不如直接让应用侧接管连接池管理高效。

3. 额外优化项 #

• 调整HikariCP超时配置：比如适当调小connectionTimeout，避免请求长时间排队；
• 排查连接泄漏：开启HikariCP的leakDetectionThreshold，确认是否存在未正常释放的连接；
• 验证数据库基础性能：检查主键索引状态、磁盘IO瓶颈，排除硬件层面的问题。

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