ну в принципе ссылка на B присутствует в A
значит сначала A потом B
но вот если
class B;
class C { protected B b; };
class A { protected B b; };
ситуация становится мрачной, на тему что и когда
может помочь
class B;
//singleton
class B_Holder { protected B b; };

class C { protected B_Holder b; };
class A { protected B_Holder b; };
но это уже игра в прокси,
становится тяжко

Для чего в приложении на жабе может понадобицца щёччик сцылок?

А если:
class B { protected Object Client; };
class A { protected B b; }; и Client это объект класса A?
Тогда, в принципе, невозможно определить, что удалять вначале, не зная логики приложения.

Это - одна из причин, почему в .NET введен интерфейс System.IDisposable { void Dispose(); }

В .NET Framework SDK Documentation, кстати, описано одно из возможных решений поставленной ниже задачи.

Да и, вообще, всегда рекомендуется делать явное освобождение внешних ресурсов, не дожидаясь запуска GC.

<origin> Не только временем, но и порядком. Предположим, у меня есть class B; class A { protected B b; };

И в деструкторе / finalize A мне надо иметь валидный b. Как я понимаю, сборщик мусора этого мне гарантировать не может. Согласитесь, что такая ситуация достаточно реалистична, особенно в сложных проектах? </origin>

Для чего в приложении на жабе может понадобицца щёччик сцылок?

>Это - одна из причин, почему в .NET введен интерфейс System.IDisposable { void Dispose(); }

А разве это что-то принципиально меняет, за исключением того, что в C# вместо try / finally я могу использовать using, причем весьма ограниченно?

>Да и, вообще, всегда рекомендуется делать явное освобождение внешних ресурсов, не дожидаясь запуска GC.
Вот и вернулись к Init / Dispose :)

Господа!

А вы в курсе, что нормальные GC не просто обходит счётчики ссылок, а ещё и по их деревьям ходит? Т.е. Объект считается мёртвым не тогда, когда счётчик ссылок равен нулю, а когда его нельзя достигнуть из корневого узла. Т.е. Если синглтон ссылается на самого себя и никто больше не содержит ссылок на него, то от умрёт, хотя он и будет ссылаться на самого себя (и счётчик его ссылок не будет равен нулю).

Для чего в приложении на жабе может понадобицца щёччик сцылок?

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

>Здорово, продолжай в том же духе - Петросяном станешь. Извини, что >сразу не въехал.

Продолжай из-за угла тявкать, авось за умного сканаешь ...

А в чём проблема. Зачем parent валидный child? В ОО (при правильной структуре) благодаря икапсуляции сущность которая занимает ресурс и должна его освобождать? Если parent открывает ресурс то в своём finalize он их должен закрыть, если же это делают child, то они. А вообще при умерщвлении дерева ссылок кторые не видны из корня, обход происходит от сверху к корню.

Прости меня, я больше не буду тяфкать, отвлекать тебя от творчества. Смело публикуй на ЛОРе свои произведения малого формата.

Для чего в приложении на жабе может понадобицца щёччик сцылок?

>В ОО (при правильной структуре) благодаря икапсуляции сущность которая занимает ресурс и должна его освобождать?

В идеале, наверное да. Но вот, положим, есть child - это сокет, в который при деинициализации parent должен записать что-то, или файл. Да мало-ли таких примеров может быть. Или вообще, это child, разделенный между несколькими parent'ами, и с точки зрения конкретного parent'а вообще неизвестно есть ли у этого child'а другие parent'ы или нет, но послать какое-то сообщение при деактивации parent'а надо. Как правильное ОО такие задачи решает? Или если в яве это не реализуется - это не ОО.

Для чего в приложении на жабе может понадобицца щёччик сцылок?

Еще
>А вообще при умерщвлении дерева ссылок кторые не видны из корня, обход происходит от сверху к корню
В общем случае, это не дерево, а направленный граф. Что считать верхом, что корнем при наличии циклов?

> А разве это что-то принципиально меняет, за исключением того, что в C# вместо try / finally я могу использовать using, причем весьма ограниченно

Еще раз пересмотрел доку :)

В общем, ситуация такая.

В .NET удаление объектов проходит в несколько фаз. Их количество зависит, например, от того, перекрывается ли метод Finalize() или не перекрывается. И как я понял, из самого метода Finalize() вполне можно ссылаться на другие объекты, поскольку они еще "существуют". Тогда ссылка на объект b из твоего примера будет валидной. Фактическое же удаление объектов из памяти будет происходить позже всех этих IDisposable, Finalize и деструкторов.

