这个是mysql的一个定时任务的，这个定时任务主要作用是在用于做查询超时的。简单举个例子，系统在执行一个sql查询情况下，jdbc会给你一个超时时间。为了保证超时时间后，可以关闭statement，会打开一个保护关闭的定时任务。如果超时情况下，sql还没响应执行，cancel task就会执行关闭任务。因为c3p0的默认设置的超时时间为25s（<setting name="defaultStatementTimeout" value="25000" />）,意味这个25s内，在执行大量sql情况下，cancel task积压到了一定程度，就会造成系统不稳定。（最后发现这个并不是根本原因，只是表象）

但是系统本身就有通过mysql做发送队列的，本身对mysql操作非常多，如果只是对代码层面下优化基本杯水车薪。

在时间紧迫的情况下，短时间内稳定业务才是最重要的任务。被逼根据以上现状采用了临时方案解决。

临时方案

通过以上判断，基本可以判定cancel task在某组线程执行应该会形成一个峰值，撑爆了JVM的堆。但是现在无法在停止业务运行做过多调试，所以当机立断，对JVM的内存扩大一倍以上，希望系统可以跨过一波内存峰值。结果把JVM的内存调整为故障时候的2倍时候，系统的内存又恢复到正常运作，不过cancel task最高值会占用到内存2G以上。虽然也是会回收，但是一直扩内存不是很好的办法。

解决方案

系统采用的mysql jdbc 5.1.6的版本，立刻反编译mysql代码，发现以下问题。因为cancel task的timer在connection中静态存放，意味statement如果正常查询出结构，业务无法把cancel task内存回收才是故障根本原因。

明确问题在mysql jdbc上面后，根本解决办法应该查询mysql jdbc是否解决了这个bug。

在5.1.11版本中找到这个bug的修复，更新后，内存泄漏故障得到解决。http://dev.mysql.com/doc/relnotes/connector-j/en/news-5-1-11.html

感谢国波与锐康的讨论及协助，使故障得以完满解决！