Утечка памяти - отсутствие сборщика мусора

Question

Давайте вспомним программу утечки памяти, в которой блок памяти кучи не освобождается, и программа завершается.Если бы это была (скажем) Java-программа, встроенный сборщик мусора автоматически освободил бы этот блок кучи до выхода из программы.

Но даже в C ++, если программа закроется, ядро ​​не будет автоматически отменять выделение всего пространства, связанного с процессом.Также в коде Java ядро ​​должно было бы освободить место для текстовой части (кода) процесса (даже если части стека и кучи освобождаются сборщиком мусора).Так есть ли общее преимущество использования функции сборщика мусора - просто увеличенная экономия времени, необходимая для освобождения кучи самой программой, а не ядром?(если есть такая экономия)

РЕДАКТИРОВАТЬ: Мое основное сомнение возникло при рассмотрении ответов - вызовет ли GC сам себя, когда использование памяти достигнет предела?Потому что, если GC вызывается только перед завершением программы, он не будет полезен для длинных программ.

Answer 1

1. Это предполагает, что ядро ​​очищается после вас.Не все ОС позаботятся о динамически распределенной памяти автоматически.(Но если быть честным: большинство современных, по крайней мере, на настольных компьютерах, делают.)
2. Даже ОС, которые освобождают всю память, делают это только , когда процесс завершается .Большинство программ выделяют гораздо больше памяти по сравнению с общим временем выполнения, чем им требуется в любой конкретный момент времени (при достаточно длительном запуске, где «long» может быть несколькими секундами для многих приложений, обрабатывающих данные).
3. Из-зачто многие - особенно долго работающие - процессы будут создавать все больше и больше мусора (памяти, которая больше не используется и больше не будет использоваться) в течение своей жизни без какой-либо надежды избавиться от нее без прерывания.Вы не хотите уничтожать и перезапускать весь процесс только для того, чтобы сохранить низкое использование памяти, не так ли?
4. Поскольку неиспользуемая память почти никогда не существует (существует довольно много процессов, которые работают бесконечно, а некоторые могут работать длячасов) утилизируется, через некоторое время вы получаете серьезную нехватку памяти.Ваш браузер хранит в памяти все изображения, документы HTML, объекты JS и т. Д., Которые вы открыли во время этого сеанса, потому что вы не будете перезапускать его каждые несколько минут.Это бред и серьезная проблема в браузере, говорите?Моя точка зрения точно.
5. Более того, большинство (то есть все хорошие) GC не освобождают все - они запускаются время от времени, когда онидумаю, это того стоит, но когда процесс завершается, все, что остается в памяти, остается на более низком уровне (будь то пользовательский распределитель или ОС) для освобождения.По этой же причине не гарантируется запуск финализаторов - в короткоходовой программе, которая не выделяет много ресурсов, GC может никогда не запуститься.

Так что нет, GC не о сохранениивремя.Речь идет об экономии тонны памяти, не позволяющей долго выполняющимся программам с интенсивным выделением ресурсов перегружать всю доступную память и в конечном итоге заставлять всех умирать из-за ошибок памяти.

Answer 2

Допустим, что программа выделяет некоторый ресурс, использует его все время, пока работает, но не освобождает его должным образом перед выходом.Когда эта программа завершается, ядро ​​освобождает все программные ресурсы - это нормально.

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

Плохо то, что программист, который делает утечки памяти и ресурсов типа 1, обычно делает утечки типа 2, производя грязный и нестабильный код,Профессиональный программист пишет идеальный код с нулевым ресурсом и утечками памяти.Если есть сборщик мусора - все нормально.Если нет - управляйте ресурсами самостоятельно.

Кстати, все еще возможно сделать утечку с помощью сборщика мусора - как хорошо известная утечка источника-потребителя события .NET.Таким образом, сборщик мусора очень полезен, экономит много времени разработчика, но в любом случае разработчик должен тщательно управлять программными ресурсами.