Что касается интерфейса IDisposable, то он предназначен для эффективного решения другой обсуждаемой здесь задачи: как удалять внешние (unmanaged) ресурсы, такие как COM-объекты.

К слову сказать, интерфейс IDisposable учитывается во время компиляции операторов foreach и using - так что, некоторая поддержка обеспечивается уже на уровне самой среды. Более того, многие стандартные классы, неявно использующие Win32, реализуют IDisposable.

Другими словами, есть хорошее решение в виде IDisposable, от которого глупо было бы отказываться :)

Для чего в приложении на жабе может понадобицца щёччик сцылок?

В общих чертах я знаю, как происходит финализация в Net :) Объекты подлежащие удалению и реализовавшие метод финализации ставятся в отдельную очередь и при следующем вызове сборщика мусора этот метод вызывается для всех объектов в очереди. Проблема, вроде, в том, что последовательность финализации все-равно не определена. Что толку с того, что объект есть, если он уже деинициализирован? Это может даже привести ко всяким неприятным ошибкам. И IDispose тут ни в чем не помогает. Хотя какое-то извратное решение там действительно было, но я не помню точно как...

> В .NET удаление объектов проходит в несколько фаз. Их количество зависит, например, от того, перекрывается ли метод Finalize() или не перекрывается. И как я понял, из самого метода Finalize() вполне можно ссылаться на другие объекты, поскольку они еще "существуют". Тогда ссылка на объект b из твоего примера будет валидной. Фактическое же удаление объектов из памяти будет происходить позже всех этих IDisposable, Finalize и деструкторов.

В Java тоже:
After the finalize method has been invoked for an object, no further action is taken until the Java virtual machine has again determined that there is no longer any means by which this object can be accessed by any thread that has not yet died, including possible actions by other objects or classes which are ready to be finalized, at which point the object may be discarded.

Там идет жесткое разделение между managed и unmanaged ресурсами.

Действительно, есть определенные пляски с перекрытием Finalize(), если текущим классом непосредственно используются внешние (unmanaged) ресурсы [ms-help://MS.NETFrameworkSDKv1.1/cpref/html/frlrfsystemidisposableclassdisposet opic.htm].

Если же класс работает только с managed объектами, то обычно достаточно ввести/перекрыть особый виртуальный метод "protected virtual void Dispose (bool disposing)", который полезен как раз для освобождения ресурсов во всех классах-предках и классах-наследниках, возможно задолго до того, как будет вызван Finalize() сборщиком мусора.

Т.о., четко разделяются два сценария:

1) идет явное особождение ресурсов через Dispose() - тогда одна обработка;

2) идет запоздалое освобождение из Finalize() от GC - тогда немного другая логика обработки.

Мне нравится, что эта фишка поддерживается на уровне самой среды.

>>Наверное, вы просто привыкли, что возврат нескольких (разнотипных)
>>значений из функции невозможен :-).

А почему не сделать так:

LinkedList result = new LinkedList();
result.add(new Integer(22));
result.add("test");
result.add(new GregorianCalendar());
return result;

?

Конечно, в яве сделано очень похоже, и там это появилось намного раньше :)

Более того, там реализован более мощный интерфейс для обработки "слабых" (weak, soft and phantom) ссылок по сравнению с более простым механизмом из .NET. Кажется, в последней есть только один тип слабых ссылок.

Вообще, судя по некоторым тестам, сборщик мусора явы посильнее будет, но ведь он и по-старше...

Re:

