java连接池最大连接数需结合数据库能力、硬件资源和业务实际确定：查max_used_connections与max_connections比值（70%～85%为优），按内存（约1mb/连接）和硬件反推安全上限，再依qps×平均持有时间+缓冲估算，并配好connectiontimeout、isvalid()等超时验证机制。
Java 中连接池最大连接数不能拍脑袋定，得结合数据库能力、硬件资源和业务实际来算。设太高，MySQL 压力大、内存吃紧；设太低，请求排队、超时报错频发。关键不是“够不够用”，而是“稳不稳定、省不省钱”。
看数据库真实扛过多少连接
别猜峰值，直接查历史数据：
- SHOW GLOBAL STATUS LIKE 'Max_used_connections'; —— 看过去最高用过多少连接
- SHOW VARIABLES LIKE 'max_connections'; —— 看 MySQL 当前上限是多少
如果前者长期占后者的 70%～85%，说明当前设置较合理；低于 30%，说明池子偏大，白占内存；接近或超过 100%，就得立刻调优或扩容。
按硬件和并发反推安全上限
每个 MySQL 连接平均消耗约 1MB 内存（含排序缓冲、临时表等）。一台 16GB 服务器若给 MySQL 分配 10GB，理论最多撑约 1000 连接，但必须留余量：
- 操作系统文件描述符限制：ulimit -n 至少设为 max_connections × 2
- 配套调整 MySQL 的 open_files_limit 和 thread_cache_size（建议设为峰值连接数的 1/4～1/2）
- 起步建议值：500～1000，上线后观察 Threads_created 增速和内存使用率再微调
根据业务流量算池子要多大
maximumPoolSize ≠ QPS，得结合连接持有时间估算：
- 例如 QPS = 200，平均每个请求占用连接 200ms → 理论需 40 个连接（200 × 0.2）
- 再加 50% 缓冲防抖动，设成 60～80 更稳妥
- 更保守的经验公式：CPU 核心数 × 2 + 磁盘数，这是数据库能高效处理的并发连接数
- HikariCP 默认是 10，Druid 建议 50～200，视 SQL 复杂度和事务时长而定
必须配对生效的超时与验证机制
光设最大数不配超时和校验，等于埋雷：
- connectionTimeout（获取连接超时）：设 3～30 秒，太短易误抛异常，太长线程卡死
- 必须与 MySQL 的 wait_timeout（默认 8 小时）错开，建议设为其 1/10～1/3（如 300 秒）
- 验证方式优先用 isValid()（底层调 mysql_ping），比 SELECT 1 更轻量
- 搭配 idleTimeout（空闲回收）和 maxLifetime（最大存活），防止连接被数据库静默断开后失效
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
