Apache Tomcat应用中C3P0疑似死锁问题排查求助

你的推测成立，C3P0的死锁问题根源确实是Hibernate与PostgreSQL的通信故障，后续的Tomcat资源耗尽、httpd进程爆增均为连锁反应，具体分析如下：

一、C3P0死锁的直接原因 #

从C3P0的告警日志可以看到：

[WARN] [Wed Feb 08 05:52:41.589 2023] [C3P0PooledConnectionPoolManager[identityToken->2t53wqaub1kdwl1wutziz|421f447f]-AdminTaskTimer|ThreadPoolAsynchronousRunner] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@578de344 -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks!

所有10个HelperThread都被ScatteredAcquireTask占用——这是C3P0向PostgreSQL发起连接请求的任务。结合你的配置：

• acquireRetryAttempts=0：连接失败后无重试机制
• 所有线程长时间阻塞在连接获取操作上，说明PostgreSQL无法响应连接请求，可能的场景包括：
  • PostgreSQL服务临时中断或重启
  • 数据库连接数达到上限，无法分配新连接
  • 应用服务器与数据库之间的网络出现波动或中断

当C3P0的辅助线程全部被阻塞时，无法处理后续的连接归还刷新任务（RefurbishCheckinResourceTask），导致任务队列堆积，触发C3P0的死锁检测机制。

二、Tomcat资源耗尽的连锁反应 #

C3P0连接池无法提供可用连接后，Tomcat的业务处理线程（如ajp-nio-127.0.0.1-8009-exec-*）会阻塞在等待连接的代码逻辑上，无法释放。随着外部请求持续涌入，Tomcat会不断创建新的业务线程，最终触发：

java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached

此时Tomcat已无法处理任何新请求。

三、httpd子进程爆增的原因 #

httpd作为反向代理，当Tomcat长时间无响应时，会认为当前请求处理超时，进而创建新的子进程来处理后续请求。当所有子进程都卡在等待Tomcat响应的状态时，httpd会持续新建进程，直到达到maxRequestWorkers的上限（500），最终服务器彻底无法处理新请求，陷入死锁。

四、现有配置的优化点 #

你的C3P0与Hibernate配置存在冲突和不合理之处，加剧了故障影响：

1. 配置冲突：C3P0数据源Bean中配置maxPoolSize=20，但Hibernate属性中又配置hibernate.c3p0.maxPoolSize=100，两者冲突，实际生效的是数据源Bean的配置，容易引发混淆。
2. 重试机制缺失：acquireRetryAttempts=0过于激进，数据库短暂波动就会直接导致连接失败，建议调整为3-5次重试。
3. 连接闲置时间过短：maxIdleTime=5意味着连接闲置5秒就会被销毁，会导致连接频繁重建，增加数据库压力，建议调整为300秒以上。

验证与修复建议 #

• 检查PostgreSQL的日志，确认故障时间点是否有连接拒绝、服务中断或连接数耗尽的记录，进一步确认通信故障的具体原因。
• 调整C3P0配置：

  <property name="acquireRetryAttempts" value="3" />
  <property name="maxIdleTime" value="300" />
  

• 统一C3P0配置，删除Hibernate中重复的hibernate.c3p0.maxPoolSize和hibernate.c3p0.min_size配置，避免冲突。

内容的提问来源于stack exchange，提问作者RichardFeynman