Is Java's fork-and-join thread pool is good for executing IO bound task?

Question

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?

Answer 1

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.

Answer 2

If you are trying to address the "I/O bound" aspect of your problem, I doubt that switching from standard threads to fork-and-join is going to improve things ... assuming that you've implemented the current thread-based solution properly. (And based on Alex Miller's answer, the switch could actually make things significantly worse.)

Or to put it another way, the way to make your I/O bound application go faster is to address the problems that make it I/O bound ... or increase your system's I/O bandwidth.

Answer 3

there does not seem to be a compelling advantage to fork-joins in this case.

there does not seem to be a signficant disadvantage either because you would not be driving some resource too hard.

all in all, i would stay with the thread pool until you have no other important development to do.