遇到一个MySQL JDBC的queryTimeout的坑，比较恶心，算是它的BUG，也可以不算，^_^，为啥这么说？看一下下面的解释：
现象：
用同一个Connection执行大批量SQL的时候，导致了OOM现象。
细节现象描述：
1、SQL是从某个存储设备上拿到的，不会直接占用大量的内存，每次只会取最多1千条数据过去，也会判定容量不超过多少M。
2、每一批SQL执行会单独创建Statement对象，执行一批SQL后，会将这个Statement关闭掉。
3、SQL语句中只有insert，没有其它的语句。
疑问：
这尼玛是什么蛋疼的问题？所有代码也review并debug过，参数是自己理想状态，看了下MySQLJDBC中的StatementImpl.close()的代码会清理掉相应的结果集以及数据，不会留下啥垃圾。
dump内存：
dump内存后发现几十万个CancelTask对象，它是StatementImpl的内部类，最终会放到ConnectionImpl中的一个静态Timer类型的对象中。
下面来分析这几个问题：这个对象是干什么的？在什么时候创建的？何时回销毁？坑在那里？
这个对象是干什么的？在什么时候创建的？
这个对象是用于将执行中的SQL取消掉的任务对象，当SQL执行前，通过Statement.setQueryTimeout(int)时（参数单位为秒），这个参数的值只要不是0，它就会在JDBC内部与MySQL通信前会创建一个任务，这个任务会放入到一个Timer的任务队列中（请参看博客中专门介绍Timer与TimerTask的文章）。
它何时回被销毁呢？
1、如果SQL语句在CancelTask还未被Timer调度前响应，则会在JDBC代码中执行调用CancelTask.cancel()方法。
2、如果SQL语句一直未响应，CancelTask在达到设置的设置的timeout值时会一般会被Timer调度，如果已经是cancel状态不执行取消SQL执行操作，直接从队列中移除，如果CancelTask还没有被cancel，则会向MySQL发送相应的取消命令，让其回收资源。Timer在调度这个任务的时候CancelTask内部会创建新的线程来处理，因此Timer很快就会认为任务执行完了，也就是和取消SQL本身的时间无关，Timer也会将这个任务对象从队列中移除，因为这个任务并不是循环执行的。
似乎销毁也是很完善的，那么坑到底在那里呢？
1、根据业务需要，这个Statement.setQueryTimeout(int)这个值设置得非常大。
2、当大批量的SQL同时执行时，每一个SQL都会创建一个CancelTask对象，虽然很快执行完，且会调用CancelTask.cancel()方法，但是CancelTask方法的源代码仅仅是将自己的状态修改为：CANCELLED，而并不会直接从队列中移除这个对象，只有等到超过queryTimeout的值时被Timer调度，才会从队列中移除。
3、因此大批量的SQL同时运行时，并很快结束时，JDBC中存放了大量的CancelTask的生命周期如果自己不结束，这个对象是和Timer相关，那么Timer是什么级别的呢？
4、经过源码跟踪，虽然Timer定义在Connection中，但是static修饰的，也就是是全局级别的，换句话说：即使将这个Connection.close()，也不会释放掉这些CancelTask对象所占用的空间。
5、通过上面dump内存图看到，每一个CancelTask对象会占用7K左右的空间，29W个对象就会占用将近2G空间。
结论：只要在timeout值没有达到之前，超过一定数量的SQL被执行（不分单线程还是多线程），内存肯定就蹦了。
临时性的解决方法：
对某些大批量的SQL执行入口不设置timeout，或设置时间非常短的timeout，这个要根据实际场景来讲。
但这样可能会带来更多的问题，所以会陷入一个圈子中。终极方案有点蛋疼，因为这个取舍问题有点麻烦，哥有点想把源代码的这一块改一改，给官网提交了不少BUG，认可了，但没见他们改过。本文只是先让大伙知道有这么一个坑存在。
下面简单贴几小段MySQL JDBC的源码，有兴趣可以看下：
《代码段1：设置QueryTimeout》
public void setQueryTimeout(int seconds) throws SQLException {
if (seconds < 0) {
throw SQLError.createSQLException(Messages
.getString("Statement.21"), //$NON-NLS-1$
SQLError.SQL_STATE_ILLEGAL_ARGUMENT); //$NON-NLS-1$
}
this.timeoutInMillis = seconds * 1000;
}
《代码段2：如果这个timeout不是0，就会创建一个新的Task》
if (locallyScopedConn.getEnableQueryTimeouts() &&
this.timeoutInMillis != 0
&& locallyScopedConn.versionMeetsMinimum(5, 0, 0)) {
timeoutTask = new CancelTask(this);
ConnectionImpl.getCancelTimer().schedule(timeoutTask,this.timeoutInMillis);
}
《代码段3：SQL执行完会调用Cancel.cancel()方法》
if (timeoutTask != null) {
timeoutTask.cancel();
}
《代码段4：java.util.Timer的添加任务到队列中的关键部分回顾》
void add(TimerTask task) {
// Grow backing store if necessary
if (size + 1 == queue.length)
queue = Arrays.copyOf(queue, 2*queue.length);
queue[++size] = task;
fixUp(size);
}
《代码段5：TimerTask是CancelTask的父类，其的cancel方法主要就是为了设置状态》
public boolean cancel() {
synchronized(lock) {
boolean result = (state == SCHEDULED);
state = CANCELLED;
return result;
}
}
关于Timer调度部分的源码我就不贴了，以前在其它文章中有描述。
现在我们回过来说为啥算BUG也不算呢？不算BUG的解释可能是Java本身的TimerTask的cancel()方法就没有从队列中移除，MySQL JDBC只是调用一下而已，它可能会认为Java应该可以处理好资源问题。
算BUG就是将问题反过来，Java是基础组件，它这样设计有它的初衷（要从队列中取找比较麻烦，因为是用数组做的，需要遍历，而且是全局加锁状态，换成Map的话对它的改造代价很大，因为它是一种有优先级顺序的队列调度模式，用数组是比较简单的方式来实现）。Java既然这样设计了，使用者就应该了解它的细节，至少cancel()后需要purge一下，虽然这个purge过程会遍历一次所有的任务，但是只要任务数可控，随时在清理，遍历一次也是可以的。所以也可以算是使用问题，如果MySQL JDBC觉得不好，应该自己写一个调度器，也不麻烦，如果自己不想写这部分代码，应该可以将它作为一个动态入口参数，我们程序员可以自己在发现这样的问题后，去编写一个调度器，MySQL JDBC通过反射加载我们的调度器，只要符合TimerTask的调度规范即可，但这几条路完全走不通，希望以后MySQL JDBC在这方面能够有所改进。现在只能暂时性傻眼地绕开这些问题，逼急了就只能改源代码了。