@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 代码并部署就行了

@byte10 nbio http 如果想支持 fasthttp 这种也不难，参考默认的支持标准库的 Processor 实现一份 Processor 就行了，不过我暂时没当期在 nbio 自带一份实现给它，以后闲了考虑给它写个

@lesismal 修正：虚拟机是 6c12t 的

@byte10 请看我上一楼的回复，有兴趣的话来跑下 1m 测试，老夫这一两周撸的 http parser 和 nbio 基础之上的 http server，并且兼容标准库的 http.Handler，所以除了 fasthttp 那种没使用标准库的，其他的 gin 、iris 、echo 、beego 等各种，都能比较容易地使用 nbio http 作为网络层，实现内存的巨大节约。不同的业务类型对性能和资源的考量不一样，响应速度和内存可能不能兼得，老夫也正考虑研究下 golang 里更高性能的协程池是否能搞定，如果能搞定，那就可以兼得了

后续还考虑支持 websocket 、http 2.0，但是每一项也都是个大活，http 1.x 已经基本完成，还剩下边边角角的细节优化项和测试，也是要耗费老夫不少时间，慢慢搞，老夫一定要让 golang 更强

@ERRASYNCTYPE golang 标准库每个连接一个协程，当前版本一个协程栈应该是 8k，连接数多了内存消耗就巨大了。其他语言多数是异步底层，每个连接不需要固定分配这么大的内存。连接数少的时候 golang 内存浪费不明显，连接数多的时候，会很明显

另外，最近一周多我又撸了份 http 1.x 的 parser，封装了 http server，在 nbio 基础上可以跑 http server 了，兼容标准库 http.Request，百万连接测试请看这里：

https://github.com/lesismal/nbio/tree/master/examples/http/1m

我单虚拟机做这种测试，虚拟机是 6C8T 的，因为客户端服务器都在这个虚拟机，所以没测百万那么多，50w 连接数，2k qps 的情况，server 端 cpu 平均 100%以内（ load 小于 1，不到单核），client 请求是多协程并发一直进行的不是平均的所有 server 端有偶发尖刺到百分之几百算正常，内存占用 400-500M
连接数更多、qps 更高内存会消耗更多些，但是跟其他语言异步底层相比，内存已经很省了，并且，50w 连接数，这种简单的 echo 测试，也随便能跑到 qps 5w+，定制少用协程的话可以跑 10w+。

另外，nbio http 从数据的 read 到 parse 到 handle request，这三个流程之间的协程使用都是可定制的，如果是做 nginx 类似的网关代理这种基础设施、不需要数据库等耗时操作，完全可以直接在 read/poller 协程内进行 parse 和 handle request，最大程度减少跨协程数据传递和调度的成本，细节我会在以后的帖子中慢慢整理，最近都忙于编码，还有很多细节或者性能优化可以做

希望能让 go 支持更广泛的业务，否则单就高阶的高并发，还真难干得过 java netty 或者其他异步方案