碎片内存是什么样的？

Question

我有一个移动应用程序，该应用程序随着时间的推移会变慢。 我的直觉（部分由本文提供 ）是由于内存碎片使应用程序变慢，但我不确定。 这是一段时间内应用程序的内存使用情况的漂亮图表：

脆弱的岩石http://kupio.com/image-dump/fragmented.png

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

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

我想知道的是，内存碎片是一个可行的解释，还是我应该首先考虑一下其他方面？ 图上的低点相对较低，因此我的假设是，在这种状态下内存不会非常分散，因为不会有很多小的内存孔引起问题。

我不知道j2me内存分配器的工作原理，所以我真的不知道。 有人可以建议吗？ 还有其他人对此有疑问并可以识别应用程序的内存配置文件吗？

Answer 1

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

如果进行完此调查后仍然发现性能下降，则不是内存碎片引起问题。 让我们都知道您的结果，我们可以帮助您进行进一步的故障排除。

Answer 2

内存碎片会造成这种情况...目前尚不清楚Apps是否使用内存导致分页？ 这也会使事情变慢....并可能导致相同的问题。

Answer 3

问题确实是内存碎片，您无能为力。

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

Answer 4

考虑查看垃圾收集统计信息。 如果您的理论要坚持下去，那么您在最后一次运行中应该比第一次运行更多。 另一个想法可能是其他东西占用了您的内存，因此您的应用程序更少了。

换句话说，探查器时间:)

Answer 5

您在什么操作系统上运行它？ 我对Windows CE5（或Windows Mobile）设备有一定的经验。 CE5的操作系统级内存体系结构已被破坏，并且对于内存密集型应用程序将很快失效。 您的图形没有任何比例，但是每个进程在CE5上仅获得32MB的地址空间。 VM和共享库也将尽其所能，从而使您所剩无几。 解决此问题的唯一方法是重新使用分配的内存，而不是将其返回给收集器并在以后重新分配。 当然，这比您通常希望在Java中进行的底层编程要多得多，但是在此平台上，您可能会不走运。