DDMS分配跟踪器填充“SimpleListIterator”

Question

我试图打击内存泄漏导致堆用尽内存和GC来调用。很多。

logcat的填充有消息是这样的：

11-27 20：54：39.052：DEBUG/dalvikvm（32167）：GC_CONCURRENT释放405K， 5％的游离11046K/11591K，暂停2MS + 3ms的

我用DDMS分配跟踪，看看是否有什么特别得到分配比平时多，那我点击“获取分配”在Eclipse中按钮的瞬间，该列表中弥漫着的java.util .AbstractList $ SimpleListIterator 他们在主循环期间得到分配，所以有很多，我相信这是吃堆内存的东西。 509分配的SimpleListIterator）

然而， DDMS告诉我，他们正在分配任何有for-each循环，我认为这是奇怪的。 O_O

通常我会用循环的常客，但this article建议使用for-each循环，而不是因为它的速度更快，但它提到关于其内存使用量没有

难道所有这些分配是使用的结果为每个循环，而不是常规的循环？ （需要一段时间才能进入并更改每个应用的每个循环，因此我宁愿先问） 如果是，那么这是正常的吗？这是我的编程错误？

UPDATE 我将for-each循环更改为regular循环，并彻底解决了这个问题。我仍然认为它的愚蠢，虽然我不得不这样做

Answer 1

大发免责声明：这不是一个真正的答案（也许）。除了我读过的东西之外，我不知道这个话题。我宁愿将此作为评论发布，但大小限制和格式化功能使答案成为更好，建设性的替代方案。我不明白这个问题足以回答，我只是在帮助研究。

在Android dev guide：

随着一个ArrayList，手写计数循环为约3倍更快（具有或不具有JIT），但对于其他集合增强循环句法将是完全等同到显式迭代器的使用。

Here，用户一基准for-each循环：

N.B.我注意到使用String s：stringsList比使用旧式for循环访问列表要慢50％左右。去图...这是我计时的两个功能;数组和列表中填充了5000个随机（不同）字符串。

下面，另一个用户警告基准。就我个人而言，我怀疑使用for循环会在代码中产生这样的问题，因为我一直对Java中的微基准测试持谨慎态度。对于我所看到的，这一切都归结为运行Iterator对象的微秒。我相信你做错了什么，只是因为你删除了增强功能，并且它的执行效果更好，并不意味着增强功能本身就很慢或很差。

On another topic：

TL; DR：增强的循环的确比超过一个ArrayList传统基于索引的循环速度较慢;但对于大多数应用来说，差异应该可以忽略不计。

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

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