今天，说一说线程池 “动态更新”（二）

核心线程动态的坑

有一个很重要的点需要注意，核心线程数设置时可能失效。比如说，最大线程数为 5，当前线程池内活跃线程数为 5，此时设置核心线程数为 10 的话，一定是不生效的，Why？

 
先假设线程池的运行时状态如下，核心线程为 3，最大线程是 5，线程池内活跃线程为 5，此时调用 #setCorePoolSize 动态设置核心线程数为 10

执行完上述操作之后，调用 #execute 向线程池发起任务执行，内部处理逻辑如下

1. 判断当前线程池核心数为 10，当前工作线程为 5，那么会 发起 #addWorker 添加线程
2. #addWorker 会对 工作线程数量 + 1，此时真正意义上并不算此 Worker 添加到线程池
3. 接下来会创建线程的包装类 Worker 并执行 Start，因为 Worker 本身持有线程对象，Start 也是操作线程去执行任务
4. 获取任务 #getTask 有一步操作是动态修改核心线程数不生效的原因，那就是在真正获取队列中任务执行时会先 判断当前的工作线程数量是否大于最大线程
5. 因为上面对工作线程有 +1 的操作，所以池内工作线程数是 6，条件判断表达式成立，接下来会对 工作线程数量执行 -1 操作，并销毁此 Worker
   这里贴一下线程池获取队列任务 #getTask 的代码片段，大家粗略看一下

 
既然已经知道问题出在哪里，应该如何去解决动态设置失效呢

其实办法很简单，那就是在设置核心线程的时候，同时设置最大线程数就可以。只要工作线程不大于最大线程数，那么动态设置就是有效的

本小节参考自 如何设置线程池参数？美团给出了一个让面试官虎躯一震的回答[2]

MaximumPoolSize（最大线程数）

表示线程池中可以创建的最大线程数。通过 #setMaximumPoolSize 重新设置最大线程数，修改逻辑如下

 
线程池中设置最大线程数的源码比较简单，并不包含复杂的逻辑，流程如下

1. 判断 new maximumPoolSize 参数是否正确，不满足条件则抛出异常终止流程
2. 设置 new maximumPoolSize 替换线程池最大线程数
3. 如果线程池工作线程大于 new maximumPoolSize，则对多余 Worker 发起中断流程
   ThreadFactory（线程工厂）

线程工厂的功能是为线程池创建线程，线程创建时可以设置自定义线程 名称前缀（重要）、设置是否 daemon 线程、线程 priority 优先级以及线程未捕获异常的处理方式

虽然线程工厂可以在运行后重新设置参数，但是并不建议这么做。因为已经运行的线程不会因为被销毁，如果之前运行的线程不被销毁，一个线程池中极有可能出现两种不同语义的线程

 
示例代码中创建了一个线程池，并指定了线程工厂前缀名称 before。对线程池运行任务使其内部拥有 before 工厂创建线程

之后新创建一个 after 线程工厂，进行替换线程池内部工厂，并运行任务创建最大线程数，我们可以查看下日志

 
不出所料两个线程工厂创建的线程各自为战，并且如果没有特殊操作，这种情况会一直持续下去 。所以综上所述，并不建议业务中对线程工厂修改，不然坑的都是自己人～

 
其它参数

剩余两个动态调整的参数较为简单，就不一一举例说明了，大家看下源码即可

• KeepAliveTime
• RejectedExecutionHandler
  还有一个很重要的参数需要动态更新，那就是 阻塞队列的大小。可能有的小伙伴就会问了，为什么不直接替换阻塞队列呢？

其实可以实现直接替换阻塞队列，但是如果直接替换会引发出很多的问题，举个最直接的例子，原队列中的堆积任务不好处理，修改容量就能解决问题的事情，没必要复杂化。所以在做动态时，考虑的只是阻塞队列的大小而不是替换

这里以 LinkedBlockingQueue 为例，队列在源码中并没有提供修改队列大小的方法，因为代表队列大小的变量 capacity 被 final 关键字修饰

大家可以考虑下，基于这种 final 修饰的情况，应该如何去扩展阻塞队列的容量修改

文章转自公众号：龙台的技术笔记