碎片化的内存是什么样的？

Question

我的移动应用程序随着时间的推移而逐渐减速。我的预感，（部分由this article喂养），这是由于内存碎片减慢了应用程序，但我不确定。以下是应用程序内存使用情况的漂亮图表：

fraggle rock http://kupio.com/image-dump/fragmented.png

图表上的4个峰值是应用程序上完全相同任务的4次执行。我开始任务，它分配了一堆内存，它坐了一会儿（顶部的扁平线），然后我停止任务。此时它调用System.gc（）;并且内存得到清理。

可以看出，完全相同任务的4次运行中的每次运行都需要更长的时间来执行。图中的低点都返回到相同的级别，因此任务运行之间似乎没有任何内存泄漏。

我想知道的是，内存碎片是一个可行的解释还是我应该首先看看别处，记住我已经做了很多看？图中的低点相对较低，所以我的假设是在这种状态下内存不会非常分散，因为不会有很多小的内存空洞导致问题。

我不知道j2me内存分配器是如何工作的，所以我真的不知道。任何人都可以建议吗？有没有其他人遇到此问题并识别应用程序的内存配置文件？

Answer 1

如果您有一点时间，可以通过使用内存池技术重新使用内存来测试您的理论：每次运行任务都会使用“相同”的内存块从池中获取内存并在发布时返回。

如果您在进行此调查后仍然看到性能下降，则不是内存碎片导致问题。让我们都知道您的结果，我们可以帮助您进一步排查问题。

Answer 2

内存碎片会解释它......目前还不清楚应用程序是否使用内存导致分页？这也会减慢事情......并可能导致同样的问题。

Answer 3

问题实际上是内存碎片，你无能为力。

但是在绝望中放弃之前，请尝试使用执行探查器运行您的应用程序，看看它是否花费了大量时间在意外的地方执行。减速可能实际上是由于算法中的问题，而与内存碎片无关。正如人们已经说过的，J2ME垃圾收集器不应该受到碎片问题的困扰。

Answer 4

考虑查看垃圾收集统计信息。如果您的理论要坚持，那么在最后一次运行中你应该拥有比第一次运行更多的东西。另一个想法可能是其他东西会占用你的记忆，所以你的应用程序就少了。

换句话说，探查器时间：）

Answer 5

你在运行什么操作系统？我对Windows CE5（或Windows Mobile）设备有一些经验。 CE5的操作系统级内存架构非常破碎，对于内存密集型应用程序很快就会失败。您的图表没有任何比例，但每个进程在CE5上只获得32MB的地址空间。 VM和共享库也将公平地分享它们，让您只剩下很少的东西。 解决此问题的唯一方法是重新使用您分配的内存，而不是将其返回给收集器并稍后重新分配。当然，这比你通常想要在Java中做的更低级别的编程，但在这个平台上你可能会运气不好。