Как выглядит фрагментированная память?

Question

У меня есть мобильное приложение, которое со временем начинает тормозить.Моя догадка (частично подпитываемая Эта статья,) заключается в том, что это связано с фрагментацией памяти, замедляющей работу приложения, но я не уверен.Вот красивый график использования памяти приложением с течением времени:

хрупкий камень 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 довольно сломана и скоро перестанет работать для приложений, интенсивно использующих память.В вашем графике нет масштабов, но каждый процесс получает только 32 МБ адресного пространства на CE5.Виртуальная машина и общие библиотеки также возьмут на себя свою долю, оставив вам совсем немного.Единственный способ обойти эту проблему — повторно использовать выделенную память вместо того, чтобы возвращать ее сборщику и перераспределять позже.Конечно, это гораздо более низкоуровневое программирование, чем обычно хотелось бы делать на Java, но на этой платформе вам может не повезти.