По поводу parent`ов, child`ов и ресурсов типа file, socket и др. Правильно сказал кто-то выше: "Тот объект который открывает ресурс его должен и закрывать". все child`ы не должны использовать этот ресурс напрямую, а только через parent, на то они и child`ы.
Если необходимо сложное управление ресурсом и многие пар-ры неопределены, то вся логика все равно должна реализовываться в parent`е. Да parent получится сложный если необходима нетривиальная логика управления, за то Вы будете полностью контролировать данный ресурс.

И прощай строгая типизация?

Такой ламерский вопрос.

Помню, были в Java "зелёные трэды". В 2.4.x и более ранних ядрах threads создавались с помощью процесса. В 2.6.x есть поддержка native threads. Использует ли Java native threads? Есть ли в этом случае ссылка по поводу улучшения производительности? Или всё-таки лучшая платформа для Java это Sun SPARC Solaris?

> >НЕФИГ ЭТО НУЖНО? > Как обычно - нет, значит и не нужно Как обычно давай еще обсудим проблему отсуствия asm {}

> Я думаю, что не все же работают со сферическим конем в вакууме...

ТЫ представь - многим повезло сопрягаться с мудацкими платформами по минимуму или вообще не сопрягаться.

> Как я понимаю, сборщик мусора этого мне гарантировать не может.

Чегоо? Иди учи матчасть.

Умри придурок!

public class Test { public static void main(String[] args) { A a = new A(); B b = new B(); a.b = b; b.a = a; a = null; b = null; System.gc(); System.gc(); System.gc(); System.gc(); } } class A { B b; protected void finalize() throws Throwable { System.out.println("A b=" + b); } } class B { A a; protected void finalize() throws Throwable { System.out.println("B a=" + a); } }

Output: B a=A@757aef A b=B@d9f9c3

> В общем случае, это не дерево, а направленный граф. Что считать верхом, что корнем при наличии циклов?

Entry point. Ну ты и неуч.

>> В общем случае, это не дерево, а направленный граф. Что считать верхом, что корнем при наличии циклов?

> Entry point. Ну ты и неуч.

А если уже успел заблудиться?

> Чегоо? Иди учи матчасть.
Про матчасть... ссылочку в студию на место в документации, где описан порядок вызова финализаторов. Пока что твои слова лишь заставляют усомниться что ты вообще понимаешь о чем речь.

Для чего в приложении на жабе может понадобицца щёччик сцылок?

>Чегоо? Иди учи матчасть
>Entry point. Ну ты и неуч.
А по существу можете чего-то сказать?

Для чего в приложении на жабе может понадобицца щёччик сцылок?

>все child`ы не должны использовать этот ресурс напрямую, а только через parent,
Погодите, а если child сам по себе ресурс?

> ро матчасть... ссылочку в студию на место в документации, где описан порядок вызова финализаторов.

The Java Virtual Machine imposes no ordering on finalize method calls. Finalizers may be called in any order, or even concurrently.

(C) JVM Concepts

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

> Погодите, а если child сам по себе ресурс?

Тогда цитата из java.io.FileOutputStream тебе поможет.

protected void finalize() throws IOException { if (fd != null) { if (fd == fd.out || fd == fd.err) { flush(); } else { close(); } } }

А посуществу: изучи то, о чем говоришь. По поводу счетчиков обрати внимание на java.lang.ref пакет.

Кстати System.gc() не гарантирует запуска сборщик мусора.

> Кстати System.gc() не гарантирует запуска сборщик мусора.

О - америку открыл. А 4 раза я его вызвал по твоему из любви к искусству?

Насколько я понимаю. Обычно происходит переодический вызов обычного GC, если ему не удаётся нормально расчистить кучу, то вызывается FullGC, который не только учитывает счётчик ссылок как в первом случае, но и обходит дерево ссылок, недоступные из Entry point куски графа и затем уничтожая их. Т.е. GC работает в нескольких режимах.

Для чего в приложении на жабе может понадобицца щёччик сцылок?

