获取I/art:显式并发标记扫描GC已释放

24

我正在启动一个服务 => 后台服务,并在 "新线程" 中启动文件检查。在日志中我得到了以下信息,服务/应用程序被暂停。

日志 : I/art: 显式并发标记扫描GC释放25935(1686KB)AllocSpace对象,13个(903KB) LOS对象,39%空闲,13MB/22MB,暂停649us总计43.569ms

这只是在SD卡的"MyData"文件夹中扫描包含一堆图片(大约20张)的文件。

**扫描 = 获取图片名称并将它们保存到字符串中。

2个回答

37

这意味着垃圾收集器正在执行其任务并释放内存。

如果您经常(或一直)看到这个消息,请注意您很可能分配了太多对象。一个常见的原因是在循环中分配许多(或少量大型)对象,如下面的例子:

for (int i = 0; i < 100; i++) {
    Bitmap bmp = Bitmap.create(100, 100, Bitmap.Config.ARGB_4444);
}

每次我们进入这个循环,我们都会分配一百个新的Bitmap对象。

防止垃圾回收扫描的最好方法是不分配对象。当然,在Java中你必须分配对象,所以你需要确保你没有不必要地进行分配。

这里是谷歌发布的许多YouTube视频之一,其中提供了避免GC事件和正确管理内存的技巧。


1
我遇到了一个问题,一个之前连续运行了30次的应用程序突然出现了故障,而且代码没有任何改动。现在只能看到一个灰色的屏幕,而且这个问题一直持续着。Android Studio真是糟糕透顶。 - ObedMarsh
2
Android Studio是一个集成开发环境,与在您的设备上运行的代码无关。听起来你有一个无限循环正在运行。 - Bryan Herbst
当我创建一个新的模拟器并开始一段时间后,代码运行良好,目前代码中没有循环。这是一个基本的笔记应用程序,它使用sqllite,在数据库中有大约3个笔记。当我尝试迭代游标时,似乎会发生某些问题。 - ObedMarsh
1
你应该发布一个新问题,包含你认为会导致问题的代码。 - Bryan Herbst
如果我自己解决不了,我会的。但是我有点厌倦了安卓工作室在随机时间似乎毫无原因地引起各种奇怪问题。对于在这个帖子里发了这么多信息,我很抱歉。 - ObedMarsh
1
你解决问题了吗?我现在一直遇到这个问题。我的应用程序一开始运行得非常好,但后来就开始出现延迟。然后我回去检查我的代码,但这个问题后来就消失了。这让我很烦恼。它的加载时间会从2秒变成超过一分钟。而且这还只是加载20个对象的情况。 - Drew Szurko

0
正如Bryan Herbst所说:“如果你经常看到这个”,那就意味着你有问题了。问题可能来自于一个已过期的监听器,也就是内存泄漏。
现在...我不太确定如果某些东西被重复垃圾回收,它怎么会成为内存泄漏呢!?
所以我的推理是...(我不太确定) 实际上,订阅本身的连接点可能无法进行垃圾回收,但是在lambda/listener-output越过订阅连接点/屏障(消费者和生产者之间)后发生的任何事情都可能符合垃圾回收的条件,但由于订阅仍然连接着,输出会反复重新上下文化。
另一方面,由于图形工作的方式,可能是图形“引擎”背后的实际循环重复发送信息,因为没有对这些数据进行处理,所以在过期的订阅者接收流之后被垃圾回收。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接