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

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

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

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

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

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

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

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

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

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

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

Допускаются ли утечки памяти?

Конечно, если это кратковременный процесс.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У вас, вероятно, есть и другие ошибки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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