【问题标题】:Chrome dev tools first memory heap snapshot is mysteriously largeChrome 开发工具的第一个内存堆快照异常大
【发布时间】:2016-05-06 05:44:48
【问题描述】:

我正在使用 Chrome 开发人员工具中的“配置文件”选项卡来记录内存堆快照。我的应用程序有内存泄漏,所以我希望快照的大小会逐渐增加,他们确实会这样做。但由于我不明白的原因,first 快照总是人为地大......在第一个和第二个之间造成看似具有欺骗性的内存下降。所有后续快照都按预期逐渐增加。

我知道,由于缓存和其他设置,在页面加载开始时通常会使用额外的内存。但无论我何时拍摄第一张快照,都会发生同样的事情。页面加载后可能是 30 秒或 30 分钟。相同的模式。我唯一的猜测是配置文件工具本身正在以某种方式与内存进行交互,但这似乎有点牵强。

有什么想法吗?

【问题讨论】:

    标签: google-chrome memory memory-leaks google-chrome-devtools


    【解决方案1】:

    在拍摄内存快照之前,Chrome 会尝试收集垃圾。但它并没有彻底收集它,它只进行了预定义的传球次数(这个神奇的数字seems to be 7)。因此,在拍摄第一个快照时,可能仍有一些未收集的垃圾。

    在制作第一个快照之前,请尝试转到“时间轴”选项卡并手动强制垃圾收集。

    根据我的测试,这总是会减小第一个快照的大小。

    【讨论】:

    • 哇,我还没有找到手动 GC 按钮。它是否也进行任意 7 次传球?我应该打几次才能确定吗?
    • @emersonthis 在我看来,这个按钮也没有彻底清洁,所以你肯定可以按几次。
    • @emersonthis 您可以测试自己是否收集了所有垃圾,方法是在页面加载后立即开始时间线记录,然后点击“收集垃圾”按钮几次,停止记录并寻找“主要 GC”事件。最后一个应该说“0 B 已收集”,这意味着没有更多的垃圾要收集 - imgur.com/ScAJWHk
    猜你喜欢
    • 1970-01-01
    • 2017-01-15
    • 1970-01-01
    • 2017-06-18
    • 2023-03-08
    • 1970-01-01
    • 1970-01-01
    • 2015-11-25
    • 1970-01-01
    相关资源
    最近更新 更多