> 如果是合同期内的裁员，公司一般会给个 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 。

很多开源作者是没有开源精神的，他们是为了自己利益，一旦看到比自己好的、当然要加固自己的护城河。

如果是我，非常喜欢别人在我项目下面聊他们的同类项目、互相交流。

我比 OP 直接还没情商。
凡事对老旧的一团和气、即使它不够好甚至很垃圾而且不改进、对它也还一团和气、没人出头去刚，那么更好的东西就很难出头，反倒被这些老旧的垃圾尸位素餐。

所以，一团和气是那些留给普通人的，做的比你好、怼脸开大是最好的了！支持 OP 怼脸！

@zhengfan2016 sqlc 生成代码的方式、性能当然是最好的，但也有不方便，比如一个 tx 、后续 tx 多个操作、操作之间还有一堆其他代码逻辑，这种如果修改功能之类的，也是麻烦。sqlx 、ent 我也都觉得不好用，所以我自己搞了个 sqlw ，raw sql+自动的 struct 绑定，日常用着省力多了。比如：

model := Model{
I: 1,
S: "str_1",
}

result, err := db.Insert("insert into sqlw_test.sqlw_test", &model) // 也可以 insert []model
// result, err := db.Insert("insert into sqlw_test.sqlw_test(i,s)", &model) // insert the specified fields
if err != nil {
log.Panic(err)
}


var models []*Model // type []Model is also fine
result, err = db.Select(&models, "select * from sqlw_test.sqlw_test")
// result, err = db.Select(&models, "select (i,s) from sqlw_test.sqlw_test") // select the specified fields
if err != nil {
log.Panic(err)
}

我一直抵制 ORM ，建议不要用 ORM 。

现在 AI 确实强，不太需要自己写 SQL 了。

@LASockpuppet #61
传统有时是美德，但有时也是枷锁，会让自己错过很多探索和体验的机会。
如果要问我怎么知道的：老来方悔读书迟——多么痛的领悟。

好奇，纹的什么图案、什么部位？

早就 star 过了，支持国人开源之光！

除了 gnet ，作者的 ants 协程池的库，我们很多人测试也是没跑出他所谓的比别人强的指标来：
https://github.com/panjf2000/ants

净搞这些没实际用处的然后一顿吹、骗小白 star 很多 star ，实话实说怎么这么难，什么世道。

之前没细看、看错了，说归类为剥离的那个人不是官方的。

gnet 作者 close lock issue ，所以没法继续在他的 issue 里说这个问题了，把对他的回复放到这里仅供吃瓜娱乐：

related: https://github.com/panjf2000/gnet/issues/733

之前没仔细看，不是官方的列为” Stripped/剥离“。但不影响这个事情的本质。


https://github.com/panjf2000/gnet/issues/733#issuecomment-3398069779
> 你这人到底是怎么回事？首先，README 上已经清楚明白地写了 techempower 测试榜单上的 gnet 的 HTTP 实现是非常不完整的，我都说明了 gnet 那个实现不是生产可用的，而是专门用于压测的；其次，gnet 以前的 issues 里就有好几个讨论过 techempower 榜单了，而且 techempower 仓库下面也有我曾经创建过的 issue 和 PR ，都对这个事情说明过好几次了，gnet 这方面的信息一直都是透明的，我一直以来的观点都是 techempower 是作为压测性能的一个榜单的参考，而且我印象里你都在这个仓库下面说过好几次这个问题了，我都回复那么多次了，你怎么还在胡搅蛮缠？

> 还有，之前有很多人在 gnet 的仓库下创建了 issue 提问题，然后你跑到那些 issue 下面拼命地宣传你自己的开源项目，我之前已经警告过你了，你现在还变本加厉了是吧？无缘无故翻出 techempower 这个我早就澄清过几百遍的事情，在这个 issue 里又夹带私货把你的自己的开源项目宣传一次，我真是忍无可忍了，你这人能不能把自己的时间花在有意义的事情上而不是天天跑来 gnet 的仓库蹭热度？开源社区最重要的是分享和讨论那些有创造性的代码和想法，而不是天天在社区里无端地去抹黑和攻击别人，希望你能好自为之！！！

本来不想再给你提这些问题，但是隔三差五就有一些公众号作者，发文章吹 gnet 性能，而且是以 TechEmpower 的 HTTP 性能结果在吹 gnet 的 HTTP 性能，这已经是好些年的对社区造成了误导的实际情况了。
并且你没有在 README 或者任何明显的地方、包括你宣传的文章帖子，没有进行有效的澄清和说明，issue 里提到过的也都关闭了，通常用户不会去翻到 issue 才知道真相。
所以，这种误导一直在持续。
当然无法指责你是主观故意利用这种虚假宣传误导用户获得更多 star ，但实际的效果确实是这样的。

提到我自己仓库，只是想告诉你，gnet 功能性能都很一般，gnet benchmark 的代码里曾经有依赖过 nbio 、nbio 的 used by 里有过，但后来删掉了、应该是有人提交过后面被你删除了并且清理了 git ，至于原因我就不猜测了，大家心里清楚。

另外，我不需要蹭热度给自己涨 star ，因为我已经不做程序员了，而且 nbio 我也已经放弃。
放弃 nbio 的原因，如上个 issue 说的，多数用户的场景不涉及海量连接、用标准库性能更好，而涉及海量连接的场景的基础设施，c/cpp/rust 性能更强开销更低，新项目用 rust 更适合。
nbio 的一些改进的地方我早已知晓，例如改纯异步、支持 protocol stack 方式的解析，buffer 一对一分配释放，http body 不用等到读完就可以触发 http handler 、后续 OnBody 等等。但是如上所述，这些改进都不重要了，所以我没有继续改进了，而是放弃了。以后用业余时间再维护下给老用户或者交流就罢了。

你要是只敢快速 close lock issue 而不是正面去处理，始终用这种虚假的方式宣传、维护这份虚荣，那随便你，但这并不是好的方式。

如果真正开源精神贡献社区的态度，请你正面说明和澄清下 gnet 性能的误导性问题，而不是让虚假的东西继续。

当然，不澄清是你的自由，但是，别人隔三差五给你说这个事情的时候，你还能问心无愧的时候，那也请你不要嫌烦。
注意：正面说明，应该在明显的地方，而不是犄角旮旯、大部分人看不到的方式。