@CloveAndCurrant 哈哈，给你机会了。既然你不会我就帮你个忙。

Wiki 中很明确的提到了 stackful 和 stackless：

https://en.wikipedia.org/wiki/Coroutine#Definition_and_types

> Besides that, a coroutine implementation has 3 features:
> - ...
> - ...
> - whether a coroutine is able to suspend its execution from within nested function calls. Such a coroutine is a stackful coroutine. One to the contrary is called stackless coroutines, where unless marked as coroutine, a regular function can't use the keyword yield.

同时也举例了：

https://en.wikipedia.org/wiki/Coroutine#Lua

> Lua has supported first-class stackful asymmetric coroutines since version 5.0 (2003), in the standard library coroutine.

很明显，有栈协程和无栈协程都是协程，不是加个定语就可以随便用的。Wiki 也不是连个有栈无栈都不懂的“过时”信息。

同一页面也明确指出了：

https://en.wikipedia.org/wiki/Coroutine#Go

> However, goroutines are not coroutines (for instance, local data does not persist between successive calls).

goroutines 不是协程，加再多定语也没用。

这个总结不是给 @CloveAndCurrant 这种人看的，他除了嘴硬啥也不懂。但我相信其他人看了自然能明辨是非。

我不相信 @CloveAndCurrant 能再给出任何有意义的回复了。不和他聊了。

@CloveAndCurrant 嘴硬。

@CloveAndCurrant 哈哈，光会说，您倒是引用一个 wiki 说“goroutines 是有栈协程”给我看看啊。需要我帮你吗？

@CloveAndCurrant 哈哈，您真是定义的神啊。您来定义下我是在“引用 wiki”还是在“抠字眼”？


https://en.wikipedia.org/wiki/Coroutine#Go

However, goroutines are not coroutines (for instance, local data does not persist between successive calls).

@CloveAndCurrant 哦？

我引用你说 wiki 不是真理？

我说大家 wiki 和你二选一，你开始骂人“老 B 登”。

我说到让你爸来投票，你开始求我别拿 wiki 抠字眼？你是真怕他不选你啊？

我都被你逗笑了，这是你的职业吗？

@CloveAndCurrant 你也不会别的啊。上来就输出一个 goroutine 是协程然后还砸脚了，然后说别人“抠字眼”哈哈。然后除了吹牛，又“工程领域”又“wiki 不是真理”的，好像你亲妈给你起名叫真理似是。

信不信让你爸来他都会选 wiki：宁要 wiki 不要逆子。

@CloveAndCurrant 诶呦，好几天了，咋还是那套车轱辘话啊。我以为你学了啥新东西来怼我呢。也是，您这辈子就这样了，连个术语都改不过来，哪还能学会新东西啊。昨天吃几碗饭没忘就不错了。

不过你总碰瓷 wiki 干啥啊？你脸不要啦？你连个术语都搞错，还代表“工程领域”否定 wiki ，好在没人把你当回事。

你觉得 wiki 是错的，但是你不说你觉得，那你就是对的了？你可真是个小天才哈哈。不知道你家长给你配手表了吗？

你和 wiki 二选一，真不知道整个地球上除了你 MA 还有谁会选你。[捂嘴笑]

格盘别选快速格式化就行。Windows 或者大多数软件都能解决。格完物理销毁，没人会捡你的垃圾再费劲儿恢复数据偷看的……

买了十几个小游戏，花了两百。

@ykrank 哈哈，无所谓了，我心里有数。

@james122333

> 作者这样搞不是有目的就是真不知

作者就是随手撸几段代码测一下，我看到的是单纯的程序员的快乐。不要阴谋论啦。

@james122333

> 那这种测试结果本身基准就不平 得出的结论也就看看就好

额，怎么说呢……测试结果，看的就是某个语言使用某种实现能得到什么样的性能。我们只要客观的理解数字就可以了。

只有带入过多感情，认为有些数值高的赢了，某些数值低的好像输了，才会纠结“公平”。

@james122333 我不认为不相似就没有可比性。性能测试的重点之一就是从一个方面提供不同策略不同实现之间的差异给人做参考。

@lesismal 我完全理解 goroutine pool 在生产环境里的作用。这东西 Java 用了几十年了，什么好说的。

但是如果 goroutine 的成本真的便宜到几乎免费，我们大多数时候是不需要因为“性能问题”而使用 pool 的。使用 pool 的主要用例应该是间接限制 goroutine 所对接的外部资源。

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

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

@james122333 额，好吧，我还是维持我的观点。

@james122333 抱歉，没能理解你说的 golang“没有队列等机制确保负载不爆阿”。

大家都是 green thread ，都需要去分配资源去占用原生线程。

你的说法听起来是在表达 golang 的调度机制不够优秀。但你说因此要 Java 换原生线程来比好像还差点说服力。

@james122333

> 虚拟线程是真实线程内用队列处理任务 其它的语言用事件驱动也是差不多道理 对标 golang 应该是 goroutine+channel

goroutine 也是在原生线程里 run 的啊……

三本也太少了……前面的挺努力了，我让了吧。

@james122333

> 如果是这样 那应该是 java 纯用线程不用虚拟线程对 go 开 goroutine 比较 这样两者相比才是正确的

Java 的虚拟线程就是对标 goroutine ，这两个都是 green thread 。我不太明白为什么不应该比较。

> 因为文内 go 的使用方式就是错的 使用对方法 go 也是可以大幅降低内存使用

关于文中 Go 的使用方式错误能否具体点？