我要评论一、tomcat（内嵌）——最大并发“入口”
| 参数 | 默认 | 建议值（4c8g） | 含义与备注 |
|---|---|---|---|
| server.tomcat.max-connections | 8192 | 10 000 | 瞬时最大 tcp 连接，含 keep-alive，不是同时处理请求的线程数[^1][^6]。 |
| server.tomcat.threads.max | 200 | 800 | 真正干活的工作线程，cpu 核数×200 是 2025 年生产经验值；再高调度开销陡增[^1]。 |
| server.tomcat.accept-count | 100 | 1000 | 三次握手完成后、但还没拿到工作线程的请求队列长度；突发流量缓冲用[^2]。 |
| server.tomcat.threads.min-spare | 10 | 100 | 预热线程，避免“冷启动”时瞬间创建 800 条线程[^6]。 |
| server.tomcat.connection-timeout | 未配置 | 20 000 ms | tcp 连接等待第一次 uri 的超时，防止慢连接占坑[^6]。 |
yaml 片段
server:
tomcat:
max-connections: 10000
threads:
max: 800
min-spare: 100
accept-count: 1000
connection-timeout: 20s二、hikaricp（默认连接池）——数据库“阀门”
| 参数 | 默认 | 建议值（4c8g） | 含义与备注 |
|---|---|---|---|
| spring.datasource.hikari.maximum-pool-size | 10 | cpu 核数 × 5 ≈ 20 | 单实例同时访问 db 的物理连接上限；绝非越大越好，超过 30 基本浪费[^3][^4]。 |
| minimum-idle | 同 maximum | 8 | 低峰保留连接，减少握手开销。 |
| connection-timeout | 30 000 ms | 3 000 ms | 拿不到连接快速失败，防止雪崩。 |
| idle-timeout / max-lifetime | 600 s / 30 min | 10 min / 30 min | 避免连接被防火墙/f5 静默断开。 |
yaml 片段
spring:
datasource:
hikari:
maximum-pool-size: 20
minimum-idle: 8
connection-timeout: 3000
idle-timeout: 600000
max-lifetime: 1800000三、一图读懂“入口→阀门”关系
客户端 ─► max-connections=10k ─► accept-count=1k ─► threads.max=800 ─► 业务线程
│
▼
hikari pool=20
│
▼
mysql max_connections≈200tomcat 线程数 >> 连接池大小，保护数据库；
连接池大小 ≈ 核数×5，保护实例内存；
数据库
max_connections≥ 所有实例连接池总和 + 50 冗余。
四、不同规格“线性折算”速查
| 规格 | tomcat threads | hikari max-pool |
|---|---|---|
| 2c4g | 400 | 10 |
| 4c8g | 800 | 20 |
| 8c16g | 1600 | 40 |
超过 8 核时，先压测再线性上调；线程 >1600 后调度开销占比陡增，建议横向扩容。
五、三步上线 checklist
改配置 → 打包 → 压测（jmeter/ gatling）
同时监控：
tomcat_threads_busy≤ 80% * threads.maxhikaricp_connections_active≤ 80% * maximum-pool-size数据库
threads_running≤ 60% * max_connections
根据 95th rt 与错误率，只调整线程数或连接池，一次只动一个参数，再压测。
按上面“入口 10 k / 线程 800 / 池 20”这套 baseline，2025 年多家 4c8g 业务系统（查询为主，qps 3 k~5 k）可直接复用，无需再调优。
总结
到此这篇关于springboot项目tomcat及数据连接池配置推荐的文章就介绍到这了,更多相关springboot tomcat数据连接池配置内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论