关于 Java 和 go 高并发的话题

[MakHoCheung]

go 因为有协程，所以高并发是它的一大优势，但是我看博客，别人说 groutine 的底层也是线程池，这样跟 Java 也一样，为什么 go 在高并发这块就很厉害呢（我不知道 Java 在高并发这块是不是比 go 弱，我没做过什么高并发项目）。发散一下就是 Java 的 NIO +线程池（现实例子就是 netty ）跟 go 在高并发这块差距是不是巨大？

[x940727]

@lesismal #56 我不知道你这个里面说的是什么玩意，Netty 就是同步非阻塞 IO 模型，你的意思是 netty 的性能很差？麻烦你搞明白 AIO 和 NIO 的区别。

[lesismal]

@x940727

"不了解就是 Go 的 GC 整体比 Java 强"
—— 我不了解 java，但是了解 go，从 java 的 jvm gc 表现看，go 确实强。比如 stw，比如高阶需要手动去调 java gc 策略然而即使调还是 stw 时间比较长，比如 java 吃内存，号称宇宙第一 gc 算法，然而同时也是宇宙第一吃内存怪兽。go 的 gc 自 1.8 以后已经非常强，而且除非代码本身 cpu 打满之类的否则基本不会有所有线程 stw 的情况，并且单个线程 gc 时长也比 java 小，如果这都不算强，那 java 这种号称 gc 算法最强但实际效果拉垮的 gc 赢了我 go 辩不过

"你知道 ElasticSearch 就是 Java 写的吗？"
—— 我上面已经说过了，这是历史原因，go 出生的晚，如果 go 早生，java 就不会如今这么繁荣了。但是话说回来，go 也是站在以前很多语言肩膀商取其精华去其糟粕，比如像 java 的臃肿、嘴炮 gc，go 就当成糟粕而没有采用，而是在 c lisp 之类的简洁基础上更加简洁、借鉴 erlang 之类的并发模型但又不限于 actor 所以让编程姿势更加通用，编译上除了动态链接库那是没办法、静态链接库直接打包到二进制内方便部署。优点很多，不一个一个说了。
ES 是 java 社区较早的积累，而且这种重量的基础设施不只是简单的语言实现、还涉及到整个社区的培养，所以不可能像 F 那样相对轻量的项目可以迅速替换掉 L 那种。
用这个举例，跟你之前用头条招聘举例子是一样的，没有辩论的逻辑性。比如我之前说用 F 替换 L，是能证明 java 有的项目不行所以用 go 取代。但你举出 ES 的例子却不能说明是 go 没能力去取代，而是 go 没有适合的时机去替代，尤其是 ES 这种社区、商业都发展的比较成熟的项目。
单就网络库、框架，我上面问你的那些，我都搞过多年了，java 虽然不熟悉，但是也手撸过 java 的网络库，c/c++/go 的都撸过，进程池、线程池各种框架层的东西、性能优化都是我日常工作内容

[x940727]

@lesismal #54 Go1.6 中的 gc pause 已经完全超越 JVM 了吗? - RednaxelaFX 的回答 - 知乎
https://www.zhihu.com/question/42353634/answer/94460053 这是 R 大的回答，这个人应该算是虚拟机界中最顶流的人了，你自己看看人家咋说的。你如果只是拿内存和 CPU 占用率来谈论，那咱们确实是没啥好说的，占用低就是好？是个正常写代码的人就不会这么认为吧？ Java 不是没有低暂停的 GC 实现，也不是没有超大吞吐的 GC 实现，但是这两者很难兼得。Go 只是取了一个比较均衡的点而已，你说吊打 Java，那真的是没啥好谈的。Go 宇宙第一……

[wanguorui123]

Go 是语法层面默认支持异步调用，Java 需要第三方库实现，方便程度和可读性不如 Go，其实都可以做一样的事情。

[x940727]

@lesisma 算了，没啥好谈的，Go 的 GC 吊打 Java 的 JVM GC，JVM 的 GC 团队都是嘴炮侠……从你的回答我就明白你为什么会喜欢 Go，看不上别的语言了，万物都手搓，难怪和个狂信徒一样。麻烦多看看世界，不是只有 Go 在进步。

[x940727]

@lesismal #62 还有如果你真的懂 GC 的话，你就知道 Go 的 GC 压根没想和 JVM 去竞争，都不是一个方向的实现，难道 Java 就没有 low pause gc?

