@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 好，如果看不懂说明基础有点弱，多读好书补补

@lesismal 业务层的程序员小伙伴们完全可以继续用同步逻辑写代码，单就 http server 来讲，应用层是不受影响的

后续要做的 Upgrader 之类的，也是框架胶水层 wrap 一下，应用层的逻辑其实都可以不受影响。

BTW，websocket 实现得差不多了，争取下周放出来

@abersheeran 其实类似兄弟你喜欢有栈协程的问题，我在主帖 “两点澄清”部分有解释，只是大部分人 Get 不到这些点，心酸，:joy:

除了 golang 、erlang，其他那些手动档的协程其实都是垃圾，并没有减轻代码逻辑复杂度的人脑解析负担，甚至比回调更让人恶心。。。

@wslzy007 http 1.x 已经支持，详情请看我上面几楼的回复

@ERR @byte10 为了省去虚拟网络或者 docker 或者多台机器之类的部署环境的麻烦，1m 连接测试的代码是开了多个监听端口，因为即使只是 1 个端口，实际处理接受连接和数据读写的 poller 还是那些个 epoll fd 协程，所以开多个端口对性能影响不大，但是测试起来就方便多了，如果想只用一个端口，代码稍微改下或者各位用自己的 cleint 代码并部署就行了