В недавнем сообщении ( Моя программа никогда не освобождает память обратно. Почему? ) Я показываю, что при использовании FastMM приложение не высвобождает значительные объемы памяти обратно в систему.Недавно я создал программу искусственного тестирования, чтобы убедиться, что проблема не в памяти, а в том, что она появляется только с FastMM.
В этой программе я создаю и уничтожаю объект (аналогичный тому, который использовался в предыдущем посте) 500 раз.
Требования к памяти («Частный рабочий набор»):
Без FastMM
Перед запуском цикла: 1,2 МБ
После запуска цикла: 2,1 МБ
С FastMM (агрессивный режим отладки)
Перед запуском циклацикл: 2,1 МБ
После запуска цикла: 25 МБ
С FastMM (режим разблокировки)
До запуска цикла: 1,8 МБ
После запуска цикла: 3 МБ
Если я запускаю цикл несколько раз, требования к памяти не увеличиваются.Это означает, что неизданная память используется повторно, так что это не утечка памяти (утечка памяти увеличит объем памяти на несколько КБ / МБ при каждом запуске).
Мои вопросы:
Как отключить это поведение в FastMM?Это вообще возможно?Я знаю, что если я выпущу программу без FastMM или с FastMM Release Mode, она будет «тратить» умеренное количество оперативной памяти.Но отключение этого поведения по требованию поможет мне (нам?) Выявить утечки памяти.На самом деле в моем первом посте (см. Ссылку) многие люди предположили, что у меня есть утечка.Беспорядок был создан, очевидно, только из-за этого поведения.Нет, очевидно, что утечки нет.Это просто диспетчер памяти, который отказывается освобождать большие объемы памяти.
Он когда-нибудь освободит дополнительную память?Когда?Что вызывает это?Может ли программист вызвать это?Например, когда я знаю, что выполнил задачу, интенсивно использующую ОЗУ, и пользователь может некоторое время не использовать программу (свести ее к минимуму), могу ли я сбросить ОЗУ обратно в систему?Что происходит, когда пользователь открывает несколько экземпляров моей программы?Не будут ли они конкурировать за оперативную память?