应使用连接池（首选HikariCP）替代DriverManager直连，关键在于选对池、配准参数（如maximumPoolSize、minimumIdle等）、严格管理连接生命周期（try-with-resources+事务显式控制），并配合监控指标持续优化。
直接用 DriverManager 每次创建连接，在高并发下会迅速拖垮系统——连接建立耗时、资源争抢激烈、数据库很快报 “Too many connections”。真正有效的解法，是用连接池把连接“管起来”，核心就三点：选对池、配准参数、管住连接生命周期。
优先选 HikariCP 作为连接池实现
HikariCP 是当前 Java 生态中性能最强、开销最低的 JDBC 连接池。它采用无锁设计（ConcurrentBag），在上千线程争抢连接时仍保持极低延迟；代码精简、依赖少，出问题排查也快。相比 C3P0 或 DBCP2，它在同等硬件下可支撑更高 TPS，且默认配置更合理，上手即用。
- Maven 引入（推荐最新稳定版，如 5.0.1）：
- <dependency>
<groupId>com.zaxxer</groupId>
<artifactId>HikariCP</artifactId>
<version>5.0.1</version>
</dependency>
关键参数必须按场景调优
不能全靠默认值。比如 maximumPoolSize 默认为 10，电商秒杀时瞬间几百请求排队等连接，必然超时失败。要结合数据库最大连接数、应用线程模型和实际压测结果来设。
- maximumPoolSize：设为数据库允许的最大连接数的 70%～80%，避免打满 DB；例如 MySQL max_connections=200，则这里设 160
- minimumIdle：保持常驻空闲连接数，建议设为 maximumPoolSize 的 1/3～1/2，减少突发请求时新建连接开销
- connectionTimeout：获取连接最长等待时间，建议 30000ms（30秒），太短易抛异常，太长阻塞线程
- maxLifetime：连接最大存活时间（如 1800000ms = 30分钟），强制刷新老化连接，防止 MySQL 的 wait_timeout 导致通信异常
- leakDetectionThreshold：设为 60000ms（60秒），自动检测未归还连接，定位 Connection 泄露点
代码层面必须严格管理连接
连接池再好，如果用完不还，等于白搭。泄露一个连接，池子就少一个，累积下来整个服务就卡死。
- 务必使用 try-with-resources 自动关闭 Connection、Statement、ResultSet
- 所有数据库操作必须在 try 块内完成，catch 中不吞异常，finally 不手动 close（交给 try-with-resources）
- 事务边界要清晰：开启事务后，必须显式 commit 或 rollback，否则连接会被长期占用
- 避免在 long-running 线程或定时任务里长期持有 Connection
配合监控持续观察池子健康状态
连接池不是配完就一劳永逸。上线后要盯几个核心指标：
- activeConnections：当前活跃连接数，持续接近 maximumPoolSize 说明池子偏小或 SQL 执行慢
- idleConnections：空闲连接数，长期为 0 表示连接复用率高但可能有泄露风险
- threadsAwaitingConnection：等待连接的线程数，大于 0 就是瓶颈信号
- connectionAcquireMillis：平均获取连接耗时，超过 10ms 就需警惕
- 可通过 HikariCP 的 Metrics（如 Dropwizard 或 Micrometer）集成 Prometheus + Grafana 实时告警
