Являются ли утечки памяти когда-либо?

Ответ 1

Нет.

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

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

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

Это похоже на предупреждения компилятора - будет ли предупреждение опасным для моего конкретного приложения? Возможно, нет.

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

Чтобы довести до крайности, было ли когда-нибудь приемлемым, чтобы хирург оставил часть рабочего оборудования внутри пациента?

Хотя возможно, что может возникнуть обстоятельство, когда стоимость/риск удаления этого оборудования превышает стоимость/риск его оставления, и могут быть ситуации, когда это было безвредно, если бы я увидел этот вопрос, размещенный на SurgeonOverflow.com и увидел любой ответ, отличный от "нет", это серьезно подорвало бы мою уверенность в медицинской профессии.

-

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

Ответ 2

Я не считаю, что это утечка памяти, если количество используемой памяти не растет. Наличие некоторой неизданной памяти, хотя и не идеальной, не является большой проблемой, если объем требуемой памяти не растет.

Ответ 3

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

#define BLK ((size_t)1024)
while(1){
    void * vp = malloc(BLK);
}

Обратите внимание, что каждый раз вокруг цикла while (1) выделяются байты 1024 (+ служебные), а новый адрес назначается vp; там не осталось указателя на предыдущие блоки malloc'ed. Эта программа, как гарантируется, будет работать до тех пор, пока не закончится куча, и нет возможности восстановить какую-либо память malloc'ed. Память "протекает" из кучи, и ее больше не видно.

То, что вы описываете, звучит как

int main(){
    void * vp = malloc(LOTS);
    // Go do something useful
    return 0;
}

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

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

Ответ 4

В теории нет, на практике это зависит.

Это зависит от того, сколько данных программа работает, как часто выполняется программа и постоянно ли она работает.

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

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

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

Ответ 5

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

Это неверно. Операционные системы обычно управляют памятью на страницах 4KiB. malloc и другие виды управления памятью получают страницы из ОС и подчиняют их по своему усмотрению. Весьма вероятно, что free() не вернет страницы в операционную систему, в предположении, что ваша программа будет malloc больше памяти позже.

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

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

Что это означает на практике? Это означает, что если вы знаете, что ваша программа больше не потребует больше памяти (например, на этапе очистки), освобождение памяти не так важно. Однако, если программа может выделять больше памяти позже, вы должны избегать утечек памяти, особенно тех, которые могут возникать повторно.

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

Комментарий, похоже, не понимал, что вызов free() не позволяет автоматически другим программам использовать освобожденную память. Но вот весь смысл этого ответа!

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

Предположим, вы выделили десять тысяч 100-байтных блоков (для простоты я проигнорирую дополнительную память, которая потребуется для управления этими распределениями). Это потребляет 1 МБ, или 250 страниц. Если вы случайно освободите 9000 из этих блоков, вы останетесь всего на 1000 блоков, но они будут разбросаны по всему месту. По статистике, около 5 страниц будут пустыми. Остальные 245 будут иметь по меньшей мере один выделенный блок в них. Это составляет 980 Кбайт памяти, которые не могут быть восстановлены операционной системой - даже если у вас теперь есть только 100 КБ!

С другой стороны, вы можете теперь malloc() еще 9000 блоков без увеличения объема памяти, которую ваша программа связывает.

Даже когда free() может технически вернуть память в ОС, это может и не сделать. free() необходимо достичь баланса между быстрой эксплуатацией и сохранением памяти. Кроме того, программа, которая уже выделила много памяти, а затем освободила ее, скорее всего, сделает это снова. Веб-сервер должен обрабатывать запрос после запроса после запроса - имеет смысл хранить некоторую "слабую" память, поэтому вам не нужно постоянно запрашивать ОС для памяти.

Ответ 6

Нет ничего принципиально неправильного в том, что очистка os после запуска приложения.

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

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

Ответ 7

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

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

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

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

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

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

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

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

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

Умное программирование является гибким и универсальным. Плохое программирование неоднозначно.

Ответ 8

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

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

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

