android中的垃圾收集（手动完成）

Question

我有一个奇怪的疑惑。我知道垃圾收集器有其自身的局限性。如果分配是 那么它可能会导致应用程序以异常方式响应的问题。

所以我的问题是，在每个活动结束时强行调用垃圾收集器（System.gc()）是不是很好的编程习惯？

更新

每个人都说调用system.gc（）根本没有用处。然后我想知道为什么它在这里.DVM将决定何时运行垃圾收集器。那么该方法需要什么？

更新2

感谢社区帮助我。但老实说，我从这个链接Java Performance Optimization

获得了关于垃圾收集真实波伏瓦的知识

Answer 1

不是在每个活动结束时强制调用垃圾收集器（System.gc（））的良好编程习惯

因为它没用，所以只有DVM决定它什么时候应该打电话，虽然你打电话给它......

Answer 2

虚拟机有时会忽略的System.gc（）在两种情况下大多有用：

1. 你正在吞噬记忆，就像没有明天一样（通常是位图）。
2. 您怀疑内存泄漏（例如意外地保留旧的Context），并且想要将VM内存置于静止状态以查看内存使用是否正在逐渐增加，以便进行调试。

在名义情况下，不应该使用它。

Answer 3

致电System.gc()，不会造成任何伤害。但你不能确定它会有用。因为你要求 DVM进行垃圾收集，但不能命令它...它完全依赖于DVM。它在内存耗尽时调用，或者可能在任何时候调用..

Answer 4

我真的认为这取决于你的情况。

因为堆是世代的，所以GC在第一次传递时可能无法摆脱某些大型对象或位图，并且其启发式可能并不表示需要额外的垃圾收集，但肯定会出现启发式错误的情况。 ，我们作为开发人员了解模式，或者可以预测GC不能使用的用法，因此调用system.gc（）将使我们受益。

我之前在特定场景中已经看到过这种情况，例如处理地图平铺或其他图形密集型行为，其中Android中的本机GC（即使在3.0以上的设备上）也没有做到正确，导致内存不足错误。但是，通过添加一些GC调用，可以防止内存不足错误，并且系统会继续处理，但速度较慢（由于垃圾回收）。在图形密集型操作中，这通常是应用程序崩溃所需的状态（稍微滞后），因为它无法将额外的资源加载到内存中。

我在某些情况下出现这种情况的唯一解释似乎是时机。如果用户操作很慢，那么原生Android GC似乎做得很好。但是，如果您的用户正在快速滚动或快速缩放，这就是我看到Android GC落后的地方，并且一些经过深思熟虑的System.gc（）导致我的应用程序没有崩溃。

Answer 5

没有;如果系统需要内存，它将自己调用GC。

当实例消失时，实例使用的任何内存（未在其他任何地方引用）都将符合GC的条件。

实例本身使用的内存（如果不再引用）也符合GC的条件。您可以进行代码审查或分析，看看您是否正在不必要地 ，但这是一个不同的问题。

Answer 6

Patrick Dubroy在Google IO 2011上展示了内存管理会议。值得一看，因为他已经讨论了堆分配和GC的工作。你可以在这里观看Memory Management

Answer 7

我尝试将System.gc（）放在我在Android应用中创建位图的行之前。垃圾收集器在某些情况下释放了几兆字节，并且结束了我的OutOfMemoryError条件。它没有干扰正常的垃圾收集，但它确实使我的应用程序运行得更快。