解决一个web的项目定时任务入库“卡住”问题

事情的起因是因为我要在一个定时任务的某处将数据入库,一个是批量入库,之后再是非批量的普通方式入库,伪代码如下:

 

for(int i=0; i

 这个定时任务是每隔1min就触发的,频率还蛮高。而且n大约是10,pools为线程池,BatchSaveThread和SaveThread分别为批量入库的线程和普通入库的线程。

 

问题现象:这个定时任务放到环境上跑,发现过个5-7min就会“卡死”,即:批量入库或普通入库都不能持续,普通入库在持续最多7分钟左右就不再进行了。debug发现普通入库的线程会进入,但是就是没法往下执行。

 

解决:其实可以从线程的角度考虑,之前想在定时任务当中,用线程池调配线程的方式异步地入库,但由于批量入库的步骤可能需要的时间较长,所以线程在此处耗费时间较多,以至于在本分钟内没能完成,卡在这导致普通入库那一步也没有完成。

把普通入库和批量入库分为2个定时任务,一前一后的执行。普通入库先执行,在那里for循环中负责生成每次跟循环有关的list,并把他们放到内存中,之后,在晚些时候执行批量入库,再在批量入库的定时任务中for循环,取出每次的list,再针对该List入库。为进一步避免线程问题,可以摈弃异步入库,直接取代原来的入库线程而调用dao的相关入库方法,,后来发现其实也并没有消耗太多时间。

注:

1)内存存取list可以使用ServletContext的setAttribute(String key, Object obj)和getAttribute(key);取完可以removeAttribute(String key)减少内存占用~~;key的设计可以带上for循环里的元素以及时间。

2)mysql中想要真正的executeBatch()起作用,要记得在jdbc的url上加上rewriteBatchedStatements=true才行,否则批量执行是不会起作用的。

改进之后,经过长时间测试发现,无论是数据量较大的批量入库,还是普通入库,都能平稳地运行下去了。

 

顺便补充些小问题:

1.循环一个集合的前提是这个集合不为null,虽然默认情况下是根本不用考虑的,但如果你是通过本例中ServletContext的getAttribute(String key)这种方式,或其他方式得到List——即不是通过常见的定义方式得到的List,在循环它之前,需要做容错处理:if(list != null)再循环哦!

2.在一个定时任务类的属性定义上不要直接带上需要通过bean得到的其他bean类,否则会报空指针异常。比如我在一个定时任务类的的属性上(方法外)这样:

WebApplicationContext ctx = ContextLoader.getCurrentWebApplicationContext();

 或这样:

Dao dao = bean.get(xxxx)

 都会报NullPointerException。之所以不能在方法体外的类属性上直接定义这些,是因为:定时任务类也是被配置成bean的,在Spring容器启动成功之前,整个Spring容器的环境是还未完全搭建成功的,而bean的这些属性会在把它管理之前就扫描到,所以你不能在还未完全搭建Spring环境成功就使用Spring的上下文。——这点需注意,可以延伸到任何一个需要被管理的bean,不能在方法体外部直接使用Spring上下文

 

你可能感兴趣的:(Java,EE)