我一直在学习 Java 8 的并行流,这篇文章出现在 Google 搜索的第一页。我无法从文章中理解这一特定行
...所有并行流都使用公共 fork-join 线程池,如果您提交一个长时间运行的任务,您实际上会阻塞池中的所有线程。
我无法弄清楚长时间运行的任务如何阻塞池中的所有其他线程。
我一直在学习 Java 8 的并行流,这篇文章出现在 Google 搜索的第一页。我无法从文章中理解这一特定行
...所有并行流都使用公共 fork-join 线程池,如果您提交一个长时间运行的任务,您实际上会阻塞池中的所有线程。
我无法弄清楚长时间运行的任务如何阻塞池中的所有其他线程。
在此声明中,“提交一个长时间运行的任务”意味着“使用并行流执行一个长时间运行的任务”。并行流处理的目的是将工作拆分并分配给公共线程池的所有工作线程。
该池具有配置为使用所有 CPU 内核的多个线程,如果所有内核都忙,则已达到该目标。
如果这些线程因等待 I/O 操作完成而被阻塞,则会出现问题。那么,CPU核心没有被利用,这不仅会降低其他并行流的性能,甚至在同一操作中,并发I/O操作的最佳数量也可能与CPU核心数量完全不同。
结论是 Stream API 不适合并行 I/O 操作。
提交一项任务不能使用公共池中的所有线程。公共池大小为core count -1
(主线程为-1)。
我认为在文章中,他的意思是不可能(在 API 中)将 io 密集型任务和 cpu 密集型任务分离到不同的池中。
例如,在 8 核机器上,如果您将 8 个 cpu 密集型任务提交到池中,那么 8 个 io 密集型任务,io 任务必须等待 cpu 密集型任务完成(反之亦然)。如果您可以将它们提交到不同的池,那么所有 16 个操作都可以同时运行,因为 io 操作在 cpu 上的成本并不高。