@charles0 #152 叫 goroutine 没毛病, 但是打字中文的时候协程比 goroutine 快, 而且很多人约定俗称都这么叫了, 日常讨论, 何必搞得学术氛围甚至法庭审判那样? 你们好几位出来说这个, 我反向建议下你们在实际生活中要灵活, 否则方言俗语一切约定俗成的谬误的词汇就都不能说出口了, 这样的活法, 会很累而且并不会对交流效率带来提升, 反倒会因为这种死板给更多遵循约定俗成的人带来麻烦, 让大家交流效率更低

@lesismal #151

甚至, golang 的 GMP, 我都忘记了, 要说 10 年 8 年 5 年甚至 3 年前, 应该都还记得, 但是现在都不记得了, 刚才回复 @Kauruus 也是临时搜了下 GMP 才又知道了个大概.
而且这几年自己可见的速度在记忆力下降, 每次看到 golang 面试题的帖子, 很多也是不会, 只剩下一些实践的套路经验了, 上年纪了也没体力重新读这些书了, 不是不想, 而是真的力不从心了
幸好工作上也不太需要这些概念了

华山派剑宗风清扬我做不到, 但是像他一样的风格还是适合工程实践的, 什么这个气那个气的内力之类的, 先能把工程搞定并且搞好才是好

早早入行, 未来可期, 加油加油!

@Kauruus
@CRVV

补充一点, 工作久了也不是钻研学术的, 很多概念定义也早忘光了, 我更多的是专注于实践, 所以有说的不对的地方是我不懂, 说错了我就认, 不会赖账的

另外, 就像我前面说的没必要咬文嚼字, 聊具体的代码问题, 不需要纠结严格定义的, 咱就少点学术氛围, 免得搞半天也搞不出个成果来

@ykrank

> 等你技术进步到和它“一个层次”了

你这个"它"很会用啊, 你技术强的话可以输出技术观点, 技术的观点一点没有, 有话都不敢直接说, 阴阳最有一套是吧?
你咋不上天呢?

@Kauruus #145

> “这组线程”就是内核线程，有对应内核调度实体，Goroutine 才是“用户态线程”。

在对线程的细分定义上讲, 用户线程你说的对, @CRVV 说的也对.
我之前没有深究过用户线程这个细分概念, 把它理解成非内核创建的线程了, 是我的错.

不论严格定义如何, 把 goroutine 叫成协程已经是大家的惯用叫法, 日常讨论说线程用于代表严格意义的内核线程多些, 除非涉及细分定义, 否则也不会去区分用户线程还是内核线程.
但是如果把 goroutine 叫成线程, 是更让人混淆的, 把 goroutine 叫成用户线程是严格定义上正确但在日常交流上更多也是会带来麻烦
各种细分的严格定义, 例如说线程的时候不叫线程而是叫轻量进程, 也是给非学术交流带来沟通障碍, 约定俗成的叫法可能会更适合日常讨论.

> 按照你的说法，就变成 M:N:O 三层了。

我只是想表达: 线程 -> go runtime -> goroutine, 没有想表达是几层, 具体到 goroutine 的调度就是 go runtime 的 GMP,

而且几层也得看怎么划分:
如果按照调度实体分类, 那就是两层: 线程被内核调度, goroutine 被 runtime GMP 调度
如果是按这些抽象角色分类, M/P/G 也可以说是三层

@CRVV #140

自己在那不 at 别人偷塔断言别人不懂说别人错了还理直气壮, 然后老夫硬刚你, 技术和逻辑都说不过就飙脏话是吗?
既要又要, 又 x 又 x 的, 当别人眼瞎好欺负呢?

谢谢你 Block 我, 免的以后再来浪费我时间

@CRVV 刚又搜了下, 你说的"用户态线程"可能是指"纤程"吧? 对不起, 这玩意好像是 Windows 的, Windows 开发相关的知识我确实是不熟悉, 我说的主要是*nix 的

@CRVV #128

你真逗, 社区里大家都叫协程, 你为了严谨, 非要叫"线程"或者"用户态线程".

而且, 你让我用 "线程或者说用户态线程" 就更扯了:
1. 线程比协程更具有辨识度, 通常是操作系统内核进行调度的, 比如 CSAPP 里这样讲:
https://cs50mu.github.io/post/2016/08/29/csapp-concurrent-programming/

