@hez2010 #5 这个确实是毫无意义的测试, 你可以看下 #6, 当然, 其他语言也一样可以不用虚拟线程或者协程之类的, 都没必要用这么多内存. 但文章却非要选择使用虚拟线程和协程来对比, 然后海量的有栈 goroutine 就劣势了, 这不搞笑呢嘛 > `从结果来看 Java 的 Virtual Thread 要远比 Goroutine 更轻量。` 这个是文章里的结论之一, 用错误的测试方法, 得出一个作者想要的`正确`结论, 有意思? 别说什么都各自有褒贬, 方法和结论都不正确的前提下, 褒贬也都是不准确的. 然后这个所谓的结论对于大多数读者而言, 就是 java 的虚拟线程更优秀, 这本身算不算误导就各自琢磨吧 > 如果你认为 Go 就是天下第一，一切 Go 表现不好的测试都是因为测试不好，而 Go 没有任何问题的话那我也没话说。 我可从来没说过这个, go 标准库海量并发占用高我自己就知道, 所以我才搞 nbio 之类的方案优化, 而且相对成熟了, 可以替换标准库方案, 但是你们非要"只用标准库方案"的方式来评价整个 golang, 就不合理了 > 况且这测试也不是我设计的。 那你可以看下我的观点, 顺便多思考下, 避免只看表象, 避免不知其中深意, 避免人云亦云 这个测试如果是哪个老外设计的, 那他是不专业的, 我本来也是说这个测试而不是针对你

@grzhan #9 > 所以一般定时要求不严格的话很多 Golang 开源项目会给定时 duration 加个 10% 左右的随机抖动吧 例如 VictoriaMetrics 的 timeutil.AddJitterToDuration - 通常的定时功能没必要加抖动, 这个库的具体内容我没看. 定时加抖动有可能是为了避免同时创建大量具有相同超时时间的内容, 后续同时到期去创建大量协程异步删除内容导致 goroutine 过多造成不稳定, 或者其他什么特殊的需要

@lesismal #10 > 我可从来没说过这个, go 标准库海量并发占用高我自己就知道, 所以我才搞 nbio 之类的方案优化, 而且相对成熟了, 可以替换标准库方案, 但是你们非要"只用标准库方案"的方式来评价整个 golang, 就不合理了 标准库目前有计划改善这个问题吗？毕竟标准库用起来最简单，如果标准库能解决这个问题的话那岂不是不需要 nbio 这类的方案优化了。 另外看了一眼 nbio ，似乎是针对 client-server 网络场景特化的，牺牲了通用性。例如通过 goroutine 来代替多线程进行并行计算也是一个有效的场景。

@lesismal #11 > 通常的定时功能没必要加抖动, 这个库的具体内容我没看. 定时加抖动有可能是为了避免同时创建大量具有相同超时时间的内容, 后续同时到期去创建大量协程异步删除内容导致 goroutine 过多造成不稳定, 或者其他什么特殊的需要 应该是这样，像 Kubernetes 项目里也会用到很多 Jitter 去避免相同的超时时间（ https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apimachinery/pkg/util/wait/backoff.go#L203 ），像 kubelet ， 以及几个组件的 LeaderElection 都会用到，确实还蛮常见的。

@grzhan #8 可能作者本意不是拉踩, 或者不是故意拉踩. 但不正确的方法, 得出的结论就会误导很多人. 因为绝大部分开发者不了解系统知识, 不了解不同语言在这个不适合的测试场景与实际应用中的区别, 却给他们造成了错误的印象——例如 java 虚拟线程优秀, 然后可能误解 java 就是比 go 好. 刚看了下文章作者的 github, 主要是 rust java, 所以可能他自己也是默认偏好 rust 和 java 多些, 所以也没考虑过要对 go 的做多一些说明吧, 非故意的默认的放纵某些他以为的`正确`结论 所以我出来澄清一下 OP 或者其他人不要误解, 这并不是 go 邪教, 而只是实事求是 如果有人说 go 性能比 c/cpp/rust 强, 我要是有时间有兴趣也是会出来反驳的, 所以请 OP 或者其他人不要拿"我认为"golang 天下第一"说事

@hez2010 > 标准库目前有计划改善这个问题吗？毕竟标准库用起来最简单，如果标准库能解决这个问题的话那岂不是不需要 nbio 这类的方案优化了。 如我前面提到的, 标准库目前的 net.Conn 这些只提供了阻塞的 io 接口, 除非是特别简单的场景, 否则没法避免一个连接一个协程. 例如读, 不一定什么时候读到一个完整 request, 就只能阻塞在那等待, 这就需要占用一个协程. > 另外看了一眼 nbio ，似乎是针对 client-server 网络场景特化的，牺牲了通用性。例如通过 goroutine 来代替多线程进行并行计算也是一个有效的场景。 nbio 的 http 与标准库基本兼容, 写法和标准库基本一样的: https://github.com/lesismal/nbio-examples/blob/master/http/server/server.go 少量特殊情况不能像标准库那样, 例如 nbio 的 epoll 部分负责的 conn 是非阻塞的, 不适合拿去像标准库那样 io.Copy. 因为 nbio 本来就是为了避免持续占用协程, 如果还像标准库那样提供阻塞的 io 接口可以去 io.Copy, nbio 就没有意义了

@grzhan #13 嗯嗯 > 以及几个组件的 LeaderElection 都会用到，确实还蛮常见的。 election 这种, 我记得不太清楚了, 但好像记得个大概. 分布式一致性算法里的选举, 通常要避免各个节点都在相同的时间参选(发出自己选举的协议给其他节点), 因为如果大家都同时参选, 同时以相同的概率获得其他人的选票, 就会更难选出 leader. 所以在参选过程中, 例如启动, leader 掉线时的重新选举, 或者选举失败时的重选, 是可以每个节点自己随机一个时间抖动来尽量避免选举冲突的