@cmdOptionKana
A 和 B 是个人发挥，这些坑货品牌我全批评，但是具体到某次发言可能只批评某个品牌，因为这是普通吐槽不是写论文，你要求消费者去完全理性逻辑严谨咬文嚼字对待这种琐事？是不是理科思维中毒、职业病太重一切都要符合逻辑、对社会、群体行为有什么误解？
消费者是人，普通人，你要求普通人不要对人挑刺、否则圣人也架不住，但是你又要求普通人像圣人一样思考、批评个坑人的品牌还要考虑一碗水端平让各个坑人的品牌反噬均等，你当自己是皇上在这搞帝王术平衡木呢啊？
生活不是做理科题，生活有很多感性。你不是圣人，别人也不是圣人，建议思考下普通人群体、心理学、行为学相关的，放过自己。

> 己所不欲勿施于人，你想不想受到不公平对待？

@cmdOptionKana #171

既然己所不欲、勿施于人，我相信，如果 x 布斯消费的时候，也不希望被其他品牌大小字坑骗，那为什么不让 x 布斯先做到己所不欲勿施于人、而是反过来让大量的相对弱势的个体消费者被坑了之后连批评这种事情都己所不欲勿施于人？

如果要讲公平，为啥只替企业鸣不平？是消费者被坑骗在先，为啥不按照先后顺序、先站在消费者角度替消费者讲讲公平讨讨公道？

替做错的品牌强者卖力吆喝、打压被坑骗的消费者的正常批评，是有点过于双标了的

@cmdOptionKana #176

> 这是事实吗？

就我个人的感受而言，这就是事实，因为国内这些明星品牌的发布会、宣传，都不如 x 布斯牛逼，所以影响范围差不多就是最大了。
结合整个社会的反响来看，真正骂它的人也是很多。xx 领先也被骂的很多，这也是事实。每个被大骂的品牌背后都有黑子，也有大量的真正觉得被欺骗的消费者，而这些大品牌也真的都有大量的公关、法务团队。所以整体上看谁被反噬的最多就差不多了，例如黑子占比 50%，一共被 10 个人骂，那真正骂的有 5 个，另一个一共被 8 个人骂，拿真正骂的是 4 个。

> 定罪要不要证据？

大家是在批评，没人在给他定罪。
按照你的逻辑，品牌坑骗消费者，还不让别人说了？

如果不是过于沉迷导致的狂热和霸道，那就是利益相关水军嫌疑了。

can't agree more!

@cmdOptionKana #170

没有不公平。

因为大小字这事情属它发扬得最光大，相比于其他品牌，它家的大小字遥遥领先、影响/误导的人最多（我也是被坑的人之一），所以骂的人最多。
欲戴王冠，必承其重。大小字做的“最强”，既要享受前期忽悠消费者时带来的正面流量，也要承受被消费者发现真相后的负面流量。
还是和上次一样，我觉得你其他挺多观点都挺客观的。但是大小字这事情，替它战斗，只会为自己也招来更多不赞同，没必要。

> 小米的小字备注具体有什么问题，如果你想把事情搞清楚，能不能讲具体一点，方便讨论？

@cmdOptionKana #27 这个没什么好洗的，前不久官媒下场批“大字吸睛、小字免责”，并且市场监管总局研究起草《广告引证内容执法指南（征求意见稿）》了。

如果觉得法无禁止即可为、品牌方不违法就不是问题，
那么大众觉得品牌方这样做不道德、骂品牌就也不应该是问题。

> 好多实现底层都直接用 epoll 了，上层协议解析还在死循环读 buffer

@penpenpen 好多都是被 gobwas/ws 带偏了吧 😂

nbio 只是不继续搞新的功能和优化, 不花那么多心思维护了, 还可以用.
但是连接数不是海量的, 基于标准库的方案确实更好, 所以就没什么必要用异步的方案了.

> 如果是合同期内的裁员，公司一般会给个 N+1 的方案，但是没有主动权，主动权在劳动者。一般没啥想法的劳动者就签了拿钱走人。但是如果劳动者不接受拒不签字，那只能走强制解除，强制解除按照劳动法的规定是要支付 2N 。

符合流程的合法的裁员是 N+1 ，强制解除也不需要 2N ，只有违法解除并且劳动者举证仲裁打官司之类的赢了才能 2N 。


> 身边最极端的一个案例是，劳动官司在法院排队了一年，最后法院支持[继续履行劳动合同]，劳动者从裁员纠纷开始一直到判决，公司都要照常支付正常工资/年终奖/股票，公司损失惨重。这以上一切还不算公司因为劳动纠纷产生的舆情损失。

这个是公司的 HR 部门和裁员流程不专业导致的吧

用谷歌的 VM 没被 D 过,国内厂的只部署个简单 echo 测试工具都会被 D 然后推销高防.

所以就很有意思,到底谁在 D 这种没有实际业务的节点.

我大学室友，大四面试的企业中，有两家知名企业有类似行政能力测试那种、包括智力题之类的，因为他笔试成绩一骑绝尘、比那两家公司当期和所有历史招聘的笔试成绩最高分还高了 20 多分，大概就是能进门萨俱乐部的水平，然后两家企业都让他止步一轮游了，说即使给 offer 即使入职了公司待遇没那么好、也是留不住。他当时很纳闷为啥一轮就凉了，因为他是整个院里智商最高的选手了，后来那两个公司给其他进入第二轮的其他哥们讲了原因、回来告诉大家才知道。

