支持一下

@qieqie 这样确实会更快一点，不过应该基本无影响。就像很多框架的 benchmark 差很多，但是架不住加上自己的业务逻辑后都差不多了。。。

@lesismal 我也是看 fiber 接口设计比较舒服，基本的功能也都比较完备，然后好像还说作者全职在做这个所以用的，之前就看到过一篇文章说高并发下有问题不过也没太在意。。。生产环境下有啥好推荐的么

https://cloud.tencent.com/developer/news/462918

@dallaslu
@no1xsyzy
@makdon

感谢分析~ 用 Immutable: true 就正常了，可结贴了

@dallaslu 确实是这样

如果是 test.lua 是

request = function()
num = math.random(1, 1)
path = "/item/id" .. num
return wrk.format("GET", path)
end


就是链接唯一的话，又正常

@makdon
@lesismal
@GTim
@Orlion
@sxfscool
@Lpl
@ClarkAbe
@kcojkcnw

我补了一份最小测试用例，你们看看能不能复现，我仍然是一头雾水

我用下面的方式测试了一下，比之前的结果要好一点，但是还是不对，但是 tmp 里面的访问次数加起来只有 nginx 的 access.log 里面的一半

accessLog.Lock()
tmp := make(map[string]int)
for k, v := range accessLog.data {
tmp[k] += v
}
accessLog.data = make(map[string]int)
accessLog.Unlock()

@makdon
@lesismal
@GTim
@Orlion
@sxfscool
@Lpl
@ClarkAbe
@kcojkcnw

各位大佬，我又测试了一下，用 counter = &Counter{data: make(map[string]int)} 初始化全局变量，然后后面重新赋值的时候也加了锁，但是仍然不行，打印 accessLog.data 的时候用 "%s, %x" 打印 key，结果 hash 是一样的

https://p26-tt.byteimg.com/origin/pgc-image/4963875f190e4ccf9b8a89fcbad8590e
https://wkphoto.cdn.bcebos.com/d1160924ab18972b923ebfb4f6cd7b899e510a43.jpg

然后如果打印 tmp 的话，因为 json 格式化之后，重复的 id 都去掉了，就会变的特别少
这个图，上面是打印 accessLog.data, 下面是打印 tmp

https://p26-tt.byteimg.com/origin/pgc-image/55a1b5f43bce43058915b2a74561f1d6

@ZSeptember
@makdon
@Lpl

就这样，直接打印 accessLog.data 的话，有重复的 id

@joesonw 嗯，就是本来只要几百个 key 的，结果 map 长度可以上万，也打印过 map 本身，看到的就是有重复的 key

@joesonw 是要加个锁，不过不是因为这个，我试过把这句注释掉，也是一样的

@Lpl 这个只是个简化的例子，实际上还需要处理一下，不过意思是一样的

@makdon 不是的，我用的就是 map[string]int，统计的就是一个字符串 id 的访问次数，hashkey 是一样的
要是正常我就不问了，问就是因为不正常
我也感觉光看这段代码应该看不出什么问题，但是事实就是这么猝不及防的发生了，脑阔疼

@no1xsyzy
@GTim

补在后面了，看看能不能发现什么问题

@AngryPanda 按理加了锁应该不同的协程也是 OK 的

@Lpl 批评的对
atomic 的话，由于 id 不是唯一的，好像不太方便
没试过用管道，我直观以为管道性能会更差一点，看来我理解错了，可以试一下
有看到过用分段锁的例子，concurrent-map 这个，不过我测了一下就用一把锁好像也足够用了就先这么用了，结果就出现了这个神奇的问题，完整的代码补上了，你看看能不能看出来哪里的问题

@skiy 这个代码简洁了一点~性能下降了一点~