我正在尝试打击内存泄漏，导致堆耗尽内存并调用GC。很多。
Logcat充满了这样的消息：
11-27 20：54：39.052：DEBUG / dalvikvm（32167）：GC_CONCURRENT释放405K， 5％免费11046K / 11591K，暂停2ms + 3ms
我使用了DDMS Allocation跟踪器来查看是否有任何特别的东西比平常分配更多，而且当我点击Eclipse中的“Get Allocations”按钮时，该列表中填充了 java.util。 AbstractList的$ SimpleListIterator 的 它们在主游戏循环中被分配，所以有很多，我相信这就是吃堆内存。（有大约509个SimpleListIterator的分配）
然而， DDMS告诉我他们被分配到每个循环的地方，我认为这很奇怪。 O_O
通常我会使用常规for循环，但是this article建议使用for-each循环，因为它更快，但它没有提到它的内存使用情况
所有这些分配都可能是使用for-each循环而不是常规for循环的结果吗？ （这需要一段时间才能进入并改变我的应用程序中的每个循环，所以我宁愿先问一下） 如果是，那么这是正常的吗？这是我编程错误吗？
更新 我将for-each循环更改为常规循环，完全解决了问题。尽管我必须这样做，但我仍然觉得它很愚蠢
答案 0 :(得分：0)
大胖免责声明：这不是一个真正的答案（也许）。除了我读过的内容，我不知道这个话题。我宁愿将此作为评论发布，但是大小限制和格式化功能使得答案成为更好，更有建设性的选择。我不明白这个问题足够回答，我只是在帮助研究。
使用ArrayList，手写计数循环的速度快3倍（有或没有JIT），但对于其他集合，增强的for循环语法将完全等效于显式迭代器的使用。 / p>
Here，用户对for-each循环进行基准测试：
n.b。我注意到使用String s：stringsList比使用旧式for循环访问列表慢约50％。去图......这是我定时的两个功能;数组和列表中填充了5000个随机（不同）字符串。
下面，另一位用户警告基准测试。就个人而言，我怀疑使用for循环会在代码中产生这样的问题，因为我一直对Java中的微基准测试持谨慎态度。对于我所看到的，这一切都归结为Iterator对象运行的微秒。我相信你做错了，因为你删除了增强的for并且表现更好并不意味着增强本身的速度很慢或很差。
TL; DR ：增强型循环确实比传统的基于索引的循环更慢;但对于大多数应用来说，差异应该可以忽略不计。
See a doc关于增强的for循环。您不应该在循环中随意更改列表。如果那与你的问题有关，我不知道。也许我可能会看到代码和日志行。
所以，我猜你在代码上做错了。 :-)但是等到有经验的人来到这里会更好。