我正在检测Dalvik VM并想知道是否有任何工具来分析dalvik中的垃圾收集。我知道分配跟踪器，但我正在寻找更精细的东西。
答案 0 :(得分：0)
获取所有GC操作的日志：
每次进行GC时，您都会在LogCat中找到一行。
08-08 16:42:21.998: D/dalvikvm(26942): GC_CONCURRENT freed 773K, 26% free 4739K/6368K, paused 4ms+3ms, total 92ms
08-08 16:42:21.998: D/dalvikvm(26942): WAIT_FOR_CONCURRENT_GC blocked 11ms
似乎我正在为我的设备上的所有应用程序获取这些内容。
这一行包含许多关于GC的有趣统计数据，例如释放的内存量，GC的使用时间，确切时间以及堆的大小（已使用/总计）。
由于所有这些日志行都有标记dalvikvm，因此您应该能够长时间收集和过滤它们并进行分析以了解GC行为。
分析GC的特定运行：
如果您想分析一个特定GC操作中发生的情况，那么该工作的最佳工具是Eclipse MAT。 Eclipse MAT可以解析堆转储。获取堆快照，等待GC（或使用DDMS自行触发），然后拍摄另一张快照。
Eclipse MAT可以显示两个快照之间的增量。请注意，您将看到新的分配和GC导致的解除分配。有关比较快照的更多信息是available here。
其他一些想法：
我不确定你能从分析GC过程中学到多少东西。 GC的内部工作原理是一个实现细节。它可以在OS版本/设备/配置之间更改，恕不另行通知。
我正在考虑改善您遇到的GC延迟的方法。在我看来，GC通常在内存条件较低时运行。这可能发生在新分配期间，因此GC可能在您的服务处于活动状态时运行。也许，如果您手动使用服务对GC不活动的时间，您将能够减少响应Web请求的关键路径中发生的GC数量。为了尝试这个，我会添加一个简单的后台计时器，并在我的服务变为活动时重置它（新请求）。当计时器滴答（一段时间不活动）时，我会手动运行System.gc()。