浅析项目实践接触到的java并发线程池应用场景

---

前言

最近研读《java并发编程之美》这本书8、9、11章关于线程池的部分，有很多新的收获，在此想结合项目经历，总结分析一下实践中对于线程池的应用场景。

---

场景一、营销场景-门店活动信息定时校验

定时执行的数据核对任务需要异步线程池处理，实现定时任务有很多种方式，比如xxl-job、scheduleX等。但是要和ScheduledThreadPoolExecutor的固定频率执行模式区分开，ScheduledThreadPoolExecutor支持三种模式：

chedule(Runnable command, long delay, TimeUnit unit)方法该方法的作用是提交一个延迟执行的任务，任务从提交时间算起延迟单位为unit的delay时间后开始执行。提交的任务不是周期性任务，任务只会执行一次，代码如下。
scheduleWithFixedDelay(Runnable command, long initialDelay, long delay, TimeUnit unit)方法该方法的作用是，当任务执行完毕后，让其延迟固定时间后再次运行（fixed-delay任务）。
scheduleWithFixedDelay(Runnable command, long initialDelay, long delay, TimeUnit unit)方法该方法的作用是，当任务执行完毕后，让其延迟固定时间后再次运行（fixed-delay任务）。

并且Timer也是不合理的，当一个Timer运行多个TimerTask时，只要其中一个TimerTask在执行中向run方法外抛出了异常，则其他任务也会自动终止。当任务在执行过程中抛出InterruptedException之外的异常时，唯一的消费线程就会因为抛出异常而终止，那么队列里的其他待执行的任务就会被清除。所以在TimerTask的run方法内最好使用try-catch结构捕捉可能的异常，不要把异常抛到run方法之外。其实要实现Timer功能，使用ScheduledThreadPoolExecutor的schedule是比较好的选择。如果ScheduledThreadPoolExecutor中的一个任务抛出异常，其他任务则不受影响。

ScheduledThreadPoolExecutor是并发包提供的组件，其提供的功能包含但不限于Timer。Timer是固定的多线程生产单线程消费，但是ScheduledThreadPoolExecutor是可以配置的，既可以是多线程生产单线程消费也可以是多线程生产多线程消费，所以在日常开发中使用定时器功能时应该优先使用ScheduledThreadPoolExecutor。

ScheduledFutureTask是具有返回值的任务，继承自FutureTask。FutureTask的内部有一个变量state用来表示任务的状态，一开始状态为NEW，所有状态为如下，代码涉及到状态转换。

    private static final int NEW          = 0; //初始状态
    private static final int COMPLETING   = 1; //执行中状态
    private static final int NORMAL       = 2; //正常运行结束状态
    private static final int EXCEPTIONAL  = 3; //运行中异常
    private static final int CANCELLED    = 4; //任务被取消
    private static final int INTERRUPTING = 5; //任务正在被中断
    private static final int INTERRUPTED  = 6; //任务已经被中断

先复习一下七大参数以及Worker任务执行流程。

我们基于此创建一个线程池，参数设计需要根据实际业务场景去考虑。
有的时候IO密集型2*N和CPU密集型的(N+1)的理论公式的策略并不一定合理。没有固定答案，先设定预期，比如我期望的CPU利用率在多少，负载在多少，GC频率多少之类的指标后，再通过测试不断的调整到一个合理的线程数。
具体参考京东云开发者社区 https://developer.jdcloud.com/article/3267

    private static final ThreadPoolExecutor EXECUTORS = ThreadPoolUtil.getThreadPool(
            corePoolSize, maximumPoolSize, 0, "DataVerify", queueSize);
         //getThreadPool方法通过new创建获取一个线程池
    public static ThreadPoolExecutor getThreadPool(Integer corePoolSize, Integer maximumPoolSize, long keepAliveTime, String poolName, Integer queues) {
        return new ThreadPoolExecutor(
                corePoolSize, maximumPoolSize, keepAliveTime, TimeUnit.SECONDS,
                new ArrayBlockingQueue<>(queues),
                new NamedThreadFactory(poolName),
                new ThreadPoolExecutor.AbortPolicy());
    }

通常创建线程和线程池时要指定与业务相关的名称，否则日志打印的是线程固定前缀加上递增的全局编号，并发情况下无法区分，具体参考书11.7节的源码讲解。

