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

Question

Теперь, когда ОЗУ обычно находится в гигабайтах на всех ПК, стоит ли мне уделять время поиску всех мелких (нерастущих) утечек памяти, которые могут быть в моей программе? Я говорю о тех дырах, которые могут быть меньше 64 байтов, или даже о группе, которая составляет всего 4 байта.

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

Я видел вопрос об утечке памяти номер один здесь, на SO: Устранены ли утечки памяти когда-либо? и ответ номер один, на который сейчас проголосовали 85 раз, это: *

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

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

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

_{(источник: beholdgenealogy.com )}

---

Также смотрите мой следующий вопрос: Какие операционные системы освободят утечки памяти?

---

Постскриптум: Я только что купил EurekaLog для разработки моей программы.

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

Answer 5

Утечки памяти когда-нибудь исправны?

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

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

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

Answer 6

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

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

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

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

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

Answer 7

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

Answer 8

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

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

Answer 9

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

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

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

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

Answer 10

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

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