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

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 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,并且线程池内的阻塞队列已满, 则根据拒绝策略来处理该任务, 默认的处理方式是直接抛异常。

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

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

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

你可能感兴趣的:(java,前端,服务器)