先拿 n+1 ，再去追缴，公积金追缴很简单，自己提交材料后，就不用管了。

小项目直接定义一个 model 从 db 到 view ，改一定就行了。

适合直播

失业半年了

@ChrisFreeMan 深有体会

666

带着问题看。

[Imgur]( https://imgur.com/3uNkFKy)

[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 对系统机器上的其他程序会不会有影响。