@blankmiss

帖子前置条件里我也说了，绝大多数人没这个扣内存的需求，但是确实也有少量比例的团队需要去扣这里，因为这部分人面临的在线量很大，扣这个能省的成本、对服务稳定性的提高也是很客观的

早几年 uber 就对海量并发各种 手动 gc 优化，甚至去改 go 源码。但其实如果用 nbio ，可能比他们的这些方式更有效一些

> 可能现在硬件条件已经很好，动态扩容，不是非常需要说对内存扣扣省省

动态扩容确实能解决一些问题，但成本也是不小，我知道的一些团队的一些服务，用的 java ，上百个云节点，而且这种公司还不是头部企业的业务量级。如果改成 nbio 这种，往多了说能省 95% 的成本，往少了说，也能省 80%

nbio 关注的用户里，估计大概三分之一是外国人吧，早期就有外国人是来用 nbio 处理高在线量的业务的

联排桌子抖腿才是大杀器
大家一起抖腿才是欢乐多

打不过就加入，你会发现工作变得有趣了

说好的男生永远专一永远喜欢 18-25 岁的女生呢

@blankmiss 欢迎来杠。

我想问一下，那 c/cpp 也都性能杠杠的，为啥还搞 rust ?
rust 解决 c/cpp 的安全问题

为啥 go 成为并发、云各种场景下的宠儿？因为它除了性能还不错，更重要的是开发效率高。

java 开发效率高，但是它对于性能场景和硬件消耗实在太不堪入目了，所以 go 替换 java 可以实现节能环保，并且开发效率也高。
别给我杠说什么 java 开发功能快，java 发展了多少年积累了多少轮子？而且很多说 go 开发效率低的真的熟悉 go 吗？而且时间久了 go 的轮子也越来越多越来越完善。如果为了当下谁轮子最多就用谁，那性能、占用之类的各种问题永远没法优化，甚至 java 社区自己都不需要进化、因为现在已经能做功能只是消耗高一些罢了。

你用 rust 更节能环保，你有 go 的这种开发效率吗？再说句不好听的，100 个人学 rust ，有几个能短时间玩熟练的？
c/cpp 三年不出门，go 三天 curd ，你 rust 学多久能快速开发？

> 唉...C1M 问题很久就有各种方案了（几乎是 10 年前），似乎重要的不是同时多少连接在线（一般只和内存大小相关），而是保持大链接下的高 QPS （调度能力），个人经验 4c 配置 QPS 很容易到达 30w 左右的（小报文）

@wslzy007

epoll 异步非阻塞早就解决 C1M 了，这没错，c/cpp 里也早就不是问题了。

但这个帖子说的不是 c/cpp/rust 或者 java netty 或者其他脚本语言那些基于 c/cpp 这些底层，而是 go ，搞 go 的 poller 目的是解决 go 标准库方案每个连接一个协程导致的内存爆炸 OOM 、GC 负担过重 STW 的问题，主要是针对 go 自己，而不是说用 go 解决了其他语言解决不了的 C1M 问题。

@byte10
嗯嗯，欢迎多来交流，java 只是社区积累的框架多，但性能相关的实在是太不友好了

平时少把 java 搞，内存杀手不环保
重心多往 golang 转，护发节能走得远

@buffzty 66666

@byte10
但如果想基于 poller 4 层 TCP 去自己实现 7 层框架比如 HTTP/Websocket ，那没什么好办法了，还是需要异步。但 nbio 提供的 http/websocket 并不需要用户全去写异步！不需要！不需要！不需要！我都给你说了好多次了而且这个帖子里也写了 “以前很多次遇到很多人先入为主地以为异步框架就是要写回调、golang 框架也如此。 为了避免误解”

你先看明白了，别再回复我说要异步了！
我快成复读机了快被你们逼疯了！！！
😇😇😇😇😇😇😇😇

@byte10 之前好多次没回复我，还以为你把我 block 了 :joy: ，感谢回复！

> 但还是保持一些观点，如果放在业务层去使用，大部分开发人员还是会用 协程去写同步代码，那么就跟你省内存的初衷违背了。

其实你还是误解了，我解释过好多次了，框架本身是提供了逻辑协程池的，用户仍然是同步代码，比如 http handler ，这个跟使用标准库写同步代码没什么区别:
https://github.com/lesismal/nbio-examples/blob/master/http/server/server.go#L19

nbio 里，每个 http 请求到来时取一个协程处理，这个请求处理完了这个协程可以继续服务其他请求，并不是每个连接固定、持续占用一个协程。

c/cpp 那些框架，线程太贵，所以线程池数量少，很多框架是逻辑单线程，所以需要各种回调。
但 golang 协程不一样，协程便宜，百万链接那是协程数量太大了，但是 1-10w 协程压力不大，所以逻辑协程池 size 弄个几千几万个协程是可以的。而且 golang 其他的 io ，比如到数据库，也是有连接池限制的。即使 100w 个逻辑协程也是可能被数据库连接池卡着等待，所以太大逻辑协程数量也意义不大，反倒是几千几万这种协程池数量，已经足够动态均衡了。

总结下就是，逻辑协程数量多但是可配置、不好过硬件能力：
1. 如果是快业务，每次请求处理很快、协程能很快释放给其他请求去复用
2. 如果是慢业务，逻辑协程再多也是要被阻塞，但逻辑协程数量通常远多余下游（比如数据库）的限制，所以仍有足够的空闲协程处理其他请求


