Почему утечки памяти общие?

Question

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

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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

Поскольку в вашем вопросе не упоминается язык, сегодня существует автоматическое управление памятью, которое заботится о учете/отслеживании памяти, чтобы не происходило утечки памяти, думаю, что Java/.NET, но некоторые могут проскользнуть через сеть. Это было бы с подобными C/C++, которые используют функции malloc/new, и неизменно их сложнее проверить из-за того, что выделен объем памяти.

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

В целом, каждый из членов команды разработчиков несет ответственность за обеспечение работы кода , и знать правила об управлении памятью (например, такие, как для каждого malloc должен быть free для каждого new должен быть delete), но никакой вины не должны учитываться команды разработчиков сами, ни в пальцем, указывающим на управление для «нагромождения давления на команду разработчиков».

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

Надеюсь, это поможет, С уважением, Tom.

Answer 4

1. Ошибки.

2. Даже без ошибок, невозможно заранее знать, какая функция должна освобождать память. Это достаточно легко, если структура кода по существу функциональна (основная функция вызывает подфункции, которые обрабатывают данные, а затем возвращают результат), но это не так просто, если несколько протекторов (или несколько разных объектов) разделяют кусок памяти. Умные указатели могут использоваться (на C++), но в противном случае это более или менее невозможно.

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

Answer 5

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