[img]https://i.imgur.com/dMXS3EQ.png[/img]

[img]https://i.imgur.com/3uNkFKy.png[/img]



前面老哥们都说得很好。

物理内存不变的情况下，把 java 内存减少到 1.5G-2G 范围内应该是可行的。元空间的话也设置最大最小一样的吧

当年轻代耗尽时候会进行 Young GC 。

CompressedClassSpaceSize: 1.00 GB 这个参数是当前默认设置吧？

从统计 E|cs: 122 + s|cs: 18 = 140 来说，当内存不足时，JVM 完全时可以进行 GC 的，但是你设置的 -Xmx2847m 欺骗了 JVM 。

之前为什么顺利进行了 GC ？因为之前 young 达到 142 个时，恰好还有物理内存，可以申请 survivor region 作为 evaluate region 。

GC Heap History (20 events):
Event: 497209.338 GC heap before
{Heap before GC invocations=64918 (full 2):
garbage-first heap total cK, used 2054473K [0x000000074e000000, 0x0000000800000000)
region size 1024K, 142 young (145408K), 23 survivors (23552K)
Metaspace used 80903K, capacity 82391K, committed 83740K, reserved 1124352K
class space used 7288K, capacity 7804K, committed 8316K, reserved 1048576K
}

Event: 497209.794 GC heap before
{Heap before GC invocations=64919 (full 2):
garbage-first heap total 2916352K, used 2089289K [0x000000074e000000, 0x0000000800000000)
region size 1024K, 142 young (145408K), 18 survivors (18432K)
Metaspace used 80903K, capacity 82391K, committed 83740K, reserved 1124352K
class space used 7288K, capacity 7804K, committed 8316K, reserved 1048576K
}

Event: 497210.355 GC heap before
{Heap before GC invocations=64920 (full 2):
garbage-first heap total 2916352K, used 2112841K [0x000000074e000000, 0x0000000800000000)
region size 1024K, 142 young (145408K), 18 survivors (18432K)
Metaspace used 80903K, capacity 82391K, committed 83740K, reserved 1124352K
class space used 7288K, capacity 7804K, committed 8316K, reserved 1048576K
}

从这些日志可以看出 young region 应该是 142 个，超过 142 就触发 GC 。
年轻大小如果没有设置是依据 GC 停顿时间（-XX:MaxGCPauseMillis=200 ）自动调整的。142 / 2848 = 4.985 % 约等于 5 %

-XX:G1NewSizePercent=5

-XX:G1MaxNewSizePercent=60

发生 OOM 的时间 young region 恰好是 141 个，说明是 《 JVM 认为还有空间剩余，不需要 GC ，直接申请新的 region 》，但是此时物理机器没有新的连续 1M 的内存就发生 OOM 了。


还有虽然参数设置的是-Xmx2847m ，但实际上 JVM 最大能够申请的是 2848 M 。

Heap:
garbage-first heap total 2916352K, used 1955145K [0x000000074e000000, 0x0000000800000000)
region size 1024K, 141 young (144384K), 18 survivors (18432K)
Metaspace used 80907K, capacity 82397K, committed 83740K, reserved 1124352K
class space used 7289K, capacity 7805K, committed 8316K, reserved 1048576K

从日志来看使用了 1,909M ，一共是 2,848M ，说明此时 JVM 进程已经占用了 1,909M 。剩下的 939 M 是需要向操作系统申请的。申请的时候出现了机器物理内存不足

然后从我统计的 Free region 来看恰好是 937 （与 939 有些许误差）。
此时 cs eden 区: 122 ，survivor cs: 18 ，JVM 完全可以进行垃圾收集。

可以认为是 JVM 给申请新的 eden region 出现了 OOM 。可能是：
1. JVM 想申请新的 region ，尝试 GC ，新的 region 作为 evacuate region 。
2. JVM 认为还有空间剩余，不需要 GC ，直接申请新的 region 。

PS：HS: 18 可以看到大对象有 18 个，并且 HC:19 个，说明大对象可能大对象超过 18 个（大多数可能大于 1M ），可以将 region 的大小设置为 4 M ， -XX:G1HeapRegionSize=4M 。

PS： 本人写了一些 G1 文章，欢迎 star https://yoa1226.github.io/

设置了参数 Xmx2048m Xms2048m ，我觉得基本没啥问题，因为从 region 的分布来看，还有 937 个是空闲。
还有是设置了 Xmx2048m Xms2048m 对系统机器上的其他程序会不会有影响。

我给出的方案是先设置。Xmx2048m Xms2048m 观察
1. 打印详细 GC 日志 -Xlog:gc*=info ，更为详细的是 debug 和 trace
2. -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/heapdump 分析内存镜像。
3. 观察物理机内存使用情况。

我猜你虽然设置了最大 Xmx2847m ，但是 JVM 启动的时候并没有申请那么多，当 运行一段时间后 JVM 再去申请内存，操作系统已经没有足够的内存了。

所以设置 Xmx2048m Xms2048m

通过查看不同 region 数量显示，如果是 2048M 还是有空余空间的。

Xmx2847m

total 2847

old: 1733
free: 937
HS: 18
HC:19
E|cs: 122
s|cs: 18

@superhot 你们业务量很大？最好 xmx 和 xms 设置为一样的 。一般的业务 1G 就好了。

Xmx2847m 为什么是 2847 啊，虽然 G1 会自动对齐。

主要是 spring boot ，还有就是 java object header 占用。
前者市面上应该有很多代替品
后者的话，JEP 450: Compact Object Headers (Experimental) 发布了会有重大改善

@azhong123 是的，会 C 和 java 肯定是能看懂的

@Geekerstar 哈哈哈，要是有空可以把经验分享给大家。G1 full gc 在 java 10 以后也有优化。G1 full gc 我应该会在后续的文章中写道。

@seedhk 感谢

@spkingr 感谢老哥提醒，你说的是 G1 对记忆集的优化是吧，现在改了，你再看看。
https://juejin.cn/post/7418363736412815370


破了两张是指，我看了下没注意到图片有问题。https://juejin.cn/post/7419978042247413797

JVM 深入还是得学会 C++吧？
只是看代码的还好，我会 c 和 java ，基本代码都能看，看不懂的就 gpt 。

这 G1 的源码搞懂了，对应实际应用是啥
1. 对面试有帮助吧，只是看《深入理解 Java 虚拟机》那本书的话，有些地方总是似懂非懂的。
2. 工作中，因为 G1 现在是默认收集器，应用范围广，java9 之后默认就是 G1 ，如果 GC 有问题的话，看了源码了解原理，查看日志和定位问题、GC 优化都比较容易。学习 G1 相比其他收集器性价比高一些吧
3. 看懂 G1 最新的优化成果，我对这个比较感兴趣。

自我感觉 Young GC 写得还比较深入，大家不要只看 G1 pin region 那篇😂