还在纠结用 parallel 还是 cms 还是 G1，运维直接给个 64GB 内存的机器

低端开发者请教一下，平常开发中真的要研究这么深，考虑用什么垃圾收集器么

开发效率第一，性能优化其次

xmx xms pretouch random fileencode 完事
垃圾回收器？容我把屎山扶好再碰吧

你挠破头调个 JVM 配置优化内存使用浪费了一周时间。

如果你月薪 2W 的话，你这一周的工资 ECC 内存都能买上 320G 。你要是花了一个月，内存都能买上 T 。

而且最关键的是，真的有那么多用户要那么多并发吗。。。。

G1 first

个人浅见：
1 、如果是 JDK8 环境，通常来说 ParaNew+CMS 算是比较万金油的选择。之所以不用 G1 ，只是因为 G1 在 jdk8 下还存在一些隐患，极端情况 Full GC 退化成单线程。ES 的配置文档也是建议 JDK10 以下，不建议配置 G1
2 、如果是 JDK11+环境，通常来说就选择 G1 就 ok 啦。需要关注下 MaxGcPauseMillis 参数，不要设置的太小了，按照实际来。而且随着 JDK 版本的升级，jdk11-14-15-17 ，G1 的性能越来越好，可以说 jdk17 下的 G1 真的强无敌，吞吐量、延迟达到了非常棒的平衡。
3 、关于 ZGC 。我在 jdk17 的生产环境测试过 zgc ，在 16g 的堆下，基本 gc 停顿时间<1ms 。但是，通过火焰图观察，大概消耗了 10%的吞吐量。所以看你的需求，如果可以舍弃一些吞吐量，那 zgc 也不是不能用。虽然我认为绝大多数的应用 g1 就够用啦

i5 9500 + 8G 内存 java 开发 瑟瑟发抖

百分之 99 的项目都不用关注这些参数直接默认的就行，别浪费时间精力在这上了，别半桶水搞一些负优化。

64G 内存服务器是低配了，当然，在 V 站 8G 内存足够搞开发，16G 内存用来造火箭都用不完。

@yty2012g Generation ZGC 来了。吞吐问题也能好很多

-Xms4g -Xmx4g -XX:+UseG1GC
不够就 Xmx 继续增加，省事

@pH #10 哈哈哈，主要是 JDK17 下的 G1 真的太棒了，在同样的测试中，G1 对吞吐量的影响大概只有 0.5%。感觉分代的 ZGC 怎么着也得优化几个版本才赶得上了

空间换时间，时间换空间；
普通场景 -XX:+UseG1GC ；
延迟要求高场景-XX:+UseZGC

jvm 调参的前提是你有数据依据,自己压测观察下机器性能和 jvm 的指标,综合决定使用哪个垃圾回收策略以及内存配置,简单粗暴就单机多实例

@yty2012g 是，不过 ZGC 的 GC 时间实在是太无解了。等 Generational ZGC 迭代几代，Java 的 GC 问题差不多就要停止争论了

是不是想太多了，业务已经到了需要这么精打细算的地步了吗

难道解决方法不是升级程序去适应 JDK 么

@pH JDK 21 出了，特地回复一下。我测试了 jdk21 的分代 zgc ，确实牛逼，对于吞吐量的影响（ 1.2%）已经非常接近于 G1GC （ 0.7%），比 jdk17 的 zgc （ 9.8%），有质的飞跃。gc 问题差不多可以不用再多聊了