Когда вы считаете, что программа протекает, и вам нужно освободиться до выхода? [Дубликат]

Вы правы, память автоматически освобождается, когда процесс завершается. Некоторые люди стараются не проводить тщательную очистку, когда процесс завершается, так как все они будут оставлены в операционной системе. Однако, пока ваша программа работает, вы должны освободить неиспользуемую память. Если вы этого не сделаете, вы можете закончиться или вызвать чрезмерный пейджинг, если ваш рабочий набор становится слишком большим.

Я думаю, что ваши два примера на самом деле только один: free() должен появиться только в конце процесса, который, как вы указываете, бесполезен, так как процесс завершается.

В вас второй пример, однако, единственное различие заключается в том, что вы разрешаете неопределенное число malloc(), что может привести к нехватке памяти. Единственный способ справиться с ситуацией - проверить код возврата malloc() и действовать соответственно.

Если вы разрабатываете приложение с нуля, вы можете сделать некоторые образованные выборы о том, когда звонить бесплатно. Ваша примерная программа в порядке: она выделяет память, возможно, у вас есть ее работа на несколько секунд, а затем закрывается, освобождая все ресурсы, которые она требовала.

Если вы пишете что-нибудь еще, сервер / долговременное приложение или библиотеку, которую должен использовать кто-то другой, вы должны ожидать бесплатного вызова всего, что вы malloc.

Игнорируя прагматическую сторону на секунду, гораздо безопаснее следовать строжайшему подход и заставить себя освободить все, что вы malloc. Если у вас нет привычки смотреть на утечки памяти, когда вы код, вы можете легко запустить несколько утечек. Так что, другими словами, да, вы можете обойтись без него; пожалуйста, будьте осторожны.

На самом деле есть раздел в онлайн-учебнике OSTEP для обучения студентов в операционных системах, в котором точно указан ваш вопрос.

Соответствующий раздел - «Забыть о свободной памяти» в в главе Memory API на стр. 6, которая дает следующее объяснение:

В некоторых случаях может показаться, что не вызов free () является разумным. Например, ваша программа недолговечна и скоро выйдет; в этом случае, когда процесс умирает, ОС очистит все выделенные страницы, и, таким образом, утечка памяти не произойдет сама по себе. Хотя это, безусловно, «работает» (см. в сторону на стр. 7 ), это, вероятно, плохая привычка развиваться, поэтому будьте осторожны в выборе такой стратегии

. Этот фрагмент находится в контексте введения концепции виртуальной памяти. В основном на этом этапе книги авторы объясняют, что одной из целей операционной системы является «виртуализация памяти», то есть каждая программа считает, что она имеет доступ к очень большому адресному пространству памяти.

За кулисами операционная система будет переводить «виртуальные адреса», которые пользователь видит в фактических адресах, указывающих на физическую память.

Однако для совместного использования ресурсов, таких как физическая память, требуется, чтобы операционная система отслеживала о том, какие процессы используют его. Таким образом, если процесс завершается, то в рамках возможностей и целей разработки операционной системы восстанавливается память процесса, чтобы он мог распространять и делиться памятью с другими процессами.

---

EDIT: . Конец, упомянутый в выдержке, скопирован ниже.

ASIDE: ПОЧЕМУ НЕ УДАЛЕНА ПАМЯТЬ ПРОТИВ ПРОЦЕССА

Когда вы пишете короткий -lived, вы можете выделить некоторое пространство, используя malloc(). Программа запускается и собирается завершить: нужно ли free() вызвать кучу раз перед выходом? Хотя кажется неправильным, что никакая память не будет «потеряна» в каком-либо реальном смысле. Причина проста: в системе действительно два уровня управления памятью. Первый уровень управления памятью выполняется ОС, которая передает их в процессы, когда они запускаются, и возвращает их, когда процессы завершаются (или иначе умирают). Второй уровень управления находится внутри каждого процесса, например, внутри кучи, когда вы вызываете malloc() и free(). Даже если вам не удалось вызвать free() (и, таким образом, удалить память в куче), операционная система восстановит всю память процесса (включая эти страницы для кода, стека и, в зависимости от ситуации, кучу), когда программа закончен. Независимо от того, каково состояние вашей кучи в вашем адресном пространстве, ОС возвращает все эти страницы, когда процесс умирает, тем самым гарантируя, что память не будет потеряна, несмотря на то, что вы ее не освободили.

Таким образом, для недолговечных программ утечка памяти часто не вызывает никаких операционных проблем (хотя она может считаться плохой формой). Когда вы пишете долговременный сервер (например, веб-сервер или систему управления базами данных, которые никогда не выходят), утечка памяти является гораздо более серьезной проблемой и в конечном итоге приведет к сбою, когда в приложении закончится память. И, конечно, утечка памяти - еще более серьезная проблема внутри одной конкретной программы: самой операционной системы. Показывая нам еще раз: те, кто пишу код ядра, имеют самую сложную задачу для всех ...

из Страница 7 из Справочника по API главы

Операционные системы: три простых пьесы Ремзи Х. Арпачи-Дуссе и Андреа К. Арпачи-Дуссеу Книги Арпачи-Дуссо Март, 2015 г. (версия 0.90)

Обычно я освобождаю каждый выделенный блок, как только я уверен, что с ним все закончится. Сегодня точкой входа моей программы может быть main(int argc, char *argv[]), но завтра это может быть foo_entry_point(char **args, struct foo *f) и введено как указатель функции.

Итак, если это произойдет, у меня теперь есть утечка.

Что касается вашего второго вопроса, если моя программа взяла ввод, например a = 5, я бы выделил место для a или перераспределял одно и то же пространство на следующем a = "foo". Это оставалось бы распределенным до:

1. Пользователь напечатал «unset a»
2. . Была введена моя функция очистки, либо обслуживая сигнал, либо пользователь набрал «quit»

Я не могу придумать никакой современной ОС, которая не восстанавливает память после выхода процесса. Опять же, free () дешево, почему бы не убрать? Как говорили другие, такие инструменты, как valgrind, отлично подходят для обнаружения утечек, о которых вам действительно нужно беспокоиться. Несмотря на то, что блоки, на которые вы, например, будете помечены как «все еще доступные», просто лишний шум в выходе, когда вы пытаетесь обеспечить отсутствие утечек.

Еще один миф: « Если его в main (), мне не нужно его освобождать ", это неверно. Рассмотрим следующее:

char *t;

for (i=0; i < 255; i++) {
    t = strdup(foo->name);
    let_strtok_eat_away_at(t);
}

Если это произошло до форкирования / демонтирования (и в теории работает вечно), ваша программа только что пропустила неопределенный размер в 255 раз.

Хорошая, хорошо написанная программа всегда должна очищаться после себя. Освободите всю память, очистите все файлы, закройте все дескрипторы, отсоедините все временные файлы и т. Д. Эта функция очистки должна быть достигнута при обычном завершении или при получении различных видов фатальных сигналов, если вы не захотите оставить некоторые файлы, лежащие вокруг, чтобы вы могли обнаружите сбой и возобновите.

На самом деле, будьте добры к бедной душе, которая должна поддерживать ваши вещи, когда вы переходите к другим вещам .. передайте их им «valgrind clean»:)