@makdon
原来 63 楼已经回复过了，66 楼多余了，缘分

@Lpl 恩恩，这种简单功能都不会性能瓶颈，主要还要考虑设计上的复杂度，chan 不是万能灵药，毕竟加了一层 chan，同步逻辑变成了异步逻辑，换成 chan 的实现也不比 mutex 来得简洁，并且也不如用 mutex 容易理解

锁是很基础的设施，不要怕用它

@GTim 不用以后深入研究，就今天吧

不能怪 fiber，fiber 是基于 fasthttp 的，以前看过 fasthttp 相关介绍大概意思是 fasthttp 为了性能，很多地方 pool 复用内存，虽然我没有读 fasthttp 源码，只是大概分析，但是大致原因应该是差不多的：

应用层获取 http 各种参数时是复用的[]byte unsafe 的方式强转成 string，类似 c/c++的浅拷贝，新的 string 和原来的[]byte 类型结构体的数据指针指向同一段内存，而在本次 handler 调用结束后，这段[]byte 就被放回了 pool 并且以后有新的地方使用时又被拿出来
比如楼主的 key 加入到 map 时字面值是 "a"，按照 "a" 的 hash index 存到对应的 map 的 bucket 里，而这个 string "a" 的结构体内部指向的内存被放回 pool，其他地方再次从 pool get 到时就可能被复用的地方修改，比如刚好其他请求的这个 key 复用了 "a" 的同一段内存但是这些请求的 key 为"b"，"b" 加到 map 里的时候是按照 "b" 的 hash index 存到对应的 bucket 里的、不同的 hash index 则不碰撞、不会跟原来的那个 string "a"（当前字面值也是"b"）比较，所以就产生了多个 key

实在不喜欢 fasthttp
但是 fiber 的接口 /API 设计看着比 gin 舒服，还是挺喜欢的
但是生产项目，我还是不打算用 fasthttp 系的

@zkdfbb 最好可以给一份可以复现的代码+测试用例，大家可以复现下看看

@Lpl 淡定点，淡定点
1. 每个路由预先存到这个简单的统计里，代码会很漂亮？而且这点计数功能用 mutex 性能也不是瓶颈
2. 照本宣科这个词不是为了贬低，而是想告诉你不要听别人说好就什么都用什么，要懂得从实际出发
3. 先看懂我回复的内容
另外，chan 和 mutex 你可以自己先 benchmark 试试，chan 的源码在 runtime/chan.go 里，本身就带有锁的逻辑，并且跨越了协程，如果你觉得会比 mutex 性能好，那可以试试看

@kcojkcnw 对。32 位也一样，pointer 是字长，并且这种非结构体成员变量是对齐的，除了老奔腾还是哪个版本年代之前的，i32 也是原子的

@Orlion 对，这份代码里问题最大的就这句，accessLog 原来的内存被赋为新值的过程不原子，所以可能 panic 、还可能 Incr 的 Lock 是原来的 Mux 、Unlock 是新的 Mux 所以死锁

我还是建议我 25 楼说的那样都改成 accessLog = &Counter{data: make(map[string]int)}

@makdon 过奖了，3q

@Lpl
我上一楼的回答的 1 中，即使 map 的 value 使用对象，然后 atomic 操作对象的 value 也不适合，因为最早 map 为空，拿不到对应的 value，如果判断空先存入，那还是要加锁，除非你的 key 数量和 key 值都是固定的、创建 map 时就初始化了 value

@Lpl

1. atomic 做的原子操作是比加锁快吧

先看 3 的回答吧，因为锁不可避免，所以在这里根本不能使用 atomic

并且因为是按 map 的 key 进行统计，首先你得取这个 map key 对应的 value，而直接取 map[key] 的地址是不行的，你试试编译下：
m := map[string]int32{"a": 0}
atomic.AddInt32(&m["a"], 1)
会报错： "cannot take the address of m["a"]"


2. 用管道通过求摸建立多个协程来消费

相对比较复杂的并且需要保证临界区一致性的并发逻辑可以考虑用 chan 替代锁来避免锁的复杂度尤其死锁等情况，但是简单功能，就比如这种计数器，使用 chan 实现起来会比锁更麻烦并且性能稍微损失一点点，完全没必要，要从实际出发、不能照本宣科

3. 目的是为了每一个 key 都能并发安全，加细粒度的锁不用去加对象锁，concurrentmap 不就是这样做的吗

首先要解决获得这个 key 的 value，获得这个 key 本身就需要对 map 的锁
标准库的 sync.Map 一样内置锁来实现、只是应用层不需要自己使用锁罢了
其他的三方 concurrentmap 实现也并不能实现每个 key 粒度，而是为了减少 key 数量巨大时并发流的竞争，所以在标准库 map 之上再加一层 hash buckets，再每个 buckets 对应的结构上用一个锁，go 标准库自己的 map 本身就是个 hash 下面多个 buckets，三方 concurrentmap 相当于再加一层 hash 分开成多个锁来降低粒度为 bucket 级别减少竞争

顺便推下自己项目：
https://v2ex.com/t/761727
https://v2ex.com/t/734682

accessLog = Counter{data: make(map[string]int)}
先改成
accessLog = &Counter{data: make(map[string]int)}
否则可能 panic

key 的问题，Counter 的 func 都把 key 先 trim 一下

@Lpl
另外，9 楼 3 条没一个是对的

也不知道楼上有几位都是啥情况，老夫如此热情，连句话都不回，是因为看不懂吗。。。

试试我这个： https://www.v2ex.com/t/734682

纯为了支持 json-iter 来占个楼 ^_^

@FucUrFrd *nix 进城内文件描述符的特点、产生与回收再利用可以看一下，数组对比下 map/rbt 的时间复杂度以及除了时间复杂度，那个复杂度的每次操作本身是包括哪些操作，都可以看下。

既然无国界，就不要上纲上线的

@FucUrFrd 如果跟太大陆了就跟 github 无国界冲突，那好多用英语的，太欧美了，其他非英语国家地区的人怎么办？这么讲的话，github 不能用地球国家的语言了

@FucUrFrd
1. NIUBILITY 即使太大陆了，也跟 github 无国界不冲突吧？难道 github 无国界所以就不能有大陆相关的了？你的逻辑思维有些乱，建议加强训练一下
2. 这个地方数组比 map/rbt 好，如果看不懂说明基础有点弱，多读好书补补