连接池解决频繁创建销毁数据库连接导致的高延迟与资源耗尽问题，其本质是“空间换时间”：预建并复用连接，避免每次tcp握手、认证和初始化；核心参数需结合业务场景理解——最小连接数保障冷启动性能，最大连接数需根据qps与响应时间合理设置，避免压垮数据库或请求堆积。
回答连接池面试题，核心是讲清“为什么需要它”和“它怎么工作”，而不是背参数或罗列名字。
紧扣本质：先说清楚连接池解决什么问题
别一上来就答“HikariCP快、Druid有监控”。先点明痛点：
- 每次 new Connection 都要 TCP 三次握手 + 认证 + 初始化，耗时几十到几百毫秒
- 高并发下频繁创建销毁连接，会打满数据库连接数，甚至拖垮服务
- 连接池就是用“空间换时间”——提前建好一批连接放着，随用随取，用完不关只归还
讲清关键参数的业务含义，不是定义
面试官问“最大连接数和最小连接数区别”，别只答“一个是上限一个是下限”。要带场景：
- 最小连接数 = 池子里常年挂着的“保底连接”，避免冷启动延迟；设太高会白占数据库资源
- 最大连接数 = 池子能撑住的极限，超过的请求会排队或报错；设太低会导致请求堆积，设太高可能压垮数据库
- 举个例子：QPS 200 的服务，平均响应 50ms，理论并发约 10，那 maxPoolSize 设 20~30 比较稳妥，不是盲目写 100
遇到“怎么排查连接泄漏”这类实操题，分步说动作
光说“要 try-finally 关闭”不够，得体现工程意识：
- 第一步：开连接池的泄漏检测（如 HikariCP 的 leakDetectionThreshold=60000，单位毫秒）
- 第二步：看日志里有没有 “Connection leak detection triggered” 提示，它会打印出哪行代码获取了连接但没归还
- 第三步：检查代码中所有 getConnection() 是否都对应了 close() 或 return，尤其注意异常分支和循环内提前 return 的情况
- 加分项：提一句 Spring 中用 @Transactional 管理事务时，连接由框架自动归还，但手动获取 Connection 就必须自己负责
被问“选 HikariCP 还是 Druid”，不站队，讲权衡
直接说“HikariCP 更快”显得单薄。可以这样组织语言：
- 如果项目追求极致性能、轻量、低延迟（比如网关、实时计算），HikariCP 是更主流的选择，启动快、代码精简、无额外依赖
- 如果团队需要 SQL 审计、防火墙、慢 SQL 记录、内置监控页面（比如运维要求看实时连接数图表），Druid 提供开箱即用的能力
- 真正关键的是：参数调优比选型更重要——哪怕用 HikariCP，maxLifetime 设成 0（永不过期），在数据库重启后就会出现大量 stale connection
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
