记一次生产多线程调优

一、问题

在某次促销活动之前,突然收到生产环境的报警,有个后台应用出现了大量的YGC,赶紧查看系统监控日志,没有什么异常,那是什么原因呢?

二、问题排查

1.登录跳板机,通过top命令查看,有个java的进程CPU占用率过高,ps -ef |grep java发现是应用的进程。

2.通过top -Hp pid可以找出该进程内最耗费CPU的线程。

3.执行printf “%x\n” 线程ID,将线程ID转化为16进制。linux下,所有的java内部线程,其实都对应了一个进程id,也就是说,linux上的sun jvm将java程序中的线程映射为了操作系统进程。

4.通过jstack输出进程(2444)的堆栈信息,然后根据16进制的线程ID过滤结果

jstack 2444 >stack.txt
grep 99b stack.txt

最终发现大量线程阻塞,阻塞的原因是一个多线程任务导致的。查看代码知道,是促销中心一个发券任务导致的。运营在后台批量创建了大量的券。而每次建券之后,后台会通过多线程去将券信息同步到索引库。

而问题代码就出现在创建多线程的地方,是使用的newCachedThreadPool去创建的线程。具体看看newCachedThreadPool内部实现知道,它最大可以创建可以创建最多Integer.MAX_VALUE个线程,最大阻塞时长60s。而同步索引库是一个比较耗时的操作。由于创建的券比较多,线程池会创建大量的线程,一直处于阻塞的状态。
我们知道线程池(Thread Pool)对于限制应用程序中同一时刻运行的线程数很有用。因为每启动一个新线程都会有相应的性能开销,每个线程都需要给栈分配一些内存等等。大量的阻塞线程会消耗大量的资源,导致大量的YGC。

三、解决办法

改为使用:

new ThreadPoolExecutor(2, 4, 60L,
            TimeUnit.SECONDS, 
            new LinkedBlockingQueue<Runnable>(50000)); 

来创建线程池,顺利解决。

猜你喜欢

转载自blog.csdn.net/chengbinbbs/article/details/86708020