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

那么针对以上错误跟踪 C3P0 源码，以及在网上搜索资料发现 C3P0 在大并发下表现的性能不佳。

线程池使用不当引起

以上代码的场景是每一次并发请求过来，都会创建一个线程，将 DUMP 日志导出进行分析发现，项目中启动了一万多个线程，而且每个线程都极为忙碌，彻底将资源耗尽。

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

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

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

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

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

修改完成以后，并发量重新上升到 100 以上 TPS，但是当并发量非常大的时候，项目 GC（垃圾回收能力下降），分析原因还是因为 Executors.newFixedThreadPool(50) 这一行，虽然解决了产生无限线程的问题，但是当并发量非常大的时候，采用 newFixedThreadPool 这种方式，会造成大量对象堆积到队列中无法及时消费，看源码如下：

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

最终线程池技术方案

方案一

注：因为服务器的 CPU 只有 4 核，有的服务器甚至只有 2 核，所以在应用程序中大量使用线程的话，反而会造成性能影响，针对这样的问题，我们将所有异步任务全部拆出应用项目，以任务的方式发送到专门的任务处理器处理，处理完成回调应用程序器。后端定时任务会定时扫描任务表，定时将超时未处理的异步任务再次发送到任务处理器进行处理。

方案二

使用 AKKA 技术框架，下面是我以前写的一个简单的压测情况：

4、日志打印问题

先看下面这段日志打印程序：

像这样的代码是严格不符合规范的，虽然每个公司都有自己的打印要求。

首先日志的打印必须是以 logger.error 或者 logger.warn 的方式打印出来。

日志打印格式：[系统来源] 错误描述 [关键信息]，日志信息要能打印出能看懂的信息，有前因和后果。甚至有些方法的入参和出参也要考虑打印出来。

在输入错误信息的时候，Exception 不要以 e.getMessage 的方式打印出来。

合理的日志格式是：

我们在程序中大量的打印日志，虽然能够打印很多有用信息帮助我们排查问题，但是更多是日志量太多不仅影响磁盘 IO，更多会造成线程阻塞对程序的性能造成较大影响。

在使用 Log4j1.2.14 版本的时候，使用如下格式：

%d %-5p %c:%L [%t] - %m%n

那么在压测的时候会出现下面大量的线程阻塞，如下图：

再看压测图如下：

原因可以根据 log4j 源码分析如下：

注：Log4j 源码里用了 synchronized 锁，然后又通过打印堆栈来获取行号，在高并发下可能就会出现上面的情况。

于是修改 Log4j 配置文件为：

%d %-5p %c [%t] - %m%n

上面问题解决，线程阻塞的情况很少出现，极大的提高了程序的并发能力，如下图所示：

作者介绍

程超，易宝支付架构师，10 年 Java 工作经验，擅长和感兴趣的技术领域是分布式和大数据方面，目前主要从事金融支付类方向。