java - DDMS 分配跟踪器填充了 "SimpleListIterator"

Question

我正在尝试解决内存泄漏问题，该泄漏会导致堆内存不足并调用 GC。很多。

Logcat 充满了这样的消息:

11-27 20:54:39.052: DEBUG/dalvikvm(32167): GC_CONCURRENT freed 405K, 5% free 11046K/11591K, paused 2ms+3ms

我使用 DDMS 分配跟踪器来查看是否有任何特定的内容比平时分配得更多，当我单击 Eclipse 中的“获取分配”按钮时，列表中充满了 java.util。 AbstractList$SimpleListIterator它们在主游戏循环期间被分配，所以有很多，我相信这就是占用堆内存的原因。(SimpleListIterator 大约有 509 次分配)

但是，DDMS 告诉我，只要有 for-each 循环，它们就会被分配，我认为这很奇怪。 o_O

通常我会使用常规的 for 循环，但是 this article建议使用 for-each 循环，因为它更快，但它没有提及其内存使用情况

所有这些分配是否都是使用 for-each 循环而不是常规 for 循环的结果？ (进入并更改我的应用程序中的每个 for-each 循环需要一段时间，所以我宁愿先询问)如果是的话，这正常吗？是我的编程错误吗？

更新我将 for-each 循环更改为常规 for 循环，完全解决了问题。尽管我不得不这样做，但我仍然认为这很愚蠢

Answer 1

重要免责声明:这并不是真正的答案(也许)。除了我读过的内容之外，我对这个话题一无所知。我宁愿将其作为评论发布，但大小限制和格式功能使答案成为更好的、建设性的替代方案。我对这个问题的理解还不足以回答，我只是帮助研究。

关于Android dev guide :

With an ArrayList, a hand-written counted loop is about 3x faster (with or without JIT), but for other collections the enhanced for loop syntax will be exactly equivalent to explicit iterator usage.

Here ，用户对 for-each 循环进行了基准测试:

n.b. I did notice that using for String s: stringsList was about 50% slower than using an old-style for-loop to access the list. Go figure... Here's the two functions I timed; the array and list were filled with 5000 random (different) strings.

下面，另一位用户就基准测试发出了警告。就我个人而言，我怀疑使用 for 循环会给您的代码带来这样的问题，因为我一直对 Java 中的微基准测试持谨慎态度。就我所见，这一切都归结为迭代器对象运行的微秒。我相信您做错了什么，因为仅仅因为您删除了增强型并且它表现更好并不意味着增强型本身很慢或不好。

On another topic :

TL;DR: enhanced loops are indeed slower than a traditional index-based loop over an arraylist; but for most applications the difference should be negligible.

See a doc关于增强的 for 循环。您不应该在循环中随意更改列表。如果这与你的问题有关，我不知道。也许如果我看到代码和日志行。

所以，我猜你的代码做错了。 :-) 但最好等到有经验的人来这里。