MySQL JDBC的queryTimeout的一个坑

来源:互联网 发布:工作流软件 编辑:程序博客网 时间:2024/06/05 15:15


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

[java] view plaincopyprint?
  1. public void setQueryTimeout(int seconds) throws SQLException {  
  2.     if (seconds < 0) {  
  3.         throw SQLError.createSQLException(Messages  
  4.             .getString("Statement.21"), //$NON-NLS-1$  
  5.                 SQLError.SQL_STATE_ILLEGAL_ARGUMENT); //$NON-NLS-1$  
  6.     }  
  7.   
  8.     this.<strong>timeoutInMillis </strong>= seconds * 1000;  
  9. }  

《代码段2:如果这个timeout不是0,就会创建一个新的Task》

[java] view plaincopyprint?
  1. if (locallyScopedConn.getEnableQueryTimeouts() &&  
  2.     this.timeoutInMillis != 0  
  3.     && locallyScopedConn.versionMeetsMinimum(500)) {  
  4.     <strong>timeoutTask = new CancelTask(this);  
  5.     ConnectionImpl.getCancelTimer().schedule(timeoutTask,this.timeoutInMillis);</strong>  
  6. }  
《代码段3:SQL执行完会调用Cancel.cancel()方法》
[java] view plaincopyprint?
  1. if (timeoutTask != null) {  
  2.     timeoutTask.cancel();  
  3. }  
《代码段4:java.util.Timer的添加任务到队列中的关键部分回顾》

[java] view plaincopyprint?
  1. void add(TimerTask task) {  
  2.         // Grow backing store if necessary  
  3.         if (size + 1 == queue.length)  
  4.         queue = Arrays.copyOf(queue, 2*queue.length);  
  5.   
  6.         queue[++size] = task;  
  7.         fixUp(size);  
  8. }  
《代码段5:TimerTask是CancelTask的父类,其的cancel方法主要就是为了设置状态》

[java] view plaincopyprint?
  1. public boolean cancel() {  
  2.         synchronized(lock) {  
  3.             boolean result = (state == SCHEDULED);  
  4.             state = CANCELLED;  
  5.             return result;  
  6.         }  
  7.     }  

关于Timer调度部分的源码我就不贴了,以前在其它文章中有描述。


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


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

0 0