>А посуществу: изучи то, о чем говоришь.
Я-то как раз изучаю и задаю вопросы, которые у меня возникают по ходу изучения, а ты, извини, как баран уперся - твою любимую технологию обижают :( В общем, "ну ты и неуч" (c) твой

> > Кстати System.gc() не гарантирует запуска сборщик мусора. > О - америку открыл. А 4 раза я его вызвал по твоему из любви к > искусству?

Я понимаю, что не из любви к искуству, но и этого может оказаться недостаточно. Ты запусти java -verbose:gc и посмотрим вызвал ли он GC и какой. ПРосто GC или Full GC. Я не пытаюсь тебя оскорбить или не дай бог унизить и выставить тебя человеком незнающим темы разговора, просто я пытаюсь сказать, что не всё тут так однозначно. Поверь.

> вою любимую технологию обижают

А это не моя любимая технология. Просто ты выбрал не правильный тон "низзя написать ассемберную инструкци значит говно" и нарвался на соотвествующий ответ.

> что не всё тут так однозначно. Поверь

Все я прекрасно понимаю - я проиллюстрировал что ссылки при вызове finalize не dereferenced и все.

Для чего в приложении на жабе может понадобицца щёччик сцылок?

Я, в отличие, от тебя привел два конкретных примера, когда подсчет ссылок _может_ оказаться полезным даже в яве. Ты же в ответ ограничился оскорблениями. Я, конечно, понимаю и принимаю аргумент насчет правильного дизайна приложения, но ведь и в C++ при правильном дизайне приложения не возникает проблема утечек памяти - тогда о чем спор?

Да ладно вам. Неявный подсчёт ссылок, позволяет делать набор классов java.lang.ref; Грамотный человек и на Java и на С и на С# может писать грамотно.

Но вот что меня бесит в поклонниках .NET так это их жада оскорблять других людей. ПРиходят и говорят. Вот Java - говоно и то она не умеет и сё. Хотя сами толком не знают как ей пользоваться? Да и их C# для людйей знающих сильно напоминает Java с немного зменёнными ключевыми словами и некоторыми добавлеными плюшечками (нужными ли?). Что ж если Java такое полное Г, так много от неё в .NET? Никто не задумывался?

Для чего в приложении на жабе может понадобицца щёччик сцылок?

>Да ладно вам. Неявный подсчёт ссылок, позволяет делать набор классов java.lang.ref;
А можно небольшой пример? Или ссылку с примером как это делается?

>Но вот что меня бесит в поклонниках .NET так это их жада оскорблять других людей
Если это Вы про меня, то я как-раз не поклонник .нет, а вовсе даже наоборот: ява мне нравится практически по всем параметрам больше. Но вот, действительно, все мои знакомые ява-программисты постоянно используют Init / Release, более того, считают, что это правильно. Что мне казалось странно, так как наличие сборщика мусора должно приводить к обратному. Сейчас я понимаю, почему это так. В C++ вызов, по крайней мере Release можно автоматизировать с использованием "умных указателей" - это очень удобно и приводит к более понятному коду. Жаль, что в яве это сделать нельзя. С моей точки зрения, это потенциально может привести к проблемам с расширяемостью и сопровождением. Вот и все. И оскорбляли пока вроде только меня :(

2 Dmt
Приношу тебе извинения. Я не ооскорблял тебя. Да и адресовалось писмо вобщем-то не тебе, а так - крик души.
я вобщем-то тоже испоользую пттерн типа
try {
// Получить ресурс от менеджера ресурсов
} finally {
// вернуть ресурс за ненабоностью
}
И это я считаю более наглядным чем использование неявно тот же
патерн неявно. Это немного затмевает логику. Соглавен что
получается возможно не слишком коротко. Но в групповой разработке
всё должно бтыь однозначно и как можно меньше использовать неявных
возможностей. Иначе такой код будет сложно поддерживать.
Поэтому и есть мнение и достаточно аргументированное против
множественного наследования, перегрузки операторов и прочих
вещей - суть которых неявное (или не очевидное) выполение
всяческих хитрых плюшечек.

> Ты же в ответ ограничился оскорблениями

Это какими? послал RTFM? Мне тебя жаль.

Бесполезно. Ваши оппоненты уже "понимают философию Java и мыслят исключительно в терминах Java".

Для чего в приложении на жабе может понадобицца щёччик сцылок?

>Мне тебя жаль.
Пожалей себя лучше, читать научись сначала.

Насчет твоего Rtfm:

>protected void finalize() throws IOException { if (fd != null) { if (fd >== fd.out || fd == fd.err) { flush(); } else { close(); } } }

Замени flush на write и покури на тему целостности

>По поводу счетчиков обрати внимание на java.lang.ref пакет.
Приведи пример, мне вот кажется, что это к предмету обсуждения никаким боком не стоит.

С приветом :)

> Замени flush на write и покури на тему целостности

Ну так замени в своем "умном" указателе Release, на exece("format c:");

и кури на ту же тему той же целостности. Если надо лечить голову - то ее лечат в специальных местах.

>Ну так замени в своем "умном"

Эй, ты давай не крути, а покажи пример как можно с помощью java.lang.ref сделать в жабе аналог плюсовых smart pointer-ов. ( Серьезно - как у офигенного эксперта спрашиваю - научи-и-и-и-и-и-и ) И еще у тебя jdk какой версии?

Опишите пожалуйста функциональность умных указателей? А то я плюсов не знаю...

Опять-таки, приведи пример, _зачем_ в жабе может понадобицца смарт-пойнтер? Пример с ком-портом и щеччиком сцылок принимаецца - действительно подсчёт сцылок мог бы оказацца полезным, но это, имхо, не столь уж типичный случай.

> И это я считаю более наглядным чем использование неявно тот же патерн неявно. Это немного затмевает логику.

Не согласен - использование умных указателей позволяет избежать таких вот участков кода. Оно ничего не скрывает, просто освобождение происходит в деструкторе указателя. ИМХО это нагляднее чем try/finally (тем более, что в C++ нет такой конструкции). В java можно забыть поставить try/finally и при появляении исключения ресурс не будет освобожден - при использовании умных указателей это исключено, т.к. вообще можно запретить создание объектов с помощью new - только с использованием специальных статических функций класса, возвращающих умный указатель.

Умные указатели позволяют переложить эту работу с программитса на компилятор.