Java的fork-and-join线程池是否适合执行IO绑定任务？ [英] Is Java's fork-and-join thread pool is good for executing IO bound task?

问题描述

在我的应用程序中，我必须通过执行许多network-io绑定任务来解决问题，有时一个io绑定任务并分成更小的io绑定任务。这些任务目前正在使用Java的标准线程池机制执行。我想知道我是否可以转向fork-and-join框架？但问题是，forkandjoin框架通常用于解决io绑定操作或CPU绑定吗？我假设它们主要用于CPU绑定操作，因为fork-and-join框架利用工作窃取技术来利用多核处理器，但如果我将它用于IO绑定任务，会不会产生任何负面影响？

解决方案

Fork-join是为计算限制任务而设计的，所以我通常会说不。 Fork-join确实有一个API（ ManagedBlocker api）告诉FJ框架你的线程会阻塞一段时间而不是排队新任务，但它实际上是为短等待（比如获取一个锁）设计的，而不是任意长时间等待IO。 / p>

我们有一个使用fork-join的系统，我们将IO绑定任务分流到一个单独的执行器池。当数据到达时，它会将任务触发到fork-join池中，以便只在那里发生cpu绑定工作。

in my application, I have to solve a problem by executing many network-io bound task and sometime one io bound task and be divided into smaller io bound tasks. These tasks are currently getting executed using Java's standard threadpool mechanism. I am wondering whether I can move to fork-and-join framework? But the question is, is forkandjoin framework usually being used to solve io bound operations or CPU bound? I assume they are mostly for CPU bound operations cause fork-and-join framework makes use of work stealing technique to make use of multo core processors, but if I use it for IO bound tasks, will there be any adverse effect?

解决方案

Fork-join is designed for compute-bound tasks so generally I'd say no. Fork-join does have an API (the ManagedBlocker api) to tell the FJ framework that your thread will be blocking for a while and not to line up new tasks but it's really designed for short waits (like obtaining a lock), not arbitrarily long waits for IO.

We have a system that uses fork-join and we shunt IO-bound tasks off to a separate executor pool. When data arrives it triggers tasks into the fork-join pool so that only cpu-bound work occurs there.

这篇关于Java的fork-and-join线程池是否适合执行IO绑定任务？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！