多线程Java不能加速

Question

我已经在Java中实现了一个简单的并行合并排序算法。这将数组切成相等的部分，并将它们传递给每个线程独立地进行排序。在对数组段进行排序后，它们由单个线程合并。因为没有共享资源，所以在对子列表进行排序时不使用任何同步。合并结果数组的最后一个线程尽管等待其他线程完成。

当使用两个线程时，性能将提高近66％。当我使用4个线程时，花费的时间与2个线程版本没有什么不同。我在linux
2.6.40.6-0.fc15.i686.PAE和Intel Core i5上。

我正在使用unix time命令对时间进行基准测试（为数组分配了统一的随机整数）。在排序结束时，我正在检查数组排序是否正确（不并行）。

1线

$ echo“ 100000000” | 时间-p java mergeSortTest

输入n： 
[成功]

真实40.73
用户40.86
sys 0.22

2个线程

$ echo“ 100000000” | 时间-p java mergeSortTest

输入n： 
[成功]

真实26.90
用户49.65
sys 0.48

4线

$ echo“ 100000000” | 时间-p java mergeSortTest

输入n： 
[成功]

真实25.13
用户76.53
sys 0.43

使用4个线程时，CPU使用率约为80％至90％；使用2个线程时，CPU使用率约为50％；使用单线程时，CPU使用率约为25％。

我期望在4个线程中运行时可以加快速度。我在任何地方错了吗？

更新1

这是代码：http :
//pastebin.com/9hQPhCa8

更新2 我有一个Intel Core i5第二代处理器。

输出cat /proc/cpuinfo | less（仅显示核心0）。

处理器：0
vendor_id：正版英特尔
cpu家庭：6
型号：42
型号名称：Intel（R）CoreTM i5-2410M CPU @ 2.30GHz
步进：7
cpu兆赫：800.000
缓存大小：3072 KB
物理编号：0
兄弟姐妹：4
核心编号：0
cpu核心数：2
尖酸：0
初始杀虫剂：0
fdiv_bug：否
hlt_bug：否
f00f_bug：否
coma_bug：否
fpu：是的
fpu_exception：是
cpuid级别：13
wp：是的
标志：fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss hts tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs tsx dxsqqtstsqpstqtsts qpstqdsts xtpr pdcm sse4_1 sse4_2 x2apic popcnt xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
bogomips：4589.60
clflush大小：64
cache_alignment：64
地址大小：物理36位，虚拟48位
能源管理：

Answer 1

Core
i5具有2个内核和超线程技术，因此似乎具有4个内核。由于您的排序算法在保持CPU繁忙方面做得很好，因此这两个额外的逻辑核心几乎无法提供比两个物理核心更多的帮助。

由于您要求提供“可信的”消息来源，因此，我将指向我读过一段时间的英特尔网站上的一篇文章：Performance-insights-to-intel-
hyper-threading-technology。特别注意以下有关“超线程的限制”的部分：

计算效率极高的应用程序。
如果处理器的执行资源已得到充分利用，那么启用英特尔®HT技术将无济于事。例如，在启用英特尔HT技术的情况下运行时，每个周期已经可以执行四条指令的代码不会提高性能，因为进程内核每个周期最多只能执行四条指令。

还要注意有关内存子系统争用的这一部分：

极高的内存带宽应用程序。
运行两个线程时，英特尔®HT技术增加了对内存子系统的需求。如果应用程序能够在禁用英特尔®HT技术的情况下利用所有内存带宽，则启用英特尔®HT技术后性能不会提高。在某些情况下，由于在这些情况下内存需求增加和/或数据缓存效应，性能可能会下降。好消息是，与采用Intel
HT技术的旧版Intel CPU相比，基于Nehalem内核，集成内存控制器和Intel®QuickPath
Interconnects的系统大大增加了可用内存带宽。

其他有趣的观点可以在《英特尔开发多线程应用程序指南》中找到。这是检测线程应用程序中的内存带宽饱和的另一个代码段：

随着越来越多的线程或进程共享有限的缓存容量和内存带宽资源，线程化应用程序的可伸缩性可能会受到限制。随着引入更多线程，内存密集型线程应用程序可能会遭受内存带宽饱和的困扰。在这种情况下，线程化应用程序将无法按预期扩展，并且可能会降低性能。