2009-11-12 1 views
4

У меня есть программа для рабочего стола. Большинство операционных систем запускают программу в своем адресном пространстве.Какие операционные системы освободят утечки памяти?

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

Что я не уверен в том, что если программа имеет утечку памяти, будет ли память «утечка» также возвращена для повторного использования или она потеряна до перезагрузки машины?

Это вопрос к вопросу, который я задал ранее сегодня: Do Small Memory Leaks Matter Anymore?, а также несколько замечаний о том, что программная память освобождается при завершении программы. Если утечки освобождаются, когда программа завершена, то это определенно оказывает на меня меньшее давление, чтобы строго избавить мою программу от мельчайших утечек.

В частности, я программист Windows, и мне нужно знать, что происходит (потеря памяти или освобождение памяти) для Windows 98, 2000, XP, Vista и 7. Но я также хотел бы услышать, что происходит на Mac и Unix.


Уточнение: Я говорю о нераспространении утечек. Это утечки постоянного размера, которые происходят один раз при запуске программы.

Я понимаю, что утечки, которые постоянно растут в программе, являются серьезными и должны быть исправлены.

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

ответ

5

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

Все современные операционные системы используют механизм, называемый виртуальной памятью, для отслеживания памяти программ.

Здесь я узнал о виртуальной памяти довольно неплохо. CS3231.

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

С точки зрения приложений, он получает полный доступ к памяти (4gig на 32-разрядной ОС, что-то массивное на 64-разрядном уровне) и может продолжать выделять до тех пор, пока он не достигнет аппаратного предела, даже если физическая память меньше чем это ограничение (для этого требуется, чтобы ОС сохраняла часть содержимого памяти на диске, как правило, в файле подкачки)

Этому способствуют аппаратные средства на процессоре, который обычно называется MMU (модуль управления памятью) , а иногда есть также TLB (Buffal Lookuside Buffer), чтобы ускорить операции виртуальной памяти.

Другой page, который объясняет немного больше о защите памяти, которая детализирует некоторые дополнительные функции виртуальной памяти.

+1

+1, но K & R все еще плачет, когда ваш код течет, как бы ни мала! – phoebus

+0

Действительно ли это во всех операционных системах? Когда ОС перешел из разделяемой памяти? – lkessler

+3

Это верно для всех современных операционных систем, которые не работают на ограниченных устройствах (например, 8-разрядные встроенные контроллеры с низким уровнем конца). Основным фактором, включенным в эту функцию, были блоки управления виртуальной памятью и аппаратной памятью (MMU). Любая система может это сделать, но подсистемы VM/MMU облегчают ее работу. И «защищенная» память не является обязательным требованием. Например, у более старой ОС Mac не было защиты памяти (один процесс мог топать в образе памяти другого), но процессы не связывались, когда они выходили (они все равно могли протекать внутри, конечно). 7 to go –

2

Windows, освободит память процесса после его завершения но утечка имеет некоторое влияние на производительность и надежность приложений (в зависимости от его размера)

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

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

2

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

A laissez faire отношение порождает проблемы. Поэтому я считаю, что следы памяти являются признаком того, насколько вы бедны на работе.

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

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

+0

Я не игнорирую утечки памяти. Я нахожу и фиксирую 98% из них. Но последние 2% очень трудно решить. Большинство из них не мои ошибки, но находятся в стороннем программном обеспечении или даже в подпрограммах, которые поставляются с моим инструментом разработки (Delphi). То, что осталось, не является основным, но оно также не равно нулю. – lkessler

+0

Возможно, у нас есть другое определение того, что такое «утечка». «Утечка» - это когда вы теряете память, так как протекающее ведро теряет воду. Если приложение имеет одноразовое распределение, которое оно никогда не освобождает, это на самом деле не «утечка», но в большинстве случаев это по-прежнему плохая практика. Множество фреймворков, в частности MFC и VCL, имеют незапятнанную память о выходе на ОС, поскольку сплайны сделаны на ранней стадии приложения и остаются на всю жизнь программы. Это не «утечки», но следует избегать там, где это возможно. –

+0

Да, я думаю, что мы делаем. Я говорю об одноразовых ассигнованиях. Я добавлю пояснение к вопросу. – lkessler