现状：
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参数的印象。
各位达者，若有什么建议请留言下方。