Угрожают ли небольшие утечки памяти?

Ответ 1

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

Однако, если:

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

Ответ 6

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

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

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

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

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

Ответ 7

Являются ли утечки памяти когда-либо?

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

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

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

Ответ 8

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

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

Ответ 9

Я согласен с более ранними ответами о том, что утечки имеют значение.

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

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

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

Ответ 10

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

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

Ответ 11

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

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

Ответ 12

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

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

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

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

Ответ 13

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

Ответ 14

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

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

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

Ответ 15

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

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

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

Ответ 16

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

Ответ 17

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

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

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