遇到一个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类型的对象中。

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQveGlleXVvb28=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="" />

以下来分析这几个问题：这个对象是干什么的？在什么时候创建的？何时回销毁？坑在那里？

这个对象是干什么的？在什么时候创建的？

这个对象是用于将运行中的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加锁对队列进行处理，这样也会带来一定得系统开销，所以呢依据实际场景假设能够不使用的情况下可尽量避免使用。