可扩展的Java线程池执行器

分享一下最近优锐课学习笔记。

Java线程池执行程序偏向于排队而不是产生新线程。从好的方面来说，我们有两种解决方法。

理想情况下，对任何线程池执行程序而言，期望如下：

• 预先创建了一组初始线程（核心线程池大小）来处理负载。
• 如果负载增加，则应创建更多线程来处理最大线程数（最大池大小）的负载。
• 如果线程数增加到“最大池大小”以外，则将任务排队。
• 如果使用了有界队列，并且队列已满，请引入一些拒绝策略。

下图描述了该过程；仅创建初始线程来处理任务（负载很低时）。

 

 

 

 随着更多的任务进入，假设创建的线程总数小于最大池大小，则会创建更多的线程来处理负载（任务队列仍然为空）。

 

 

 

 如果任务总数大于线程总数（初始+扩展），则任务队列开始填充：

 

 

 不幸的是，Java线程池执行器（TPE）偏向于排队而不是生成新线程，即，在初始核心线程被占用之后，任务被添加到队列中，并且在队列达到其限制之后（这只会在有界队列中发生） ），则会产生额外的线程。如果队列不受限制，则完全不会产生扩展线程，如下图所示。

 

 

 

 

1. 创建了初始核心线程来处理负载。
2. 一旦任务数量超过核心线程数，队列就会开始填满以存储任务。
3. 队列填满后，将创建扩展线程。

这是TPE中的代码，出现了问题

 

 

 

 

我们有两种解决方法：

解决方法1：调整池大小

将corePoolSize 和maximumPoolSize设置为相同的值，并将allowCoreThreadTimeOut 设置为true。

优点

• 无需编码技巧。

缺点

• 由于线程的创建和终止非常频繁，因此没有真正的线程缓存。
• 没有适当的可伸缩性。

解决方法2：覆盖要约方法

• 重写委托人TransferQueue的offer方法，并尝试将任务提供给空闲的工作线程之一。如果没有等待线程，则返回false。
• 实现自定义RejectedExecutionHandler以始终添加到队列中。

 

 

 实现自定义RejectedExecutionHandler以始终添加到位数中。

优点

• TransferQueue确保不需要创建线程，并将工作直接转移到等待队列。

缺点

• 不能使用定制的拒绝处理程序，因为它用于插入要排队的任务。

解决方法＃3：使用自定义队列

使用自定义队列（TransferQueue）并覆盖offer方法以执行以下操作：

1. 尝试将任务直接转移到等待队列（如果有）。
2. 如果以上操作失败，并且未达到最大池大小，则通过从offer方法返回false来创建扩展线程。
3. 否则，将其插入队列。

 

 

 

 

优点

• TransferQueue确保不需要创建线程，并将工作直接转移到等待队列。
• 可以使用自定义拒绝处理程序。

缺点

• 队列和执行程序之间存在循环依赖关系。

解决方法4：使用自定义线程池执行程序

使用专门用于此目的的自定义线程池执行程序。它使用系统@ Facebook规模中所述的LIFO调度。