当eden和survior保持不变时，JVM的旧版本不断增加

Question

我有一个java spring启动应用程序，它应该是长时间运行的，并且整个过程中需要的响应时间也小于50ms。通常情况下，我们能够服务于此，但当旧的gen接近填满时，CMS开始发挥作用，我们的响应时间SLA被破坏。有没有什么策略我可以用来确保完整的GC永远不会生效。

我的服务器是IO密集型的，我们不在内存中存储任何东西，但大量的并发IO (30k rpm)，每个IO响应携带大约3-4MB的数据。从日志中我观察到，minor GC在一秒钟内几乎运行了3-4次，由于eden和survivor空间很小(Eden空间为600MB，survivor空间为75MB)，minor GC被频繁触发。由于非常频繁的GC，对象可能存活在阈值较小的GC(15)中，并被提升到旧的gen。所以我通过制作-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]

使用新的遗物I监控内存，年轻的一代是不变的，而旧的一代在不断增加，下面是快照。

​

​

我认为，我的应用程序的一个好的堆分发策略是，年轻的gen不断地填充和清空，而旧的gen几乎没有使用，因为我们几乎没有任何长寿的对象。请建议如何实现上述目标，或者您可能想到的任何更好的策略

Answer 1

以下是一些建议：

、

1. 、大对象，例如数组等，都是在旧的生成空间中创建的。因此，检查您正在创建的大型对象，以及当达到某个对象的期限阈值时，它们被staying.
2. Objects移动到旧GC的时间有多长。因此，您可以在此direction.
3. Check中查看次要和主要GC是如何执行的，就好像它们正在快速填充或达到对象移动到旧gen时的阈值一样。
4. 查看你的伊甸园和幸存者的大小，如果它们太小，可能会触发主要的gc并导致对象移动到旧的gen。