Объекты создаются с использованием новой, но нет соответствующей операции удаления для переработки памяти, занятой объектом. Когда мы завершаем использование объекта, мы просто прекращаем ссылаться на этот объект: изменить нашу ссылку на то, чтобы указать на другой объект или на NULL; или вернуться из метода так, чтобы локальные переменные метода больше не существовали, чтобы ссылка на эти локальные переменные не указывала на какой -либо объект. Объекты, на которые больше не упоминаются, называются мусором. Процесс поиска и утилизации этих объектов называется сбором мусора o
Виртуальные машины Java используют сборку мусора, чтобы гарантировать, что указанные объекты будут сохранены в памяти, а также освобождают пространство для хранения, занятое объектами, которые недоступны через любую ссылку в коде выполнения. Это является сильной гарантией того, что если объект не переработана, если эталонная цепочка, начинающаяся с корневой ссылки (то есть, ссылки, которые могут быть непосредственно доступны в коде выполнения).
Короче говоря, когда мы не можем добраться до объекта из какого -либо исполняемого кода, пространство, которое он занимает, может быть переработано. Обратите внимание, что мы используем слово «Can», потому что уточнение памяти, определяется коллекционером мусора. Как правило, сборщик мусора будет работать только в том случае, если потребуется больше места для памяти или чтобы избежать переполнения памяти. Тем не менее, программа может выйти без переполнения памяти, или даже когда она не близка к переполнению памяти, поэтому она вообще не требует сбора мусора. Во всех методах, выполненных в настоящее время, если все переменные содержат ссылки на объект, и начиная с этих переменных, ссылки на этот объект не могут быть найдены во всех доменах или элементах массива вдоль эталонной цепи, затем мы говорим, что объект «недоступен».
Утилизация мусора означает, что нам никогда не приходится беспокоиться о висящих ссылках. В системах, где программисты могут напрямую контролировать, когда объекты удаляются, программисты могут удалять объекты, на которые другие объекты все еще ссылаются. Если программисты удаляют такие объекты, ссылки, которые все еще ссылаются на удаленные объекты, станут недействительными, потому что они относятся к тишине.
Система считает, что это является распределимым пространством памяти (но на самом деле пространство было выпущено). Система может выделить это распределяемое пространство на новые объекты, так что ссылки, изначально указывающие на пространство, на самом деле приводят к объектам, которые полностью отличаются от того, что они ожидали. В этом случае непредсказуемые бедствия могут возникнуть, когда в программе используются значения, хранящиеся в этом пространстве, и управляет ими как объекты, к которым они не принадлежат. Сбор мусора решает проблему подвешивания ссылок для нас, потому что все объекты, которые все еще упоминаются, не будут рассматриваться как сбор мусора, поэтому пространство, которое они занимают, не может быть освобождено. Сбор мусора также решает проблему случайного удаления одного и того же объекта несколько раз - эта проблема также может вызвать бедствия. Утилизация объектов мусора не требует нашего вмешательства, но утилизация мусора будет занимать определенное количество системных ресурсов. Создание и утилизация большого количества объектов может мешать критическим приложениям, поэтому при разработке таких систем мы должны тщательно справиться с количеством объектов, созданных, чтобы уменьшить количество мусора, которое нужно переработать.
Сбор мусора не гарантирует, что память всегда будет иметь место для создания новых объектов. Например, если мы продолжаем создавать объекты и размещать их в список, мы больше не можем создавать новые объекты, когда не хватает места для создания новых объектов, и нет никаких беззаботных объектов. Если мы сохраним вышеупомянутые ссылки на объекты, которые больше не нужны, то произойдет утечка памяти. Сбор мусора решает много (но не все) проблемы распределения памяти.
Взаимодействовать с коллекционером мусора
Хотя сам язык Java не имеет явного способа распоряжения обстоятельными объектами, мы все еще можем найти объекты, которые больше не используются, напрямую вызывая коллекционер мусора. Некоторые удобные методы в классе и системном классе выполнения позволяют нам вызвать сборщик мусора, запросить запуск всех финализаторов, которые будут выполнены, или просмотреть статус текущего памяти:
.public void GC Q: Этот метод просит виртуальную машину Java тратить объекты переработки энергии, которые больше не используются, чтобы она могла повторно использовать память, занятую этими объектами.
.public void runfinalization (): Этот метод просит виртуальную машину Java потратить энергию на запуск следующих финализаторов: объекты, которые, как было обнаружено, недоступно, но финализатор которого еще не выполнен.
«Public Long Freedom (): возвращает предполагаемое количество доступных байтов в системной памяти.
・ Общественная длинная общая память (): возвращает общее количество байтов в системной памяти.
.public long maxmemoryo: возвращает максимальное количество байтов системной памяти, доступных для виртуальной машины Java. Если операционная система не имеет ограничений на использование памяти на виртуальных машинах Java, Long. MAX-значение будет возвращено. В Java нет метода, чтобы установить максимальную память системы. Обычно виртуальные машины Java устанавливают это значение через командную строку или другие параметры конфигурации.
Чтобы вызвать приведенный выше метод, нам необходимо получить ссылку на текущий объект времени выполнения через статический метод выполнения. Системный класс поддерживает статические методы GC и RunFinalization, которые будут вызывать соответствующие методы на текущем объекте Runt-UTE; Другими словами, System.gc () эквивалентна среде выполнения.
При вызове метода runtime.gc () коллектор мусора может не освободить дополнительную память, потому что не может быть мусора для переработки, и не все коллекционеры мусора могут обнаружить утилизируемые объекты по требованию. Поэтому призыв к коллекционеру мусора может не иметь никакого эффекта. Тем не менее, вызов метода Runtime.gc () желателен перед созданием большого количества объектов, особенно в критических приложениях, где накладные расходы сбора мусора могут повлиять на него. Существует два потенциальных преимущества для его выполнения: во -первых, мы можем получить как можно больше памяти, прежде чем запустить приложение, а во -вторых, мы можем уменьшить возможность того, что сборщик мусора работает во время выполнения задач. Следующий метод активно выпускает все пространство, которое может быть выпущено во время выполнения:
public static vo recordful1gc () {runtime rt = runtime.getruntime (); long Isfree = rt.freememory (); долгое время; do {wasfree = isfree; rt.runfinalization (); rt.gc (); Isfree два Rt.freememory (); } while (isfree> wasfree); }Метод постоянно зацикливается, и значение Freememory продолжает увеличиваться, постоянно вызывая методы Runfinalization и GC. Когда объем свободной памяти больше не увеличивается, цикл метода заканчивается.
Обычно нам не нужно вызывать метод RunFinalization, потому что метод завершения завершается асинхронно коллекционером мусора. В некоторых случаях, например, когда ресурс, который может быть переработан методом завершения, будет исчерпан, будет полезен для обеспечения как можно большего количества завершений, вызывая финализацию. Но помните, что мы не можем гарантировать, что любой объект, ожидающий прекращения, использует этот ресурс, поэтому RunFinalization может не иметь никакого эффекта.
Метод FullGC кажется слишком радикальным для большинства приложений. В особых случаях, когда требуется сбор мусора, даже если не весь доступный мусор собирается одним вызовом методу System.gc, это подавляющее большинство из них. Следовательно, повторные вызовы снижают скорость выхода сбора мусора, и во многих системах эти повторные вызовы без выходных.