之前在性能测试中,我重新认识了随机数的功能性能测试中的随机数性能问题探索。但目前工作中接触到的都是静态的比例,即用例真正开始前,各个接口、场景的比例都是固定的。按照我的思路,旧会存在一个提前初始化完成的 list,但是最近工作中遇到了需要在压测过程中(动态 QPS 模型),动态调整两个场景的比例值,计划是在某个范围内周期波动。
其实核心问题:如何在一个变动的 list 随机实践中,保证线程安全。
这里先分享一下从一个数组中随机取一个对象的思路,如下:
/**
* 随机选择某一个对象
*
* @param list
* @param <F>
* @return
*/
public static <F> F random(List<F> list) {
if (list == null || list.isEmpty()) ParamException.fail("数组不能为空!");
return list.get(getRandomIntZero(list.size()));
}
可以看出这个方案中十分依赖 list 的size()
,这也是在动态数组中随机面临的问题。我解决问题的方案是这样:
size()
这里再附加两个逻辑:
下面是我的异步实践:
boolean upKey = false
fun {
//100s转变一次
while (FunQpsConcurrent.key) {
if (upKey) {
10.times {
sleep(10.0)
size.getAndAdd(-reduce)
reduce.times {
PriapiWriteApiQpsConfig.apiList.remove(13 as Integer)
}
add.times {
PriapiWriteApiQpsConfig.apiList.add(10)
}
size.getAndAdd(add)
}
} else {
10.times {
sleep(10.0)
reduce.times {
PriapiWriteApiQpsConfig.apiList.add(13 as Integer)
}
size.getAndAdd(reduce)
size.getAndAdd(-add)
add.times {
PriapiWriteApiQpsConfig.apiList.remove(10 as Integer)
}
}
}
upKey = !upKey
}
}
其中缓存 size 的代码:static AtomicInteger size = new AtomicInteger()
这里已经实现了预设需求。其中两点:
java.util.concurrent.atomic.AtomicInteger
,其实并不是必要的,可以使用 int 也是可以的。下面是我的随机的方法:PriapiWriteApiQpsConfig.apiList.get(getRandomIntZero(size.get()))
这里可能有的小伙伴有个疑问,因为在这个线程执行的过程中,从 list 中随机的方法的 QPS 是非常高的。一定会有随机到 100,但是刚好这个 100 的元素被移除这种情况。虽然我没有从现有资料中看到这个情况会 get 到 null 还是新的元素。但是据我自己的测试中,当随机方法在 10 万 QPS 的测试中,并没有发生。
FunTester 原创专题集锦
阅读原文,跳转我的仓库地址