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

@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 的使用方式错误能否具体点？

@lesismal

> 即使争吵, 我也真心祝你技术越来越进步, 这样可以避免大家以后更多争吵

谢谢了。不过避免争吵不是靠谁技术进步，而是平等和包容的讨论问题。技术进步是为了保护自己下次别吵输了。

@lesismal

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

您可下找到重点了。看标题，人家测的就是 Memory ，很明显测一百万是为了知道每个 goroutine （以及其他语言里常见的并发模式）的平均开销。这是这个测试的唯一目的。这个测试结果，不代表 Java 比 Go 强，也不代表 Java 在高性能的表现比 Go 强，连 latency 和 cpu 这种数据都没有，这个测试就是很单纯的一个内存测试，它并不是一个完整的性能测试，但它绝非无效测试。

具体来说，它提供了一个对比数据：一个 goroutine 的内存开销大概是 2KB ，Java virtual thread 大概是 1KB 。

这个测试就是这么简单纯粹，没有一点问题。后面也有人提出了“golang 的 goroutine 是预分配固定大小 2kb 的内存”，和测试完全相符。

您：

> 毫无意义的测试, 却顺便拉踩, 捧 java 踩 go, 实在看不下去了我才必须出来澄清下.

遇到质疑，您的回复是：

> 说句不好听的, 你懂吗? 你懂多少?
> 系统, 底层知识不了解, 只知道看个半吊子脑残的老外的 blog 就在那人云亦云? 还很自豪?

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

还“半吊子脑残老外”这种话，您也说得出口？礼貌吗？看你现在说话收敛了点，冷静了？自己回头看自己的回复脸红不？

> 就是你们这种人多了, 才把技术讨论搞得乌烟瘴气!

信不信，如果你不出现，这个贴子早就在讨论为什么“一个 goroutine 的内存开销大概是 2KB”。

看你最后几个回帖码字不少，虽然观点我不敢苟同，但能看到到你的微妙变化。不再一一针锋回复了。

@CloveAndCurrant 啥也拿不出来在这嘴硬，别误人子弟了。

你知不知道有些错了一辈子的老油条，从一开始就错了，还一直觉得自己是对的，遇到别人振振有词“我们就这么叫”。

我再重复一遍：Goroutine 不是协程。

这句不是写给你看的，因为你老了，改不了了。但总有年轻的有心的。他们会知道你是错的。

@CloveAndCurrant 你是不是不认识英文 cooperative ？协程的“协”对你也有点理解困难？你一张嘴说“工程领域就叫有栈协程”，你在工程领域算老几？我还有 WIKI ，你除了你认为你还有毛能拿出来的？

@yuan1028 朋友，你这才是明灯，这才叫“技术干货”。

@CloveAndCurrant

goroutine 不是协程不是我定义的，我前面有 wiki 链接。

coroutine 的 co 是 cooperative ，goroutine 是 preemptive 。

哪怕加上“有栈”的定语，它也不是协程。典型的有栈协程应该是 lua 的 coroutine 。

@CloveAndCurrant 实际生产环境的性能表现当然会有各种干扰，没有任何单一指标能决定一切，但不意味着我们不去对单一指标进行量化。Benckmark 的作用之一就是去除变量。

go 和 java 的优劣固然不能一概而论。但“Java 的 virtual thread 比 go 的 goroutine 成本还要低”这点，我认为是结论。

@CloveAndCurrant 有栈没错，但 goroutine 不是协程啊……