一段JAVA线程池的设置引发的血案

最新推荐文章于 2025-08-31 20:17:26 发布

原创最新推荐文章于 2025-08-31 20:17:26 发布 · 205 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #java

java基础专栏收录该内容

55 篇文章

订阅专栏

本文详细阐述了一个项目在进行线上压力测试时遇到的性能瓶颈，从数据库连接池问题出发，深入分析并优化了线程池配置。通过更换连接池类型、调整线程池大小和优化代码实现，成功提升了系统并发处理能力，揭示了在使用线程池时需要注意的关键细节。

应公司需求我们对一个项目进行了线上压力测试，结果发现，三台服务器一共只有59TPS，结果惨不忍睹。

那么针对这样的场景，我们利用一周时间进行专注性的优化，寻找性能的瓶颈点。

第一步：我们针对线上的环境进行模拟，尽量真实的在测试环境中再现，采用数据库连接池为咱们默认的C3P0。

那么当压测到二万批，100个用户同时访问的时候，并发量突然降为零！报错如下：

Could not get JDBC Connection; nested exception is java.sql.SQLException: An attempt by a client to checkout a Connection has timed out.

针对以上错误跟踪C3P0源码，以及在网上搜索资料（http://blog.sina.com.cn/s/blog_53923f940100g6as.html）发现，C3P0在大并发下表现的性能不佳。

第二步：针对这个问题进行数据库连接池优化，更换了BoneCPDataSource，以及Apache BasicDataSource后，发现报错如下：

java.lang.OutOfMemoryError: unable to create new native thread, dubbo version: 2.5.4, current host: 192.168.122.1
java.lang.OutOfMemoryError: unable to create new native thread

第三步：由此可以判断，问题不在于连接池的问题，于是在压测的时候，将DUMP日志导出进行分析发现，项目中启动了一万多个线程，而且每个线程都极为忙碌，彻底将资源耗尽。

于是迅速定位到代码，发现如下代码：

private static final ExecutorService executorService = Executors.newCachedThreadPool();
/**
* 异步执行短频快的任务
* @param task
*/
public static void asynShortTask(Runnable task){
executorService.submit(task);
//task.run();
}

           CommonUtils.asynShortTask(new Runnable() {
                @Override
                public void run() {
                    String sms = sr.getSmsContent();
                    sms = sms.replaceAll(finalCode, AES.encryptToBase64(finalCode, ConstantUtils.getDB_AES_KEY()));
                    sr.setSmsContent(sms);
                    smsManageService.addSmsRecord(sr);
                }
            });

那么问题到底在哪里呢？？？就在这一行！

private static final ExecutorService executorService = Executors.newCachedThreadPool();

在并发的情况下，无限制的申请线程资源造成性能严重下降，在图表中显抛物线形状的元凶就是它！！！那么采用这种方式最大可以产生多少个线程呢？？答案是：Integer的最大值！看如下源码：

public static ExecutorService newCachedThreadPool(ThreadFactory threadFactory) {
    return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                  60L, TimeUnit.SECONDS,
                                  new SynchronousQueue<Runnable>(),
                                  threadFactory);
}

那么尝试修改成如下代码：

private static final ExecutorService executorService = Executors.newFixedThreadPool(50);

修改完成以后，并发量重新上升到100以上TPS，但是当并发量非常大的时候，项目GC（垃圾回收能力下降），分析原因还是因为 Executors.newFixedThreadPool(50)这一行，虽然解决了产生无限线程的问题，但是

当并发量非常大的时候，采用newFixedThreadPool这种方式，会造成大量对象堆积到队列中无法及时消费，看源码如下：

public static ExecutorService newFixedThreadPool(int nThreads) {
    return new ThreadPoolExecutor(nThreads, nThreads,
                                  0L, TimeUnit.MILLISECONDS,
                                  new LinkedBlockingQueue<Runnable>());
}

可以看到采用的是无界队列，也就是说队列是可以无限的存放可执行的线程，造成大量对象无法释放和回收。

结论：

目前我们的项目还在持续优化中，还没有最终优化完成，目标是要把项目优化完善，但此次事件，再次提醒我们，在使用线程池的时候，一定要把握其细节，深入了解其原理再使用，不要随意使用，任何线程池的使用方式都有不同的使用场景，并不是只要使用了线程池就万事大吉，还有很多工作需要我们去注意。