Threads. Threads are logical flows that run in the context of a single process and are scheduled by the kernel. You can think of threads as a hybrid of the other two approaches, scheduled by the kernel like process flows, and sharing the same virtual address space like I/O multiplexing flows.

2. 用户态线程通常是对应内核线程, 而一个 golang 进程首先是进程自己有一组(1-N 个)用户态线程, goroutine 是基于用户态线程之上的应用层语言 runtime 自己进行调度的, 最大的区别, goroutine 可不是由内核调度的

你要是说 goroutine 是"类似线程的东西"这种模糊的定义还凑合, 但是直接把 goroutine 叫做线程或者用户态线程, 你可以做个问卷调查看看, 是我们把它叫做协程容易让人懵逼还是你的叫法更容易让人懵逼.

> 技术词汇和 “那可不是嘛” 是两码事

方言, 约定俗成这些事你如果不认同, 那咱们不用讨论这个了, 但是也请尽量弄清楚你自己的技术词汇是否真的准确, 比如 goroutine 线程.


> 但你说的最后一段就是纯扯蛋，不要论断人。

如果不想自己被他人断, 就不要自己先乱断他人.

@kneo #122

> 如果还是因为 goroutine 本身的性能原因而使用 pool ，我认为就语言实现层面还是差点意思。

是单个 runtime 的阈值. 我日常 4c8g vm 跑个压测, 10w 协程这种级别, 调度/内存/gc 都没什么压力的. 但是 50w 以上, 压力就大了起来, 1M 级别的压力就更大了, 耗费非常高的硬件仍然稳定性艰难.
标准库是满足了绝大多数人的需求, 因为没这么大量, 足够好的性能, 但少量业务还是需要海量的, 能稳定高性能低消耗就能省很多硬件成本.

> 回到这个帖子所引用的原文，我认为它至少从一个方面回答了到底在哪还差了点。

不同的业务 golang 有不同的应对方案, 我前面也说过了, blog 作者用这种方式测这个并发任务属于错误用法, 而其他场景, 也会有对应的优化 goroutine 数量的方案.

但有些场景确实目前还没有海量 goroutine 的优化方案, 例如 HTTP2.0 QUIC/HTTP3.0, 暂时还是一个连接至少一个协程的方案, 因为目前的 2.0 3.0 实现都还是基于标准库的 net.Conn 都还是阻塞的 IO 接口.
我想把 nbio 做更多支持这些, 但是工程量太大了, 年纪也大了体力跟不上, 而且是业余时间为爱发电不是全职搞, 个人的精力消耗实在承受不起.
我希望以后能有人继续把 HTTP2.0/3.0 以及更多协议也搞成类似 nbio 的这种方案, 然后就不用再担忧这些瓶颈了

@CRVV

> 不过错的就是错的，别理直气壮地用错误词汇。

我想问下, 如果想用中文, 用什么词翻译 goroutine?
约定俗称的事情你也是一点不提啊? 我十几年前就写 lua 用 coroutine, 刚开始用 go 也是看了一些人讨论的定义, 但是照样, 大家中文叫法就是协程, 因为即使讨论了说了 goroutine 不是协程, 也没人给它个正确的中文翻译并且流行起来, 所以大家继续这样叫.
然后你就这么断言觉得别人就是不知道 goroutine 不是协程定义的那个协程并且错了还理直气壮是吗?

这么自信吗? 普通话里"那可不是嘛", 这里用"不是"但意思是"是", 要不要也去给大众纠正批判下, 让大家平时说话不要这么讲错就错至少不要这么大声面的看上去犯了错还太过理直气壮?
这种谬误和约定俗成的事情多了去了, 好几个人跑这卖弄贬低还不敢直接 at 人, 显得你们能是吧?

@kneo 其实吵吵挺好的, 不打不相识, 技术这种, 只要理性吵, 越吵道理越清晰, 而且很多技术路线之争, 即使是在老爷子们或者不同社区之间, 也是互相很多争吵, 争吵是因为没有一个完美的方案, 吵的多了, 改进多了, 就越来越好了
吵过了就都翻篇过去了, 以后咱也多多交流

@james122333 @kneo

