获取 I/art：显式并发标记清除 GC 已释放

Question

我正在启动一项服务 => 后台服务，并开始检查 "new Thread" 中的文件，在日志中我得到以下内容，service/app 被暂停。

日志：I/art: Explicit concurrent mark sweep GC freed 25935(1686KB) AllocSpace objects, 13(903KB) LOS objects, 39% free, 13MB/22MB, paused 649us total 43.569ms

只是对SDcard中MyData中的文件进行扫描，里面有一堆图片（约20张）。

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

Answer 1

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

如果您经常（或始终）看到这种情况，那么您可能分配了太多对象。一个常见的原因是在循环中分配许多（或一些大的）对象，如下所示：

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

每次执行此循环时，我们都会分配一百个新的位图对象。

防止 GC 扫描的最佳方法是不分配对象。当然你必须在Java中分配对象，所以你需要确保你没有分配不必要的。

Here is one of many YouTube videos Google 发布了有关避免 GC 事件和正确管理内存的提示。

Answer 2

正如 Bryan Herbst 所说：“如果您经常看到这种情况”，则表示您遇到了问题。该问题可能是由失效的侦听器引起的，也就是内存泄漏。

现在..我不太确定如果某些东西被重复垃圾收集怎么会是内存泄漏！？

所以我的推理是...（我不太确定）订阅本身的实际联合不能被垃圾收集，但是 lambda/listener-output 在它越过订阅边缘 joint/barrier 之后发生的任何事情（在消费者和生产者之间）实际上可能有资格进行垃圾收集，但是由于订阅仍处于连接状态，因此输出会反复重新上下文化。

另一方面，由于图形的工作方式，图形“引擎”背后的实际循环可能正在重复发送信息，并且由于没有对该数据进行任何处理，因此在失效后被垃圾收集订阅者接收流。

获取 I/art：显式并发标记清除 GC 已释放

Getting I/art: Explicit concurrent mark sweep GC freed

java

android

android-service