Утечки памяти когда-либо нормально?

Теоретически нет, на практике По-разному.

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

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

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

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

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

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

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

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

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

Я работаю с устаревшими серверными приложениями, которые должны быть надежными, но в них есть утечки, а глобальные переменные НЕ ДОЛЖНЫ мешать инструментам обнаружения памяти. Это большая сделка.

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

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

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

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

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

Я отвечу нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Для вашего программного обеспечения и вашего пользовательского опыта.
2. Для системы (и пользователя) с точки зрения экономии системных ресурсов.
3. Влияние исправления на обслуживание и надежность.
4. Вероятность регресса в другом месте.

Foredecker

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

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

Нет.

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

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

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

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

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

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

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

-

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

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

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

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

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

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

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

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

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

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

Так что ответ - однозначное «да».

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

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

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

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

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

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

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

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

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

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

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

Убирайся за собой. Йо, мама, здесь больше не работает.

Похоже, ваше определение «утечки памяти» - это «память, которую я не очищаю сам». Все современные ОС освобождают его при выходе из программы. Однако, поскольку это вопрос C++, вы можете просто обернуть рассматриваемую память в соответствующий std::auto_ptr, который вызовет delete, когда он выйдет за пределы области видимости.

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

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

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

Однако то, что вы описываете, звучит как

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

KIV

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

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

Преимущество простого выхода из приложения:

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

Плохая ситуация с выходом состоит из двух моментов:

1. Легко забыть о высвобождении ресурсов, которые ОС не отслеживает, или о том, что ОС может немного подождать с освобождением. Один из примеров - сокеты TCP.
2. Программное обеспечение отслеживания памяти сообщит об утечках все, не освобожденных при выходе.

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

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

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

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

Несколько вызовов if () free () в функции очистки дешевы, почему бы их не использовать?

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

What if you allocate some memory and use it until the very last line of code in your application (for example, a global object's deconstructor)? As long as the memory consumption doesn't grow over time, is it OK to trust the OS to free your memory for you when your application terminates (on Windows, Mac, and Linux)? Would you even consider this a real memory leak if the memory was being used continuously until it was freed by the OS.

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

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

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

Если вы используете его до конца вашего main(), это просто не утечка (конечно, при наличии защищенной системы памяти!).

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

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

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

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

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

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

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

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

В общем, утечки памяти лучше устранить.

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

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

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

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

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

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

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

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

Используйте какой-то умный указатель, который сделает это за вас автоматически (например, scoped_ptr из Boost libs)

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

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

I only see one practical disadvantage, and that is that these benign leaks will show up with memory leak detection tools as false positives.

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

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

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

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

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

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

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

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

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

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

What if you allocate some memory and use it until the very last line of code in your application (for example, a global object's destructor)?

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

is it OK to trust the OS to free your memory for you when your application terminates

Когда короткоживущая программа создает большие коллекции C++ (например, std::map), на каждый объект приходится как минимум 2 выделения. Итерация по этой коллекции для уничтожения объектов требует реального времени для ЦП, а оставление объекта для утечки и очистки ОС дает преимущества в производительности. Счетчик, есть ли некоторые ресурсы, которые не приводятся в порядок ОС (например, общая память), и не уничтожение всех объектов в вашем коде создает риск того, что некоторые из них удерживаются на этих несвободных ресурсах.

What if a third party library forced this situation on you?

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

В общем, если бы библиотека не была повторно инициализирована, я бы, вероятно, не беспокоился.

допустимое время для получения сообщения об утечке памяти.

1. Сервис при выключении. Здесь есть компромисс между показателями времени и правильностью.
2. Сломанный объект, который нельзя уничтожить. Мне удалось обнаружить сбойный объект (например, из-за перехвата исключения), и когда я пытаюсь уничтожить объект, результатом является зависание (удерживаемая блокировка).
3. Ошибка проверки памяти.

Сервис во время выключения

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

Сломанный объект

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

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

неверное сообщение о проверке утечек

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

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