Ответ 1
То, что вы описываете, - это не утечка памяти, это мусор, о котором знает Хром, и который будет удален, когда Хром решит это сделать. Чтобы объяснить это, давайте более подробно рассмотрим описанный вами сценарий.
Устранение утечки памяти
- Сначала откройте новое окно инкогнито (просто чтобы убедиться, что расширения браузера не влияют на наши результаты) и перейдите на страницу google.com.
- Затем откройте диспетчер задач и включите столбец "Память JavaScript" (щелкнув правой кнопкой мыши на окне диспетчера задач). Нам нужен этот столбец, чтобы быть уверенным, что память, которую мы будем "утечки", фактически выделяется JavaScript. Мы закончили с чем-то вроде этого:
- Теперь, как вы сказали, мы должны перезагрузить страницу пару раз и наблюдать за памятью нашей вкладки:
До сих пор так хорошо - все работает точно так, как вы его описали.
Подождите секунду...
Однако за полминуты не двигайте курсором или переходите на другую вкладку, и вы увидите огромное количество использования памяти на нашей вкладке "Tab: google". Почему это? Что там произошло? Кто очистил нашу "утечку" памяти для нас?
Снижение использования памяти
Чтобы исследовать это, повторим то, что мы сделали до сих пор, так что "Tab: google" снова использует много памяти. Затем откройте Chrome Developer Tools и начните запись на вкладке "Timeline". После этого давайте изменим вкладку на пару секунд, и когда падение памяти прекратит запись на "временной шкале". Вы должны в итоге:
В последние пару секунд нашей записи появились загадочные "GC Events". Точно в то же время, когда память была выпущена. Совпадение? Нет.
События GC
GC означает Сборщик мусора. Это механизм, который "пытается вернуть мусор или память, занятую объектами, которые больше не используются программой". Таким образом, оказывается, что память нашей вкладки была загрязнена мусором, и GC был способен избавиться от этих мусора в течение всего времени (вы даже можете заставить сбор мусора использовать кнопку в нижней части вкладки "Временная шкала" ). Так почему он решил не делать этого? Почему он ждал, когда мы перестанем взаимодействовать со страницей или изменим вкладку?
Коллектив мусора с ленивым мусором
Короткий ответ заключается в том, что сбор мусора должен "заморозить" выполнение всех скриптов, прежде чем любая работа может быть выполнена. Кроме того, для выполнения может потребоваться значительное количество процессорного времени. Это может привести к задержке, прерывистой анимации, невосприимчивым элементам управления и т.д. Поэтому Chrome ждет подходящего момента, чтобы вызвать сбор мусора. И лучший момент для этого - когда пользователь не смотрит.
Кроме того, обратите внимание, что "GC Events" входят в серию, всегда есть пара из них с короткими перерывами между ними. Эти перерывы предназначены для "нормального" JavaScript для выполнения, делая сбор мусора менее заметным.
Живые объекты
Взгляните на вкладку "Память JavaScript" в двух верхних скриншотах в этом сообщении. Вы заметите, что этот столбец содержит два числа. Первый - это память ", зарезервированная для JavaScript VM heap ", другой -" сколько объектов памяти доступно (достижимых) (источник). При тестировании ваших приложений вы должны беспокоиться только о втором значении, все остальные будут обрабатываться GC.
Пример утечки
Может произойти реальная утечка JavaScript, т.е. в приложении веб-чата. Если со временем он будет использовать все больше "живой" памяти, всегда отображая только последние 10 сообщений , а затем, мы можем говорить об утечке. Такая утечка приведет к сбою вкладки (или браузера).
Заключение
Для сценариев, запущенных на странице, перезагрузка страницы (или переход в другое место) равна перезапуску вашего компьютера во время работы приложения ANSI C. После этого вы должны подумать обо всей памяти, выделенной вашими сценариями, как уничтоженной. Единственная причина, почему на практике это может не произойти сразу после перезагрузки страницы, так это то, что браузер ждет подходящего момента для очистки. И вы, как веб-разработчик, не должны беспокоиться об этом.