在我的应用程序中,我必须通过执行许多network-io绑定任务来解决问题,有时一个io绑定任务并分成更小的io绑定任务。这些任务目前正在使用Java的标准线程池机制执行。我想知道我是否可以转向fork-and-join框架?但问题是,forkandjoin框架通常用于解决io绑定操作或CPU绑定吗?我假设它们主要用于CPU绑定操作,因为fork-and-join框架利用工作窃取技术来利用多核处理器,但如果我将它用于IO绑定任务,会不会产生任何负面影响?
答案 0 :(得分:24)
Fork-join是为计算绑定任务而设计的,所以我通常会说不。 fork-join确实有一个API(ManagedBlocker api)告诉FJ框架你的线程会阻塞一段时间而不是排队新任务但它真的是为短等待设计的(比如获取一个锁) ,而不是任意长时间等待IO。
我们有一个使用fork-join的系统,我们将IO绑定任务分流到一个单独的执行器池。当数据到达时,它会将任务触发到fork-join池中,以便只在那里发生cpu绑定的工作。
答案 1 :(得分:2)
如果您正在尝试解决问题的“I / O绑定”方面,我怀疑从标准线程切换到fork-and-join会改善一些事情......假设您已经实现了当前基于线程的解决方案。 (根据Alex Miller的回答,转换实际上可能会使事情变得更糟。)
或者换句话说,使您的I / O绑定应用程序更快的方法是解决使其受I / O限制的问题......或者增加系统的I / O带宽。
答案 2 :(得分:1)
在这种情况下,fork-joins似乎没有令人信服的优势。
似乎没有显着的劣势,因为你不会太过努力地推动某些资源。
总而言之,我会留在线程池中,直到你没有其他重要的开发要做。