предисловие
Эта серия изначально была подготовлена для моего собственного интервью, потом я обнаружил, что сортировок становится все больше и больше, почти 120 000 символов, и, наконец, решил поделиться со всеми.
Чтобы поделиться ими и упорядочить их, я потратил много времени, по крайней мере, в три раза больше времени, которое я только использовал.Если вам это нравится, добро пожаловать, чтобы собрать и подписаться на меня!Спасибо!
Ссылка на статью
- Интервью на начальном этапе для проверки утечек и заполнения вакансий -- (1) Защита от встряски и дросселирование
- Предварительное интервью для проверки пропусков -- (2) Механизм сбора мусора
- Предварительные собеседования для проверки и заполнения вакансий -- (3) Междоменные и общие решения
- Предварительное собеседование для проверки и заполнения вакансий -- (4) Переднее локальное хранилище
- Предварительное собеседование для проверки утечек и заполнения вакансий -- (5) Механизм рендеринга, перерисовка и перекомпоновка
- Интервью переднего плана для проверки пропусков -- (6) Кэш браузера
- Начальное собеседование для проверки и заполнения вакансий — (7) XSS-атака и CSRF-атака
- Предварительное собеседование для проверки и заполнения вакансий -- (8) Переднее шифрование
- Предварительное собеседование для проверки и заполнения вакансий — (9) HTTP и HTTPS
- Предварительное собеседование для проверки и заполнения вакансий -- (10) Передняя аутентификация
- Начальное собеседование для проверки и заполнения вакансий — (11) Образец архитектуры программного обеспечения внешнего интерфейса MVC/MVP/MVVM
- Предварительное собеседование для проверки упущений и заполнения вакансий — (12) Весь процесс от ввода URL-адреса до просмотра страницы (включая три рукопожатия и четыре волны для подробного объяснения)
- Предварительное собеседование для проверки утечек и заполнения вакансий -- (13) Утечки памяти
- Предварительные собеседования для проверки и заполнения вакансий--(14) Алгоритмы и сортировка
- Предварительные собеседования для проверки и заполнения вакансий -- (15) Event Loop
Коллекция:
Предварительные собеседования для проверки пропусков и заполнения вакансий — индекс (набор из 120 000 слов)Содержит более дюжины других статей из серии, которые были написаны до сих пор.Последующие новые статьи с добавленной стоимостью больше не будут добавлять ссылки на каждую статью.Настоятельно рекомендуется ставить лайк и следить за коллекцией!!!!, спасибо!~
Последующий план обновления
Будет продолжать добавлять в будущемШаблоны проектирования,Фронтенд-инжиниринг,процесс проекта, развертывание, замкнутый цикл,Vue часто проверяет очки знанийДождитесь контента. Если вы считаете, что контент хорош, добро пожаловать, собирайте и подписывайтесь на меня! Спасибо!
Спросите инсайдера
В настоящее время я тоже готовлюсь к смене работы, надеюсь, вы и HR дамы порекомендуете надежную.УханьФронтальный пост! Электронная почта: bupabuku@foxmail.com. Спасибо!~
механизм сбора мусора
JavaScript имеет автоматический механизм сборки мусора(GC: GarbageCollecation), то есть среда выполнения отвечает за управление памятью, используемой во время выполнения кода. Разработчикам больше не нужно заботиться об использовании памяти, а выделение требуемой памяти и утилизация бесполезной памяти полностью управляются автоматически.
жизненный цикл памяти
Память, выделенная в среде JS, обычно имеет следующий жизненный цикл:
- Выделение памяти: когда мы объявляем переменные, функции, объекты и выполняем их, система автоматически выделяет для них память.
- Использование памяти: то есть чтение и запись памяти, то есть использование переменных, функций и т. д.
- Утилизация памяти: после использования память, которая больше не используется, автоматически перерабатывается механизмом сборки мусора.
Политика механизма сбора мусора
Алгоритм развертки пометки
Наиболее распространенной формой сборки мусора в JavaScript является пометка и очистка.
Этот алгоритм упрощает определение того, «не нужен ли объект больше», как «доступен ли объект».
Алгоритм предполагает создание объекта с именем root (в Javascript root — это глобальный объект). Сборщик мусора будетРегулярно начинать с корня(глобальный объект в JS) сканирует объект в памяти. Все объекты, к которым можно получить доступ из корня, по-прежнему необходимо использовать. Объекты, недоступные из корня, помечаются как неиспользуемые и будут переработаны позже.
Этот алгоритм можно разделить на два этапа: один — этап маркировки (mark), а другой — этап развертки (sweep).
- стадия маркировки, сборщик мусора будет проходить от корневого объекта. К каждому объекту, доступному из корневого объекта, добавляется идентификатор, поэтому объект помечается как достижимый.
- этап очистки, сборщик мусора будет линейно обходить память кучи от начала до конца.Если будет найден объект, который не помечен как достижимый объект, то память, занятая этим объектом, будет высвобождена, а пометка, изначально помеченная как достижимая объект будет очищен, так что перейдите к следующей операции сборки мусора.
На этапе маркировки к B можно получить доступ из корневого объекта 1, а к E можно получить доступ из B, тогда достижимыми объектами являются B и E. Точно так же достижимыми объектами являются F, G, J и K.
На этапе сбора все объекты, не отмеченные как доступные, собираются сборщиком мусора.
Когда начинается сбор мусора?
Как правило, при использовании алгоритма маркировки-развертки объекты, на которые нет ссылок, сразу не собираются. Вместо этого объекты мусора будут накапливаться до тех пор, пока память не будет исчерпана.Когда память будет исчерпана, программа будет приостановлена и начнется сборка мусора.
Добавлено: с 2012 года все современные браузеры используют алгоритм сборки мусора с отметкой и очисткой. Все улучшения алгоритма сборки мусора JavaScript основаны на улучшениях алгоритма пометки и очистки, а не самого алгоритма пометки и очистки и его упрощенного определения того, «не нужен ли объект больше».
Отметить недостатки алгоритма развертки
- Объекты, которые не могут быть запрошены из корневого объекта, будут очищены.
- После сборки мусора можно вызвать большиестепень фрагментации памяти, как показано на картинке выше, в памяти после сборки мусора есть три фрагмента памяти.Предполагая, что квадрат представляет 1 единицу памяти, если есть объект, который должен занимать 3 единицы памяти, это приведет к тому, что Мутатор будет приостановлено все время, и Collector продолжает пытаться выполнить сборку мусора, пока не закончится память.
алгоритм подсчета ссылок
Это самый простой алгоритм сборки мусора, ни один браузер больше не использует этот алгоритм.
Этот алгоритм упрощает определение «не нужен ли объект больше» как «объект не имеет других ссылок на него". Если ссылок на объект нет (ноль ссылок), объект будет утилизирован механизмом сборки мусора.
Смысл подсчета ссылок заключается в отслеживании количества ссылок на каждое значение. Когда переменная объявляется и ей присваивается значение ссылочного типа, количество ссылок на это значение равно 1. Если такое же значение присваивается другой переменной, количество ссылок на это значение увеличивается на 1. И наоборот, если переменная, содержащая ссылку на это значение, принимает другое значение, количество ссылок на это значение уменьшается на 1. Когда количество ссылок на это значение становится равным 0, это означает, что нет возможности получить доступ к этому значению, поэтому занимаемое им пространство памяти может быть восстановлено. Таким образом, при следующем запуске сборщика мусора он освободит память, занятую значениями с нулевой ссылкой.
Недостатки подсчета ссылок
Алгоритм имеет ограничение: он не может обрабатывать циклические ссылки. Если два объекта созданы и ссылаются друг на друга, образуется цикл. Они покидают область действия функции после вызова, поэтому они бесполезны и могут быть переработаны. Однако алгоритм подсчета ссылок учитывает, что все они имеют хотя бы одну ссылку друг на друга, поэтому собираться они не будут.
Алгоритм сборки мусора Chrome V8
Движок V8, используемый браузером Chrome, представляет собой стратегию переработки поколений. Это согласуется с идеей стратегии утилизации Java. Цель состоит в том, чтобы восстановить «область временных объектов», различая «временные» и «постоянные» объекты;Кайнозоймолодое поколение), меньшая переработка «постоянной области объекта» (старое поколениепостоянная генерация), уменьшая количество объектов, которые необходимо каждый раз проходить, тем самым уменьшая время, затрачиваемое на каждый сборщик мусора.
Лимит памяти V8
в узлеСуществует ограничение на объем памяти, которую может использовать javascript.
- Около 1,4 ГБ в 64-битной системе.
- Около 0,7 ГБ в 32-битной системе.
По умолчанию соответствует памяти поколений.
- Для 32-битных систем размер памяти нового поколения составляет 16 МБ, а размер памяти старого поколения — 700 МБ.
- В 64-разрядной системе размер памяти нового поколения составляет 32 МБ, а размер памяти старого поколения — 1,4 ГБ.
Новое поколение равномерно разделено на два равных пространства памяти, называемых полупространствами, каждое из которых имеет размер 8 МБ (32-разрядная версия) или 16 МБ (64-разрядная версия).
Это ограничение можно настроить, передав --max-old-space-size и --max-new-space-size при запуске узла, например:
node --max-old-space-size=1700 app.js //单位为MB
node --max-new-space-size=1024 app.js //单位为kb
Вышеупомянутые параметры вступают в силу при инициализации V8 и не могут быть изменены динамически после вступления в силу.
Причина для ограничения памяти:
Насчет того, почему V8 ограничивает размер кучи, причина поверхностная: V8 изначально разрабатывался для браузеров, и вряд ли встретится со сценариями, использующими много памяти. Глубокая причина: ограничение механизма сборки мусора V8. Официально, взяв в качестве примера 1,5 ГБ кучи памяти для сборки мусора, V8 требует более 50 миллисекунд для выполнения небольшой сборки мусора и даже более 1 секунды для выполнения неинкрементной сборки мусора. Это время, когда сборка мусора приводит к приостановке выполнения потока JS. При таком потреблении времени производительность и скорость отклика приложения резко падают.
Поколение GC для V8
Стратегия сборки мусора V8 в основном основана на механизме сборки мусора поколений. В современном алгоритме сборки мусора сбор мусора памяти разделяется на разные поколения в соответствии со временем выживания объекта, а затем к памяти разных поколений применяется более эффективный алгоритм.
Генерация памяти для V8:
В V8 память в основном делится на новое поколение и старое поколение.Память молодого поколения хранит объекты с коротким временем выживания.,Память старого поколения хранит объекты, которые живут долгое время или постоянно находятся в памяти.,Как показано ниже:
Общий размер кучи V8 — это пространство памяти, используемое молодым поколением, плюс пространство памяти старого поколения.
Алгоритм нового поколения V8 (Scavenge):
На основе генерации объекты в новом поколении в основном представляют собой мусор, собранный с помощью алгоритма Scavenge. В конкретной реализации Scavenge в основном используется алгоритм Чейни.
Алгоритм Чейни — это алгоритм сборки мусора, реализованный посредством репликации. Он делит память кучи на две части, и каждая часть пространства называется полупространством. Из двух полупространств только одно используется, а другое не используется.
Поскольку Scavenge копирует только уцелевшие объекты, и только малую часть уцелевших объектов в сценах с коротким жизненным циклом, онОтличная производительность в эффективности времени. Scavenge — типичный алгоритм, жертвующий пространством ради времени.Поэтому его нельзя применять ко всем сборкам мусора в больших масштабах. Однако можно обнаружить, что Scavenge очень подходит для применения в новом поколении, потому что жизненный цикл объектов в новом поколении короткий, что как раз подходит для этого алгоритма.
Повышение:
Фактическая используемая память кучи представляет собой сумму размера двух полупространств молодого поколения и размера памяти старого поколения. Когда объект выживает в нескольких копиях, он будет считаться долгоживущим объектом. Затем такие долгоживущие объекты переводятся в старое поколение и управляются с использованием нового алгоритма.Процесс перемещения объектов от молодого поколения к старому называется продвижением.
В простом процессе Очистки уцелевшие объекты в пространстве «Откуда» будут скопированы в пространство «В», а затем роли пространств «Откуда» и «В» будут заменены местами (это также называется переворачиванием). Но в условиях поколенческой сборки мусора,Живые объекты в пространстве From должны быть проверены перед копированием в пространство To. При определенных условиях объекты с длительным жизненным циклом необходимо перевести в старое поколение, то есть завершить продвижение объекта.
Условия акции:
Существует два основных условия для повышения уровня объекта: первый — прошел ли объект переработку очистки, а второй — коэффициент использования памяти в пространстве «Кому» превышает предел 25 %.
Причины установки лимита в 25%:
Когда это восстановление очистки будет завершено, пространство «Кому» станет пространством «Откуда», и следующее выделение памяти будет происходить в этом пространстве.Если соотношение слишком велико, это повлияет на последующее выделение памяти.После продвижения объекта он будет рассматриваться как объект с длительным жизненным циклом в пространстве старой генерации и будет обрабатываться новым алгоритмом рециркуляции.
Алгоритм старого поколения V8 (Mark-Sweep && Mark-Compact):
Для объектов старого поколения, поскольку уцелевшие объекты составляют большую долю, при использовании метода Scavenge возникают две проблемы: первая заключается в том, что уцелевших объектов много, и эффективность копирования уцелевших объектов будет очень низкой; другая проблема - это еще половина отходов, космическая проблема. С этой целью V8 в основном использует комбинацию Mark-Sweep и Mark-Compact для сборки мусора в старом поколении.
Mark-Sweep:
Mark-Sweep означает Mark Sweep, который делится на два этапа: Mark и Sweep. По сравнению с Scavenge, Mark-Sweep не делит пространство памяти пополам, поэтомуНет поведения, которое тратит впустую половину пространства. В отличие от Scavenge, который копирует живые объекты,Mark-Sweep проходит все объекты в куче на фазе маркировки и помечает живые объекты, а в последующей очистке, только очищает объекты, которые не отмечены.Как можно заметить,В Scavenge копируются только живые объекты, в то время как Mark-Sweep удаляет только мертвые объекты.Живые объекты занимают лишь небольшую часть в молодом поколении, а мертвые объекты занимают лишь небольшую часть в старом поколении, поэтому два метода переработки могут быть эффективно обработаны.
На рисунке ниже представлена схема маркировки Mark-Sweep в пространстве старого поколения, а черная часть отмечена как мертвый объект
Самая большая проблема Mark-Sweep:
После рекуляции отметки помещения пространство памяти появятся прерывистыми. Эта фрагментация памяти может вызвать проблемы для последующих ассигнований памяти, так как вероятно, чтоКогда нужно выделить большой объект, то все фрагментированное пространство не может завершить выделение, и сборка мусора будет запущена заранее, а эта сборка не нужна. (Обратите внимание на понимание этого предложения, не думайте о памяти как о жидкости. Это твердое тело, как разбросанный маджонг, который нужно разобрать - то есть Марк-Компакт, о котором речь пойдет позже)
Mark-Compact:
Для решения проблемы фрагментации памяти Mark-Sweep был предложен Mark-Compact. Mark-Compact — это значение отделки с маркировкой, которая разработана на основе Mark-Sweep. Разница в том, что после того, как объект помечен как мертвый,В процессе сортировки переместите живой объект в один конец, а после завершения перемещения непосредственно очистите память за границей.На следующем рисунке показана схема Mark-Compact после маркировки и перемещения уцелевших объектов: белая сетка — уцелевший объект, темная сетка — мертвый объект, а светлая сетка — полость, оставленная уцелевшим объектом после перемещения.
После завершения перемещения вы можете напрямую очистить область памяти за самым правым уцелевшим объектом, чтобы завершить восстановление.
Простое сравнение трех основных алгоритмов сборки мусора Mark-Sweep, Mark-Compact и Scavenge
| Алгоритм сбора | Mark-Sweep | Mark-Compact | Scavenge |
|---|---|---|---|
| скорость | Средняя | самый медленный | самый быстрый |
| пространство над головой | несколько (с фрагментами) | мало (без мусора) | Двойное пространство (без фрагментации) |
| перемещать ли объект | нет | да | да |
Из таблицы между Mark-Sweep и Mark-Compact, поскольку Mark-Compact необходимо перемещать объекты, скорость его выполнения не может быть очень высокой, поэтому с точки зрения компромиссов V8 в основном использует Mark-Sweep,Mark-Compact используется только тогда, когда недостаточно места для размещения объектов, продвигаемых из молодого поколения.
Инкрементная маркировка:
- Чтобы избежать несоответствий между логикой js-приложения и тем, что видит сборщик мусора,Все три основных алгоритма сборки мусора должны приостанавливать логику приложения., а затем возобновить выполнение логики приложения после выполнения сборки мусора. Такое поведение называется «остановить мир». В сборке мусора поколений V8 небольшая сборка мусора собирает только новое поколение.Поскольку новое поколение по умолчанию настроено на меньший размер, и обычно меньше выживших объектов, даже если это полная пауза, влияние невелико. Однако старое поколение V8, как правило, настроено крупнее и имеет больше выживших объектов.Пауза, вызванная маркировкой, очисткой и сортировкой полной сборки мусора (полная сборка мусора), будет ужасной, и ее нужно улучшать (PS: Если V8 Память кучи V8 составляет 1,5 ГБ, и для V8 требуется более 50 мс для выполнения небольшой сборки мусора, и даже для выполнения неинкрементной сборки мусора требуется более 1 секунды.).
- Чтобы сократить время паузы, вызванное сборкой мусора с полной кучей, V8 начинает с фазы маркировки и изменяет действие, которое изначально должно было быть приостановлено за один раз, на инкрементную маркировку, то естьОн разбит на множество маленьких «шагов».После выполнения каждого «шага» в течение короткого времени выполняется логика js-приложения, а поочередно выполняются сборка мусора и логика приложения, пока не завершится фаза разметки.
- После того, как V8 будет улучшен путем инкрементной маркировки, максимальное время паузы сборки мусора может быть уменьшено примерно до 1/6 от исходного.
- Позже в V8 были введены ленивая подметание и поэтапное уплотнение, что сделало действия по очистке и сортировке инкрементными. Также планируется ввести параллельную маркировку и параллельную очистку, чтобы еще больше использовать преимущества многоядерной производительности для сокращения времени на паузу.
Уменьшите влияние мусора и сборки на производительность:
В основном обратите внимание на следующие два момента:
- Создавайте как можно меньше сборок мусора, особенно сборок мусора с полной кучей. Мы в принципе не можем помочь в этой части, мы в основном полагаемся на собственный механизм оптимизации v8.
- Избегайте утечек памяти и позволяйте памяти освобождаться вовремя.Это то, на что нам нужно обратить внимание.Для получения дополнительной информации, пожалуйста, обратитесь к главе об утечке памяти этой серии, которая имеет очень подробное объяснение.
спасибо и ссылка
- Примечания к механизму сборки мусора JS
- Управление памятью MDN
- Механизм сборки мусора V8 и лимит памяти(Если вы хотите узнать о сборке мусора в узле или получить более полное представление)