引言
设想一下,在我们的项目中存在一个边缘的业务流程,它并不频繁地被触发。在设计线程池时,我不禁回想起了线程池的经典理论。为了最大限度地节省资源,我将核心线程数设置为0。这样的配置真的能够执行任务吗?
线程池经典理论回顾
在任务提交时,线程池会根据以下策略进行处理:
- 如果线程池中的线程数少于核心线程数,则创建一个新线程来执行任务。
- 如果线程池中的线程数大于或等于核心线程数:
- 如果阻塞队列未满,任务会被放入阻塞队列中。
- 如果阻塞队列已满:
- 如果线程池中的线程数小于最大线程数,则创建一个新线程来执行当前任务。
- 如果线程池中的线程数大于或等于最大线程数,则执行拒绝策略。
这就是线程池的基本工作流程。那么,当corePoolSize
设置为0时,根据上述理论,任务是否会直接被放入阻塞队列中等待执行?如果队列足够大,任务是否可能因为队列未满而永远无法执行(因为不会创建“空闲线程”)?
实例演示
猜测是无用的,实践才能揭示真相。下面我配置了一个线程池,希望在提交任务时,能够通过“空闲线程”快速处理,然后自动销毁,不占用系统资源。那么,这种线程池在执行过程中是否可能因为阻塞队列未满而导致任务迟迟未执行?
private static final ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(
0,
8,
5, TimeUnit.MINUTES,
new LinkedBlockingQueue<>(512),
new CallerRunsPolicy()
);
我们使用这个线程池打印一个字符串,以验证任务是否能够执行。
public static void main(String[] args) {
MonitorThreadPoolConfig.addThreadPoolExecutor(threadPoolExecutor);
threadPoolExecutor.execute(() -> System.out.println("hahahhaha "));
}
执行结果显示:任务确实会被执行(这里我添加了对线程池的定时监控)。
深入源码
public void execute(Runnable command) {
if (command == null)
throw new NullPointerException();
/*
* 执行分为三个步骤:
*
* 1. 如果运行的线程数少于核心线程数,尝试
* 用给定的命令作为其第一个任务启动一个新线程。
* addWorker原子地检查runState和workerCount,
* 因此可以防止在不应该添加线程时添加线程,
* 通过返回false来避免误报。
*
* 2. 如果任务可以成功入队,那么我们仍然需要
* 再次检查我们是否应该添加一个线程(因为现有的线程
* 自上次检查以来可能已经死亡)或者池是否已经关闭。
* 因此,我们重新检查状态,如果必要的话,如果停止了,
* 回滚入队操作,或者如果没有线程,则启动一个新线程。
*
* 3. 如果我们不能将任务入队,那么我们就尝试添加一个新
* 线程。如果失败,我们知道我们已经关闭或饱和
* 因此拒绝任务。
*/
int c = ctl.get();
if (workerCountOf(c) < corePoolSize) {
if (addWorker(command, true))
return;
c = ctl.get();
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);
}
else if (!addWorker(command, false))
reject(command);
}
}
从源码的第34行到第35行可以看出:当核心线程数为0时,会创建一个新的线程来执行当前的任务。
进一步探讨
既然可以通过将corePoolSize
设置为0的方式来尽可能减少“常驻”线程的资源占用,那么是否有其他方法可以达到同样的效果呢?
有经验的开发者可能会立刻回答:从Java 1.6开始,ThreadPoolExecutor
有一个属性,它允许核心线程超时销毁。
```java
/
如果设置为false(默认),核心线程即使在空闲时也会保持活动状态。
相关文章
暂无评论...