碎片內存是什么樣的？

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中進行的底層編程要多得多，但是在此平台上，您可能會不走運。