[lesismal]

@x940727 我铜币不够了，你先看下你引用帖子日期吧，其他的我明天说

[x940727]

@lesismal 不想和你争论了，Go 无敌，JVM 垃圾！

[lesismal]

@x940727 go 不无敌，但 jvm 确实垃圾。

[ahmcsxcc]

@x940727 #63
这个是 go 1.6 的回答，现在 go 已经到 1.17 了。这期间 go gc 的优化挺大的。

[x940727]

@lesismal 不想和你争论了，Go 无敌，JVM 垃圾！
@ahmcsxcc Java 也到了 16 马上就 17 了，也引入了 ZGC，Shenandoah 这些更加现代的 GC，为什么非要盯着十几年前的 CMS 和七八年前的 G1 呢？我都说了，这个世界又不是只有 Go 在进步。

[hpeng]

go 用起来简单，但是真要大规模用，不太好用。

[beidounanxizi]

go runtime gmp 用户态的 goroutine

[iyaozhen]

@x940727 为什么头条现在也在大规模的招聘 Java 的程序员？你听谁说的
内部没看见这个风向，而且内部那一堆库很多压根都没 java 版本。当然我可能盲人摸象，但没看出要用 java 的理由。注：这里并不是 java 不好，只是字节在特定历史时期选择了 go

[iyaozhen]

恰好 java 和 go 的团队都待过

除去特殊的高并发场景（比如 IM ），两者工程上写起来差不多。个人看到的差异：
1. 因为 go 新一点，所以很多理念新一点，比如全面面向云原生。我们之前 java 还在 spring mvc+jdk1.6 折腾（不是说 java 不行，是因为有历史包袱）
2. java 启动确实比 go 慢，实际看到的项目 go 10s 左右，java 2-3 分钟。java 就打出的 jar 包有 1G 多（不含静态资源）
3. java 确实占内存一点
4. go 项目大了也确实很“百花齐放”，到处都是 interface{}，缺少 spring 这样大统一的框架，有时候还要解决框架问题，只能找内部资料

[iseki]

Java 传统的那一套 J2EE 体系里的东西（包括 JDBC 和 serverlet 等等）都是基于会占用线程的阻塞 io 的，高并发下不可避免占用大量线程资源，而线程又比较贵所以就······
如果你不使用这套传统生态的话， 新的库基本上都是基于非阻塞 io 的，如果你可以切换到 Kotlin，使用 Kotlin Coroutine 等方案也能享受到协程。
Go 原生就有协程，没历史包袱，生态的东西自然对协程都是一级支持。

至少在 Web 开发上个人比起 Go 更倾向选择 Kotlin，在语言特性上，Go 还是太缺乏了，就算说是“大道至简”，这也太简陋了。而使用 Kotlin，有并发需求的场景，完全可以选择规避 Java 传统的那一套生态。当然这个问题见仁见智了。

[x940727]

@iyaozhen 你可以自己去头条的招聘网站看到底招不招 Java，还有我认识就有在头条写 Java 的，2B 业务……哪个业务线没问太具体，而且 thrift 又没限制语言，Java 人更多，大规模数据，流量下都有更成熟的解决方案，为啥不选 Java ？

[x940727]

@iyaozhen 难道 Java 做不了抖音的后台？就像上面那个狂信徒一样，他带队从头做电商会选 Java 做？肯定还是用 Go 去做，说白了，用什么技术，什么语言并不是一定非要用这个，可能就是因为带头大哥熟悉这个，或者 KPI 任务(重构)而已……

[BBCCBB]

@lesismal 事情不是非 1 即 0, 非黑即白, 不要太偏执,

java 里 gc 可选择的很多, 低暂停的 gc 做的比 go 的 gc 好的也有很多. zgc, Shenandoah, 商业的 zing 等.

java 内存这块其实和 go 相差无几, 只是现在开发比如套上一层 spring. 框架占的内存是大头, 但是这类框架抽象成都高, 很好用, 能简化开发.. 所以大家依然愿意用. java 和 go 裸写内存占用区别真的不大..

[BBCCBB]

@lesismal 虽然 go 的 内置协程支持, native 编译这些的确是优点, 但缺点依然不少. 我工作用 java, 不过也是在不断的学 go..