在eden和survior不变的情况下,JVM的旧版本不断增加

我有一个Java spring boot应用程序,该应用程序运行时间很长,并且整个响应时间也

我的服务器是IO密集型的,我们没有在内存中存储任何内容,而是存储大量并发IO(30k rpm),每个IO响应均携带3-4MB的数据。从日志中,我观察到次要GC在一秒钟内运行了近3-4次,次要GC经常由于伊甸园和幸存者空间较小(Eden空间为600MB,幸存者空间为75MB)而频繁触发。由于GC非常频繁,因此这些对象可能幸存了阈值的次要GC(15),并被提升为老一代。所以我通过制作-XX:NewRatio=1来增加年轻一代的空间。

问题仍然存在,我可以在一秒钟内看到3-4次分配失败日志(如下所示)

[GC (Allocation Failure) 56455.997: [ParNew: 10705358K->222390K(11796480K),0.0467254 secs] 13148872K->2667031K(24903680K),0.0468292 secs] [Times: user=0.34 sys=0.00,real=0.05 secs]

使用新的遗物我监视了内存,年轻的一代保持不变,而老一代则保持增长,下面是快照。

在eden和survior不变的情况下,JVM的旧版本不断增加

对于我的应用程序来说,一个很好的堆分配策略是,我认为这将是年轻一代连续被填充和清空的地方,而老一代则几乎没有被使用,因为我们几乎没有长寿的对象。请建议如何实现上述目标,或者您可能会想到的其他更好的策略

xiangjiale 回答:在eden和survior不变的情况下,JVM的旧版本不断增加

以下是建议:

  1. 大型对象,例如数组等被创造了旧的一代空间。因此,请检查您要创建的大型对象以及它们可以停留多长时间。

  2. 当满足对象的使用期限阈值时,会将对象移动到旧的GC。因此,您可以朝这个方向看。

  3. 检查次要GC和主要GC的执行方式,就像它们正在快速填充或达到将对象移至旧一代时的阈值一样。

  4. 查看伊甸园和幸存者的大小,如果它们太小,可能会触发主要的gc并导致物体移动到旧世代。

本文链接:https://www.f2er.com/3167262.html

大家都在问