Java 的分叉和连接线程池是否适合执行 IO 绑定任务?
在我的应用程序中,我必须通过执行许多网络 io 绑定任务和有时一个 io 绑定任务来解决问题,并将其划分为较小的 io 绑定任务。这些任务目前使用Java的标准线程池机制执行。我想知道我是否可以迁移到分叉和连接框架?但问题是,forkandjoin框架通常用于解决io绑定操作还是CPU绑定?我假设它们大多是针对CPU绑定操作导致分叉和连接框架利用工作窃取技术来利用多核处理器,但是如果我将其用于IO绑定任务,会不会有任何不利影响?
在我的应用程序中,我必须通过执行许多网络 io 绑定任务和有时一个 io 绑定任务来解决问题,并将其划分为较小的 io 绑定任务。这些任务目前使用Java的标准线程池机制执行。我想知道我是否可以迁移到分叉和连接框架?但问题是,forkandjoin框架通常用于解决io绑定操作还是CPU绑定?我假设它们大多是针对CPU绑定操作导致分叉和连接框架利用工作窃取技术来利用多核处理器,但是如果我将其用于IO绑定任务,会不会有任何不利影响?
分叉连接是为计算密集型任务设计的,所以通常我会说不。Fork-join确实有一个API(ManagedBlocker api)来告诉FJ框架你的线程将阻塞一段时间,而不是排列新任务,但它实际上是为短暂的等待而设计的(比如获得一个锁),而不是任意长时间等待IO。
我们有一个使用分叉连接的系统,我们将IO绑定的任务分流到一个单独的执行器池。当数据到达时,它会触发分叉连接池中的任务,以便仅发生 CPU 密集型工作。
如果您正在尝试解决问题的“I / O绑定”方面,我怀疑从标准线程切换到分叉和连接是否会改善事情......假设您已正确实现了当前基于线程的解决方案。(根据亚历克斯·米勒(Alex Miller)的回答,这种转变实际上可能会使事情变得更糟。
或者换句话说,使您的I / O绑定应用程序运行得更快的方法是解决使其I / O绑定的问题...或增加系统的 I/O 带宽。