Как уничтожить объекты java?

Ну, я разработал приложение java, используя несколько отношений объектов, которые делают использование памяти слишком дорогим. У меня нет опыта управления памятью java, потому что дизайн приложения затрудняет уничтожение объектов и повторное использование ранее очищенного пространства. Например, я использую Обозреватель и шаблоны MVC.

Итак, теория говорит это..

объект получает право на сборку мусора или GC, если его нет достижимый из любых живых потоков или любой статической ссылки

другими словами, вы можете сказать, что объект получает право на сборку мусора, если все его ссылки равны нулю.

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

в соответствии с этим контекстом, как я могу иметь дело с уничтожением объекта, когда есть несколько ссылок на него? или как мне нужно управлять памятью, когда у вас есть сложные ссылки друг на друга?

7
garbage-collection java memory memory-management

5 ответов

Учет

В соответствии с этим контекстом, как я могу иметь дело с уничтожением объекта, когда есть кратные ссылки на него?

, убедившись, что эти ссылки больше не нужны.

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

локальные переменные, которые имеют дойдя до конца своей области, они будут иметь право на сборку мусора (а также их содержащиеся) объекты, если они не были" связаны " с чем-либо еще (добавлены в коллекцию, AC omposite и т. д...). Для объектов пользовательского интерфейса, с которыми действительно может быть трудно договориться с точки зрения графов объектов, убедитесь, что они правильно расположены или прочитали документацию, чтобы убедиться, что они будут естественно удалены.

Simplified View of Reference Counting in the JVM

" оставьте [GC] в покое!!"

или как мне нужно управлять памятью, когда у вас есть сложные ссылки друг на друга?

вы не можете "управлять" памятью. Вы можете просто управлять ссылками. Идея состоит в том, чтобы" серьезно " связать ваши связи с вашими объектами, просто не имея ссылок на них. Затем они живут в памяти, пока GC не уничтожит их.

не пытайтесь возиться с GC, чтобы заставить его делать вещи. Это довольно умный зверь, и пока ты можешь!--9-->попробовать для проинструктируйте его реагировать на некоторые запросы явно - он может игнорировать вас - это обычно плохая идея: не вызывайте GC явно, во избежание финализаторы и принудительное обнуление если вы не понимаете их последствия.

Примечание, чтобы ответить на ваш комментарий

просто обнуление a ссылка на объект, который был добавлен в несколько коллекций или композиты не будет делает его подходящим для сбора. Делая это,вы бы аннулировали только одну ссылку.

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

может быть, это звучит утомительно, но если вы подумайте об этом с языка, где вы вручную управляете памятью (C или C++, чтобы назвать самые очевидные ссылки 2), свободные и нулевые указатели на динамически выделенные объекты действительно уничтожат их, но вам все равно нужно будет удалить элемент из списков (или любых контейнеров), или они будут выглядеть как пустые ведра для нулевого указателя.

Более Дальнеишее Чтение

17

весь смысл сборки мусора java заключается в том, что вам ничего не нужно делать. Сбор мусора сделан для вас.

6

назначьте каждую ссылку, которую вы хотите собрать GC,null.

1

то, что вы могли бы сделать, это сделать один промежуточный класс. Например, если у вас есть экземпляр класса A, для которого у вас есть много ссылок, и вы хотите удалить его, но много ссылок затрудняет это, вы можете сделать следующее: Создать экземпляр класса B, который не содержит ничего, кроме ссылки на экземпляр класса A (например, какой-то прокси). Теперь у вас будет много ссылок на экземпляр класса B, но только одна ссылка на экземпляр класса A, который вы можете легко удалить и сборщик мусора будет собирать экземпляра класса А.

изображение показывает разницу при использовании прокси (экземпляр класса B): теперь только одна ссылка должна быть удалена.

enter image description here

1

по большей части, GC сделает это волшебство в свое время.

У вас может быть ситуация, когда, скажем, вид наблюдает модель, и вы хотите отказаться от вида, но сохранить модель. В этом случае вам нужно будет запомнить объекты обратного вызова наблюдателя и удалить их при удалении представления. Вам не обязательно иметь специальные поля для каждого наблюдателя - набор задач, которые отменяют регистрацию обратного вызова, будет прекрасным. Или, что более сложно, вы можете иметь слой переходного косвенность над моделью, которая расстегивается от базовой. Я предлагаю избегать странных вещей со слабыми ссылками того или иного рода.

в случае, если у вас могут быть финализаторы (или требуется какое-то слабое выселение карты), например, предположительно с java.ОУ.Кадр, вам может понадобиться слой косвенности между ресурсом и свиньей памяти, который может быть просто аннулирован.

0