连接池基础：连接池的作用、常用连接池（HikariCP、Druid等）
嘿，朋友们。今天咱们来聊聊连接池。我刚开始做后端时，对连接池的理解就只是“池子里放几个连接”。直到第一次线上事故，我才真正懂了它。
连接池的作用，说白了就四个字：复用与保护。你想想看，每次请求都新建数据库连接，开销多大啊？
为什么需要连接池？
数据库连接的创建，可不是new一个对象那么简单。它要经历TCP握手、认证、会话初始化等步骤。我做过测试，一次完整的连接建立，大概要消耗10-30毫秒。如果请求并发高，光花在连接上的时间就够呛。
我在项目中遇到过，一个简单的查询接口，因为没有配置连接池，QPS一上来数据库连接就耗尽了。数据库CPU直接飙到100%，整个系统都挂了。
连接池的核心价值：
- 复用连接：避免频繁创建和销毁，降低延迟
- 控制并发：限制连接总数，防止数据库被打满
- 快速响应：连接已经在池中，拿起来就能用
- 保护数据库：连接数可控，不被冲垮
一句话总结：连接池是系统的“守门员”，既提升性能，又保护后端数据库。
连接池的工作原理
理解原理，才能用好它。连接池内部其实是个队列，核心流程我画了张图，你看一眼就懂了。
这张图展示了连接池的核心决策路径。说白了就是三步：
- 有空闲连接？有就直接拿，没有就下一步
- 池子满了？没满就新建，满了就去排队
- 排队超时？超时就抛异常，不超时就等别人还回来
我在项目中被坑过一次。当时因为等待超时设得太大，结果连接池队列积压了上千个请求，系统直接OOM了。嗯，这里要注意，超时时间不是越大越好。
常用连接池对比
市面上连接池不少，但最常用的就几个。我个人用得最多的是HikariCP和Druid。为啥？来，看这张表你就明白了。
| 特性 | HikariCP | Druid | DBCP2 | Tomcat JDBC |
|---|---|---|---|---|
| 性能 | 最快（字节码级优化） | 中等 | 较慢 | 较快 |
| 监控 | 有限（自带HikariConfig） | 强大（Web界面、SQL分析） | 无 | 无 |
| 功能丰富度 | 简洁 | 全面（防火墙、防注入、日志） | 基础 | 基础 |
| Spring Boot默认 | 是 | 否（需引入Starter） | 否 | 否 |
| 适合场景 | 高性能、低延迟 | 需要监控、安全控制 | 遗留系统 | Tomcat容器项目 |
我个人习惯：新项目直接上HikariCP，Spring Boot默认就是它，性能没得说。如果团队需要可视化监控或者要对慢SQL做拦截，就上Druid。不过Druid有点重，别为了一点点功能盲目堆料。
连接池的关键参数
参数配置比想象中重要。我记得有一次线上事故，就是因为maximumPoolSize设得太大，数据库连接被打满了。你想想看，连接池不是越大越好。
核心参数有这些：
| 参数 | 作用 | 建议 |
|---|---|---|
minimumIdle |
最小空闲连接数 | 一般等于maximumPoolSize/2 |
maximumPoolSize |
最大连接数 | 根据数据库能力计算，不是无限大 |
connectionTimeout |
等待连接的超时时间 | 建议30秒以内，太长会堆积请求 |
idleTimeout |
空闲连接存活时间 | 建议10分钟，防止连接被数据库回收 |
maxLifetime |
连接最大生命周期 | 建议30分钟，避免连接泄漏 |
validationQuery |
连接可用性检查SQL | 用SELECT 1，别太复杂 |
我曾经遇到一个案例：连接池的connectionTimeout设成了60秒，结果接口响应时间全部飙到50秒以上，直接触发了熔断。记住，超时参数是熔断的加速器，不是保护伞。
连接池与熔断的关系
说实话，很多熔断实际不是被保护触发的，而是被连接池“憋”出来的。为什么？
你想想看，如果连不上数据库，或者数据库很慢，连接池里的连接就会全被占着。新来的请求拿不到连接，一直等，等到超时就报错。一个报错还好，如果大量报错，熔断器就会跳闸。
我总结了一个规律：
- 连接池太小 → 容易排队超时 → 触发熔断
- 连接池太大 → 打满数据库 → 全部失败 → 触发熔断
- 超时太长 → 请求堆积 → 内存溢出 → 触发熔断
- 超时太短 → 正常波动也熔断 → 误伤
核心结论：连接池配置是熔断的前置防线。先管好连接池，再配置熔断器，顺序不能反。
配置示例
我直接给你一个我项目中常用的HikariCP配置，你拿去就能用：
# 数据源配置
spring.datasource.hikari.minimum-idle=10
spring.datasource.hikari.maximum-pool-size=30
spring.datasource.hikari.connection-timeout=30000
spring.datasource.hikari.idle-timeout=600000
spring.datasource.hikari.max-lifetime=1800000
spring.datasource.hikari.validation-timeout=5000
spring.datasource.hikari.leak-detection-threshold=60000注意那个leak-detection-threshold，我建议一定要开。它能在连接泄漏时帮你快速定位。说白了，运维阶段最怕的就是“连接莫名其妙没了”，这个参数就是你的探照灯。
Druid的配置也类似，但多一个监控配置：
# Druid配置
spring.datasource.druid.initial-size=10
spring.datasource.druid.min-idle=10
spring.datasource.druid.max-active=30
spring.datasource.druid.max-wait=30000
spring.datasource.druid.time-between-eviction-runs-millis=60000
spring.datasource.druid.min-evictable-idle-time-millis=300000
spring.datasource.druid.validation-query=SELECT 1
spring.datasource.druid.filters=stat,wall,log4j我个人经验：先把连接池配好，再用熔断器兜底。连接池配不好，熔断器再多也救不了。你想想看，连数据库都拿不到连接，熔断器再灵敏也没用啊。
好了，连接池基础部分咱们就聊到这儿。记住我今天说的核心：连接池是系统的第一道防线，配好了能扛住大部分压力，配不好就是熔断的导火索。下节课咱们聊聊超时参数怎么设，才不会被熔断器误伤。