dalvik的垃圾收集工具
我正在检测 Dalvik VM，想知道是否有任何工具可以分析 dalvik 中的垃圾收集。我了解分配跟踪器，但我正在寻找更详细的东西。
I am instrumenting the Dalvik VM and would like to know if there are any tools to analyze garbage collection in dalvik. I know about allocation tracker but I'm looking for something more elaborate.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
获取一段时间内所有 GC 操作的日志：
每次发生 GC 时，您都会在 LogCat 中看到一行。
看来我正在为我的设备上的所有应用程序获取这些内容。
该行包含许多有关 GC 的有趣统计信息，例如释放的内存量、GC 花费的时间、确切发生的时间以及堆的大小（已使用/总计）。
由于所有这些日志行都带有标签
dalvikvm，因此您应该能够在很长一段时间内收集和过滤它们并进行分析以了解 GC 行为。分析 GC 的特定运行：
如果您想分析一个特定 GC 操作中发生的情况，那么最好的工具是 Eclipse MAT。 Eclipse MAT 可以解析堆转储。拍摄一个堆快照，等待 GC（或使用 DDMS 自行触发），然后拍摄另一个快照。
Eclipse MAT 可以显示两个快照之间的差异。请注意，您将看到新的分配和 GC 引起的释放。有关比较快照的更多信息可在此处< /a>.
一些其他想法：
我不确定您能从分析 GC 过程中学到多少东西。 GC 的内部工作原理是一个实现细节。它可能会在操作系统版本/设备/配置之间发生更改，恕不另行通知。
我正在尝试想办法改善您遇到的 GC 延迟。在我看来，GC 通常在内存条件较低时运行。这可能会在新分配期间发生，因此 GC 可能会在您的服务处于活动状态时运行。也许，如果您使用服务不活动的时间手动进行 GC，您将能够减少响应 Web 请求的关键路径中发生 GC 的次数。为了尝试这一点，我将添加一个简单的后台计时器，并在我的服务变为活动状态（新请求）时重置它。当计时器滴答作响（一段时间不活动）时，我会手动运行
System.gc()。Get a log of all GC operations over time:
Every time a GC takes place, you get a line in your LogCat.
It seems I'm getting those for all apps on my device.
This line includes lots of interesting stats about the GC like the amount of memory freed, how long the GC took, when exactly did it happen and the size of your heap (used/total).
Since all of those log lines have the tag
dalvikvm, you should be able to collect and filter them over a long period of time and analyze to learn about GC behavior.Analyzing a specific run of the GC:
If you want to analyze what happens in one specific GC operation, the best tool for the job is Eclipse MAT. Eclipse MAT can parse heap dumps. Take a heap snapshot, wait for the GC (or trigger it yourself using DDMS), and then take another snapshot.
Eclipse MAT can show you the delta between the two snapshots. Notice you'll see both new allocations and GC-caused deallocations. More info about comparing snapshots is available here.
Some other thoughts:
I'm not sure how much you would be able to learn from analyzing the GC process. The inner workings of the GC are an implementation detail. It can change without notice between OS versions / devices / configurations.
I'm trying to think of ways to improve the GC latency you're experiencing.. It seems to me the GC usually runs when memory conditions are low. This probably happens during new allocations, therefore the GC might be running while your service is active. Maybe, if you use the time your service is inactive to GC manually, you would be able to reduce the number of GC's happening in the critical path of responding to a web request. To try that, I would add a simple background timer, and reset it whenever my service becomes active (new request). When the timer ticks (inactivity for some period of time), I would run
System.gc()manually.