连接池翻车实录：我是如何把服务器搞挂的

事情是这样的，那天我兴高采烈地部署了一个新服务，刚想泡杯咖啡庆祝，监控就红了。

不是一般的红，是那种「服务器在冒烟」的红。

作为一个在后端坑里摸爬滚打多年的老油条，我决定把这血泪史分享出来，让各位少走弯路。看完你可能会说：「这人怎么这么傻？」——是的，我就是这么傻，但傻过之后学到了东西，这就值了。

一切从「连接池」说起

先科普一下，什么是连接池？

想象一下，你去餐厅吃饭。每次想吃饭都要先去厨房建一个厨房（建立连接），吃完再把厨房拆了（销毁连接）。这不是神经病吗？

连接池就是那个「提前准备好一堆厨房」的方案。用的时候拿一个，用完了还回去，不用每次都新建销毁。听起来很美好对吧？

美好是美好，但美好的东西往往有坑。

翻车现场还原

我的服务架构大概是这样的：

Java服务（Tomcat）
    ↓
MySQL数据库
    ↓
Redis缓存

听起来很正常对吧？标准得不能再标准的架构。

问题出在我给MySQL配的连接池——HikariCP。这玩意儿号称「史上最快连接池」，我配了两个参数：

maximumPoolSize=50
minimumIdle=50

啥意思呢？就是我不管用不用，先给你整50个连接备着。

测试环境跑得飞起，一上线——完蛋。

为什么？因为数据库服务器最大连接数是100，我这个服务就占了50个。结果有一天，业务高峰来了，数据库连接直接打满，其他服务也跟着遭殃。

第一个教训：连接池不是越大越好

很多人觉得「连接池越大越好」，这简直是大错特错。

你可以把数据库连接想象成餐厅的座位。座位越多越好吗？不一定。座位多了，服务员就累了（上下文切换），厨房压力也大了（数据库负载），而且很多座位可能空着浪费。

那怎么确定连接池大小？有个著名的公式：

连接数 = (核心数 * 2) + 有效磁盘数

这个公式是PostgreSQL官方推荐的。我用它算了一下，我那个8核的服务器，连接池大小设为20左右就够了。结果我设了50——这是要上天啊。

后来我改成了这样：

maximumPoolSize=20
minimumIdle=5
idleTimeout=300000
maxLifetime=1800000

解释一下：最多20个连接，最少保持5个连接空闲，空闲超过5分钟就回收，连接最多存活30分钟就强制回收。

这一改，内存占用直接降了60%。

第二个教训：别忘了Timeout

你以为这就完了？图样图森破。

有一次运维跑来找我：「兄弟，数据库有好多处于Sleep状态的连接，啥情况？」

我一查，好家伙，上百个连接在那躺着睡觉。问题是——这些连接早就没用了，但数据库服务器还以为它们在干活。

原因是什么呢？是我的应用在处理请求的时候，有时候会抛异常，异常之后连接没有正确归还到池里。听起来低级吧？但这种事真的很常见。

解决方案：一定要配置连接超时和空闲超时。

connectionTimeout=30000  # 获取连接超时30秒
idleTimeout=600000      # 空闲超时10分钟
maxLifetime=1800000     # 最大生存时间30分钟

更重要的是——写代码的时候一定要用try-with-resources或者finally来保证连接释放。

// 错误写法
Connection conn = dataSource.getConnection();
try {
    // 业务逻辑
} catch (Exception e) {
    // 这里conn没有关闭！
}

// 正确写法
try (Connection conn = dataSource.getConnection()) {
    // 业务逻辑
} // 自动关闭

第三个教训：连接池也会泄漏

说到连接泄漏，我再讲个真实的坑。

有一次我遇到了这样的错误：

HikariPool - Connection is not available, request timed out after 30000ms.

翻译成人话就是：「连接池没连接了，你等的花儿都谢了。」

我用jstat看了一下，活跃连接一直是满的，但数据库那边查询显示并没有那么多实际在执行的SQL。

这说明什么？说明有连接泄漏——应用拿走了连接，但从来没还回来。

怎么查？我开启了HikariCP的泄漏检测：

leakDetectionThreshold=60000  # 如果一个连接被占用超过60秒，就认为是泄漏

然后我看到了堆栈信息，顺藤摸瓜，发现是某个同事在filter里写了这么一段：

public void doFilter(...) {
    Connection conn = dataSource.getConnection();
    if (someCondition) {
        return; // 啊，连接泄漏了！
    }
    chain.doFilter();
    conn.close();
}

当someCondition为true的时候，直接return了，conn没还回去。这种bug在代码里藏得很深，不靠泄漏检测根本发现不了。

第四个教训：高并发下的连接池黑洞

好了，上面都是小场面，现在说个大的。

有一次我们搞促销，流量突然暴增10倍。结果数据库连接池直接被打爆，接口响应时间从200ms变成了20秒。

问题在哪？我分析了一下，发现问题不是连接池配置太小，而是——请求太多了。

每个请求都要从连接池拿连接，假设平均每个请求处理时间是100ms，那一个连接1秒能处理10个请求。20个连接，每秒最多处理200个请求。但流量高峰是每秒500个请求。

500-200=300个请求在排队等连接，等着等着就超时了。

怎么解决？三个思路：

1. 优化SQL，让每个请求占用连接的时间更短

-- 加索引
CREATE INDEX idx_user_id ON orders(user_id);

-- 避免 SELECT *
SELECT id, amount, status FROM orders WHERE user_id = ?;

-- 用批量操作减少数据库往返
INSERT INTO items(name) VALUES (?), (?), (?);

2. 把耗时操作异步化，不要在请求处理线程里干

@Async
public void sendEmailAsync(String to, String content) {
    // 发邮件，不占用连接池
}

3. 用本地缓存扛住读请求，减少数据库压力

@Cacheable("user")
public User getUser(Long userId) {
    return userDao.findById(userId);
}

最后的忠告

说了这么多，总结一下连接池的正确打开方式：

1. 连接池大小不是越大越好，按公式算，按实际调
2. 一定要配置timeout，防止连接泄漏杀死你
3. 用try-with-resources，确保连接一定归还
4. 开启泄漏检测，这玩意儿能救你一命
5. 流量大了连接池不够用？先优化SQL，再考虑扩容

连接池就像生活中的钱包——不是越大越好，而是够用就行。配置得当你就能从容应对各种场景，配得不好迟早翻车。

希望我的这些翻车经历能给你一些启发。毕竟，别人踩过的坑才是最好的教材。

如果你也有连接池相关的血泪史，欢迎留言区分享，让大家一起乐——啊不对，一起学习。