垃圾收集器没有像 Android 应用程序中那样释放“垃圾内存”

Hello!

我是一名 Java 和 Android 开发新手，最近在处理应用程序的内存管理方面遇到了麻烦。我将把本文分成几个部分，以使其更清晰易读。

我的应用程序的简要说明

这是一个由多个阶段（级别）组成的游戏。每个阶段都有一个玩家的起点和一个出口，引导玩家进入下一个阶段。每个阶段都有自己的一组障碍。目前，当玩家到达最后阶段（到目前为止我只创建了 4 个阶段）时，他/她会自动返回到第一阶段（1 级）。

一个名为的抽象类游戏对象（延伸Android.View）定义了玩家以及游戏中存在的所有其他对象（障碍物等）的基本结构和行为。所有对象（本质上是视图）都在我创建的自定义视图中绘制（扩展了 FrameLayout）。游戏逻辑和游戏循环由副线程（gameThread）处理。这些阶段是通过从 xml 文件检索元数据来创建的。

问题

除了我的代码中所有可能的内存泄漏（所有这些我一直在努力寻找和解决）之外，还有一个与垃圾收集器相关的奇怪现象发生。我不会用文字来描述它，以免让你感到困惑，而是使用图像。正如孔子所说：“形象胜千言”。好吧，在这种情况下，我刚刚让您免于阅读 150,000 个单词，因为下面我的 GIF 有 150 帧。

描述：第一个图像代表首次加载“第一阶段”时我的应用程序的内存使用情况。第二张图片 (GIF) 首先代表第二次加载“第一阶段”时我的应用程序的内存使用时间线（如前所述，当玩家击败最后一个阶段时会发生这种情况），然后是四个垃圾收集是我强行发起的。

您可能已经注意到，两种情况之间的内存使用量存在巨大差异（几乎 50MB）。首次加载“Stage 1”时，游戏启动时，应用程序使用 85MB 内存。当第二次加载同一个stage时，稍晚一点，内存使用量已经是130MB了！这可能是由于我的编码不当造成的，因此我不在这里。您是否注意到，在我强制执行 2 次（实际上是 4 次，但只有前 2 次重要）垃圾回收后，内存使用量又回到了“正常状态”（与首次加载阶段时的内存使用量相同）？这就是我说的奇怪现象.

问题

If the 垃圾收集器应该从内存中删除不再被引用的对象（或者至少只有弱引用), 为什么你上面看到的“垃圾内存”只有当我强行调用时才会被删除GC并且不在GC's正常处决？我的意思是，如果垃圾收集我手动启动可以消除这个“thrash”，然后正常GC's处决也能够将其删除。为什么它没有发生？

我什至尝试过打电话系统.gc()当阶段被切换时，但是，即使垃圾收集发生这种情况时，这个“thrash”内存不会像我手动执行时那样被删除GC。我是否遗漏了一些关于如何垃圾收集器工作原理或者 Android 如何实现它？

最后的考虑因素

我花了几天时间搜索、研究和修改我的代码，但我无法找出为什么会发生这种情况。 StackOverflow 是我最后的手段。谢谢你！

NOTE:我本来打算发布我的应用程序源代码的一些可能相关的部分，但由于问题已经太长了，我将在此停止。如果您觉得需要检查一些代码，请告诉我，我将编辑这个问题。

