【上线复盘】上线时线程池使用问题

线程池使用问题

问题是个小问题，但暴露的其它问题比较多，记录一下。
原因是需要使用线程池做异步处理，实现是使用java.util.concurrent.ExecutorService，在配置线程池的基本大小corePoolSize参数时，通过使用Runtime.getRuntime().availableProcessors()获取Java虚拟机的可用的处理器数量，来初始化线程池基本大小，设置数量为处理器数量*2

	/**
     * 创建线程池
     * @return
     */
    @Bean
    public ExecutorService createThreadPool() {
        ExecutorService executorService = new ThreadPoolExecutor(Runtime.getRuntime().availableProcessors() * 2,
                20, 0L, TimeUnit.MILLISECONDS,
                new LinkedBlockingQueue<Runnable>(1024));
        return executorService;
    }

程序修改上线前经过了本地环境、开发环境、测试环境、预发环境的检验，结果线上环境出了问题，启动时报异常：

Caused by: java.lang.IllegalArgumentException: null
	at java.util.concurrent.ThreadPoolExecutor.<init>(ThreadPoolExecutor.java:1307)
	at java.util.concurrent.ThreadPoolExecutor.<init>(ThreadPoolExecutor.java:1195)
	at com.xxx.xxx.xxx.config.ExcutorServiceConfig.createThreadPool(ExcutorServiceConfig.java:27)

看日志错误是ExecutorService类报的IllegalArgumentException错误，再查看ExecutorService源码：

/**
     * Creates a new {@code ThreadPoolExecutor} with the given initial
     * parameters.
     *
     * @param corePoolSize the number of threads to keep in the pool, even
     *        if they are idle, unless {@code allowCoreThreadTimeOut} is set
     * @param maximumPoolSize the maximum number of threads to allow in the
     *        pool
     * @param keepAliveTime when the number of threads is greater than
     *        the core, this is the maximum time that excess idle threads
     *        will wait for new tasks before terminating.
     * @param unit the time unit for the {@code keepAliveTime} argument
     * @param workQueue the queue to use for holding tasks before they are
     *        executed.  This queue will hold only the {@code Runnable}
     *        tasks submitted by the {@code execute} method.
     * @param threadFactory the factory to use when the executor
     *        creates a new thread
     * @param handler the handler to use when execution is blocked
     *        because the thread bounds and queue capacities are reached
     * @throws IllegalArgumentException if one of the following holds:<br>
     *         {@code corePoolSize < 0}<br>
     *         {@code keepAliveTime < 0}<br>
     *         {@code maximumPoolSize <= 0}<br>
     *         {@code maximumPoolSize < corePoolSize}
     * @throws NullPointerException if {@code workQueue}
     *         or {@code threadFactory} or {@code handler} is null
     */
    public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue,
                              ThreadFactory threadFactory,
                              RejectedExecutionHandler handler) {
		if (corePoolSize < 0 ||
            maximumPoolSize <= 0 ||
            maximumPoolSize < corePoolSize ||
            keepAliveTime < 0)
            throw new IllegalArgumentException();
        ...
        ...

方法头注释里对于IllegalArgumentException的说明为：
corePoolSize小于0
或者maximumPoolSize小于等于0
或者maximumPoolSize小于corePoolSize
或者keepAliveTime小于0
会抛出IllegalArgumentException异常

当时看到 null 时，被带向了是空值的方面，其实后来发现是maximumPoolSize小于corePoolSize的问题，因为线上node1节点的服务器CPU核数为12，乘以2后大于20，而其它环境CPU核数都小于10。

问题1：
对ExecutorService类不是太熟，只知道使用线程池要用这个类，但还是比较粗浅的了解

问题2：
研发和运维分开的团队，在涉及性能优化的时候，一定要走设计评审，特别是涉及CPU、内存

问题3：
错误提示要明确，比如ExecutorService类中的异常信息抛出的时候，不能很容易的看出问题原因，特别是上线的功能比较多，马上找不到问题的原因，会影响上线的时间

问题4：
其实在使用Spring框架的时候，线程池有更好的解决方案ThreadPoolExecutor

问题5：
在使用线程池时，没有考虑如何正确地关闭线程池，当服务重启或升级，没有对进行中的线程有好的处理，万一数据有影响，再进行数据修正会特别麻烦

解决方案：

1. 使用ThreadPoolExecutor来实现，初始化参数与运维一起讨论更合适的数量，并且针对线程池的关闭要做好处理
2. 规范开发流程，开发阶段有超出设计时的功能或优化时，进行补充设计评审，如果是技术上的优化，组织其他组长和上级领导参加评审
3. 复盘并对线程池进行专门技术分享，提高开发人员的技术水平