现状：

k8s 的一个pod 有32G内存，每秒产生新对象的峰值在900Mb ---- 1900Mb(根据jstat计算Eden区获得) 。

修改之前的参数

就一个命令行参数是-Xmx31g;

我修改为：

-Xms:30g

-Xmx:30g

-Xmn:15g

-XX:SurvivorRatio=6

以上目的是为了减少年轻代GC频率（由6秒1次 增加到10+秒一次），让Queue队列中的大对象在to区停留的更长。同时，由于队列的大对象紧到不死，通常存活的对象空间就>to区(s0、s1)空间，被移到了老年代。 不过，结果还是失败了，如下两图：

理论上来说，图1中pod启动后就存在4次fgc，9万秒后进行正经的第一次fgc，居然没有作用，直接OOM。

再改为简单的：

-Xms:30g

-Xmx:30g

其默认O区20G，N区10G。继续观察，这一次fgc成功了，但O区有剩余空间后仍然显示因OOM重启服务。

我只好推测是：虚拟机的问题，parallel　ｇｃ 在回收时应该stw, 回收后有空间的，jvm那一瞬间却认为没有。

特喵的跟我理论知识冲突了/ 进入知识盲区了，说好的fgc 有效呢，最大=最小堆内存 有助于降低性能消耗……。

在官网VM Options 没有找到Old达到一定70%阈值使用率时，触发1次OOM的参数。 CMS回收器倒是有，可不适合我们高吞吐量的服务器需要。

于是我修改为：

-Xms:30g

-Xmx:15g

作用几乎没有，最多减少因初始512M堆内存 面对大量新对象重启后没几分钟直接OOM的次数。

一次失败的处理，只让我加深了各JVM参数的印象。

各位达者，若有什么建议请留言下方。