Когда сборка "мусора" Java освобождает выделение памяти?

Обратите внимание, что даже вызов System.gc() не гарантирует, что JVM сделает это немедленно.

System.gc() - это просто запрос, и нет никакой гарантии, что он будет выполнен немедленно.

На самом деле объект не называется FOO. FOO - это имя переменной, не являющейся объектом; переменная содержит ссылку на объект. Может быть несколько разных переменных, содержащих ссылки на один и тот же объект.

Сборщик мусора работает, автоматически обнаруживая недоступные объекты: это объекты, которые приложение больше не может использовать, потому что оно безвозвратно забыло, где они находятся (приложение может получить доступ к любому объекту, на который у него есть ссылка to, включая ссылки, хранящиеся в field, в объектах, к которым он имеет доступ, и т. д.).

Когда вы устанавливаете FOO = null , предполагая, что FOO содержал в этот момент последнюю доступную ссылку на объект, тогда память немедленно освобождается , в следующем смысле: в тот самый такт, в котором null установлен в FOO , объект становится недоступным. Таким образом, сборщик мусора заметит этот недостижимый объект и освободит соответствующий блок памяти; то есть сборщик мусора сделает это в следующий раз, когда его не удастся запустить. Конечно, фактические биты, составляющие объект, могут немного задерживаться в памяти; но этот блок, тем не менее, «свободен», поскольку распределитель памяти автоматически запускает сборщик мусора, когда свободной памяти мало. С точки зрения приложения, объект практически мертв, и соответствующая память свободна, поскольку эта память будет повторно использована в следующий раз, когда она понадобится приложению. Все происходит автоматически.

С операционной системой все немного сложнее. Если недоступный объект представляет собой свободную память с точки зрения приложения, с точки зрения ОС он все равно остается блоком ОЗУ, выделенным для запущенного процесса. Этот блок ОЗУ может быть возвращен ОС только тогда, когда сборщик мусора (который на уровне ОС является частью процесса) действительно работает, замечает, что объект недоступен, и снисходительно возвращает блок обратно в ОС. .Когда GC работает, сильно зависит от технологии GC и того, как приложение распределяет объекты; Кроме того, некоторые сборщики мусора вообще никогда не вернут блок ОС (сборщик мусора знает, что блок, который он освобождает, распределитель памяти будет повторно использовать его по желанию, но не другие процессы).

System.gc () - это подсказка для виртуальной машины, поэтому теперь она запускает сборщик мусора. Формально это всего лишь подсказка, и виртуальная машина может ее игнорировать. На практике он запускает сборщик мусора, если только виртуальной машине не было дано указание не подчиняться таким командам (с JVM Sun это зависит от конкретного флага командной строки). Даже если сборщик мусора работает, он не обязательно возвращает память операционной системе. System.gc () не очень полезен.

Сборщик мусора освободит память после того, как вы «уничтожите» ссылку. i.3 Установка нулевой ссылки на объект. Вы можете использовать опцию принудительной сборки мусора, но вы должны использовать ее с осторожностью. Сборщик мусора разработан для использования оптимизированного расписания, поэтому вызов System.gc () может испортить рифму и, возможно, снизить производительность из-за ненужного переключения задач.

В качестве альтернативы вы можете подумать о способе, который позволит вам не загружать большие объемы данных в память. Если бы вы могли добиться этого, улучшив свой код, это было бы намного лучше.

Нет гарантии, что JVM сделает это сразу, вы можете попытаться сделать это принудительно, используя System.gc()

Установка foo = null; не означает, что foo будет немедленно удален сборщиком мусора. Вместо этого он будет собран при следующем запуске GC, если это возможно. Когда foo собирается, любые объекты, для которых он содержит единственную ссылку, также будут иметь право на сбор и, следовательно, будут собраны.