java 7与java 6的年轻垃圾收集暂停时间更长
我注意到，与java 6相比，使用java 7的每个年轻垃圾收集平均需要10毫秒以上。我使用的是1.6.0_31和1.7.0_21。配置没有改变，硬件也没有改变，JVM参数是：
-server -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+TieredCompilation -XX:+AggressiveOpts -Xms1g -Xmx1g -XX:MaxNewSize=256m -XX:NewSize=256m
- Java 7：
S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT 26176.0 26176.0 3531.6 0.0 209792.0 21648.8 786432.0 86777.6 49472.0 49350.1 82 1.830 0 0.000 1.
- 爪哇6
S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT 26176.0 26176.0 0.0 1210.5 209792.0 95873.4 786432.0 65327.1 35968.0 35891.2 83 0.620 0 0.000 0.620
我还查看了每个单独的时间，对于java 6，每个YGC大约需要10ms，而java 7是20ms。第6版和第7版之间有什么变化可以解释这种行为吗？
编辑：我注意到java 7在64位模式下运行，而java 6使用32位JVM，这能解释差异吗？
谢谢
共有1个答案
Java 6的默认值为8，但Java 7的默认值为2。因此，在java 6中，年轻一代的规模小于java 7，因此我感觉到了差异。
因为收集城市垃圾的时间与城市的大小成正比。如果城市规模因此而增加。
-
如果我错了，请随时指正。在JVM堆中，有老一代和年轻一代两代。在做全GC时，在老一代中，有像紧凑空间和修复漏洞这样的繁重操作，这会使JVM挂起。而我发现在年轻一代中，应用了一个轻量级的GC，从我的搜索结果中还有一个叫做Eden的区域涉及年轻一代。但是，在搜索了很多文档后，我对年轻一代中的GC仍然有两个困惑， 在年轻一代中，GC似乎不像老一代GC那样工作（即老一代GC压缩并修复漏洞）？如果是这样，年
-
我在尝试理解垃圾收集机制，我在研究代际算法，我有一个关于年轻人和老年人的代沟的问题。我读到，在年轻一代开始收集物品，GC是从GC根开始标记它们，以找到活的，通常它会将它们复制到幸存者空间，清除年轻一代区域，然后瞧。 我不明白，如果我们从GC根开始，我们开始遍历活动对象，我们不是也在旧一代中找到了对象吗？这是否意味着，当我们击中旧空间中的一个物体时，我们会在那个点上停止跟踪参照物？
-
问题内容： 当伊甸园空间年轻时已满，将触发次要GC。在次要GC过程中，伊甸园和一个源Survivor空间中的非自由对象将被复制到另一个目标Survivor空间。 我的问题是，如果目标“幸存者”空间已满，次要GC如何处理？ 问题答案： 如果不可能执行/完成次要收集，则将执行主要/完整收集。通常使用标记扫描紧凑算法而不是复制算法来完成此操作……这是完整收集昂贵的原因之一。 但是最终（如果您继续填充堆）
-
当伊甸园空间充满年轻一代时，小GC将被触发。在次要GC过程中，伊甸园和一个源幸存者空间中的非自由对象将被复制到另一个目标幸存者空间。 我的问题是，如果目标幸存者空间已满，minor GC如何处理？
-
问题内容： 我遇到这样的情况，我的Android应用程序无法及时执行软实时任务，因为调用了Garbage Collector需要花费几毫秒的时间。分配给GC的时间只有几毫秒，不足以错过一些重要的期限，这些期限是从IO设备读取数据的小任务。 我当时正在考虑引入另一个线程，并赋予它轮询重要数据的任务。但是我不确定GC是否挂起所有线程还是仅挂起内存占用线程？ 问题答案： 在Patrick Dubroy撰
-
问题内容： 我有一段代码可以在内存中加载很大的图像。所以打电话似乎是合理的事情 在加载图像之前。据我所知，它毫无问题。 昨天，我决定使用一个名为FindBugs的非常有用的软件来扫描您的代码并报告可能导致错误或通常不建议使用的策略的问题。问题是我提到的这段代码得到了报告。描述是这样的： …强迫垃圾收集；除了基准测试代码外，都非常可疑 并继续阐述： 代码显式调用垃圾回收。除了基准测试中的特定用途外，