一、问题
在某次促销活动之前,突然收到生产环境的报警,有个后台应用出现了大量的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));
来创建线程池,顺利解决。