所以对于通用需求，根本不存在你先入为主地以为的那种用了 nbio 就要写回调的问题。

而有一些需求，即使是用标准库，也可能是需要写回调的。特殊问题，特殊处理就可以了。

比较均衡的并发模式是：
1. 纵向的不同分层上（比如网络库、框架、业务层），各层限制好自己的资源使用，比如协程池、buffer pool
2. 横向的不同模块上（比如 A 功能 B 功能 C 功能），各模块限制好自己的资源使用，比如协程池、buffer pool


架构是灵活的，人也应该灵活，欢迎来试试 nbio

> 可，评论区的一些评论我实在看不懂～

你可能还不知道吧，以前只是站着说话不腰疼，现在是躺着说话他也不腰疼呐

@fds #26 windows 只为方便开发。。打死我也不会去支持 iocp 了，哈哈哈，太难搞了

@fds
> 标准库不可能接受这种异步的实现方式。go 标准都是用同步写逻辑的。

标准库底层是非阻塞 io ，net.Conn 给用户提供阻塞接口 Read/Write ，用户需要主动 Read
nbio 底层也是非阻塞 io ，nbio 的 http/websocket nonblocking 模式下给用户提供的是非阻塞接口 Write ，用户不需要主动 Read 。nbio 基本兼容标准库，用户基于 nbio 可以像写标准库 http 一样，少量不兼容比如涉及 io.Copy ，其他的普通功能，只要把 io 替换成 nbio 就可以了、业务代码都不需要改，gin/echo 之类的也都能轻松用 nbio 替换 std http server 。
代码看下就能用了：
https://github.com/lesismal/nbio-examples/blob/master/http/server/server.go
https://github.com/lesismal/nbio-examples/blob/master/http_with_other_frameworks/gin_server/gin_server.go

> op 不要灰心，大部分不需要连上万客户端的场景确实没必要这样优化，但我确实遇到过需要的情况。我当时是先试了 > https://github.com/panjf2000/gnet 后来用的是 https://github.com/xtaci/gaio 但结果跑了一个月遇到了一次死锁，> 运维直接重启了，也没日志，公司当时还有别的事要忙，就没继续改进。

来吧，用 nbio ，还有救：
https://github.com/lesismal/nbio

这里有百万连接 websocket 的：
https://github.com/lesismal/go-websocket-benchmark

> 3202 年是不是可以用上 io uring 了（

@codehz 单就网络 io 这块，不同场景下 io uring 、epoll 性能好像是各有优劣，并不是所有情况都一边倒，所以综合网络库 epoll 有历史加持、足够了。特定场景的话倒是可以考虑定向优化

> 2023 年还在写回调，无异于开历史倒车

@z3phyr
试试我这个，http 基本兼容标准库，http 和 websocket 来消息时都是可以写同步代码的。
https://github.com/lesismal/nbio

支持 OP 一下！

标准库的 net.Conn 底层是异步 io ，但提供给应用层的读、写都是阻塞接口。
1. 对于读：如果不使用一个协程循环读，它目前也没有提供事件回调机制通知用户数据到来，所以用户不知道什么时候可读，所以就循环等待读、读到了就处理。
2. 对于写：如果涉及广播、或者不允许写阻塞免得业务被卡住，那么也得自己封装异步写的机制

自己写也可以，但既然对读写还有疑问，估计 OP 要摸索很久才能做完善。
想省力的话可以直接用我的：
https://github.com/lesismal/arpc
https://github.com/lesismal/nbio

搜了下 "why macbook smells good"，得到如下：

https://www.quora.com/Why-does-Apple-packaging-have-a-distinct-smell

Of course, Apple won’t reveal the original combination of fragrances that goes on to create that smell. However, very recently, a Melbourne based artistic group “Greatest Hits” requested the famous scent marketing company “Air Aroma” to replicate this very fragrance for their art exhibition and to a great extent, they have succeeded. They are calling it "Eau de Mac Unboxing". However, it is not for sale!

For the record, that elusive smell is a combination of ozone, burnt plastic (polystyrene) used for wrapping, the smell of cardboard and quality paper and above all the massive piece of aluminum product. Some believe that the particular style of packaging and the process involved back in China factories are responsible for this odd but nice smell.

I personally find it is deliberately introduced in Apple products to induce the feeling into its consumer’s mind that they have bought a beautiful and essential product “all must and glory”!

翻译：
当然，Apple 不会透露产生这种气味的原始香料组合。然而，最近，墨尔本的一个艺术团体“Greatest Hits”要求著名的香水营销公司“Air Aroma”为他们的艺术展览复制这款香水，并在很大程度上获得了成功。他们称之为“Eau de Mac Unboxing”。但是，它是非卖品！ 根据记录，这种难以捉摸的气味混合了臭氧、用于包装的烧焦塑料（聚苯乙烯）、纸板和优质纸张的气味，尤其是大块铝制品的气味。有些人认为，这种奇怪但好闻的气味是由中国工厂的特殊包装风格和工艺造成的。 我个人发现它是故意在 Apple 产品中引入的，目的是让消费者产生一种感觉，即他们购买了一款美丽而必不可少的产品，“all must and glory”！