Содержит ли класс ссылки на свои объекты поля?

Question

Я немного запутался в аспекте GC, когда дело доходит до переменных экземпляра, особенно полей.

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

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

Итак, каковы здесь факты?

---

Уточнение для "полевых объектов" (как указано в комментариях)

• Под полевыми объектами я подразумеваю полевые члены объекта, которые сами являются объектами

---

Редактировать 2: немного более подробно

Итак, вы видите, что потоки - это исполнительные блоки, имеющие представление в памяти через экземпляр объекта Thread. Любое выполнение кода, происходящее где-либо, происходит в каком-то потоке.

Как бы это произошло?

Хорошо, через выполнение некоторого кода в методе. Что бы это сделало этот объект создан?

• Локальная переменная

И это сделало бы его корнем GC.

Кстати, для вызова метода есть стек для этого конкретного вызова, и это то, о чем я говорил здесь.

Answer 1

Это не так просто, как сказал @ louis-wasserman - "Да, естественно" или, если на то пошло, не естественно .. (?)

Я исследовал еще несколько вопросов и нашел ответ на вопрос ... где вы, вероятно, ожидаете этого - Спецификация языка Java

2,7. Представление объектов

Виртуальная машина Java не требует какого-либо конкретного внутреннего структура для объектов.

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

Да, это решает вопрос. Несмотря на то, что JLS не требует внутренней структуры java.lang.Object, вполне вероятно, что можно использовать структуру, аналогичную JVM Oracle.

Это имеет большее значение, как вы могли подумать. Представьте себе очень тяжелый объект, содержащий один очень громоздкий объект поля члена Хммм ... а Bitmap возможно. Растровое изображение размером 10 МБ, а другой объект просто содержит заголовок изображения:

bulky_object = {растровое изображение, заголовок}

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

void someMethod(){

        // Outer block of the method
        bitmap_ref;

        // Nested block starts
        {
            some_object = new some_object();
            // Hold a ref to the bitmap
            bitmap_ref = some_object.bitmap;
        }
        // Nested block has ended. some_object is eligible for GC and is not accessible as a GC root
        // anymore

        // bitmap_ref shall remain available alive and well here as we are holding a ref to it
        // Also, some_object garbage collection may have happened leaving bitmap_ref alive
    }

Здесь может показаться утечка объекта.