当我在模拟器上运行我的应用程序时，Logcat显示：
04-22 16:21:30.685: D/dalvikvm(967): GC_CONCURRENT freed 1545K, 20% free 7019K/8720K, paused 78ms+17ms, total 360ms
04-22 16:21:30.685: D/dalvikvm(967): WAIT_FOR_CONCURRENT_GC blocked 143ms
04-22 16:21:31.845: D/dalvikvm(967): GC_CONCURRENT freed 1552K, 20% free 7019K/8720K, paused 116ms+18ms, total 554ms
04-22 16:21:31.845: D/dalvikvm(967): WAIT_FOR_CONCURRENT_GC blocked 268ms
04-22 16:21:32.435: D/dalvikvm(967): GC_CONCURRENT freed 1545K, 20% free 7019K/8720K, paused 75ms+9ms, total 192ms
04-22 16:21:32.435: D/dalvikvm(967): WAIT_FOR_CONCURRENT_GC blocked 73ms
04-22 16:21:32.945: D/dalvikvm(967): GC_CONCURRENT freed 1552K, 20% free 7019K/8720K, paused 75ms+10ms, total 209ms
04-22 16:21:32.945: D/dalvikvm(967): WAIT_FOR_CONCURRENT_GC blocked 70ms
04-22 16:21:33.434: D/dalvikvm(967): GC_CONCURRENT freed 1545K, 20% free 7019K/8720K, paused 78ms+12ms, total 192ms
并且这一直持续到我退出应用程序。任何建议？谢谢
答案 0 :(得分：7)
好像你正在制作许多新物品并很快扔掉它们。
对于WAIT_FOR_CONCURRENT_GC，请参阅以下内容： what does WAIT_FOR_CONCURRENT_GC blocked mean?
这意味着您尝试分配内存（例如，对象创建），但它不适合内存。这就是GC_CONCURRENT释放的原因。它通常是垃圾收集。
如果遇到性能问题，请尝试重用对象或备用它们。
答案 1 :(得分：3)
这意味着您正在执行太多操作并且正在使用大量内存。因此，调用GC（垃圾收集器）来释放内存。
04-22 16：21：30.685：D / dalvikvm（967）：GC_CONCURRENT释放1545K，20％ 免费7019K / 8720K，暂停78ms + 17ms，总计360ms
freed表示释放了多少内存
GC_CONCURRENT当堆变得太大而无法防止溢出时调用。
暂停78ms + 17ms - 表示GC完成收集所花费的时间。
另外进行内存转储并分析转储使用MAT工具。
答案 2 :(得分：2)
主要同意@luxer，但我相信并不是你分配了太多的对象，而是分配了一些巨大的对象。如果您参考@luxer指向WAIT_FOR_CONCURRENT_GC的链接，您将意识到在您的应用程序中触发了第二个gc，而并发gc（通常在堆占用率达到软限制时触发）正在进行中。第二个gc可能是由您明确触发的，或者是因为分配失败。既然您没有表明您正在调用System.gc（），我会假设您的分配失败并且系统正在尝试执行gc。
所以，是的，你应该认真考虑重复使用一些巨大的物体，而不是每次都分配它们。这是一个更好的做法，但如果由于某种原因你无法做到这一点，你可能会碰到你的堆大小（通过设置大堆），这可能有所帮助。
答案 3 :(得分：2)
有时候，当你有一个永无止境的循环时，只是因为某些条件总是正确的。
试着弄清楚它是否首先出现这种情况，因为它主要是因为这个。
答案 4 :(得分：0)
我能够通过调试代码来解决我的问题：在无限的while循环中潜伏着一个DB操作，该操作正在填充bean，从而导致内存泄漏。
如果您是像我这样的新手，请检查while / do-while / for循环以及循环中完成的对象分配。 未关闭的连接和游标也应关闭。
谢谢