Understand memory leaks in JavaScript applications / Понимание утечек памяти в приложениях на JavaScript: Жизненный цикл объекта

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

Stutzer 23.01.13 в 23:49

Сборщик мусора периодически пробегается по графу объектов и считает для каждого объекта количество внешних ссылок (других объектов, ссылающихся на данный объект). Если таких ссылок не найдено или if the only references to it are circular, память, выделенная под данный объект, может быть высвобождена. На рисунке 1 приведен пример того, как сборщик мусора высвобождает память.

Stutzer 24.01.13 в 00:02

Рисунок 1. Высвобождение памяти сборщиком мусора.

Stutzer 24.01.13 в 00:03

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

Stutzer 24.01.13 в 00:15

Например, если вы работаете под Mac OSX и у вас установлен XCode, вы можете запустить the Instruments application и приаттачить его монитор активности к вашему браузеру для аналитики в режиме реального времени. Под Windows® для этих целей можно использовать менеджер задач (task manager). Если вы обнаружите, что при имитации работы пользователя в вашем приложении, график использования памяти во времени постоянно растет, значит у вас имеет место быть утечка памяти.

Stutzer 24.01.13 в 00:28

Наблюдение за состоянием памяти браузера — это очень грубая оценка использования памяти вашего JavaScript-приложения. Данные, полученные таким образом, не ответят на вопрос, какой именно объект «утекает», кроме того эти данные могут не отражать реальной картины по расходу памяти вашим приложением. Также, из-за особенностей реализации некоторых браузеров, DOM-элементы (или объекты уровня приложения) могут оставаться в памяти в то время, как соответствующие им элементы уничтожены на странице. Это, в частности, справедливо для тэга video, который требует от браузера более сложной инфраструктуры для реализации.

Stutzer 24.01.13 в 00:48

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

Stutzer 24.01.13 в 00:56

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

Stutzer 24.01.13 в 01:01

На текущий момент единственным браузером, который реализовал инструмент управления памятью как часть инструментов для разработчика, является Google Chrome, предлагающий инструмент Heap Profiler. В этой статье я буду использовать именно его тестирования для иллюстрации того, как JavaScript runtime оперирует памятью.

Stutzer 24.01.13 в 01:04