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

∥☆過路亽.° 提交于 2019-12-02 18:05:06

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.

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.

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.

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!