gpt4 book ai didi

java - 并发程序的性能会随着线程的增加而下降吗?

转载 作者:行者123 更新时间:2023-12-01 22:20:13 25 4
gpt4 key购买 nike

我一直在尝试在四核计算机上实现以下代码,执行器服务中线程数超过 100 次迭代的平均运行时间如下

1 thread = 78404.95

2 threads = 174995.14

4 thread = 144230.23

但是根据我的研究,2*(核心数) 线程应该为程序提供最佳结果,但这显然不是我的程序的情况,它奇怪地为单线程提供了最佳时间.

代码:

  import java.util.Collections;
import java.util.Random;
import java.util.Set;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;

public class TestHashSet {

public static void main(String argv[]){
Set<Integer> S = Collections.newSetFromMap(new ConcurrentHashMap<Integer,Boolean>());
S.add(1);
S.add(2);
S.add(3);
S.add(4);
S.add(5);
long startTime = System.nanoTime();
ExecutorService executor = Executors.newFixedThreadPool(8);
int Nb = 0;
for(int i = 0;i<10;i++){
User runnable = new User(S);
executor.execute(runnable);

Nb = Thread.getAllStackTraces().keySet().size();
}
executor.shutdown();
try {
executor.awaitTermination(Long.MAX_VALUE, TimeUnit.DAYS);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
long endTime = System.nanoTime();
System.out.println(0.001*(endTime-startTime)+" And "+Nb);
}
}
class User implements Runnable{
Set<Integer> S;
User(Set<Integer> S){
this.S = S;
}
@Override
public void run() {
// TODO Auto-generated method stub
Set<Integer> t =Collections.newSetFromMap(new ConcurrentHashMap<Integer,Boolean>());;
for(int i = 0;i<10;i++){
t.add(i+5);
}
S.retainAll(t);
Set<Integer> t2 =Collections.newSetFromMap(new ConcurrentHashMap<Integer,Boolean>());;
for(int i = 0;i<10;i++){
t2.add(i);
}
S.addAll(t);
/*
ConcurrentHashSet<Integer> D = new ConcurrentHashSet<Integer>();
for(int i=0;i<10;i++){
D.add(i+3);
}
S.difference(D);
*/
}
}

更新:如果我将每个线程的查询数量增加到 1000,则 4 线程的性能优于单线程。我认为当我每个线程仅使用大约 4 个查询并且没有查询时,开销高于运行时增加的运行时间现在大于开销。谢谢

最佳答案

But 5 Threads Supposed to increase the performance..?

这就是>>你<<的假设。但事实上,并不能保证添加线程会提高性能。

But according to what I have studied 2*(no of cores) of threads should give optimal result ...

如果您在某处读到过该内容,那么您要么误读它,要么完全错误。

现实情况是,实现最佳性能的线程数量高度依赖您的应用程序的性质,以及您所运行的硬件。

<小时/>

根据对代码的粗略阅读,这似乎是测试 Java 处理多线程访问和更新共享集 ( S ) 的性能的基准。每个线程都在线程限制集中执行一些操作,然后将线程限制集中的所有条目添加或删除到共享集中。

问题是addAllretainAll调用很可能是并发瓶颈。基于 ConcurrentHashMap 的集合将比基于 HashMap 的集合提供更好的点访问/更新并发性能。然而,addAll 和retainAll 对其他线程正在操作的相同条目执行N 个这样的操作。鉴于这种操作模式的性质,您可能会在 ConcurrentHashMap 的不同区域内发生严重争用。这可能会导致一个线程阻塞另一个线程……并导致速度减慢。

Update : If I increase no of queries per thread 4-threaded is performing better than Single threaded .I think overhead has been higher than run-time when I used only about 4 queries per thread and as no of queries increased Runtime is now greater than Overhead.

我假设您的意思是要增加 HashMap 条目的数量。这可能会减少平均争用,因为 ConcurrentHashMap作品。 (该类将映射划分为多个区域,并安排涉及不同区域中的条目的操作产生尽可能小的争用开销。通过增加不同条目的数量,您可以降低两个同时操作导致争用的可能性。)

<小时/>

所以回到“2 x 线程数”事实。

我怀疑您一直在阅读的资料实际上并没有说这会给您带来最佳性能。我怀疑他们真的这么说:

  • “2 x 线程数”是一个很好的起点...您需要根据您的应用程序/问题/硬件调整它,和/或

  • 对于计算密集型任务,不要超过“2 x 线程数”……因为这不太可能有帮助。

在您的示例中,争用的主要来源很可能是对共享集/映射的更新......以及确保它们自动发生的开销。

您还可以在较低级别获得争用;即内存带宽争用(RAM 读/写)和内存缓存争用。是否会发生这种情况取决于您所运行的硬件的规范...

<小时/>

最后要注意的是,您的基准测试存在缺陷,因为它不允许各种 VM 预热效果......例如 JIT 编译。您的 2 个线程时间超过 1 个线程时间的两倍这一事实表明了该问题。

关于您的基准测试还有其他可疑的方面:

  • run() 完成的工作量方法太小了。

  • 该基准测试似乎并不代表现实世界的用例。在完全虚构的(无意义的)算法中测量加速不会为您提供有关在缩放线程数时真实算法可能如何执行的任何线索。

  • 在 4 核机器上运行测试意味着您可能没有足够的数据点来得出具有科学意义的结论......假设基准测试是合理的。

<小时/>

话虽如此,您所看到的 2 到 4 个线程的速度减慢对我来说并不意外。

关于java - 并发程序的性能会随着线程的增加而下降吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/30008459/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com