Утечка памяти и операционная система - PullRequest
4 голосов
/ 27 июля 2011

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

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

Я знаю, что утечки - это плохо, но мой вопрос проистекает из того, что предположим, что объект используется в заключительной процедуре кода - НЕ ИСПРАВЛЯЕТ утечку, что будет иметь какое-либо значение, поскольку процесс все равно будет завершен после этого

Заранее спасибо :)

Ответы [ 3 ]

2 голосов
/ 27 июля 2011

Это очень зависимый от ОС вопрос.

В современной многопроцессорной ОС, которая использует виртуальную память (например, Windows 7, Linux), верно, что все (хорошо, не все , но давайте не будем придирчивыми) ресурсы обрабатываться -специфичный и будет возвращен в систему после завершения процесса.

Так имеет ли значение, если ваша программа "утечка памяти"? Ну, это зависит от того, как это происходит.

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

Однако, если вы по какой-то причине выделяете ресурсы в цикле или по требованию во время выполнения и не пытаетесь каким-либо образом управлять ими, то теоретически, если вы позволите вашей программе работать достаточно долго, она будет постоянно «пропускать» ресурсы пока не настанет момент, что больше не осталось выделять. Это Плохая вещь . Не делай этого.

Сейчас существует множество платформ, которые не ведут себя таким образом. Если вам когда-нибудь придётся выполнять встроенную работу, вы, скорее всего, окажетесь на платформе, где вам придется управлять всеми своими ресурсами (свободная память вручную, закрывать дескрипторы файлов и т. Д.)

1 голос
/ 27 июля 2011

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

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

0 голосов
/ 27 июля 2011

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

Мне непонятно, откуда вы знаете, что у вас утечка памяти в этой ситуации, но если предположить, что вы действительно делаете это, то вам все равно следует это исправить. Это бомба замедленного действия в вашем коде.

Два примера того, почему:

  1. Код, который вы имеете, может быть повторно использован где-то еще, либо путем вырезания и вставки, либо путем рефакторинга.
  2. У вас могут быть проблемы с масштабируемостью:

    для (некоторый список вещей) сделать какую-то работу, которая пропускает 100 байтов

прямо сейчас вы повторяете 10 раз, пропускаете 1000 байтов, завершаете, ничего страшного. В будущем вы используете 10 000 раз, и из-за нехватки памяти основная работа по завершению работы завершается неудачей ...

...