Java 7的fork/join框架并未使用所有可用的CPU电源

我正在使用Java's fork-join framework来处理CPU密集型计算。我已经调整了“顺序阈值”（用于确定是创建子任务还是做这项工作），但令人失望的是，从单线程到4 + 4核心只有将整体性能提高了一倍。该池确实报告了8个CPU，当我手动设置2,3,4时，..我看到性能逐渐增加，但仍然达到总体单线程吞吐量的两倍左右。此外，Linux系统活动监视器为该Java进程徘徊约50％。Java 7的fork/join框架并未使用所有可用的CPU电源

也非常可疑的是，当我启动多个Java进程时，集合吞吐量更接近于线（几乎比单个线程快4倍），系统活动监视器显示更高的CPU使用率。

在Java，Linux或fork/join框架中是否存在不允许完全占用CPU的限制是可能的？任何建议或类似的经历？

注意：这是一个Intel 3770 CPU，具有4个核心和4个超线程核心，在Linux Mint盒子上运行Oracle Java 7r13。

来源

2013-03-14 Ray

要了解叉式连接设置发生了什么，需要找出瓶颈在哪里。除此之外，我们很难根据您的问题中的信息提出具体的建议。 – NPE 2013-03-14 16:12:22

有趣的情况。关于平顺化加速，这是理论上的限制：[Amdahl's law]（http://en.wikipedia.org/wiki/Amdahl's_law） – linski 2013-03-14 16:12:42

此外，你不能指望超线程核心，因为你可以在“真实“内核，例如：[1]（http://stackoverflow.com/questions/680684/multi-cpu-multi-core-and-hyper-thread）[2]（http://stackoverflow.com/questions/360307 /多核超线程如何，都线程分布）。但我要做的第一件事就是遵循NPE的建议 – linski 2013-03-14 16:23:59

感谢大家的想法和答案！从您的建议中，我得出结论认为问题不在于框架本身，而是继续进行更多测试，发现几分钟后CPU负载降至15％！

原来，Random（我广泛使用）在多线程安装中性能较差。解决方案是使用ThreadLocalRandom.current（）。nextXXX（）代替。我现在达到一致的80％使用率（还剩下一些连续的通道）。甜！

再次感谢您让我走上正轨。

来源

2013-03-15 11:35:39 Ray

Java 7的fork/join框架并未使用所有可用的CPU电源

回答

相关问题