Утечки памяти, когда-нибудь в порядке? [закрытый]

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

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

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

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

Моются после себя. Эй мама не работает здесь больше.

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

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

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

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

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

Я отвечу нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На самом деле, нет никакой потребности выполнить вызовы к свободному () или удалить прямо перед выходом. Когда процесс выходит, вся его память исправлена ОС (это, конечно, имеет место с POSIX. На других Ose †“особенно встроенные †“YMMV).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

KIV

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

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

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

Так, если у Вас есть утечка †“, оценивают ее влияние два пути

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

Foredecker

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

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

я работаю с серверными приложениями прежней версии, которые, как предполагается, являются горным телом, но у них есть утечки, и globals ДЕЙСТВИТЕЛЬНО мешают инструментам обнаружения памяти. Это - грандиозное предприятие.

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

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

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

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

, Что Вы описываете, тем не менее, походят

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

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

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

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

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

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

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

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

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

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

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

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