遇到一个MySQL JDBC执行execute方法时指定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调度，才会从队列中移除。

注意：在MySQL JDBC 5.1.13版本有一个purge操作，但是这个操作对execute方法存在BUG，因为它在这个方法的try里面执行了这部分代码：

if (timeoutTask != null) {
if (timeoutTask.caughtWhileCancelling != null) {
    throw timeoutTask.caughtWhileCancelling;
}

timeoutTask.cancel();
timeoutTask = null;
}

这里将timeoutTask设置为null了，但没有purge，导致了一个问题就是在finally里面不会进入if语句，从而不会执行purge操作，也会导致问题，这个问题一直延续到现在的最新版本5.1.34。不过executeQuery、executeUpdate方法是在5.1.13版本后修复了这个问题。

3、因此大批量的SQL同时运行时，并很快结束时，JDBC中存放了大量的CancelTask的生命周期如果自己不结束，这个对象是和Timer相关，那么Timer是什么级别的呢？

4、经过源码跟踪，虽然Timer定义在Connection中，但是static修饰的，也就是是全局级别的，换句话说：即使将这个Connection.close()，也不会释放掉这些CancelTask对象所占用的空间。（MySQL JDBC 于5.1.11版本修改为非静态成员变量，但是这个版本还没有做purge，因此还没有真正解决问题，关于5.1.13增加purge请参看上面的说明，而另外需要注意的是修改为非静态成员后，每一个连接都会有一个单独的线程Timer在后台运行，因此在设计上可能需要注意些什么）。

5、通过上面dump内存图看到，每一个CancelTask对象会占用7K左右的空间，29W个对象就会占用将近2G空间。

结论：只要在timeout值没有达到之前，超过一定数量的SQL被执行（不分单线程还是多线程），内存肯定就蹦了。

临时性的解决方法：

对某些大批量的SQL执行execute方法入口不设置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调度部分的源码我就不贴了，以前在其它文章中有描述。

总结下：

1、5.1.11版本后将Timer改为非静态成员，和Conenction绑定，但没有做purge操作，因此没有真正解决问题。另外，每一个连接都会在后台多一个线程出来。

2、5.1.13版本在finally以及相应执行完成部分添加了purge回收资源操作，但是对于execute方法是存在BUG的，这个BUG延续到现在最新版本5.1.34对于executeUpdate、executeQuery方法是可以正常完成了。

3、虽然已经可以顺利完成purge，但要考虑一下这个顺利完成的代价是不断地通过synchonized加锁对队列进行处理，这样也会带来一定得系统开销，所以呢根据实际场景如果能够不使用的情况下可尽量避免使用。