2011-11-18 58 views
9

我有个奇怪的疑惑。我知道垃圾收集器有其自身的局限性。如果分配是 不好,那么它可能会导致应用程序以不寻常的方式响应的问题。Android中的垃圾回收(手动完成)

所以我的问题是,在每个活动结束时强制调用垃圾回收器(System.gc())是否是好的编程习惯?

更新

每一个是说,调用System.gc()在all.Then不利于我很奇怪,为什么目前的here.DVM将决定何时运行垃圾collector.Then什么是必要的那种方法?

更新2

感谢社区帮助我。但老实说,我从这个链接了解垃圾收集真正的波伏娃Java Performance Optimization

+0

我不这么认为,如果你的应用程序缺乏性能,它应该是别的东西,除非你分配了大量的数据。是这样吗? – lc2817

+1

需要system.gc()方法http://stackoverflow.com/questions/3117429/garbage-collector-in-android –

+0

@ Ic2817仔细阅读这个问题。我没有说我的应用程序是以这种方式运行的。我正在讨论system.gc() – Sameer

回答

9

不是良好的编程习惯在每次活动结束时强行调用垃圾收集函数(System.gc())

因为它是无用的,所以只有DVM决定它应该在什么时候打电话,但你称它为...

+0

谢谢大家快速回复。如果我在每个活动之后调用它,那么它将如何工作。 – Sameer

+0

这将帮助你http://chaoticjava.com/posts/how-does-garbage-collection-work/ –

+0

是thanx ..但它会谁,谁想读取垃圾收集java.But我想知道为什么system.gc()存在于这里,如果一切都由DVM – Sameer

1

不;如果系统需要内存,它将自行调用GC。

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

实例自身使用的内存(如果不再引用)也符合GC的条件。你可以做一个代码审查或分析,看看你是否坚持内存不必要,但这是一个不同的问题。

+0

的存在,那么为什么要使用system.gc()? – Sameer

+0

@Sameer问原始的Java工程师。我假设你可以向系统提供提示 - 但它的行为取决于实现。你知道你在一年前问过这个问题吗? –

+0

是的,我在一年前问过这个问题。但是我仍然不确定使用System.gc()。所以我假设它提示JVM运行垃圾回收器(正如你刚才所说),但不能强制JVM – Sameer

2

致电System.gc(),没有任何伤害。但你不能确定它会有用处。因为你要求该DVM做垃圾回收,但不能命令它......它完全依赖于DVM。当内存被耗尽或者可以在任何时候,它调用..

1

Patrick Dubroy在Google IO 2011上展示了一个关于内存管理的会话。自从他讨论了堆分配和GC的工作以来,值得关注。你可以在这里看它Memory Management

1

我试图把System.gc()放在我在我的Android应用程序中创建位图之前的行上。垃圾收集器在某些情况下释放了几兆字节,并放置并结束了我的OutOfMemoryError条件。它不会干扰正常的垃圾收集,但它确实使我的应用程序运行得更快。

+0

好吧..我有一些关于system.gc()的存在的想法,但让它为将来的最佳答案打开。然后我会接受其中的一个作为答案,但为你的努力付出高昂的代价 – Sameer

4

System.gc()的,其虚拟机有时会忽略瞎指挥,是在两种情况下最有用:

  1. 你吞噬了记忆像没有明天(通常与位图)。
  2. 您怀疑存在内存泄漏(例如意外持有旧的Context),并且希望将虚拟机内存置于静止状态以查看内存使用量是否正在逐渐增加以进行调试。

在名义上的情况下,不应该使用它。

2

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

因为堆是世代的,所以GC在其第一遍时可能不会摆脱某些大对象或位图,并且其启发式可能不会指示额外的垃圾回收是必要的,但确实存在启发式可能的场景错误的,我们作为开发人员了解模式,或者可以预测GC不能使用的用法,因此调用system.gc()会使我们受益。

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

我唯一的解释,为什么在某些情况下发生这种情况似乎是时机。如果用户操作速度很慢,那么本机Android GC似乎很棒。但是,如果您的用户快速滚动,或者快速缩放,这就是我看到Android GC滞后的原因,并且一些深思熟虑的System.gc()导致我的应用程序不会崩溃。

0

调用GC手动一个坏习惯编码...

Developer docs on RAM usage状态:

...
GC_EXPLICIT

一个明确的GC,这样当你调用如gc()(其中您应该避免致电而是相信GC在需要时运行)。

...

我在这里大胆强调了最重要,最相关的部分。