Web服务器线程数与数据库连接池需匹配：Tomcat线程数≈QPS×平均耗时（秒）×1.2～1.3；HikariCP的maximumPoolSize应略大于maxThreads（如大10%～20%），且Oracle processes≥maximumPoolSize×1.2。
Web服务器线程数和数据库连接池大小不匹配的典型表现
并发请求一多，connection wait timeout 或 connection acquisition timed out 就频繁抛出，但 oracle 数据库本身 cpu、io 并不饱和。这说明不是数据库扛不住，而是应用层“卡在排队”——tomcat 线程想拿连接，但连接池里没空闲连接可分；或者反过来，连接池配得过大，但 tomcat 线程根本用不完，还白白占着 oracle 的会话资源（v$session 里大量 inactive 连接）。
Tomcat 线程数怎么设才不算瞎猜
别直接套用默认的 maxThreads=200。它得和你真实业务请求的平均耗时挂钩：
- 先用 APM 工具（比如 SkyWalking 或 Spring Boot Actuator + Prometheus）测出单次 DB 请求平均耗时（含网络+SQL执行+结果集处理），记为
T_ms - 预估峰值 QPS，记为
Q - 理论最小线程数 ≈
Q × T_ms / 1000（单位统一成秒）；再上浮 20%～30% 应对毛刺 - 如果接口大量调用外部 HTTP 或等待异步任务，
T_ms要包含这些阻塞时间，不能只算 JDBC 那一段
例如：QPS = 150，DB 平均耗时 80ms，那基础线程需求是 150 × 0.08 = 12，加缓冲后设 maxThreads=20 就够了——远低于默认值，也避免线程上下文切换开销。
HikariCP 连接池参数必须和 Tomcat 对齐
光调 maximumPoolSize 不行，这几个参数联动才起作用：
-
maximumPoolSize应 ≥ TomcatmaxThreads，但建议最多大 10%～20%，比如 Tomcat 是 20，这里设 24；设太大（如 100）会导致 Oracleprocesses参数超限或触发ORA-12516 -
minimumIdle别设为 0；设成maximumPoolSize × 0.3左右，保证冷启动后有连接可立即用，避免首次请求延迟飙升 -
connection-timeout建议 ≤ Tomcat 的connectionTimeout（默认 20000ms），否则 Tomcat 等不到连接就先超时断开，用户看到 500 而不是连接池超时日志 - 务必打开
connection-test-query=SELECT 1 FROM DUAL（Oracle 场景），并设validation-timeout=3000，不然空闲连接被 Oracle 主动 kill 后，HikariCP 不知道它已失效，下次分配就报IO Error: Connection reset
Oracle 侧必须同步检查的硬限制
Java 层调得再细，Oracle 拦在门口照样白搭：
- 查当前设置：
SELECT name, value FROM v$parameter WHERE name IN ('processes', 'sessions') -
processes必须 ≥ HikariCP 的maximumPoolSize× 1.2（Oracle 自身要占用部分进程）；若不够，DBA 得改ALTER SYSTEM SET processes=300 SCOPE=SPFILE并重启 - 确认 Oracle 监听器没限并发：检查
$ORACLE_HOME/network/admin/listener.ora里有没有MAX_CONNECTIONS之类配置，有就删掉或调大 - 避免使用
jdbc:oracle:thin:@//host:port/service这种 URL；改用jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host)(PORT=port))(CONNECT_DATA=(SERVICE_NAME=service)))，能更好支持连接池的连接复用和故障转移
最常被忽略的是 Oracle 的 processes 和 Tomcat 线程数之间没有做比例校验，结果压测时一半错误日志在 Java 侧，一半在 Oracle 的 alert.log 里报 ORA-00020: maximum number of processes exceeded，来回排查浪费半天。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
