Java 在许多内核上的扩展性比 C# 差得多？

Question

我正在测试在 Java 和 C# 的 32 核服务器上生成许多运行相同功能的线程。我使用函数的 1000 次迭代运行应用程序，使用线程池在 1、2、4、8、16 或 32 个线程上进行批处理。

在 1、2、4、8 和 16 个并发线程时，Java 的速度至少是 C# 的两倍。然而，随着线程数量的增加，差距缩小，C# 的平均运行时间几乎相同，增加了 32 个线程，但 Java 偶尔需要 2000 毫秒（而两种语言通常运行大约 400 毫秒）。 Java 开始变得更糟，每个线程迭代所花费的时间大幅增加。

编辑这是 Windows Server 2008

EDIT2 我已更改以下代码以显示使用执行器服务线程池。我还安装了 Java 7。

我在热点虚拟机中设置了以下优化：

-XX:+UseConcMarkSweepGC -Xmx 6000

但它仍然没有让事情变得更好。代码之间的唯一区别是我使用下面的线程池和我们使用的 C# 版本：

http://www.codeproject.com/Articles/7933/Smart-Thread-Pool

有没有办法让 Java 更加优化？ Perhaos，您能解释一下为什么我会看到性能大幅下降吗？

有没有更高效的 Java 线程池？

（请注意，我不是指改变测试功能）

import java.io.DataOutputStream;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.PrintStream;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.ThreadPoolExecutor;

public class PoolDemo {

    static long FastestMemory = 2000000;
    static long SlowestMemory = 0;
    static long TotalTime;
    static int[] FileArray;
    static DataOutputStream outs;
    static FileOutputStream fout;
    static Byte myByte = 0;

  public static void main(String[] args) throws InterruptedException, FileNotFoundException {

        int Iterations = Integer.parseInt(args[0]);
        int ThreadSize = Integer.parseInt(args[1]);

        FileArray = new int[Iterations];
        fout = new FileOutputStream("server_testing.csv");

        // fixed pool, unlimited queue
        ExecutorService service = Executors.newFixedThreadPool(ThreadSize);
        ThreadPoolExecutor executor = (ThreadPoolExecutor) service;

        for(int i = 0; i<Iterations; i++) {
          Task t = new Task(i);
          executor.execute(t);
        }

        for(int j=0; j<FileArray.length; j++){
            new PrintStream(fout).println(FileArray[j] + ",");
        }
      }

  private static class Task implements Runnable {

    private int ID;

    public Task(int index) {
      this.ID = index;
    }

    public void run() {
        long Start = System.currentTimeMillis();

        int Size1 = 100000;
        int Size2 = 2 * Size1;
        int Size3 = Size1;

        byte[] list1 = new byte[Size1];
        byte[] list2 = new byte[Size2];
        byte[] list3 = new byte[Size3];

        for(int i=0; i<Size1; i++){
            list1[i] = myByte;
        }

        for (int i = 0; i < Size2; i=i+2)
        {
            list2[i] = myByte;
        }

        for (int i = 0; i < Size3; i++)
        {
            byte temp = list1[i];
            byte temp2 = list2[i];
            list3[i] = temp;
            list2[i] = temp;
            list1[i] = temp2;
        }

        long Finish = System.currentTimeMillis();
        long Duration = Finish - Start;
        TotalTime += Duration;
        FileArray[this.ID] = (int)Duration;
        System.out.println("Individual Time " + this.ID + " \t: " + (Duration) + " ms");


        if(Duration < FastestMemory){
            FastestMemory = Duration;
        }
        if (Duration > SlowestMemory)
        {
            SlowestMemory = Duration;
        }
    }
  }
}

Answer 1

总结

以下是原始响应、更新 1 和更新 2。更新 1 讨论了使用并发结构处理测试统计变量周围的竞争条件。更新 2 是处理竞争条件问题的一种更简单的方法。希望我不再更新 - 很抱歉回复的长度，但多线程编程很复杂！

原始回复

代码之间的唯一区别是我使用下面的 线程池

我会说这绝对是一个巨大的差异。当两种语言的线程池实现是完全不同的代码块，编写在用户空间时，很难比较两种语言的性能。线程池实现可能会对性能产生巨大影响。

您应该考虑使用 Java 自己的内置线程池。请参阅ThreadPoolExecutor 及其所属的整个java.util.concurrent 包。 Executors 类具有方便的池静态工厂方法，是一个很好的高级接口。您只需要 JDK 1.5+，尽管越新越好。其他发帖人提到的 fork/join 解决方案也是这个包的一部分 - 如前所述，它们需要 1.7+。

更新 1 - 使用并发结构解决竞争条件

您有围绕FastestMemory、SlowestMemory 和TotalTime 设置的竞争条件。对于前两个，您正在进行< 和> 测试，然后进行不止一步的设置。这不是原子的；另一个线程肯定有可能在测试和设置之间更新这些值。 TotalTime 的 += 设置也是非原子的：伪装的测试和设置。

这里有一些建议的修复方法。

总时间

这里的目标是线程安全的原子+= 或TotalTime。

// At the top of everything
import java.util.concurrent.atomic.AtomicLong;  

...    

// In PoolDemo
static AtomicLong TotalTime = new AtomicLong();    

...    

// In Task, where you currently do the TotalTime += piece
TotalTime.addAndGet (Duration); 

FastestMemory / SlowestMemory

这里的目标是在原子步骤中测试和更新FastestMemory 和SlowestMemory，因此没有线程可以在测试和更新步骤之间滑入导致竞争条件。

最简单的方法：

使用类本身作为监视器来保护变量的测试和设置。我们需要一个包含变量的监视器以保证同步可见性（感谢@A.H. 捕捉到这一点。）我们必须使用类本身，因为一切都是static。

