如果说没有合同解释，op 的行为还可以商榷
如果完全知道并且签了合同，那么按规则行事

@volatile 别迷信，水果水分糖分很高，不适合长期喝

@14104chk 能提到树，我觉得算 ok 一半了，就是实际实现，还是很考验的，我这个例子就是说明并发的存在和挑战

@GraySoul 依赖关系你怎么处理，等待怎么等待

@levintrueno 肯定用 Future ，但是你按照我上面要求写一个，就发现很多小细节，能体现并发掌握如何

@GraySoul 不是这个对象大，是这个对象上面要填充的数据大，可能触发多个 rpc ，db 等

@GraySoul 我这个就真的是真实场景

@GraySoul 给你一个我最近遇到现实例子：
一个很复杂的工作 job ，对一个对象进行操作，比如同时进行 a 、b 、c 、d 处理
同时之间这些处理逻辑，可能存在依赖关系，比如 a 完全可以独立运行，c 依赖 b 、d 完成之后才运行，等等

要求：
1. 尽量多并发执行，同时避免线程空等待
2. 严格按照依赖关系运行，并发安全
3. 最后有个等待动作，要求所有操作完成，job.wait

如果更高要求：
1. 是否可以中途中断，取消当前 /后续执行
2. 某个操作异常处理如何，是否做到 继续 or 中断
3. 每个处理逻辑，是否可以影响调度过程，比如跳到指定逻辑，或者跳过指定逻辑
4. 有没有最大等待时间
5. 是否可指定等待某个阶段完成就好了，不需要所有都明确完成
6. 防止滥用资源，是否可以控制最大并发数

想想，你要怎么设计

如果写中间件，那么多线程就是基本知识了
而一个好的框架，就是让开发者不需要过度考虑并发问题

15w 美系（伪）豪华品牌，这个价位基本和“豪华”没关系了，取舍而已
去年 byd 卖了 186w 量，怎么可能都是滴滴

@Livid
V2ex 有些 bug ，提醒也没有，@ 引用提示的人，逻辑我有点看不懂，是帖子出现的人吗？好像也不是

@house600 公司内部项目，不大合适开源，原理基本都讲了

@machen
我可没对你怎么输出，就是说你这个功能，不是刚需，没解决痛点
我更没怎么蹭，引 gist 是为了和 @house600 讲怎么实现，“来回引用”？相对你的帖子，我们两位的讨论更有价值点

@lesismal 我刚想说这种回调式写法，协议要使用状态机去实现，就看到你 nbhttp 用状态机解析 http 协议
omg ，这工作量我都不敢想，但是你确定实现了一个完整的 http 协议解析了吗？这工作量可不小

@lesismal 我为我言语表示道歉，因为这个帖子本身在推广自己 lib （还蹭美团），你又贴了自己链接，导致把你也一顿输出~。不是相轻，相反，能写出这样项目的人，水平很高，因为需要知识扎实（我写不出来，除非我去看别人代码）。

> 你前面提出的几十万协程问题，是指实际进行同步 io 的行为，后面楼层又说标准库的同步 io 也足够。

回归这个问题，就是说不管是否池化，是否协程，对资源的限制都是需要的，否则下游都会击垮，因为真实环境，就是一定还会访问下游（ db/redis/rpc ）等
标准库的同步 io 也足够，是指如果只是挂在 net.Conn.Read() 的协程，那多一些也问题不大

---
回到技术问题：之前没看你这个项目，这次去认真看了~
但是，盲猜通过回调实现，比如 Java 里面的 netty ，只有这样才实现少数 io 协程分发
结果确实是：
g.OnData(func(c *nbio.Conn, data []byte) {
c.Write(append([]byte{}, data...))
})

刚好我写过 netty 协议的 encoder/decoder ，还写过一些嵌入式类似回调解析协议
我的体验就是，回调式符合机器设计，不符合人类思想，维护状态是很累的
如果你用两种方式来解析 websocket 协议，就能体现明显差距
我说的“反感”，就类似，Golang 官方那么努力能你写平铺直叙的同步读写，一把给干回来了

我另外一个顾虑是：类似这种依赖某个 x 这么基础组件，有一天 Golang 升级到 xxx 版本了，协程更高效了
然后没有人敢升级，因为这个 x 组件重度依赖，做了好多高科技，没人敢动，这在我们技术上出现过
---
说点我的技术选择：
1. 主流技术优先，Java 世界 Spring 一把梭，甚至按着官方文档来就好了； Golang 就官方库，在上面封装一下脚手架
2. 选择 /实现方案的时候：解决程序员心智问题优于其他，代码的可读性优于其他
---
你这项目我准备 clone 下来看看怎么实现的

@lesismal 你这逻辑，无非是，net.Conn 都会挂住一个协程，比如 Read 操作，到几百万协程
而你自己写了类似 epoll 监听，只有 readable connection 才会实际占据协程，对不？

我说的几十万协程，是指实际进行同步 io 的行为，比如消费 kafka 然后 db/redis/rpc 操作等，瞬间击垮对方 /自己系统
对于因为监听 io 阻塞的协程，其实 Go 官方也是足够用的，虽然看起来协程多很多

说点打击你积极性的话，我非常反感一些很底层操作，使用非官方库的行为，其中包括协程、nio 部分
真正有你这种需求的，只有有限的 im 、网络转发才需要
the key point: 绝大部分遇到的问题，都是 io 相关，说的天花乱坠，db/redis/log 先要看能不能抗住

很多人做的事情，很像是，把一个长板，构建的更长，然后给大家看，哇，我做了多厉害的工作，然后短板依在。

这个计数器控制，直接上代码：
https://gist.github.com/cloudzhou/3d0eae4c77b35117071a05e3d2c4f999

@house600 细节上，做了多个线程池的梯度下降处理，举个例子，定义线程池 poo1 -> pool2 -> pool3 ，最大线程数量从高往低，每个 namespace 定义的最大 pool 占用百分比，分别是 5%，20%，30%，类似这样，一个 namespace 最大占用线程数：
max = poo1*5% + pool2*20% + pool3*30%

除非同时有 20 个 namespace 都占用了那么 5%（那你系统一定有大问题），否则资源最大化同时，又有隔离限制，达到一个平衡