NamedThreadFactory官方示例，自定义命名线程工厂，方便排查问题

    /**
     * 自定义命名线程工厂,方便排查问题
     */
    static class NamedThreadFactory implements ThreadFactory {
        private static final AtomicInteger poolNumber = new AtomicInteger(1);
        private final ThreadGroup group;
        private final AtomicInteger threadNumber = new AtomicInteger(1);
        private final String namePrefix;
        NamedThreadFactory(String name) {
            SecurityManager s = System.getSecurityManager();
            group = (s ! = null) ? s.getThreadGroup() : Thread.currentThread().
              getThreadGroup();
            if (null == name || name.isEmpty()) {
                name = "pool";
            }
            namePrefix = name + "-" + poolNumber.getAndIncrement() + "-thread-";
        }
        public Thread newThread(Runnable r) {
            Thread t = new Thread(group, r, namePrefix + threadNumber.
              getAndIncrement(), 0);
            if (t.isDaemon())
                t.setDaemon(false);
            if (t.getPriority() ! = Thread.NORM_PRIORITY)
                t.setPriority(Thread.NORM_PRIORITY);
            return t;
        }
    }

下面是具体定时任务执行的部分，通过注入Runnable类型的task经过execute方法交给Worker执行，结构上类似生产-消费模型。

@Override
    public Result process(xxContext context) throws Exception {
        //..............前置处理
        for (Long storeServiceId : allStoreServiceIds) {
            EXECUTORS.execute(() -> {
                try {
                //优惠数据校验 卡券与saas侧的数据一致性compare
                //从Saas云服务ERP系统上拉取最近更新的活动数据
                    dataVerifyService.verify(storeServiceId, startTime, endTime);
                } catch (Exception e) {
                    log.error("xxxxxx", e);
                }
            });
        }
        //所有异步任务提交完成
        log.info("all asyc task submit over");
        return new Result(SUCCESS);
    }

这里顺便介绍一下execute和submmit的区别：
提交任务的类型：
execute和submit都属于线程池的方法，execute只能提交Runnable类型的任务，submit既能提交Runnable类型任务也能提交Callable类型任务。
异常：
execute会直接抛出任务执行时的异常，可以用try、catch来捕获，和普通线程的处理方式完全一致。submit会吃掉异常，可通过Future的get方法将任务执行时的异常重新抛出。也就是execute()方法在执行任务出现异常时，会直接抛出异常，而submit()方法则会捕获异常并封装到Future对象中。我们可以通过调用Future对象的get()方法，来获取执行过程中的异常。
返回值：
execute()没有返回值，submit有返回值，所以需要返回值的时候必须使用submit()方法。
execute和submmit源码分析如下：

    public Future<? > submit(Runnable task) {
        ...
        //（1）装饰Runnable为Future对象
        RunnableFuture<Void> ftask = newTaskFor(task, null);
        execute(ftask);
        //(6)返回Future对象
        return ftask;
    }
        protected <T> RunnableFuture<T> newTaskFor(Runnable runnable, T value) {
        return new FutureTask<T>(runnable, value);
    }
  public void execute(Runnable command) {
        ...
        //(2) 如果线程个数小于核心线程数则新增处理线程
        int c = ctl.get();
        if (workerCountOf(c) < corePoolSize) {
            if (addWorker(command, true))
                return;
            c = ctl.get();
        }
        //（3）如果当前线程个数已经达到核心线程数则把任务放入队列
        if (isRunning(c) && workQueue.offer(command)) {
            int recheck = ctl.get();
            if (! isRunning(recheck) && remove(command))
                reject(command);
            else if (workerCountOf(recheck) == 0)
                addWorker(null, false);
        }
        //（4）尝试新增处理线程
        else if (! addWorker(command, false))
            reject(command); //(5)新增失败则调用拒绝策略
    }

可以看到区别在于RunnableFuture包装了task，之前execute返回值是void现在变成了Future对象，底层还是封装了execute的执行逻辑。

场景二、算法工程依赖-批量查询数据集

实际开发中更多的是使用SpringBoot来开发，Spring默认也是自带了一个线程池方便我们开发，它就是ThreadPoolTaskExecutor，其更方便与Spring框架进行整合，本质还是java.util.concurrent.Executor。UML类图关系如下：

应用场景：例如查询字段和Id匹配的数据集的表的信息，这里可以给予Spring Core内置的ThreadPoolTaskExecutor来实现，特意看了一下它和JUC包的ThreadPoolExecutor区别：

//
// Source code recreated from a .class file by IntelliJ IDEA
// (powered by FernFlower decompiler)
//

package org.springframework.scheduling.concurrent;

