我用java编写了一个简单的map/reduce程序，用于两个文本文件的关系连接操作。该算法在很多地方都有描述，即在reduce任务中进行连接。
我想把它调得更好。第一件事是尝试不同数量的reduce任务。目前我只在一台4核的计算机上运行，但实际上是在分布式文件系统中运行。
我遇到了一个奇怪的现象，如果我运行4个或32个reduce任务，墙时间（time stat直到time finish）甚至比我只运行1个reduce任务的时间还要长：

1 reducer:  22.4 seconds
4 reducer:  23.3 seconds
32 reducer:  26.1 seconds

从这个趋势来看，我真的无法解释。第一个印象是瓶颈在i/o，因为我在一台机器上运行，高i/o操作并不是真正并行的。但是，通过查看cpu stat，i/o等待时间非常小（并且输入数据在我的测试数据中只有几兆字节），因此这看起来不是一个很好的解释。
值得一提的是，我在运行map/reduce程序时监视了不同内核的cpu使用情况，我发现大多数情况下cpu使用情况仅限于一个内核，看起来不像是并行的。
我还怀疑运行更多reducer的好处被额外的map/reduce开销所抵消。
你觉得这个怎么样？
[更新]我发现了这样一种说法（通过一些计时观察也证明了这一点），即在单个jvm中，map和reduce任务只能串行运行，而不是多线程运行。这将解释为什么结果是更多的时间与更多的任务。
我看到hadoop使用multi-threadedmapper类支持多线程Map器，我尝试了，不幸的是结果再次变得更糟。
但是我不知道为什么会有一个类叫做multi-threadedmapper，但是为什么会有另一个类似multi-threadedreducer的类呢？