gpt4 book ai didi

java - 以线程安全的方式更新ConcurrentHashMap

转载 作者:行者123 更新时间:2023-12-01 04:42:54 24 4
gpt4 key购买 nike

我正在对客户端代码中的一些方法进行基准测试,以了解这些方法花费了多少时间。因此,我编写了一个多线程程序,它将产生多个线程,然后我将测量这些方法在客户端代码和服务器端代码中花费的时间。

我有一个 ConcurrentHashMap 声明为

public static ConcurrentHashMap<Long, Long> map = new ConcurrentHashMap<Long, Long>();

现在我试图找出有多少调用在 X 毫秒内返回,因此我将这些数字存储在上面的 map 中。所以上面的 map 会存储这样的东西-

KEY will be Milliseconds
and VALUE will be Number of calls came back in those milliseconds.

下面是代码,我已经得到了。

final long start = System.nanoTime();

method.getInformation();

final long end = System.nanoTime() - start;
final long key = end / 1000000L;
boolean done = false;
while(!done) {
Long oldValue = map.putIfAbsent(key, 1L);
if(oldValue != null) {
done = map.replace(key, oldValue, oldValue + 1);
} else {
done = true;
}
}

我想看看上面的代码有没有问题?

我问的原因是,如果我正在运行我的多线程程序,那么服务器CPU使用率通常会达到80-90%左右。但是,如果我从服务器端代码中删除上述基准测试代码,则 CPU 使用率 不会达到 80-90%。所以这就是原因,我想看看是否有更好的方法来编写上面的基准测试代码来满足上面相同的场景?

感谢您的帮助。

更新:-

我在unix中使用TOP命令监视服务器端的CPU和内存使用情况-

top - 17:13:18 up 25 days, 23:24,  4 users,  load average: 1.72, 1.43, 1.04
Tasks: 114 total, 1 running, 111 sleeping, 0 stopped, 2 zombie
Cpu0 : 79.2%us, 5.8%sy, 0.0%ni, 23.1%id, 0.0%wa, 0.0%hi, 1.9%si, 0.0%st
Cpu1 : 83.7%us, 3.7%sy, 0.0%ni, 40.7%id, 0.0%wa, 0.0%hi, 1.9%si, 0.0%st
Mem: 6127684k total, 5122736k used, 1004948k free, 240436k buffers
Swap: 1331196k total, 0k used, 1331196k free, 2485984k cached

下面是我刚刚捕获的运行时的快照

最佳答案

这里存在一些潜在的性能问题。

  1. 您的基准测试代码正在向每个请求添加两次对 System.nanoTime() 的调用。根据请求中涉及多少实际工作,这些调用可能会很重要。

  2. 虽然您尝试使用 ConcurrentHashMap 减少并发瓶颈,但这并不能完全消除它。事实上,如果您有大量请求花费相同的毫秒数,则该特定计数器将出现瓶颈。如果特定计数器存在争用,则会导致“旋转”,因为不同的线程竞争更新它。

  3. 如果(假设) map 变得非常大,您可能会开始遇到与内存使用相关的问题;例如更大的工作集、增加的缓存和 TLB 争用、抖动。

但最重要的是,您添加的任何性能测量代码都可能会改变系统的性能特征。

关于java - 以线程安全的方式更新ConcurrentHashMap,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/16258118/

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