继续上点货, golang timer+简单的 goroutine pool:
https://gist.github.com/lesismal/aaf767b03f669908b1d5aae61a135a1c

goroutine pool 就是用 chan 的简单实现
timer 的是直接用的 B 站毛剑的这个单协程, 稍微改了下 timer 到时触发后用上面的 goroutine pool 去执行 func:
https://github.com/Terry-Mao/goim/blob/master/pkg/time/timer.go

具体需要多少 size 的 goroutine 自己设置, 10000 的并发度已经足够满足绝大部分需要了

m3 macos 简单跑了下:
1M task, goroutine pool size 10000, chan queue 1000, cost 115M
1M task, goroutine pool size 1000, chan queue size 1000, cost 95M

如果再改改时间轮之类的优化下海量 timer 的每个 itemsize, 还能再省些内存, 但是这个版本已经足够了

@kneo

> 感情我只要“同意”就是人云亦云？和你意见不一样就是“底层知识不了解”？您了解底层也没看您说出来“golang 的 goroutine 是预分配固定大小 2kb 的内存”这种话啊。

前面说我不礼貌, 你不看为啥措辞这么火气, 因为你们阴阳在先
我假定你不懂这个那个, 也是因为这么没意义的测试, 你在那阴阳而且很赞同, 但凡基础知识够用也会对这个测试产生质疑和更多的理性探讨, 就像其他很多楼层的兄弟提到的那样, 草率觉得这个测试没问题同意测试结论, 大概率就是基础知识不够. 如果我的这个假定是错的, 那你再看看我#96 替你惋惜的吧

即使争吵, 我也真心祝你技术越来越进步, 这样可以避免大家以后更多争吵, 甚至会在同一个战线上同一个观点上去为别人厘清真相

@lesismal @kneo #100 只是举例子哈

@lesismal #99

> 就像是, 咱俩要测试 100 米谁跑得快, 我可能跑不过你, 但是让你坐轮椅用手弄轮子向前, 然后我跑赢了说你跑得慢你也觉得合理是吧?

+ 因为虽然 [ 咱俩都可以双腿正常跑, 且用轮椅跟我用双腿正常跑两者方法不一样 ], 但是, 结论确实是你用轮椅比我正常跑慢 —— 这个就跟 blog 这个测试是一样的, 那我建议你保持逻辑的严谨和一贯性, 所以以后你就自认你自己跑得慢吧

@kneo

@kneo #97 和着他测试方法不对齐, 结论文不对题你是一点都不 care 是吧? 就像是, 咱俩要测试 100 米谁跑得快, 我可能跑不过你, 但是让你坐轮椅用手弄轮子向前, 然后我跑赢了说你跑得慢你也觉得合理是吧?
前提和基础都错了, 还在这聊什么结论? golang 协程占用还用聊吗, 大把的帖子文章说过这个事情好些年了, 这还用专门去测才能得出结论?

> 遇到质疑，您的回复是

你不看看为啥我用这种语气是吧? 你在本帖第一句上来是啥方式在回复自己都不记得了是吧?
“半吊子脑残老外”确实是不友善, 但也被你们阴阳怪气在先气到了, 而且也是说说事实罢了, 能写这么篇看上去清晰但实际上没有意义甚至误导还好几个站去推广他的观点, 说他半吊子脑残也是陈述事实, 而且不只是在这个帖子里说, 我这个人比较直接, 在你 #97 回复之前我就已经在 reddit 上去回复他了, 英文我直接说 Stupid :
https://www.reddit.com/r/programming/comments/1h2e35m/comment/lzjwidj/

我也有菜鸡的时候懵逼的时候头昏说错的时候, 发生这种情况别人喷我 sb 等我反应过来我也乖乖承认, 被人说菜说脑残是自己活该, 毕竟误导了别人

什么收敛什么脸红, 扯淡! 之前大部分回复, 没有太过认真编辑, 因为上班时间草草回复了事, 前面你所谓收敛的几个, 是因为下班回家了在这时间充沛, 所以把几个完整的逻辑理清了给你, 要是收敛我就不去 reddit 回复原作者了, 这种 blog 是属于坑小白的误导人的, 就该有人出来指正, 当然, 没被你们阴阳气到的话我也不至于这么不礼貌

