Pull to refresh

Comments 16

Спасибо за статью! Как раз вовремя.
Что я не так сказал?
Самая полная и подробная статья про утечки памяти в JS, которую я видел. Огромное спасибо
Отличная статья, большое спасибо!!!
Может ли кто-то дать ссылки или советы по поиску утечек в проекте с jQuery и событиями?
Я стараюсь работать, в основном, с бэкендом и на фронтенд не очень много сил трачу. Использую CoffeeScript+jQuery и некоторые плагины.
Вижу что в FF память течет — после перезагрузки страницы объем занятой памяти (плагин TabMemoryUsage) увеличивается стабильно на 3Мб. Профилирование javascript — не такая простая задача, как для Python — покопался в отладочных инструментах, но не все так очевидно как на примере из статьи.
Есть еще какие-то рекомендации?
Краткое содержание, если опустить специально сконструированные хаки для js:
1. «use strict», Luke
2. Не быдлокодь
Огромное спасибо, очень интересно!
Остался вопрос — сборщик мусора запускает алгоритм поиска и пометки недостижимых ссылок с какой-то периодичностью или по какому-то событию? Как часто это происходит, примерно?
Как указано в статье, работа сборщика недетерменирована. Т.е. мы не можем запустить его из JS или угадать, когда он сработает.
Да, это я понимаю, но ведь есть какой-то алгоритм его запуска.
В статье сказано, что сборка мусора может не произойти, если все недостижимые ссылки будут найдены, но не происходит последующих выделений памяти — тут всё понятно. А как на счёт самого процесса поиска недостижимых ссылок — как часто это происходит? При новых выделениях памяти, через фиксированный интервал времени или как-то иначе?
Нашёл статью http://v8project.blogspot.ru/2015/08/getting-garbage-collection-for-free.html
Грубо говоря, выходит, что у Хрома есть 16.6ms-циклы, и если он успевает сделать приоритетные задачи до окончания итерации, то остаток времени расходуется на низко-приоритетные задачи, включая и сборку мусора.
В Chrome есть флажек --js-flags="--expose-gc", с ним в коде можно вызывать gc(), бывает полезно при ловле утечек.
Большое спасибо за статью!
Не так часто бывает что после прочтения, практически не остается вопросов, а для тех что возникли, уже и ссылки в статье подготовленны.
Спасибо за статью!
Сказанное о каллбеках на примере рекомендуемого к использованию addEventListener справедливо так же и для attachEvent / detachEvent?
Как правильно поступать перед удалением объекта при простом «навешивании» обработчиков в стиле:
element.onclick = function() { alert(1); }

Делать
element.onclick = null;


var theThing = null;
var replaceThing = function () 
{
  var originalThing = theThing;
  var unused = function ()     // Данная лямбда ссылается на ссылку originalThing,
                               // однако на данную лямбду окромя ссылки unusued 
                               // ссылок нет. 
  {
    if (originalThing)
      console.log("hi");
  };
  theThing = // переинициализируем ссылку theThing нижеописанной лямбдой, 
             // которая ни на что не ссылается. На текущую лямбду будет ссылаться 
             // ссылка theThing, на предыдущую лямбду в данный 
             // момент ссылается только лишь ссылка originalThing, верно?
  {
    longStr: new Array(1000000).join('*'),
    someMethod: function () 
    {
      console.log(someMessage);
    }
  };
};     // смело грохаем лямбду по ссылке unused, затем
       // грохаем лямбду originalThing (gc с подсчетом ссылок)

setInterval(replaceThing, 1000);


Так в чем проблема? При выходе из области видимости лямбды replaceThing мы можем смело грохнуть объект (лямбду) расположенную по ссылке unused, тем самым разрешив разрушение объекта (лямбды) расположенной по ссылке originalThing.
Sign up to leave a comment.

Articles