Это не просто теоретическое. Всякий раз, когда я нахожусь со слишком большим количеством загруженных приложений, и диск начинает биться, я даже не думаю, что нажимаю "exit". Я добираюсь до терминала так быстро, как могу, и набираю killall -9... потому что я знаю, что "выход" только усугубит его.

Ответ 9

Я думаю, что в вашей ситуации ответ может заключаться в том, что все в порядке. Но вам определенно нужно документировать, что утечка памяти является сознательным решением. Вы не хотите, чтобы программист по обслуживанию приходил, ударил свой код внутри функции и называет его миллион раз. Поэтому, если вы принимаете решение о том, что утечка в порядке, вам необходимо задокументировать ее (В БОЛЬШИХ ПИСЬМАХ) для тех, кто, возможно, придется работать над программой в будущем.

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

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

Также вам нужно проверить документацию операционной системы. Если это встроенное устройство, могут быть операционные системы, которые не освобождают всю память от программы, которая выходит. Я не уверен, может быть, это не так. Но стоит посмотреть.

Ответ 10

Я уверен, что кто-то может придумать причину сказать "Да", но это не я. Вместо того, чтобы сказать "нет", я скажу, что это не должно быть "да/нет". Есть способы управлять утечками памяти или содержать их, и многие системы имеют их.

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

Ответ 11

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

Ответ 12

С одной стороны, я могу рассчитывать количество "доброкачественных" утечек, которые я видел со временем.

Таким образом, ответ - очень квалифицированный да.

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

Я видел, что этот подход был полезен для вещей с очень четко фиксированными учетными записями, такими как требования к краху во время работы с процессорами, и в гораздо меньшей степени в буфере, используемом для хранения состояния singleton /proc/self/maps в Hans Бем консервативный сборщик мусора для C/С++, который используется для обнаружения наборов корней и т.д.

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

Ответ 13

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

На самом деле, нет необходимости делать вызовы free() или удалять прямо перед выходом. Когда процесс завершается, вся его память возвращается ОС (это, безусловно, относится к POSIX. В других ОС - особенно встраиваемых - YMMV).

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

Ответ 14

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

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

и существует спектр промежуточных ситуаций.

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

Ответ 15

В этом вопросе контекст - это все. Лично я не могу терпеть утечки, и в своем коде я стараюсь исправить их, если они появятся, но не всегда стоит исправить утечку, и когда люди платят мне к тому моменту, когда я иногда сказал им, что не стоит моей платы за меня, чтобы исправить утечку в их коде. Позвольте мне привести вам пример:

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

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

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

Ответ 16

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

Что делать, если вы выделяете некоторую память и используете ее до самой последней строки кода в своем приложении (например, глобальный объект-деконструктор)? До тех пор, пока потребление памяти не будет расти со временем, можно ли доверять ОС, чтобы освободить вашу память для вас, когда ваше приложение завершается (в Windows, Mac и Linux)? Вы даже считали бы это реальной утечкой памяти, если бы память использовалась непрерывно, пока она не была освобождена ОС.

Если используется связанная память, вы не можете освободить ее до завершения программы. Независимо от того, свободен ли выход программы или ОС, это не имеет значения. Пока это документировано, чтобы изменения не вносили реальные утечки памяти, и до тех пор, пока в изображении не будет деструктора С++ или функции очистки C. Незакрытый файл может быть обнаружен через пропущенный объект FILE, но отсутствующий fclose() также может привести к тому, что буфер не будет очищен.

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

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

Ответ 17

Вы должны сначала понять, что существует большая разница между воспринимаемой утечкой памяти и фактической утечкой памяти. Очень часто инструменты анализа будут сообщать о многих красных сельдях и помечать что-то как просочившееся (память или ресурсы, такие как ручки и т.д.), Где это на самом деле нет. Часто это происходит из-за архитектуры инструмента анализа. Например, некоторые инструменты анализа будут сообщать о времени выполнения объектов как утечки памяти, потому что они никогда не видят, что эти объекты освобождены. Но освобождение происходит в коде завершения работы, который инструмент анализа может не увидеть.

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

