禁用AdaptiveSizePolicy时出现并行垃圾收集器问题
我对并行GC进行了一些尝试，基本上我试图将幸存者空间大小设置为以前运行时观察到的最大值，以避免幸存者空间溢出。在我的情况下，幸存者大小为96mx2应该没问题。为了避免jvm调整幸存者空间大小，我关闭了AdaptiveSizePolicy。
显然，我遗漏了一些东西，因为我在应用程序上负载很少的情况下不断地得到溢出，但仍然是一个奇怪的溢出，因为溢出时旧的生成空间似乎没有增加。
以下是Java 1.7.0_51 jvm上的jvm arg:
在这里，旧一代的堆占用率增加了19M，而不是96M（幸存者空间的大小）。其余的日志也是如此。
2014-02-10T10:05:17.796+0200:40075.866:[GCADAPTIVESIZEPolicy::compute_survivor_space_size_and_thresh:幸存：100623664提升：1384448溢出：false[psyounggen:1081330K->98265K(1081344K)]1899117K->917405K(3309568K),0.1350010秒][times:user=0.51 sys=0.01,real=0.13秒]
2014-02-10T10:07:56.135+0200:40234.204:[GCADAPTIVESIZEPolicy::compute_survivor_space_size_and_thresh:surved:100650360提升:19069104溢出:true[psyounggen:1081305K->98291K(1081344K)]1900445K->936053K(3309568K),0.1847340秒][times:user=0.64 sys=0.08，real=0.18秒]
2014-02-10T10:08:26.613+0200:40264.682:[GCADAPTIVESIZEPolicy::compute_survivor_space_size_and_thresh:surved:100658976 provended:12245304溢出:true[psyounggen:1081331K->98299K(1081344K)]1919093K->948020K(3309568K),0.1578130秒][times:user=0.57 sys=0.04，real=0.16秒]
所以问题是：我错过了什么？为什么这么多的物体似乎幸存了下来？打开AdaptiveSizePolicy后，在相同负载下的存活率确实很低。
共有1个答案
经过更多的实验，我想我找到了答案。
首先，并行GC只溢出到旧世代的幸存者空间之上，而不是整个幸存者空间，正如我在问题中错误地陈述的那样。
其次，当禁用AdaptiveSizePolicy时，tenuring阈值默认为2或更多，大于1的值（在几乎没有发生溢出的情况下，AdaptiveSizePolicy在99%的情况下计算的值）。因此，在每一个小集合上，GC都试图将第一个幸存者空间中的内容复制到第二个，但这里没有足够的空间（也有来自伊甸园的活对象需要容纳），所以它溢出到老一代。
2014-02-12T20:31:28.967+0200:74464.855:[GCADAPTIVESIZEPolicy::Compute_Survivor_Space_size_and_thresh:Survide:21423336 Provended:4189088 Overflow：false
AdaptiveSizeStart:74464.928 Collection:250
AVG_Survived_Padded_AVG:35720128.000000AVG_Promoted_Padded_AVG:21338244.000000AVG_Pretenured_Padded_AVG:0.000000Tenuring_Thresh:1 target_size:36175872ps.
有趣的是，1的老化与老一代的不断溢出相比，在应用程序性能上有很大的不同，主要是在较短的收集时间内，但也有较小的完整GC频率。
-
问题内容： 我们有一个PHP Webapp，它调用Java二进制文件以生成PDF报告（使用JasperReports）。Java二进制文件将PDF输出到标准输出，然后退出。然后，PHP将PDF发送到浏览器。这个Java命令持续大约3到6秒，我认为当它持续6秒时是因为GC启动。我想禁用GC，因为无论如何该命令退出时都会返回所有内存。 我想知道如何针对Java 1.4.2和Java 1.6.0禁用它，
-
Java 15 使 ZGC、Z 垃圾收集器成为标准功能。它是 Java 15 之前的一个实验性功能。它是低延迟、高度可扩展的垃圾收集器。 ZGC 是在 Java 11 中作为一项实验性功能引入的，因为开发人员社区认为它太大而无法提前发布。 即使在机器学习应用程序等海量数据应用程序的情况下，ZGC 也具有高性能和高效工作。它确保在处理数据时不会因垃圾收集而长时间停顿。它支持 Linux、Window
-
Java 15 使 ZGC、Z 垃圾收集器成为标准功能。它是 Java 15 之前的一个实验性功能。它是低延迟、高度可扩展的垃圾收集器。 ZGC 是在 Java 11 中作为一项实验性功能引入的，因为开发人员社区认为它太大而无法提前发布。从那时起，对这个垃圾收集做了很多改进，例如 - 并发类卸载 取消提交未使用的内存 支持班级数据共享 NUMA 多线程堆Pre-touch 最大堆大小限制从 4 T
-
问题内容： 我有一段代码可以在内存中加载很大的图像。所以打电话似乎是合理的事情 在加载图像之前。据我所知，它毫无问题。 昨天，我决定使用一个名为FindBugs的非常有用的软件来扫描您的代码并报告可能导致错误或通常不建议使用的策略的问题。问题是我提到的这段代码得到了报告。描述是这样的： …强迫垃圾收集；除了基准测试代码外，都非常可疑 并继续阐述： 代码显式调用垃圾回收。除了基准测试中的特定用途外，
-
Kubernetes 垃圾收集器的角色是删除指定的对象，这些对象曾经有但以后不再拥有 Owner 了。 注意：垃圾收集是 beta 特性，在 Kubernetes 1.4 及以上版本默认启用。 Owner 和 Dependent 一些 Kubernetes 对象是其它一些的 Owner。例如，一个 ReplicaSet 是一组 Pod 的 Owner。具有 Owner 的对象被称为是 Owner
-
问题内容： 是什么决定了垃圾收集器何时真正收集？它是在一定时间之后还是在一定数量的内存用完之后发生的吗？还是还有其他因素？ 问题答案： 它在确定是时候运行时运行。在世代垃圾收集器中，一种常见的策略是在第0代内存分配失败时运行收集器。也就是说，每次你分配一小块内存（大块通常直接放置在“旧”代中）时，系统都会检查gen-0堆中是否有足够的可用空间，如果没有，则运行GC释放空间以使分配成功。然后将旧数据