TaskRejectedException: Executor [java.util.concurrent.ThreadPoolExecutor@75bc9f01[Running, pool size
我们在做性能测试的时候，按照梯度来施加压力，每个阶段维持10到20分钟，直到服务器资源耗尽，各个模块的服务都没有出现问题；然后就开始做72小时的稳定性测试，仅仅过了一晚上，差不多十个小时左右，就发现有服务OOM 无法正常进行数据处理了。
TaskRejectedException: Executor [java.util.concurrent.ThreadPoolExecutor@75bc9f01[Running, pool size
代码中线程池的配置如下：
@Value("${threadPool.maximumPoolSize}")
private int maxThraedCount = 20;
@Value("${threadPool.queueSize}")
private int maxQueueSize = 2000;
@Value("${threadPool.corePoolSize}")
private int corePoolSize = 5;
@Value("${threadPool.keepAliveTime}")
private int keepAliveTime = 60;
@Value("${alarmSending.timeout}")
private int alarmSendTimeOut_ms = 5 * 1000;
/**
* The thread pool used to send alarms
*/
private ThreadPoolTaskExecutor threadPool;
@PostConstruct
private void init(){
threadPool = new ThreadPoolTaskExecutor();
threadPool.setCorePoolSize(corePoolSize);
threadPool.setMaxPoolSize(maxThraedCount);
threadPool.setThreadGroupName("EventManager");
threadPool.setThreadNamePrefix("alarmSend");
threadPool.setQueueCapacity(maxQueueSize);
threadPool.setKeepAliveSeconds(keepAliveTime);
threadPool.setRejectedExecutionHandler((r, executor) -> {
throw new RejectedExecutionException();
});
threadPool.initialize();
}ThreadPoolTaskExecutor的参数：
int corePoolSize:线程池维护线程的最小数量.
int maximumPoolSize:线程池维护线程的最大数量.
long keepAliveTime:空闲线程的存活时间.
TimeUnit unit: 时间单位,现有纳秒,微秒,毫秒,秒枚举值.
BlockingQueue<Runnable> workQueue:持有等待执行的任务队列.
RejectedExecutionHandler handler: 用来拒绝一个任务的执行，有两种情况会发生这种情况。
一是在execute方法中若addIfUnderMaximumPoolSize(command)为false，即线程池已经饱和；
二是在execute方法中, 发现runState!=RUNNING || poolSize == 0,即已经shutdown,就调用
ensureQueuedTaskHandled(Runnable command)，在该方法中有可能调用reject。开始解决这个问题的时候，想得简单了，想着是不是线程池给得小了，或者是workQueue给的小了？但是扩大了maxPool和workQueue后只是多坚持了几个小时就再次OOM了，冷静下来仔细想想💭；
既然当时压力测试的时候的压力都顶住了，到了稳定性测试却出问题了，可能就不是线程池本身的原因了，可能是长时间的运行有哪些代码new的对象没有被GC回收掉，或者线程没有释放，或者队列中堆积了大量无法处理的任务。。。猜测总归是猜测，还是得看看问题得根本。。。
@Override
public void messageArrived(String topic, MqttMessage mqttMessage) throws Exception {
threadPool.execute(() -> handleMessage(topic, mqttMessage));
}
## 开始在这个地方也猜测是不是有问题，但是来来回回几次都排除掉了这里的可能，觉得应该没啥问题啊。。。直到进入到handleMessage方法时，发现果然是有点‘东西’的。。。
private void handleMessage(String topic, MqttMessage mqttMessage) {
String message = gson.toJson(uplinkRequest);
//TODO There is a risk of OOM and frequent GC in the case of high concurrency
/*RestTemplate restTemplate = new RestTemplate();
HttpHeaders headers = new HttpHeaders();
headers.add("Connection", "Keep-Alive");
headers.add("Authorization", http_header);
headers.setContentType(MediaType.APPLICATION_JSON);*/
HttpEntity request = new HttpEntity(message, headers);
}可以看到在我注释TODO的地方，等于在每一个handleMessage方法，也就是每一个线程里都new了个RestTemplate和HttpHeaders，按照每秒600~1000的数据压力，10几个小时，可不早就OOM了嘛，可能跟我不喜欢修改别人的代码的习惯有关，请示了领导后，修改完代码再次测试下来，问题就再没有出现了。
回想起来还是比较庆幸的，幸亏做了稳定性测试，要是只做了压力测试想着每秒2000都没事，每秒600怎么可能有问题的心态，上线后就傻了，谨记谨记！！！