public class ThreadPoolTaskExecutor extends ExecutorConfigurationSupport implements AsyncListenableTaskExecutor, SchedulingTaskExecutor {
    private final Object poolSizeMonitor = new Object();
    private int corePoolSize = 1;
    private int maxPoolSize = Integer.MAX_VALUE;
    private int keepAliveSeconds = 60;
    private int queueCapacity = Integer.MAX_VALUE;
    private boolean allowCoreThreadTimeOut = false;
    @Nullable
    private TaskDecorator taskDecorator;
    @Nullable
    private ThreadPoolExecutor threadPoolExecutor;
    private final Map<Runnable, Object> decoratedTaskMap;

    public ThreadPoolTaskExecutor() {
        this.decoratedTaskMap = new ConcurrentReferenceHashMap(16, ReferenceType.WEAK);
    }

这里解释一下这个decoratedTaskMap：
decoratedTaskMap 是 ThreadPoolTaskExecutor 中的一个成员变量，用于存储任务（Runnable 对象）和关联的装饰器（Object 对象）之间的映射关系。具体来说，decoratedTaskMap 的作用是为了在任务执行前后应用装饰器，以对任务进行一些额外的处理。
在 Spring 的 ThreadPoolTaskExecutor 中，装饰器的使用场景通常涉及任务执行的一些扩展需求，例如：
任务监控和记录： 通过装饰器可以在任务执行前后记录任务的执行信息、运行时间等，用于性能监控和日志记录。
任务上下文传递： 在多线程环境下，任务可能需要访问一些上下文信息，通过装饰器可以在任务执行前将上下文信息传递给任务，以保证任务执行时上下文正确。
任务异常处理： 装饰器可以用于在任务执行时捕获异常，进行特定的异常处理逻辑，而不影响原始任务。
任务计数器和统计： 通过装饰器可以实现任务的计数、统计功能，用于监控线程池的运行状态。在 ThreadPoolTaskExecutor 中，使用 decoratedTaskMap 存储任务和装饰器之间的映射关系，可以确保对于相同的任务不会重复应用装饰器，同时能够有效地管理装饰器的生命周期。这个映射关系使用了 ConcurrentReferenceHashMap，它是一个并发安全的、支持弱引用的哈希表，可以有效地管理映射关系，防止内存泄漏。
总的来说，decoratedTaskMap 提供了一种灵活的机制，允许开发者通过装饰器对线程池中的任务进行一些额外的处理，以满足特定需求。
具体参考 https://zhuanlan.zhihu.com/p/346086161 https://blog.csdn.net/qq_40386113/article/details/127581333

可以看到它的构造器是不传参的，需要我们通过set方法设置内部threadPoolExecutor属性对象的核心参数，应用的时候在方法上添加@Async注解，然后还需要在@SpringBootApplication启动类或者@Configuration注解类上 添加注解@EnableAsync启动多线程注解，@Async就会对标注的方法开启异步多线程调用，注意，这个方法的类一定要交给Spring容器来管理。
或者直接通过@Resource(name=“xxxxExecutor”)
private AsyncTaskExecutor xxxxExecutor; 进行bean注入调用也是可以的。

@Configuration
public class xxxExecutor {

    @Bean("xxxExecutor")
    public AsyncTaskExecutor xxxExecutor() {
        ThreadPoolTaskExecutor asyncTaskExecutor = new CustomThreadPoolTaskExecutor();
        asyncTaskExecutor.setMaxPoolSize(MAX_POOL_SIZE);
        asyncTaskExecutor.setCorePoolSize(CORE_POOL_SIZE);
        asyncTaskExecutor.setThreadNamePrefix("xxxxx");
        asyncTaskExecutor.setQueueCapacity(MAX_QUEUE_SIZE);
        asyncTaskExecutor.setThreadFactory(new NamedThreadFactory());
        asyncTaskExecutor.initialize();
        return asyncTaskExecutor;
    }
}

返回一个AsyncTaskExecutor对象，继承自Executor，并且可以通过继承重写它的execute和submit方法，源码参考如下。

应用的时候执行批量查询的部分，这个过程可能是走数据库执行SQL查询的，也可能是基于API经过OkHttpClient调用相关方法进行返回。

public List<xxxx> searchDataSet(){
	//........参数校验 图数据库向量组装 前置处理
	List<Future<xxxxResult>> futures = new ArrayList<>();
	        for(SearchResult xxxxResult : allResults){
	                futures.add(asyncTaskExecutor.submit(() -> xxxxxSearch(xxxxSearchRequest)));
	            }
	        }
	//........对象转换 日志记录 后置处理
	return futures;
}

---

总结

本文根据最近研读《java并发编程之美》这本书8、9、11章关于线程池的部分与实际项目经历，分析了java并发线程池具体应用场景，并结合个人的思考进行了一定的拓展，记录的过程也是对知识的一种巩固和加强，以便于对并发编程有更深入的理解。