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

А почему нет?

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

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

Это бессмысленно. В поле объект хранится ссылка на объект в куче. Изменение этой ссылки никак не влияет на сам объект.

s/В поле объект/В поле объекта/

Если у меня есть объект и я создал ссылку на его поле

Каким образом?

AnyObject ob1 = new AnyObject(); InnerField ob2 = ob1.getInnerField();

Благодарю, разжевали все отлично!

Это ссылка на объект, который возвращается getInnerField, а не на поле.

Даже если объект 1 будет ссылаться на объект 2, а тот — на объект один, то GC с этим справится.

Правда, да?

И это конечно же описано в стандарте?

А если поле не объект, а примитивный тип, например, int?

А если поле не объект, а примитивный тип, например, int?

Тогда ты получаешь копию значения.

It's important to note that not just any strong reference will hold an object in memory. These must be references that chain from a garbage collection root. GC roots are a special class of variable that includes

Temporary variables on the stack (of any thread) Static variables (from any class) Special references from JNI native code

Ну я думаю это понятно и так, вы придираетесь.

И это конечно же описано в стандарте?

Да. Сбор мусора с кольцевыми зависимостями — это очень важный момент и всегда указывается в свойствах GC явно.

Для Java это так. Даже PHP в последних версиях и то научился закольцованный мусор чистить.

Ну я думаю это понятно и так

Если это понятно, непонятно, в чем был вопрос.

будет

Я спрашивал не про фичи конкретного GC, а про язык в целом.

Есть ли гарантия того, что каждый GC обязан чистить кольцевые зависимости?

Ну и как этот текст относится к жабке на телефоне LG?

Я спрашивал не про фичи конкретного GC, а про язык в целом.

Язык с GC в общем случае никак не связан. Зависит от конкретной реализации VM, а не языка. В JVM этот момент определён явно.

Есть ли гарантия того, что каждый GC обязан чистить кольцевые зависимости?

Нет, конечно. Я потому PHP в качестве примера и привёл. До версии 5.3 кольцевые ссылки не удаляются, после — удаляются.

Язык с GC в общем случае никак не связан.

Общий случай меня не интересует. Тема то про Java! Ну и про РНР туда же. У них своя песочница, имеют полное право делать, что хотят. Оно и без примера с РНР понятно, что есть разные реализации GC, у которых возможности очень различаются.

В JVM этот момент определён явно.

А это уже по теме. Только хотелось бы уточнить. Любой ли JVM обязан поддерживать циклические ссылки, или эта возможность отдается на откуп разработчикам конкретной реализации?

Любой ли JVM обязан поддерживать циклические ссылки

Полностью стандартный, насколько я знаю, да. Но кто сказал, что в Java JVM обязан быть стандартным? Java может, вообще, без JVM работать. Например, IKVM.

Но кто сказал, что в Java JVM обязан быть стандартным?

Стандартным может и не быть, а вот обеспечить некое поведение, которой полностью эквивалентно стандарту обязан. В противном случае получаем UB со всеми вытекающими.

Применительно к циклическим ссылкам в Java получается, что язык не гарантирует корректность работы программ с циклическими ссылками. Следовательно переносимости у Java програм нету )

язык не гарантирует корректность работы программ с циклическими ссылками

Ещё раз — ни один _язык_ этим не занимается. Это вопрос не языка, а среды исполнения.

Следовательно переносимости у Java програм нету )

может она и не 100%, но она есть, и её поболее, чем у тебя мозгов

На LG тоже циклы разруливает. Вообще на всех телефонах, которые я встречал, даже с самыми кривыми реализациями виртуальной машины и окружения, GC работал хорошо.

Применительно к циклическим ссылкам в Java получается, что язык не гарантирует корректность работы программ с циклическими ссылками.

Язык вообще ничего не гарантирует. Платформа — гарантирует, у нее спецификация есть как раз для переносимости.

Ещё раз — ни один _язык_ этим не занимается. Это вопрос не языка, а среды исполнения.

Какая красивая и правильная теория. Но что я получу на практике? А получу я программу, которая в зависимости от среды допускает утечку памяти.

Платформа — гарантирует, у нее спецификация есть как раз для переносимости.

Я ж не против, пусть платформа гарантирует. Только мне так никто и не ответил, является ли возможность работа с циклическими ссылками обязательной для GC JVM?

А получу я программу, которая в зависимости от среды допускает утечку памяти.

А где в доке по _языку_ написано, что _можно_ делать кольцевые ссылки? Не написано? Так какого хера...

