一个关于java ExecutorService的故事

手头有一个项目，其中有一个业务项是向某个服务推送/上传 渠道文件。

因为某些原因 这些渠道文件 在推送之前要先从我们的非结构化存储服务上下载下来，然后压缩一下在上传。 这样带来几个问题：

1 下载比较费时间，可以多线程并发减少等待时间

2 压缩很费CPU计算时间，为了控制对CPU的影响可以通过控制压缩 的线程数来减少 发布时cpu的消耗，进而保证服务稳定可用。

因此我们为这个业务引入了一个专用的TheadPoolExecutor ，对其进行资源隔离。

ExecutorService servie = new ThreadPoolExecutorService(8,8,1, TimeUnit.SECONDS,new ArrayBlockingQueue(2048))

for(Artifact artifact: artifacts) {

     service.submit(new Runnable() {

         public void run() {

                 download();

                compress();

                upload();

        }

    });

}

初期只有1200多个渠道文件，

这么运行是没问题的。

后期 渠道文件增加到了 2099个， 每次发布就发现一个现象， 发布到 2058个，日志就不再刷新了。

当时很纳闷，为啥呢？

后来仔细分析代码，发现自己还是没有完全搞清楚这个 executor的submit

submit任务时， 如果超出队列长度，默认的策略是拒绝策略（AbortPolicy），该策略被触发时会直接抛一个RejectedExecutionException。

我队列长度2048， 添加过程中部分任务已经被执行，添加到2058之后 队列满了，触发 AbortPolicy，抛异常了。 我的外围 for 循环也没有异常捕捉，所以被打断了。

所以这个有以下教训：

1   提交到 executor service 最好预估好 任务量，根据任务量来定义好足够的 缓冲队列长度

2  如果队列长度很容易被打满，定义好自己的重试策略，比如等5分钟重新提交。

3 一定定义好统一的异常捕捉，有兜底的异常捕捉。 如果执行逻辑是提交到线程池开始的，以避免阻塞主处理线程的，那这样主线程的异常处理逻辑就无法捕捉到对应的异常。 需要自己在提交异步处理时定义好异常处理。