Утечки памяти когда-либо в порядке? [закрыто]

Допустимо ли когда-нибудь иметь утечку памяти в вашем приложении на C или C ++?

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

Что если сторонняя библиотека навязывает вам такую ​​ситуацию? Отказались бы от использования сторонней библиотеки, какой бы великой она ни была?

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

Нет.

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

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

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

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

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

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

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

-

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так что ответ очень квалифицированный да.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Foredecker

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

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

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

KIV

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

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

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

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

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

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

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

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

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

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

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

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

Я отвечу нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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