深入剖析Druid连接异常，化解应用数据库死锁隐患

背景

1.1 现象

2021.12.16 凌晨，我们的应用数据库因故发生了主备切换，之后某个 Pod 就持续报错 GetConnectionTimeoutException，并且该 Pod 的进程也逐渐累积。最终导致应用无法正常提供服务，给业务造成了不小的影响。

1.2 追溯源头

为了快速定位问题根源，我们立刻对Pod进行了日志排查，从中发现问题源自Druid数据源，抛出了以下异常：

com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after connection closed.

这表明连接已经关闭，但还被某些地方使用着，从而造成了线程阻塞。由此我们判断，问题可能出在Druid连接池的配置上。

2. 故障分析

2.1 配置探因

我们进一步对Druid的配置进行了详细检查，发现了一个可能导致问题的设置：maxWait。这个参数表示在连接池中等待可用连接的最大时间，默认值为30秒。在我们的案例中，maxWait 被错误地设置为0，这意味着连接池在检测到没有可用连接时将立即抛出 GetConnectionTimeoutException 异常，而不是等待可用连接。

2.2 线程池隐患

除了maxWait配置问题，我们还发现应用使用了Spring Boot的异步线程池，但没有对线程池进行合理的配置。这导致当应用并发量较高时，线程池中的线程可能无法及时释放，从而造成线程阻塞。

3. 解决方案

3.1 优化连接池配置

针对maxWait参数的配置错误，我们将maxWait设置为一个合理的值，例如30秒。这样，当连接池中没有可用连接时，连接池将等待30秒，然后才抛出 GetConnectionTimeoutException 异常。

3.2 合理配置线程池

为了避免线程阻塞问题，我们对应用的异步线程池进行了合理配置，包括设置合理的线程池大小、队列大小以及拒绝策略。通过这些调整，我们确保了线程池能够及时释放线程，避免线程阻塞。

4. 总结与反思

通过对问题的排查与解决，我们深刻认识到合理配置连接池和线程池的重要性。在应用开发过程中，需要对这些组件进行充分的了解和优化，以避免类似问题的再次发生。

4.1 经验教训

通过此次故障分析，我们吸取了以下经验教训：

• 仔细检查数据库连接池的配置，确保各项参数合理。
• 合理配置应用的线程池，包括线程池大小、队列大小以及拒绝策略。
• 定期对应用进行压力测试，以发现潜在的问题。
• 在生产环境中对新功能进行充分的测试，以避免问题发生。

4.2 技术赋能

为了进一步提升应用的稳定性和可靠性，我们计划采用以下技术手段：

• 使用更强大的监控工具，实时监测应用的性能和健康状况。
• 采用更健壮的数据库连接池，以提高连接池的稳定性。
• 引入更先进的线程池管理框架，以实现更精细的线程池管理。

5. 结语

通过此次故障分析，我们对Druid连接异常的原因有了更深入的了解，并采取了有效的解决方案来解决问题。同时，我们也吸取了宝贵的经验教训，并制定了相应的技术赋能计划，以进一步提升应用的稳定性和可靠性。