@Nanosk
go 协程池的几种主要实现方式：
1. 早期最简单的 chan 方式，多数实现会支持常驻协程，性能一般，但是简单易用。
2. gent 作者的 ants ，用 cond_t 实现，好像也是支持常驻协程。实现复杂，号称性能吊打其他协程池，但我和一些朋友实测并没有发现性能优势，而且实现的过于复杂，可能只是跟其他那些用 chan 的实现方式对比有优势。
3. 字节家的 gopool ，链表作为任务队列，如果当前执行任务的协程数量小于协程池 size ，则直接创建新的协程去执行任务，否则就等待当前正在执行任务的协程 for 循环挨个取任务执行。这种相较于 1 、2 性能是最好的，实现也简单。但有个缺点，生产持续大于消费速度时，队列一直增长，没有对上游自动反馈和限流的机制。
4. nbio/taskpool 的实现方式，与 3 中的字节家 gopool 类似、区别在于用 chan 做队列。


1 、2 两种都是支持常驻协程。但是，大概 golang 1.18 以后，runtime 自己有 goroutine 复用之类的，所以 go func()开销很小，比 1 、2 用 chan 、cond_t 那些实现方式性能更好，而且省掉了常驻协程。常见的 rpc 框架中、每个 Call 的处理默认都是 go func()，压测每秒几十万次 go func()都没什么压力，因为任务快速、同时并发存在的协程数量不多。协程池本身就限制了协程池 size ，所以每次 go func()就可以了，根本没必要使用常驻协程等待任务到来、新任务用 chan 传递反倒浪费性能甚至大于 go func()的开销。


3 、4 两种，多数时候设置的协程池 size 是 1w 以上，多数的业务，整个系统请求下有资源可能阻塞才会让协程池的协程短暂驻留，但通常 1w 这种级别也足够用了，否则下有资源也扛不住太高的并发量级，而且下有通常也是自带池限制的、比如 http.Client 和 sql.DB 的连接池。
而且多数情况是协程池 size 跑不满的，所以 3 、4 两种通常都是简单的原子判断协程池 size 、然后 go func()去执行、性能最好也最简单。


所以 1 、2 的那些库我是不推荐的。


我自己在 nbio 中使用自己的这种实现，因为 nbio 的主要设计目标就是资源控制、避免严重的 STW 和 OOM ，所以这种上下游之间的自动反馈和限流很有用。
如果你的业务上游自己有对协程池的限流，则直接使用字节家的就好，否则建议用 nbio 的这种。


字节家的：
https://github.com/bytedance/gopkg/tree/main/util/gopool

nbio 的（实现的很简单，百十来行有效代码，如果需要定制之类的、自己拷贝过去随便修改即可，feel free ）：
https://github.com/lesismal/nbio/blob/master/taskpool/taskpool.go

免费版够用+1

@sthwrong
突然就没了是指 nbio 删掉了？我说放弃不是这个意思，而是放弃进一步开发或者优化了，以后只做基础的维护。

我总结了一些 nbio 可以优化的点，需要新开个仓库或者 v2 的方式，不与旧版本兼容：
1. 不兼容标准库 http 了，改成纯异步，因为标准库是同步的方式、http handler 退出就意味着这个请求结束，但如果涉及 handler 内逻辑需要阻塞（例例如请求数据中间件、调用 rpc 、请求三房 api ），那么协程就需要常驻等待。
2. 纯异步后，不用等到 http body 收完整就调用 handler ，并且提供异步的 OnBody 给用户使用。现在的方式是读到完整请求（包括大 body ）再调用 http handler ，遇到比如上传大文件这种场景内存就扛不住了，所以应该改成异步、读到一点就处理一点、避免内存压力。
3. buffer 的严格一对一分配和释放，这样有利于引入 c 的内存池 lib 例如 jemalloc 、tcmalloc 做内存优化。现在的方式，因为早期没考虑这么细，实现上使用 sync.Pool ，而 sync.Pool 即使不严格一对一 Put 也会在不需要的时候被 gc 、不会导致内存泄漏，所以当前版本不是严格的一对一分配释放，这样的话就没法使用 c 的内存池库优化了、因为会内存泄漏。我倒是想过另一个办法，利用 Finalizer 在变量被 gc 的时候自动去调用释放、避免有遗漏释放的情况，但这种毕竟也是不严格、如果遇到短期洪峰也可能会爆、还不如 runtime gc 压制 OOM 的效果好。
4. protocol stack 的方式去实现协议栈的解析。比如 tcp/udp 收到数据后，给上层的 tls parser 去解析，tls 解析后得到的 buffer 再给 http 或者 websocket 的 parser 去解析。当前不是这种类似中间件、协议栈链的方式去层层传递的，所以支持多层次的协议或者一些扩展时实现起来比较痛苦。例如有些用户想用同一个端口监听 http 、sock5 、普通 tcp 自定义协议，nbio 现在的方式是硬编码、很难去做这种根据第一段 buffer 的内容判断是哪种协议再分流的功能，只能让用户自己实现 listener 然后再额外包装再转给 nbio 之类的，但这种观念方式意味着用户自己实现的 listener 需要为每个链接阻塞读到至少 N 字节的协议头数据、这意味着每个链接要开一个协程，与 nbio 的设计就冲突了。

放弃的原因主要因为：
1. 如果改纯异步，与现在兼容标准库 http 就设计冲突了。
2. 上面提到的几个优化点，虽然实现方式了然于胸，但工作量不小，我现在没这个精力去做。
3. golang 的性能虽然已经不错了，但我对它的性能还是不满意、甚至失望。尤其这种海量连接数的场景毕竟是少数、而且都是基础设施比如网关之类的，这种场景 c/c++/rust 性能和开销更优势，golang 除了开发效率、毫无优势，而能有这种并发量级的通常是大厂、有人力物力去用 c/c++/rust 做，比如 CF 开源的那个 rust 版的 pingora 。