遇到一个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;
}

if (locallyScopedConn.getEnableQueryTimeouts() &&
	this.timeoutInMillis != 0
	&& locallyScopedConn.versionMeetsMinimum(5, 0, 0)) {
	timeoutTask = new CancelTask(this);
	ConnectionImpl.getCancelTimer().schedule(timeoutTask,this.timeoutInMillis);
}

if (timeoutTask != null) {
	timeoutTask.cancel();
}

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);
}

public boolean cancel() {
        synchronized(lock) {
            boolean result = (state == SCHEDULED);
            state = CANCELLED;
            return result;
        }
    }

现在我们回过来说为啥算BUG也不算呢？不算BUG的解释可能是Java本身的TimerTask的cancel()方法就没有从队列中移除，MySQL JDBC只是调用一下而已，它可能会认为Java应该可以处理好资源问题。

算BUG就是将问题反过来，Java是基础组件，它这样设计有它的初衷（要从队列中取找比较麻烦，因为是用数组做的，需要遍历，而且是全局加锁状态，换成Map的话对它的改造代价很大，因为它是一种有优先级顺序的队列调度模式，用数组是比较简单的方式来实现）。Java既然这样设计了，使用者就应该了解它的细节，至少cancel()后需要purge一下，虽然这个purge过程会遍历一次所有的任务，但是只要任务数可控，随时在清理，遍历一次也是可以的。所以也可以算是使用问题，如果MySQL JDBC觉得不好，应该自己写一个调度器，也不麻烦，如果自己不想写这部分代码，应该可以将它作为一个动态入口参数，我们程序员可以自己在发现这样的问题后，去编写一个调度器，MySQL JDBC通过反射加载我们的调度器，只要符合TimerTask的调度规范即可，但这几条路完全走不通，希望以后MySQL JDBC在这方面能够有所改进。现在只能暂时性傻眼地绕开这些问题，逼急了就只能改源代码了。

MySQL JDBC的queryTimeout的一个坑