Идеальный ответ: "нет, никогда". Более прагматичный ответ может быть "нет, почти никогда". Очень часто в реальной жизни у вас ограниченное количество ресурсов и времени для решения и бесконечного списка задач. Когда одной из задач является устранение утечек памяти, часто возникает закон уменьшения прибыли. Вы можете устранить 98% всех утечек памяти в приложении через неделю, но оставшиеся 2% могут занять несколько месяцев. В некоторых случаях может быть даже невозможно устранить некоторые утечки из-за архитектуры приложения без серьезного рефакторинга кода. Вы должны взвесить затраты и преимущества устранения оставшихся 2%.

Ответ 18

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

Для меня, спрашивая это, как вопрос: "Могу ли я сломать красный свет в 3 часа ночи, когда никто не будет рядом?". Конечно, это может не вызвать никаких проблем в то время, но это даст вам рычаг, чтобы вы сделали то же самое в час пик!

Ответ 19

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

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

Процесс, который захватывает все больше и больше памяти, не обязательно протекает. До тех пор, пока он способен ссылаться и освобождать эту память, он остается под явным контролем процесса и не просочился. Процесс может быть плохо спроектирован, особенно в контексте системы, где память ограничена, но это не то же самое, что утечка. И наоборот, потеря объема, скажем, 32-байтового буфера по-прежнему является утечкой, хотя количество утечки памяти невелико. Если вы считаете, что это несущественно, подождите, пока кто-то не обернет алгоритм вокруг вашего вызова библиотеки и называет его 10 000 раз.

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

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

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

Ответ 20

Я думаю, вы ответили на свой вопрос. Самым большим недостатком является то, как они мешают обнаружению утечек памяти, но я считаю, что этот недостаток является ОГРОМНЫМ недостатком для определенных типов приложений.

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

В книге "Collapse" Джареда Даймонда автор задается вопросом о том, что думал парень, который вырубил последнее дерево на острове Пасхи, дерево, которое ему понадобилось бы, чтобы построить каноэ, чтобы выйти с острова. Интересно о том, как много лет назад, когда этот первый глобальный был добавлен в нашу кодовую базу. Это был тот день, когда он был пойман.

Ответ 21

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

Ответ 22

Я не отвечу.

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

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

Ответ 23

Я согласен с vfilby - это зависит. В Windows мы рассматриваем утечки памяти как относительно серологические ошибки. Но это очень зависит от компонента.

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

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

Итак, если у вас есть утечка - оцените ее влияние двумя способами.

• К вашему программному обеспечению и вашему пользовательскому интерфейсу.
• Системе (и пользователю) с точки зрения экономности с системными ресурсами.
• Влияние исправления на обслуживание и надежность.
• Вероятность возникновения регрессии в другом месте.

Foredecker

Ответ 24

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

Вот пример, на SunOS в эпоху Sun 3 возникла проблема, если в процессе использовался exec (или более традиционно fork, а затем exec), последующий новый процесс наследовал бы тот же объем памяти, что и родительский, и это могло бы не сокращаться. Если родительский процесс выделил 1/2 гигабайта памяти и не освободил его перед вызовом exec, дочерний процесс начнет использовать тот же 1/2 концерт (хотя он не был выделен). Это поведение лучше всего проявлялось SunTools (их оконная система по умолчанию), которая была похожей на память. Каждое приложение, которое оно создало, было создано через fork/exec и унаследовало SunTools, быстро заполнив пространство подкачки.

Ответ 25

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

Ответ 26

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

Что вы делаете для серверных программ, которые разработаны так, чтобы они не выходили?

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

Утечка этой памяти и пусть программа очистит ее? Нет. Абсолютно нет. Это плохая привычка, которая приводит к ошибкам, ошибкам и большему количеству ошибок.

Очистите себя. Йо мамо не работает здесь больше.

Ответ 27

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

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

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

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

Ответ 28

Нет, у вас не должно быть утечек, которые ОС будет чистить для вас. Причина (не упомянутая в ответах выше, насколько я могу проверить) заключается в том, что вы никогда не знаете , когда ваш main() будет повторно использоваться как функция/модуль в другой программе. Если ваш основной() становится часто называемой функцией в программном обеспечении других лиц - это программное обеспечение будет иметь утечку памяти, которая ест память с течением времени.

КИВ

Ответ 29

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

Ответ 30

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

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

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