线程池阻塞队列长度设置失误导致任务一直被阻塞未能执行

1、生产环境中有个接口耗时比较久，然后自己的阻塞队列没有设置默认值，导致后续提交过来的任务一直在阻塞队列中，具体代码如下

 
@Slf4j
@RestController
@RequestMapping(value = "/vman/task/run/")
public class RunTask2Controller {
    // 阻塞队列没有设置，则默认是Integer.MAX_VALUE，而核心线程数是1，会导致后续提交的任务一直放在队列里
    private final ExecutorService executorService = new ThreadPoolExecutor(1,5, 180L, TimeUnit.SECONDS,
            new LinkedBlockingQueue(), new ThreadFactoryBuilder().setNameFormat("thread-repeater-run-%d").build());
    private ExecutorService repeaterExecutorService = TransferExecutors.getTtlExecutorService(executorService);
 
    @RequestMapping(value = "/run_job2", method = RequestMethod.GET)
    public BasicResult runTask2(@RequestParam(value = "id") String id) throws SQLException {
        BasicResult<RunTaskResult> basicResult = new BasicResult<>();
        final String userName = UserInfoHolder.getUserOa();
        log.info("run_job请求参数信息1,userName:{},id:{}", userName, JSONObject.toJSONString(id));
        repeaterExecutorService.execute(new Runnable() {
            @Override
            public void run() {
                log.info("run_job请求参数信息2,userName:{},id:{}", userName, JSONObject.toJSONString(id));
                try {
                    Thread.sleep(10000000);
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
            }
        });
        basicResult.setCodeMessage("0", "任务执行中");
        return basicResult;
    }
}

2、线程池的执行逻辑

1. 如果workerCount < corePoolSize，则创建并启动一个线程来执行新提交的任务；
2. 如果workerCount >= corePoolSize，且线程池内的阻塞队列未满，则将任务添加到该阻塞队列中；
3. 如果workerCount >= corePoolSize && workerCount < maximumPoolSize，且线程池内的阻塞队列已满，则创建并启动一个线程来执行新提交的任务；
4. 如果workerCount >= maximumPoolSize，并且线程池内的阻塞队列已满, 则根据拒绝策略来处理该任务, 默认的处理方式是直接抛异常。

3、更加上述线程池执行逻辑，因为业务执行很长时间，而阻塞队列设置很大，则导致后续提交的任务都放到阻塞队列了，从而导致任务挤压。改进措施，根据任务执行时间合理设置LinkedBlockingQueue的大小，比如设置20个，最大线程数也设置大点。

Java线程池实现原理及其在美团业务中的实践 - 美团技术团队