连接池解决的实际问题
开发 Web 项目时，数据库访问是家常便饭。比如做一个电商后台，用户下单、查库存、更新订单状态，每一步都要连数据库。如果每次操作都新建一个数据库连接，用完就关，那系统早就扛不住了。就像高峰期打车，每人临时叫一辆，司机来回跑空，效率低还浪费资源。
连接池就是为了解决这个问题。它提前创建一批数据库连接，放在“池子”里备用。需要用的时候直接从池子里拿，用完不是销毁，而是还回去，下次还能用。这样既避免频繁建立和断开连接的开销，又能控制最大并发数，防止数据库被拖垮。
常见连接池选型
Java 项目里最常用的有 HikariCP、Druid 和 C3P0。HikariCP 性能强、轻量，Spring Boot 默认就是它。Druid 功能更全，自带监控页面，适合需要排查 SQL 性能的场景。C3P0 老项目见得多，但现在基本被前两者替代。
比如你接手一个老系统，发现配置里写着 C3P0，连接慢还经常超时，换成 HikariCP 后，接口响应快了一半，这就是选对工具的差别。
Spring Boot 中配置 HikariCP
在 application.yml 里加上数据源配置就行：
spring:
datasource:
url: jdbc:mysql://localhost:3306/test_db?useUnicode=true&characterEncoding=utf8
username: root
password: 123456
driver-class-name: com.mysql.cj.jdbc.Driver
hikari:
maximum-pool-size: 20
minimum-idle: 5
connection-timeout: 30000
idle-timeout: 600000
max-lifetime: 1800000maximum-pool-size 控制最多多少个连接，别设太大，不然数据库吃不消。minimum-idle 是池子里最少留几个空闲连接，保证突发请求能快速响应。后面的超时时间按实际网络情况调，别让坏连接占着位置。
Druid 的监控能力
要是你想看谁查了慢 SQL，哪个接口调用次数最多，Druid 的监控页就很实用。加个依赖：
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>druid-spring-boot-starter</artifactId>
<version>1.2.8</version>
</dependency>再配个监控入口：
spring:
datasource:
type: com.alibaba.druid.pool.DruidDataSource
druid:
stat-view-servlet:
url-pattern: /druid/*
login-username: admin
login-password: admin启动后访问 /druid，输入账号密码，就能看到实时 SQL 执行情况、连接使用率、慢查询统计。上线后发现数据库负载高，进去一看，原来是某个报表接口没加索引，扫了全表，问题一目了然。
连接泄漏怎么防
用完连接不归还，池子迟早枯竭。常见原因是代码异常跳出了，没执行 close()。连接池一般都有检测机制，比如 HikariCP 的 leak-detection-threshold：
spring:
datasource:
hikari:
leak-detection-threshold: 60000单位是毫秒，这里设的是 60 秒。如果某个连接借出去超过一分钟还没还，日志就会报警。开发时开着这个，配合测试压一压，很容易揪出那些忘了释放连接的地方。
不同环境区分配置
本地开发可能就一个连接够用了，但生产环境得撑住并发。可以用 Spring 的多 profile 管理：
# application-dev.yml
spring:
datasource:
hikari:
maximum-pool-size: 5# application-prod.yml
spring:
datasource:
hikari:
maximum-pool-size: 20
connection-timeout: 10000上线前切到 prod 环境跑一遍集成测试，确保配置生效。别等到线上卡了才想起来改，那时候用户早就投诉了。