通常来说，各种技术实现的优化参数或者选项或者歪门邪道之所以能被想出来，通常是因为开发者或者实现的贡献者曾经遇到过导致此结果的问题，所以才出了对应的策略选项。

在有些情况下，比如存在客户端或者服务端连接级别内存泄漏或者资源不释放，但是在较短的周期内无法解决的时候亦或是从经济角度或其他角度我们不愿意更改和修复的时候，公司当前版本的某个关键性产品就存在这么个问题，因为在存储过程中使用了不计其数的prepare动态SQL，而mysql在此实现上存在着服务端连接的内存泄露，起初我们通过将空闲连接数设置为0缓解了很大一部分线上问题，由于行情以及业务量的快速增长，在一些繁忙的节点最终为了高吞吐量将最大连接数设置的很大，由于业务一直运行，导致连接长时间处于非空闲状态，又导致了部分线上问题。

最终我们选择设置连接的最长生命周期来缓解这个问题，根治这个问题需要等系统全部迁移到公司自主研发的新的中间件平台后。因为c3p0是早期一直在用的，后来部分切换成了dbcp。故在此说明c3p0和dbcp分别如何解决。

c3p0:maxConnectionAge 参数，http://www.mchange.com/projects/c3p0/#maxConnectionAge

dbcp: dbcp 1.x版本没有提供开放选项。

dbcp2:可以变相的通过设置lifo=true来达到更为接近的目标。

jdbc连接池c3p0/dbcp强制连接超过设置时间后失效