Android in-ART垃圾收集暂停时间表示主线程还是工作线程？
有人知道下面的GC日志“暂停1.439ms”是指CMS正在处理的后台线程上的暂停时间，还是主线程上的暂停时间？
I/art：背景粘性并发标记扫描GC释放266189（12MB）AllocSpace对象，0（0B）LOS对象，14%空闲，46MB/54MB，暂停1.439ms总计179.694m
提前多谢！！
共有1个答案
ART中有两种GC暂停：
1）在日志下面显式并发标记扫描GC表示前台调用。
I/art(801): Explicit concurrent mark sweep GC freed 65595(3MB) AllocSpace objects, 9(4MB) LOS objects, 810% free, 38MB/58MB, paused 1.195ms total 87.219ms
2）在日志下面背景部分并发标记扫描GC和背景粘并发标记扫描GC表示后台调用。
I/art(29197): Background partial concurrent mark sweep GC freed 74626(3MB) AllocSpace objects, 39(4MB) LOS objects, 1496% free, 25MB/32MB, paused 4.422ms total 1.371747s
I/art(29197): Background sticky concurrent mark sweep GC freed 70319(3MB) AllocSpace objects, 59(5MB) LOS objects, 825% free, 49MB/56MB, paused 6.139ms total 52.868ms
希望这能帮到你！
-
问题内容： 该问题已发布在某个网站上。我在这里找不到正确的答案，因此我将其再次发布在这里。 我的查询与停止线程无关。让我改一下我的问题。A行（请参见上面的代码）启动一个新线程；和B行使线程引用为空。因此，JVM现在具有一个线程对象（处于运行状态），该对象不存在引用（如B行中的t = null）。所以我的问题是，为什么这个线程（在主线程中不再有引用）一直保持运行状态，直到主线程运行。根据我的理解，线
-
问题内容： 我遇到这样的情况，我的Android应用程序无法及时执行软实时任务，因为调用了Garbage Collector需要花费几毫秒的时间。分配给GC的时间只有几毫秒，不足以错过一些重要的期限，这些期限是从IO设备读取数据的小任务。 我当时正在考虑引入另一个线程，并赋予它轮询重要数据的任务。但是我不确定GC是否挂起所有线程还是仅挂起内存占用线程？ 问题答案： 在Patrick Dubroy撰
-
我注意到，与java 6相比，使用java 7的每个年轻垃圾收集平均需要10毫秒以上。我使用的是1.6.0_31和1.7.0_21。配置没有改变，硬件也没有改变，JVM参数是： Java 7： 爪哇6 我还查看了每个单独的时间，对于java 6，每个YGC大约需要10ms，而java 7是20ms。第6版和第7版之间有什么变化可以解释这种行为吗？ 编辑：我注意到java 7在64位模式下运行，而j
-
问题内容： 有人可以解释一下G1垃圾收集器的工作原理吗？我还无法在任何地方找到任何全面，易于理解的描述。 谢谢 问题答案： 收集器将堆分成固定大小的区域，并跟踪这些区域中的实时数据。它将一组指针（“记住的集”）保留在区域内和区域外。当认为有必要使用GC时，它将首先收集实时数据较少的区域（因此，“垃圾优先”）。通常，这意味着一步就可以收集整个区域：如果进入一个区域的指针数量为零，则无需对该区域进行标
-
问题内容： 在此代码示例中，ExecutorService仅用于其中一个，并允许其超出范围。 一旦executorService超出范围，就应该对其进行收集和完成。ThreadPoolExecutor中的finalize（）方法调用shutdown（）。 调用shutdown（）后，池线程应终止，并且应允许JVM退出。但是，永远不会收集executorSerivce，因此JVM仍保持活动状态。甚至
-
问题内容： 我有一段代码可以在内存中加载很大的图像。所以打电话似乎是合理的事情 在加载图像之前。据我所知，它毫无问题。 昨天，我决定使用一个名为FindBugs的非常有用的软件来扫描您的代码并报告可能导致错误或通常不建议使用的策略的问题。问题是我提到的这段代码得到了报告。描述是这样的： …强迫垃圾收集；除了基准测试代码外，都非常可疑 并继续阐述： 代码显式调用垃圾回收。除了基准测试中的特定用途外，