我已经读过的内容：
Java中如何强制垃圾回收？ https://stackoverflow.com/questions/1481178/how-to-force-garbage-collection-in-java
Android 中的垃圾收集器 https://stackoverflow.com/questions/3117429/garbage-collector-in-android
Oracle 的 Java 垃圾收集基础知识 https://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html
Android 内存概述 https://developer.android.com/topic/performance/memory-overview
Android 中的内存泄漏模式 https://android.jlelse.eu/memory-leak-patterns-in-android-4741a7fcb570
避免 Android 中的内存泄漏 https://android-developers.googleblog.com/2009/01/avoiding-memory-leaks.html
管理应用程序的内存 https://developer.android.com/topic/performance/memory
关于 Android 应用程序内存泄漏您需要了解的内容 https://techbeacon.com/what-you-need-know-about-android-app-memory-leaks
使用 Memory Profiler 查看 Java 堆和内存分配 https://developer.android.com/studio/profile/memory-profiler
LeakCanary（适用于 Android 和 Java 的内存泄漏检测库） https://github.com/square/leakcanary
Android 内存泄漏和垃圾收集 https://stackoverflow.com/questions/31635184/android-memory-leak-and-garbage-collection
通用 Android 垃圾收集 https://stackoverflow.com/questions/11035593/generic-android-garbage-collection
如何从内存中清除动态创建的视图？ https://stackoverflow.com/questions/9949047/how-to-clear-dynamically-created-view-from-memory
引用在 Android 和 Java 中如何工作 https://medium.com/google-developer-experts/finally-understanding-how-references-work-in-android-and-java-26a0d9c92f83
Java 垃圾收集器 - 未定期正常运行 https://stackoverflow.com/questions/4309105/java-garbage-collector-not-running-normally-at-regular-intervals
android 中的垃圾收集（手动完成） https://stackoverflow.com/questions/8177802/garbage-collection-in-android-done-manually
...还有更多我找不到了。

垃圾收集很复杂，不同平台的实现也不同。确实不同versions同一平台的垃圾回收实现方式不同。 （和更多 ... ）

典型的现代收藏家基于以下观察：most物体在年轻时就会死亡；即它们在创建后很快就变得无法访问。然后堆被分成两个或多个“空间”；例如一个“年轻”的空间和一个“老”的空间。

• “年轻”空间是新物品被创造的地方，并且被频繁地收集。 “年轻”的空间往往较小，而“年轻”的收藏发生得很快。
• “旧”空间是长期存在的对象最终存放的地方，并且很少被收集。在“旧”空间收集往往更昂贵。 （由于各种原因。）
• 在“新”空间中存活下来的多个 GC 周期的对象将获得“终身”；即它们被移动到“旧”空间。
• 有时我们可能会发现需要同时收集新旧空间。这称为完整集合。完整的 GC 是最昂贵的，并且通常会“停止世界”相对较长的时间。

（还有各种各样其他聪明而复杂的事情......我不会详细讨论。）

您的问题是为什么空间使用量在您致电之前没有显着下降System.gc().

答案基本上是这样的高效的做事的方式。

收集的真正目标不是始终释放尽可能多的内存。相反，目标是确保在需要时有足够的可用内存，并以最小的 CPU 开销或最小的 GC 暂停来实现这一点。

因此，在正常操作中，GC 的行为将如上所示：进行频繁的“新”空间收集和不太频繁的“旧”空间收集。还有收藏品 将“按要求”运行。

但当你打电话时System.gc()JVM 将通常尝试恢复尽可能多的内存。这意味着它会执行“完整GC”。

现在我想你说过这需要几个System.gc()呼吁做出真正的改变，这可能与使用finalize方法或Reference物体或类似物体。事实证明，可终结的对象和Reference主 GC 完成后由后台线程进行处理。对象实际上仅处于可以收集和删除的状态after那。所以需要再次GC来最终摆脱它们。

最后，还有总堆大小的问题。当堆太小时，大多数虚拟机会向主机操作系统请求内存，但又不愿意归还内存。 Oracle 收集器会记录连续“完整”收集结束时的可用空间比率。仅当经过多次 GC 循环后可用空间比率“太高”时，它们才会减小堆的总体大小。 Oracle GC 采取这种方法有多种原因：

1. 当垃圾与非垃圾对象的比例较高时，典型的现代 GC 工作效率最高。因此保持堆很大有助于提高效率。

2. 应用程序的内存需求很可能会再次增长。但 GC 需要运行来检测这一点。

3. JVM 反复将内存返还给操作系统并重新请求它可能会破坏操作系统虚拟内存算法。

4. 如果操作系统内存资源不足就会出现问题；例如JVM：“我不需要这个内存。把它拿回来”，操作系统：“谢谢”，JVM：“哦......我再次需要它！”，操作系统：“不”，JVM：“OOME”。

假设 Android 收集器以同样的方式工作，这就是为什么你必须运行的另一种解释System.gc()多次以缩小堆大小。

在开始添加之前System.gc()调用您的代码，阅读为什么调用 System.gc() 是不好的做法？ https://stackoverflow.com/questions/2414105/why-is-it-bad-practice-to-call-system-gc.