А где в доке по _языку_ написано, что _можно_ делать кольцевые ссылки?

Это не аргумент, т к запрета тоже нет. Да и в доке сказано, что GC сам все освободит, когда данные станут ненужны. И, кстати, «хорош» язык, который позволяет писать такой небезопасный код ))

А где в доке по _языку_ написано, что _можно_ делать кольцевые ссылки? Не написано? Так какого хера...

Что такое «дока по языку» - JLS? Там и про сборку мусора нету, потому что это деталь реализации.

А получу я программу, которая в зависимости от среды допускает утечку памяти.

Да. И что?

Что такое «дока по языку» - JLS? Там и про сборку мусора нету

Немного есть:

12.6. Finalization of Class Instances

The class Object has a protected method called finalize; this method can be overridden by other classes. The particular definition of finalize that can be invoked for an object is called the finalizer of that object. Before the storage for an object is reclaimed by the garbage collector, the Java virtual machine will invoke the finalizer of that object.

В теории памяти неограниченно много, поэтому такие неинтересные мелочи, как освобождение памяти, не специфицируются. С++ в общем то тоже не обещает, что после delete что-то там освободиться, никто не мешает в вызове delete не делать ничего, и это не будет противоречить стандарту. Только на практике такой реализацией пользоваться вряд ли будут многие.

Да. И что?

Я внешний API не вызывал, пользовался базовыми средствами языка и получил такой сюрприз. Не хорошо как-то получается.

Я внешний API не вызывал, пользовался базовыми средствами языка и получил такой сюрприз

Почему «сюрприз»? Где сказано, что тебе вообще гарантирована сборка мусора? Цитата, которую ты привел, этого не гарантирует.

Нет, не является. Даже GC обязательным не является, в реалтаймовых реализациях так часто и делают.

Где сказано, что тебе вообще гарантирована сборка мусора?

До сегодняшнего дня я считал, что в java автоматическое управление памятью. Теперь я понял - его там нет, ни ручного, не автоматического.

Как оно только работает? )

Значит правильный ответ на вопрос ТС- ХЗ!

С++ в общем то тоже не обещает, что после delete что-то там освободиться

В C++ программу можешь собрать с тем delete, который тебе нужен. И никакое окружение тебе не помешает.

А в Java, сначала пишешь, на что-то надеешся, а потом мордой о суровую реальность!

В теории памяти неограниченно много, поэтому такие неинтересные мелочи, как освобождение памяти, не специфицируются.

Посмотрел на планшет перед собой. Java там уже есть, а памяти всего 512. 512 - это уже не ограничено много?

До сегодняшнего дня я считал, что в java автоматическое управление памятью. Теперь я понял - его там нет, ни ручного, не автоматического.

Ты снова понял неправильно.

А в Java, сначала пишешь, на что-то надеешся, а потом мордой о суровую реальность!

Суровая реальность такова, что память все реализации освобождают нормально. А те, которые не освобождают, используются теми, кто очень хорошо представляет, что происходит.

Посмотрел на планшет перед собой. Java там уже есть, а памяти всего 512. 512 - это уже не ограничено много?

Планшет это пошлая реальность, стандартоведы до такого не опускаются.

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

Чего ты добиваешься?

дык, имхо может быть и уничтожен, а поле не уничтожится.

Ну и как этот текст относится к жабке на телефоне LG?

какую жабку и на каком телефоне имеешь в виду? javaME или далвик на андроиде? как работает далвик спрашивай у гугла, тут на лоре 200 раз уже написали что Dalvik != Java

Да, будет. «Внешний» объект и «внутренний» обект - разные объекты, каждый со своим счетчиком ссылок.

[nastishka@home ~]$ cat test.java
class test {
    String name;
    test internal;
    test(String aname, test ainternal) { name = aname; internal = ainternal; }
    void dosomething() {}
    public void finalize() {
	System.out.println("test["+name+"] destroyed");
    }
    public static void main(String args[]) {
	test into = new test("InternalObject",null);
	test exto = new test("ExternalObject",null);
	exto.dosomething(); // I hate "unused"-warnings
	exto = null;
	System.gc();
	return;
    }
}
[nastishka@home ~]$ javac test.java
[nastishka@home ~]$ java test
test[ExternalObject] destroyed
[nastishka@home ~]$ 

Изначально я не знал ответа на вопрос, но мне ответили до Вас.

Вот, спасибо что написали за меня код)))