至于礼貌, 你们个别人上来不说技术具体的点, 上来就阴阳别人, 这样就礼貌了? 这几年, 不只是 v 站, 各种社媒, 阴阳的人都太多了, 是啥好事情吗? 十句话八句不离阴阳, 有的人甚至张嘴必阴阳, 感情阴阳就是礼貌了? 连技术这种摆在桌面上 1 就是 1 2 就是 2 的问题都不敢直接坦坦荡荡聊非要阴阳, 还跟我谈礼貌, 我的礼貌是留给值得的人的

@kneo 再说说我为什么提到 nbio

我在 #6 就说过了：

1. 实际场景里也不可能全是 cpu 消耗的 task, 所以 sleep 类型的 task 是合理的
3. 如果 sleep 是为了模拟实际场景里的 io 消耗例如网络 io ...

因为测试是用于给实践作参考，所以看到这些 benchmark 我都会联系实际场景，我看他这个 blog ，会从多方面多个角度去考虑问题，例如前面楼层我讲到的一些，而不是像你那样只看他几个简单文不对题的结论。
#6 里我也给出了前提，基于实践场景的考虑，并且我也从来没觉得 golang 天下第一，因为我知道 golang 的性能不是第一，也知道海量 goroutine 内存占用带来很大压力、不只是内存，还有 gc 和对应的 stw 。
所以我把解决方案带出来，但是巧了，这个方案就是我自己搞的，你可以说我是夹带私货，因为确实是夹带私货，但也正如我前面所说，我把好东西拿出来分享，没什么觉得羞愧的，反倒是觉得光荣，因为我确实给有需要的人带来了帮助。

另外，你说我说的这些技术点不是干货，如果对于你确实不是干货，
首先我为你感到欣慰，因为这说明你基础知识比较好、已经算是基础很不错的同行了，
其次我也为你感到惋惜，因为即便掌握了这么多干货知识：
却不能上来就聊技术的点而是上来就阴阳，
却只是看到别人个 blog 就跟着人云亦云，
却不懂得辩证低综合地实践地去分析和看待技术问题，
却像孔乙己对待茴字一样在这咬文嚼字拿着一个协程概念当成宝，连什么是约定俗成都搞不明白
。。。

@kneo
> 你在这刷一天，连个结论都说不出来，我现在告诉你“Java 的 virtual thread 比 go 的 goroutine 成本还要低”，我说了，你反驳我下试试？

说到这个 blog 的结论，我建议你先看看 blog 的标题吧：
How Much Memory Do You Need to Run 1 Million Concurrent Tasks ？

这是测试百万并发任务占用多少内存，而不是百万 go 协程/java 虚拟线程情况下协程和虚拟线程的占用对比，而他的结论呢？
有的语言是说总占用，go 和 java 又谈协程和虚拟线程了，并且得到的结论之一就是你咬住的这个 “Java 的 virtual thread 比 go 的 goroutine 成本还要低”，我说他文不对题不为过吧？
如果是为了这种结论，我建议他把标题直接改成 “Java virtual thread vs goroutine memory cost“。

咱们再回到这个测试的意义上，为什么我说他这个测试没有意义：
1. 百万并发任务的实现有多种方案，通常是为了测出语言能力的上限，对应内存占用，应该是尽量找出消耗更小的实现，而这个测试里的 go 方案就是用最浪费内存的方式
2. 例如 node 这种，本质上就是定时器+回调，java 和 go 是有栈 vthread 和 goroutine ，但不论是 java 还是 go ，也都可以用定时器+线程/协程池的方式去实现，这些不同的实现方案来对比内存占用，不只是对 go 不公平，对 java 也是不公平的
3. blog 作者不同语言采用不公平的方案来测试百万任务，得出虚拟线程和 go 协程占用的对比结论

综上，在多种语言能够对齐实现方案的前提下，为不同语言采用了内存消耗差异巨大的不同方案，然后为了测试一个目的 A ，得出了一些 XYZ 结论。
从标题立意，到过程方法，到结论，驴唇不对马嘴！
说他没意义一点也不为过！

我刷一天得不得出结论不需要你下结论，但是如果前面你说的这些就是你的结论，我建议你，既然聊技术，即使带着情绪，至少也要对技术的部分心平气和点，多用事实说话而不是只输出语气