[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-java-core-dlya-chego-nuzhen-sborshchik-musora":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":20,"progress":21,"seo":22},50,"dlya-chego-nuzhen-sborshchik-musora",2,"java-core","Java Core","☕","Для чего нужен сборщик мусора?","Сборщик мусора (Garbage Collector) должен делать всего две вещи:\n\n+ Находить мусор - неиспользуемые объекты. (Объект считается неиспользуемым, если ни одна из сущностей в коде, выполняемом в данный момент, не содержит ссылок на него, либо цепочка ссылок, которая могла бы связать объект с некоторой сущностью приложения, обрывается);\n+ Освобождать память от мусора.\n\nСуществует два подхода к обнаружению мусора:\n\n+ Reference counting;\n+ Tracing\n\n**Reference counting** (подсчёт ссылок). Суть этого подхода состоит в том, что каждый объект имеет счетчик. Счетчик хранит информацию о том, сколько ссылок указывает на объект. Когда ссылка уничтожается, счетчик уменьшается. Если значение счетчика равно нулю, - объект можно считать мусором. Главным минусом такого подхода является сложность обеспечения точности счетчика. Также при таком подходе сложно выявлять циклические зависимости (когда два объекта указывают друг на друга, но ни один живой объект на них не ссылается), что приводит к утечкам памяти.\n\nГлавная идея подхода **Tracing** (трассировка) состоит в утверждении, что живыми могут считаться только те объекты, до которых мы можем добраться из корневых точек (GC Root) и те объекты, которые доступны с живого объекта. Всё остальное - мусор.\n\nСуществует 4 типа корневых точки:\n\n+ Локальные переменные и параметры методов;\n+ Потоки;\n+ Статические переменные;\n+ Ссылки из JNI.\n\nСамое простое java приложение будет иметь корневые точки:\n\n+ Локальные переменные внутри `main()` метода и параметры `main()` метода;\n+ Поток который выполняет `main()`;\n+ Статические переменные класса, внутри которого находится `main()` метод.\n\nТаким образом, если мы представим все объекты и ссылки между ними как дерево, то нам нужно будет пройти с корневых узлов (точек) по всем рёбрам. При этом узлы, до которых мы сможем добраться - не мусор, все остальные - мусор. При таком подходе циклические зависимости легко выявляются. HotSpot VM использует именно такой подход.\n\n---\nДля очистки памяти от мусора существуют два основных метода:\n\n+ Copying collectors\n+ Mark-and-sweep\n\nПри **copying collectors** подходе память делится на две части «from-space» и «to-space», при этом сам принцип работы такой:\n\n+ Объекты создаются в «from-space»;\n+ Когда «from-space» заполняется, приложение приостанавливается;\n+ Запускается сборщик мусора. Находятся живые объекты в «from-space» и копируются в «to-space»;\n+ Когда все объекты скопированы «from-space» полностью очищается;\n+ «to-space» и «from-space» меняются местами.\n\nГлавный плюс такого подхода в том, что объекты плотно забивают память. Минусы подхода:\n\n1. Приложение должно быть остановлено на время, необходимое для полного прохождения цикла сборки мусора;\n2. В худшем случае (когда все объекты живые) «form-space» и «to-space» будут обязаны быть одинакового размера.\n\nАлгоритм работы **mark-and-sweep** можно описать так:\n\n+ Объекты создаются в памяти;\n+ В момент, когда нужно запустить сборщик мусора приложение приостанавливается;\n+ Сборщик проходится по дереву объектов, помечая живые объекты;\n+ Сборщик проходится по всей памяти, находя все не отмеченные куски памяти и сохраняя их в «free list»;\n+ Когда новые объекты начинают создаваться они создаются в памяти доступной во «free list».\n\nМинусы этого способа:\n\n1. Приложение не работает пока происходит сборка мусора;\n2. Время остановки напрямую зависит от размеров памяти и количества объектов;\n3. Если не использовать «compacting» память будет использоваться не эффективно.\n\nСборщики мусора HotSpot VM используют комбинированный подход **Generational Garbage Collection**, который позволяет использовать разные алгоритмы для разных этапов сборки мусора. Этот подход опирается на том, что:\n\n+ большинство создаваемых объектов быстро становятся мусором;\n+ существует мало связей между объектами, которые были созданы в прошлом и только что созданными объектами.","","junior",[15,16,17,18,19],"JVM","core","garbage-collector","GC","память",[],null,{"title":23,"description":24,"ogTitle":25,"ogDescription":26,"keywords":27,"schemaAnswer":33,"featuredSnippetReady":34},"Для чего нужен сборщик мусора (Garbage Collector) в Java — Gymterview","Сборщик мусора находит неиспользуемые объекты и освобождает память. Два подхода к обнаружению: Reference counting и Tracing (используется в HotSpot).","Зачем нужен Garbage Collector в Java?","GC находит мусор (объекты без ссылок) и освобождает память. HotSpot использует подход Tracing с корневыми точками (GC Roots).",[28,29,30,31,32],"сборщик мусора Java","Garbage Collector","GC Java","Reference counting","Tracing GC","Сборщик мусора (Garbage Collector) выполняет две задачи: находит мусор — неиспользуемые объекты, на которые нет ссылок, и освобождает занятую ими память. Существует два подхода к обнаружению мусора: Reference counting (подсчёт ссылок) и Tracing (трассировка от корневых точек GC Root). HotSpot VM использует подход Tracing. Для очистки применяются методы Copying collectors и Mark-and-sweep, а также их комбинация — Generational Garbage Collection.",true]