Имеют ли значение небольшие утечки памяти больше?

Это полностью личное решение.

Однако если:

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

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

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

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

Утечки - это ошибки.

Возможно, у вас есть и другие ошибки.

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

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

На самом деле, утечки могут отличаться в одном важном отношении, а именно: если вы отправляете библиотеку / API, вы действительно должны их исправить, потому что выгода для клиента огромна (в противном случае все ваши клиенты `` унаследуют '' вашу утечку и будут звоню вам так же, как вы должны сейчас поговорить со сторонним поставщиком).

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

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

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

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

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

Однако трудно доказать, что наблюдаемая утечка памяти не растет; у вас достаточно эмпирических данных. На самом деле, многие огромные программы (даже написанные на Java / C #) имеют утечки памяти, но большинство из них не растут.

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

Но не могу согласиться с вашим мнением: «память - дешевая». Это не может оправдать утечку памяти. Это очень опасно.

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

Утечка памяти действительно зависит от нескольких вещей:

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

Например, если вы теряете 40 байт каждый раз, когда выполняется задача, и эта задача выполняется при запуске программы, то никого не волнует. Если вы теряете 40Мб каждый раз при запуске программы, то это следует исследовать. Если вы теряете 40 байтов в каждом кадре в движке видео или игры, вам следует изучить это, потому что вы будете терять 1,2 КБ каждую секунду, а через час вы потеряете почти 4 МБ.

Это также зависит от того, как долго программа будет работать. Например, у меня есть небольшое приложение-калькулятор, которое я открываю, запускаю в нем расчет, а затем снова закрываю. Если это приложение теряет 4 МБ при запуске, это не имеет особого значения, потому что ОС восстановит потерянную память, как только я ее закрою. Если гипотетический движок видео / игр, упомянутый ранее, терял 4 МБ в час, и он запускал демонстрационный блок в течение нескольких часов в день на стенде на съезде, я бы посмотрел на это.

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

Возможны ли утечки памяти?

Конечно, если это недолговечный процесс.

Утечки памяти в течение длительного периода времени, как следует из ответа из 85 баллов, проблематичны. Возьмем, к примеру, простое настольное приложение - до версии 3.x вы когда-нибудь замечали, что вам нужно было перезагрузить Firefox через некоторое время, чтобы восстановить его после медлительности?

Что касается краткосрочной перспективы, то нет, это не имеет значения. Возьмем, к примеру, сценарии CGI или PHP или небольшой трехстрочный файл Perl в вашем каталоге ~/bin. Никто не будет вызывать полицию памяти, если вы напишете на языке C приложение из 30 строк без цикла с 5 строками malloc() и ни одного обращения к free().

Я в одной лодке с тобой. У меня небольшие утечки памяти, которые никогда не растут. Большинство утечек вызвано неправильным удалением COM-объектов. Я изучил утечки и пришел к выводу, что время и деньги на их устранение несоразмерны ущербу, который наносят утечки. Windows очищает большую часть времени, поэтому истинный ущерб осознается только в том случае, если пользователь запускает свой компьютер в течение многих лет без перезагрузки.

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

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

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

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

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

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

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

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

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

Да, это важно. Каждая маленькая утечка складывается.

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

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

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

Утечки памяти никогда не допустимы ни в одной программе, какой бы незначительной она ни была. Постепенно они будут складываться, чтобы заполнить всю вашу память. Предположим, у вас есть вызывающая система, которая теряет около 4 байтов памяти на каждый вызов, который она обрабатывает. Вы можете обрабатывать, скажем, 100 вызовов в секунду (это очень маленькое число), поэтому в итоге вы теряете 400 байт в секунду или 400x60x60 (1440000B) в час. Так что даже небольшая утечка недопустима. И если вы не знаете источник утечки, то это может быть серьезной проблемой, и в конечном итоге у вас будут баги в программном обеспечении. Но, по сути, все сводится к таким вопросам, как, сколько времени выполняется программа и сколько раз происходит утечка. Так что это может быть нормально, утечка очень небольшая и не повторяется, но все же утечка может быть небольшой частью более серьезной проблемы. Итак, я чувствую, что утечки памяти никогда не допустимы.

Это все равно, что спросить, была ли трещина в дамбе, нормально? НЕТ! НИКОГДА! Избегайте утечек памяти, как будто от этого зависит ваша жизнь, потому что, когда ваше приложение разрастется и получит больше использования, эта утечка превратится в наводнение, и рано или поздно кто-то или что-то утонет в ней. То, что у вас может быть много памяти, не означает, что вы можете использовать ярлыки в своем коде. Как только вы обнаружите утечку, сделайте все возможное, чтобы устранить ее, а если вы не можете решить ее, обязательно возвращайтесь к ней, пока она не будет устранена.

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

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

Меня бы не так беспокоило количество, а частота утечки памяти, но если вы очень часто утекаете даже всего несколько байтов, ваши структуры данных malloc будут расти и могут значительно замедлить их обход, выделение новая память и бесплатно. Если вы не дойдете до границы, на которой произошла утечка более чем крошечной части вашей оперативной памяти, от этих проблем с производительностью пострадает в основном ваша программа, а не вся система. Не применяется даже к удаленным системам на основе dlmalloc (FreeBSD, Linux и т. Д.), Там это просто не волнует, все, что вы теряете, это память (возможно, в несколько раз больше, чем вы думаете), а не производительность.

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

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

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

Утечки памяти очень важны в 32-битных приложениях, потому что приложение ограничено 2 ^ 32 байтами памяти, что составляет примерно 4 ГБ. Как только 32-разрядное приложение пытается выделить более 2 ^ 32 байтов памяти, приложение может аварийно завершить работу или зависнуть.

Утечки памяти не так важны в 64-битных приложениях, потому что приложение ограничено 2 ^ 64 байтами памяти, что составляет примерно 16 ЭБ; поэтому с 64-битным приложением вы в большей степени ограничены аппаратным обеспечением, но ОС, скорее всего, когда-нибудь наложит искусственное ограничение.

Суть в том, что утечка памяти в вашем коде - плохое программирование; так что исправь это и будь лучшим программистом.