16

我正在测试在 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 我更改了下面的代码以显示使用 Executor Service 线程池。我还安装了 Java 7。

我在热点 VM 中设置了以下优化:

-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;
        }
    }
  }
}
4

4 回答 4

19

概括

以下是原始响应、更新 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每个步骤都在原子步骤中,因此没有线程可以在测试和更新步骤之间滑入以导致竞争条件。

最简单的方法

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

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

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

中间方法

您可能不喜欢为监视器使用整个类,或者通过使用类来公开监视器等。您可以做一个单独的监视器,它本身不包含FastestMemoryand 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();
    }
}

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

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

最后但同样重要的是,涵盖所有这些材料的优秀资源是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# 代码是否存在类似的竞争条件。

于 2012-04-04T12:41:40.617 回答
5

...但 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。因此,此时您的高度“并发”代码将被很好地序列化。只需将其删除并重新测试。

于 2012-04-08T12:43:13.400 回答
4

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

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

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

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

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

于 2012-04-08T04:48:27.117 回答
2

你用的是java6吗?Java 7 具有提高并行编程性能的特性:

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

于 2012-04-04T12:26:19.310 回答