数据库连接池管理连接数，线程池管理并发线程数，二者需协同配置：连接池最大连接数应≥线程池活跃线程数×单请求平均持连占比，按CPU/I/O/混合型业务特征联动调优，并通过监控指标动态闭环优化。
数据库连接池本身不使用“线程池大小”这个概念，它管理的是数据库连接数；而“线程池大小”属于 ThreadPoolExecutor 的配置范畴，用于控制并发执行任务的线程数量。两者常被混用，但优化目标和参数完全不同——混淆会导致调优方向错误。真正需要关注的是：如何让连接池的连接数与业务线程池的并发能力协同匹配，避免资源错配。
明确连接池与线程池的分工关系
典型 Web 服务中，一个请求通常经历：线程池分配线程 → 执行业务逻辑 → 从连接池获取 DB 连接 → 发起 SQL → 归还连接。若线程池太大而连接池太小，大量线程会卡在 getConnection() 上等待；反之，连接池过大而线程池过小，则空闲连接堆积、数据库负载虚高、内存与连接数浪费。
- 线程池负责“并发执行能力”，决定同时处理多少请求
- 连接池负责“数据库访问通道数”，决定同时能发起多少 SQL 请求
- 二者应大致平衡：连接池最大连接数 ≥ 线程池活跃线程数 × 单请求平均连接持有时间占比
按任务类型联动配置线程池 + 连接池
不能孤立设置任一池子，要结合业务特征做组合策略：
-
CPU 密集型服务（如报表计算、规则引擎）：线程池设为
Runtime.getRuntime().availableProcessors() + 1；连接池maximum-pool-size设为 5–10 即可，因单次请求持连时间短、并发连接需求低 -
I/O 密集型服务（如 REST API + 多次 DB 查询/远程调用）：线程池可设为 CPU 核心数 × 2～4；连接池
maximum-pool-size建议设为线程池核心线程数的 1.2～1.5 倍（例如线程池 core=20，则连接池 max=24～30），预留缓冲应对慢查询或连接复用延迟 - 混合型服务（常见于 Spring Boot 微服务）：建议拆分线程池 + 连接池——读操作用独立线程池+轻量连接池，写操作用另一组更保守配置，避免相互阻塞
关键参数协同调优要点
以下参数需成对观察、联动调整：
立即学习“Java免费学习笔记（深入）”；
-
spring.datasource.hikari.maximum-pool-size与ThreadPoolExecutor.getMaximumPoolSize()：压测时若发现连接池耗尽（抛SQLException: Connection is not available），且线程池活跃线程数稳定在高位，说明连接池是瓶颈，优先扩容连接池而非线程池 -
spring.datasource.hikari.connection-timeout（默认 30s）应略大于线程池任务超时时间（如Future.get(25, TimeUnit.SECONDS)），防止线程等不到连接就超时，掩盖真实瓶颈 -
spring.datasource.hikari.minimum-idle建议设为maximum-pool-size × 0.3～0.5，保证突发流量来临时有足够热连接可用，减少新建连接开销 - 启用连接有效性检测：
spring.datasource.hikari.connection-test-query=SELECT 1（MySQL）或spring.datasource.hikari.validation-timeout=3000，避免因网络闪断导致连接池持续返回失效连接，间接拉高线程等待时间
监控驱动的动态适配
静态配置易失效，必须依赖运行时指标闭环调优：
- 关注 HikariCP 指标：
HikariPool-1.ActiveConnections（当前活跃连接）、HikariPool-1.IdleConnections、HikariPool-1.TotalConnections - 关注线程池指标：
getActiveCount()、getQueue().size()、拒绝任务数 - 当
ActiveConnections ≈ maximum-pool-size且线程池队列持续非空→ 连接池是瓶颈 - 当
ActiveConnections 长期 且 <code>线程池活跃线程数远低于 corePoolSize→ 整体负载低，可双降节约资源
