Моя программа никогда не освобождает память. Зачем?

Question

У меня есть программа MDI.При запуске требуется 2-3 МБ оперативной памяти.Затем в этой программе я создаю около 260 дочерних окон MDI (каждое имеет TStringGrid, растровое изображение и некоторые другие элементы управления) и отображаю некоторые данные.Приложению требуется около 500 МБ для загрузки всех этих окон.Если я закрываю каждый дочерний MDI вручную, приложение все равно использует 160 МБ ОЗУ.Почему не возвращается несколько МБ ОЗУ?Должен ли я беспокоиться об этом?160 МБ это много для системы, которая имеет только 1 ГБ или ОЗУ !!

Примечание. Я использую столбец РАБОЧИЙ НАБОР в диспетчере задач, чтобы просмотреть статистику ОЗУ.Может быть, мне нужен лучший инструмент для чтения использования оперативной памяти.(Частный рабочий набор чуть меньше, чем рабочий набор).

Это не утечка!
FastMM (установлен на агрессивный режим) указывает на отсутствие утечки памяти при закрытии программы,См. Мой пост «Ответ» для дополнительных доказательств того, что это не утечка.

Я выпускаю материал
Многие люди говорили мне, что закрытие дочернего окна только скрывает его.Я знаю это.Я использую «Action: = caFree», чтобы фактически выпустить формы.Каждая форма отвечает за освобождение имеющихся у нее элементов управления.

Ответ
Я обнаружил, что FastMM отвечает за это.См. Ответ, который я разместил ниже.

---

Delphi 7, Win 7 32 bit
Похожие сообщения:
Можно ли очистить память?
Когда вызывать SetProcessWorkingSetSize?(Убедить менеджера памяти освободить память)

Answer 1

Диспетчер задач не подходит для обнаружения утечек памяти. Delphi выделяет большие блоки памяти и сохраняет их для дальнейшего использования, поэтому ожидается некоторое увеличение выделенной памяти даже после освобождения всех ресурсов. Любые другие результаты (и более подробные ответы) можно получить только с помощью специализированных инструментов анализа памяти. AQTime - это первое, что приходит на ум, или, если вы найдете старый, но полезный MemProof, он вам очень поможет (MemProof бесплатен, а для анализа памяти удобнее, чем AQTime).

Answer 2

Ответ:

Я только что удалил FastMM из своего проекта, и программа освободилась до нескольких МБ после освобождения всех этих дочерних окон.Многие могут возразить, что это не является неправильным поведением и что FastMM делает это для того, чтобы сделать некоторую странную оптимизацию памяти.Они могут быть правдой.Тем не менее, это может быть хорошо для МОЕГО приложения, но не может быть хорошим для других работающих приложений.

Итак, по крайней мере, мы знаем, кто это вызывает.Я целый день волновался, что программа может вытекать из памяти как старое ведро.Теперь я с облегчением.

ОБНОВЛЕНИЕ:

Чтобы подтвердить, что FastMM генерирует это поведение (как предложил Барри Келли), я создал вторую программу, которая выделяла МНОГО ОЗУ.Как только Windows исчерпала ОЗУ, использование моей памяти программы вернулось к своему первоначальному значению.
(Примечание: я не говорю, что в FastMM есть ошибка!)

Моя программа не протекает.Проблема решена.

Answer 3

Вполне возможно, что FastMM не показывает утечки памяти после завершения работы приложения (например, потому что все объекты являются принадлежащими TComponents, а владелец освобождает их).
Но в то же время, когда эти компоненты работают, они все еще могут присутствовать, и их не достаточно быстро освободить.

Использовали ли вы модуль FastMM, который показывает форму с текущим использованием памяти?

<Редактировать>
Это FastMMUsageTracker.pas в каталоге ...\FastMM\Demos\Usage Tracker.
Используйте это устройство, затем вызовите в нем функцию ShowFastMMUsageTracker. Вы можете обновлять эту форму время от времени, чтобы увидеть, как растет потребление памяти. Я поместил FastMMUsageTrackerProject образец онлайн , включая обновление FastMM4, которое облегчает проверку и устранение утечек памяти:

• форма в блоке FastMMUsageTracker теперь имеет изменяемый размер, и элементы управления в ней привязываются правильным образом
• появился новый FastMmBootstrapUnit модуль, облегчающий отладку утечек памяти

На прошлой неделе у меня была под рукой сторонняя DLL, которая не была написана на Delphi.
В DLL произошла утечка памяти при использовании вызовов Windows GlobalAlloc, которые не отслеживаются FastMM.

NB. Я собираюсь опубликовать обновление для FastMM на

- Йерун

Answer 4

Если закрыть форму MDI, она не освобождается автоматически. Используйте Action = caFree (Google для этого), чтобы убедиться, что форма также освобождена.

Answer 5

Основное ограничение трассировки утечки памяти в FastMM заключается в том, что он может работать только при закрытии программы. Возможно, вы по-прежнему храните ссылки на объекты или другие данные, которые очищаются при завершении работы программы, но остаются до тех пор.

Например, когда вы закрываете дочерние окна MDI, вы вызываете Free или Release для них или просто заставляете их исчезать? Если они спрятаны, но не освобождены, они все равно останутся в памяти.