Old区内存满之后，无法回收，RednaxelaFX在吗

Posted 2023-04-22

参考技术A 从【HeapUsage】看，老年代（concurrentmark-sweepgeneration）的内存使用了99%以上，相较而言，新生代还有较多剩余；JVM参数配置中的这一条，-XX:MaxTenuringThreshold=0，使新生代Eden区域的Java对象不经过Survivor区域，而直接晋升到老年代。这增加了老年代的垃圾回收负担，而且老年代开启了碎片整理，更加耗时；请尝试将-XX:MaxTenuringThreshold参数调大一些，让对象晚一些进入老年代；另外，请试一下增大Java堆内存的分配量，看是否能解决问题。【以上只是个人猜测，不知能否帮上忙。从JVM的GC日志中，也许能进一步发现问题。】

JDK8 GC 分代垃圾回收之 内存分配

Eden ——> Survivor（From ——> To） ——> Old 

1、先在Eden区给新对象分配空间（大对象，很长的字符串、数组。直接分配在Old区），Eden区没有足够的空间分配时 ——> YGC；

GC开始时，Eden区对象全部进入To Surivor区，From Survivor中的对象年龄超过阈值（15，每次未回收标志加一）的对象进入Old区，

如果Survivor区中某一年龄的对象 >= Survivor区的一半，那么 >= 该年龄的对象直接进入Old区。

2、其他进入To Survivor区。然后，Eden 区， From Survivor区清空。From Survivor ， To Survivor角色互换；

3、如果To Survivor区没有足够空间容纳Eden，From Survivor中的对象，需要Old区分配担保，分配到Old区中。如果Old区分配空间不够，Out memory。

 

Old区分配担保：

Minor GC之前，检查Old 最大可用连续空间是否大于新生代所有对象总空间：

大于，Minor GC安全；

否则，虚拟机查看HandlePromotionFailure 设置值是否允许担保失败：

允许，继续检查Old区最大可用的连续空间是否大于历次晋升到Old区对象的平均大小：

　　大于，尝试 Minor GC，尽管存在风险。

　　小于，或者不允许担保失败，则进行 Full GC。

 

JDK8 元空间替换了永久区，字符串，方法可以直接分配在内存中，避免 插入 永久区大小，Perm out memory。