// In Task
synchronized (PoolDemo.class) {
    if (Duration < FastestMemory) {
        FastestMemory = Duration;
    }

    if (Duration > SlowestMemory) {
        SlowestMemory = Duration;
    }
}

中间方法：

您可能不喜欢为监视器使用整个类，或者通过使用该类来暴露监视器等。您可以做一个单独的监视器，它本身不包含FastestMemory 和SlowestMemory，但是您将运行同步可见性问题。您可以使用 volatile 关键字解决此问题。

// In PoolDemo
static Integer _monitor = new Integer(1);
static volatile long FastestMemory = 2000000;
static volatile long SlowestMemory = 0;

...

// In Task
synchronized (PoolDemo._monitor) {
    if (Duration < FastestMemory) {
        FastestMemory = Duration;
    }

    if (Duration > SlowestMemory) {
        SlowestMemory = Duration;
    }
}

高级方法：

这里我们使用java.util.concurrent.atomic 类而不是监视器。在激烈的争论下，这应该比synchronized 方法执行得更好。试试看。

// At the top of everything
import java.util.concurrent.atomic.AtomicLong;    

. . . . 

// In PoolDemo
static AtomicLong FastestMemory = new AtomicLong(2000000);
static AtomicLong SlowestMemory = new AtomicLong(0);

. . . . .

// In Task
long temp = FastestMemory.get();       
while (Duration < temp) {
    if (!FastestMemory.compareAndSet (temp, Duration)) {
        temp = FastestMemory.get();       
    }
}

temp = SlowestMemory.get();
while (Duration > temp) {
    if (!SlowestMemory.compareAndSet (temp, Duration)) {
        temp = SlowestMemory.get();
    }
}

让我知道这之后会发生什么。它可能无法解决您的问题，但围绕跟踪您表现的变量的竞争条件太危险了，不容忽视。

我最初将此更新发布为评论，但将其移至此处，以便我有空间显示代码。此更新经过了几次迭代 - 感谢 A.H. 捕获了我在早期版本中遇到的错误。此更新中的任何内容都将取代评论中的任何内容。

最后但同样重要的是，涵盖所有这些材料的优秀来源是 Java Concurrency in Practice，这是 Java 并发方面最好的书籍，也是整体上最好的 Java 书籍之一。

更新 2 - 以更简单的方式解决竞争条件

我最近注意到，除非您添加 executorService.shutdown()，否则您当前的代码将永远不会终止。也就是说，必须终止存在于该池中的非守护线程，否则主线程将永远不会退出。这让我想到既然我们必须等待所有线程退出，为什么不在它们完成后比较它们的持续时间，从而完全绕过FastestMemory等的并发更新呢？这更简单，可能更快；没有更多的锁定或 CAS 开销，而且无论如何你已经在做 FileArray 的迭代了。

我们可以利用的另一件事是您对FileArray 的并发更新是非常安全的，因为每个线程都在写入一个单独的单元格，并且在写入期间没有读取FileArray。

这样，您可以进行以下更改：

// In PoolDemo
// This part is the same, just so you know where we are
for(int i = 0; i<Iterations; i++) {
    Task t = new Task(i);
    executor.execute(t);
}

// CHANGES BEGIN HERE
// Will block till all tasks finish. Required regardless.
executor.shutdown();
executor.awaitTermination(10, TimeUnit.SECONDS);

for(int j=0; j<FileArray.length; j++){
    long duration = FileArray[j];
    TotalTime += duration;

    if (duration < FastestMemory) {
        FastestMemory = duration;
    }

    if (duration > SlowestMemory) {
        SlowestMemory = duration;
    }

    new PrintStream(fout).println(FileArray[j] + ",");
}

. . . 

// In Task
// Ending of Task.run() now looks like this
long Finish = System.currentTimeMillis();
long Duration = Finish - Start;
FileArray[this.ID] = (int)Duration;
System.out.println("Individual Time " + this.ID + " \t: " + (Duration) + " ms");

也试试这种方法。

您绝对应该检查您的 C# 代码是否存在类似的竞争条件。

Answer 2

...但是 Java 偶尔需要 2000 毫秒...

还有

    byte[] list1 = new byte[Size1];
    byte[] list2 = new byte[Size2];
    byte[] list3 = new byte[Size3];

hickups 将是清理您的数组的垃圾收集器。如果你真的想调整，我建议你对数组使用某种缓存。

编辑

这个

   System.out.println("Individual Time " + this.ID + " \t: " + (Duration) + " ms");

在内部执行一个或多个synchronized。因此，此时您的高度“并发”代码将被很好地序列化。只需将其删除并重新测试。

Answer 3

虽然@sparc_spread 的回答很棒，但我注意到的另一件事是：

我以 1000 次函数迭代运行应用程序

请注意，HotSpot JVM 在客户端模式下任何函数的前 1.5k 次迭代和服务器模式下的 10k 次迭代都在 解释 模式下工作。 HotSpot JVM 自动将具有这么多内核的计算机视为“服务器”。

这意味着 C# 将在 Java 之前执行 JIT（并以机器代码运行），并且有机会在函数运行时获得更好的性能。尝试将迭代次数增加到 20,000 次，然后从 10k 次迭代开始计数。

这里的基本原理是 JVM 收集有关如何最好地执行 JIT 的统计数据。它相信你的函数会随着时间的推移运行很多，所以它需要一个“缓慢的引导”机制来实现更快的整体运行时间。或者用他们的话说“20% 的函数在 80% 的时间内运行”，那么为什么要全部 JIT？

Answer 4

你用的是java6吗？ Java 7 具有提高并行编程性能的功能：

http://www.oracle.com/technetwork/articles/java/fork-join-422606.html