В этой статье я кратко объясняю понятие утечек памяти в информатике и то, как простое понимание утечек памяти поможет вам более эффективно кодировать ваше приложение. Как и многие другие, я часто слышал термин «утечка памяти» во время своих путешествий в качестве начинающего программиста, но я никогда полностью не понимал, что это такое и что с ними делать. Таким образом, этот блог предназначен для начинающих программистов или студентов, изучающих программирование, таких как я, чтобы расширить свои знания по этому предмету.
Что такое утечки памяти?
Во-первых, что такое утечка памяти? Как программисты, мы знаем, что код, который мы пишем, занимает память. Каждый раз при создании объектов или переменных пространство памяти требуется при каждом выполнении программы. По сути, утечка памяти — это когда память выделяется для чего-то, но больше не нужна и теперь без надобности занимает оперативную память. Один из способов подумать об этом, если вы включаете кран, и вода течет, но когда вы закончили с тем, для чего вам нужна вода, вы просто выключите его. Утечка памяти была бы, если бы из крана все еще капала вода, когда вы этого не хотели.
В основном утечки памяти являются серьезной проблемой, потому что они приводят к снижению производительности. Если утечка памяти происходит постоянно и программа использует больше памяти, чем требуется, то в конечном итоге она займет всю доступную память. Следовательно, производительность будет постоянно снижаться до тех пор, пока приложение не выйдет из строя или пока программа не будет полностью закрыта.
Утечки памяти обычно возникают из-за плохого программирования или непреднамеренно написанного кода. Например, вы, возможно, создали объект и больше не нуждаетесь в нем, но ваше приложение все еще может думать, что вы это делаете, поэтому оно по-прежнему будет удерживать для него память. К сожалению, поскольку утечки памяти являются результатом неправильного кодирования, это говорит о том, что мало что можно сделать для их предотвращения. Вот почему важно понимать концепцию утечек памяти и основы намеренного написания кода для повышения эффективности использования памяти.
Сборка мусора и Javascript
Кажется, что у разных языков программирования есть свои способы борьбы с утечками памяти. Для языков более низкого уровня, таких как Pascal, C или C ++, программисты должны явно / вручную выделять память, а затем освобождать память после того, как программа завершит выполнение кода. Однако такие языки, как Javascript, имеют автоматизированные системы управления памятью. Автоматизированная система решает множество проблем, так как она автоматически выделяет память каждый раз, когда создается объект, и, когда он больше не нужен, автоматически освобождает это пространство. Процесс автоматического освобождения неиспользуемого кода часто называют «сборкой мусора». Сборщики мусора очень эффективны и хорошо анализируют ваш код и избавляются от неиспользуемых переменных / объектов. Вероятно, поэтому начинающие программисты не умеют кодировать таким образом, чтобы эффективно использовать память, поскольку система — это место, чтобы сделать это за них. Однако для меня еще важнее, чтобы программисты понимали утечки памяти, чтобы они не приобрели плохие навыки программирования на протяжении всей своей карьеры, которые будут замечены потенциальными работодателями. Кроме того, сборщики мусора несовершенны, это просто алгоритмы. Они не знают, что вы пишете намеренно или нет. И все еще есть много способов, которыми сборка мусора не решает полностью утечки памяти.
Например, необъявленные глобальные переменные не будут считаться «мусором» сборщиком мусора, поскольку он не знает, что вы собираетесь с ними делать. Глобальный объект будет удерживать место в памяти при каждом запуске скрипта, поскольку программа считает, что вы собираетесь использовать эту переменную для чего-то. Подчеркивая, что важно понимать масштабы создаваемых нами объектов, и внимательно относиться к тому, когда их создавать.
Примеры утечки памяти в React.js
Одна из основных причин утечек памяти в приложениях React — невыпущенные слушатели в componentDidMount. Вот пример, изображенный Магиерой в его блоге 2018 года:
В приведенном выше коде есть прослушиватели событий клавиатуры, которые отслеживают состояние клавиатуры как состояние компонента. Слушатели событий монтируются с помощью componentDidMount, однако слушатели продолжают действовать после того, как компонент размонтируется из-за логики рендеринга. Даже если вы не визуализируете компонент, прослушиватели событий по-прежнему запускаются в фоновом режиме. Магерия объясняет: «В то же время модуль Keyboard должен хранить список активных слушателей в глобальной области видимости — в нашем случае он сохранит стрелочные функции, которые мы передаем методу addListener. В свою очередь, эти стрелочные функции сохраняют this — то есть ссылку на компонент Composer, который, в свою очередь, ссылается на свои свойства через this.props, на свои дочерние элементы через this.props.children, на дочерние элементы и т. Д. Эта простая ошибка может привести к тому, что останутся очень большие области памяти. сохранено случайно. » Чтобы решить эту проблему, вам нужно будет удалить прослушиватели событий с помощью componentWillUnmount:
Блог Магерии отлично объясняет это в деталях и дает еще больше примеров проблем с утечкой памяти для React Native и React.js в целом.
Другой пример плохого управления памятью в React.js, по общему признанию, принадлежит мне. Там, где у меня был clickHandler в родительском компоненте, переданный дочернему компоненту, который просто передавал обратно объект фильма в качестве реквизита. Однако clickHandler просто нуждался в идентификаторе объекта фильма, чтобы сделать запрос POST, и я передавал ВСЕ объект, когда требовалось только целое число movie.id. Таким образом, каждый раз, когда браузер прослушивал это событие щелчка, передавался весь объект, заполненный тоннами информации, а не просто идентификатор, который объект имел в качестве ключа.
Оглядываясь на большую часть моего кода после краткого понимания утечек памяти, я смог увидеть множество моих ошибок. Вдобавок я почувствовал, что узнал кое-что, что поможет мне стать лучшим программистом, и у меня в голове врезалось, что я должен писать свой код более внимательно.
В заключение
В этой статье я потратил много времени, жалуясь на утечки памяти и на то, как важно их избегать. По правде говоря, избежать утечек памяти практически невозможно. Как программистам, нам нужно следить за многими вещами и постоянно помнить о них. Поэтому добавление усилий по обеспечению того, чтобы каждая строка кода, которую вы пишете, учитывала утечки памяти, не было целью этого блога. Нам нужно просто знать об утечках памяти и более пристально программировать. Работодатели, вероятно, будут более склонны искать кандидатов, которые знают их кодекс и могут объяснить решения, которые они принимают. Вы можете оказаться в ситуации, когда определенный код занимает много памяти или, казалось бы, ненужный объем. Однако, если вы можете обосновать свою методологию, это не должно быть проблемой, но для того, чтобы объяснить, что и почему вы делаете определенные действия, вам необходимо приобрести некоторые знания, чтобы продемонстрировать это с уверенностью. Учет утечки памяти определенно помог мне написать лучший код. В своих прошлых проектах я осознавал, насколько плохо я написал код, и не учел, какую нагрузку могут оказать определенные действия на браузер пользователя. Несмотря на то, что я новичок и все еще учусь, я чувствую, что просто узнавая немного больше об утечке памяти, я повышаю свою привлекательность для потенциальных работодателей, ищущих инженеров-программистов.
РЕСУРСЫ:
