不能直接用 LinkedBlockingQueue 当连接池，因其无连接生命周期管理，易因归还错误导致连接泄漏或阻塞；需封装代理类重写 close()、加超时获取、预热连接、用 isValid()校验归还连接有效性并丢弃失效连接。
为什么不用 LinkedBlockingQueue 直接当连接池？
它确实能存 Connection，也能阻塞取用，但「归还」动作一旦出错（比如忘记归还、重复归还、归还已关闭的连接），池子会快速退化：可用连接越来越少，甚至全卡死在阻塞队列里等不到新连接。
根本问题在于：LinkedBlockingQueue 没有绑定连接生命周期管理逻辑，它只管“放”和“取”，不管“这个连接还能不能用”。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 必须封装一层
PoolConnection代理类，重写close()方法——不是真的关掉连接，而是调用池子的returnConnection() - 在
getConnection()中加超时控制，避免线程无限等待；例如用poll(timeout, unit)而非take() - 初始化时预热连接：启动时主动创建并校验一批连接，再放入队列，避免首请求触发延迟
如何判断一个 Connection 归还时是否有效？
不能只靠 connection.isClosed()——有些驱动返回 false 即使网络已断，或者连接被数据库主动踢出。更可靠的方式是执行一条轻量 SQL，比如 SELECT 1，并捕获异常。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 归还前做简单校验：用
connection.isValid(2)（JDBC 4.0+），比isClosed()更准，且带超时 - 若校验失败，直接丢弃该连接，不放回队列，并记录 warn 日志（别 throw 异常，否则归还逻辑中断）
- 避免在归还路径上做耗时操作（如查元数据、设 autocommit），这些应放在获取连接后、业务执行前
getConnection() 失败时，要不要抛 SQLException？
要，但得区分原因。如果是池子空 + 等待超时，抛自定义运行时异常（比如 PoolExhaustedException）更合适；如果是底层驱动连不上数据库，才该抛原始 SQLException。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 不要把所有错误都包装成
SQLException，下游无法区分是配置错、网络断，还是池子满了 - 在获取连接时捕获
SQLException后，先检查sqlEx.getSQLState()或消息关键字（如"Connection refused"），再决定怎么包装 - 对外暴露的
getConnection()方法签名保持throws SQLException即可，内部按需转换，别强行统一异常类型
为什么不能在 finally 块里直接 connection.close()？
因为那会真实关闭物理连接，池子就废了。你看到的 Connection 对象其实是代理，close() 必须指向池子的回收逻辑，而不是 JDBC 驱动的关闭。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 永远用池子提供的
DataSource.getConnection()获取连接，而不是自己DriverManager.getConnection() - 确保项目里没有直接 new 的
Connection实例混入池子——它们没有代理层，close()就是真关 - 如果用了 MyBatis 或 Spring，确认
DataSource配置指向的是你写的池子，而不是 HikariCP 或 DBCP 这类第三方实现，否则代理逻辑不生效
真正麻烦的不是写队列和取放逻辑，而是让每个归还动作都稳稳落在回收路径上——少一次 try-catch 里的漏网之鱼，池子就能多撑十分钟。
