Здравствуйте, Shmj, Вы писали:

S>Ну на счет квалификации — если нет встроенного механизма dispose — это не значит что теперь ресурсы станут бесконечными и вам не нужно будет об этом беспокоиться.

А это из опыта C#.

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

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

Поэтому, для чувствительных к освобождению ресурсов объектов рулит или своевременная финализация, или никакая.

Плюс, для ресурсоёмких shared-объектов иерархия владения должна быть только однонаправленной, тут хорошо работает ref-counting, не зря есть объекты InspectorReferenceData, которые обслуживают этот сценарий (в несколько строк ты можешь нарисовать свои хелперы для аналогичного).

Ну и, для отложенной финализации есть классы Finalizer и NativeFinalizer, которые, в отличие от C#, надо дёргать явно, т.е. в очередь финализации попадает не каждый объект.

Тут убивается сразу два зайца:
— явное задействование механизма подразумевает, что программер продумал схему управления ресурсами для целевых объектов, т.е. что отложенная финализация для целевых ресурсов допустима;
— в очередь финализации ставятся не все объекты подряд, а лишь единичные, что делает сборку мусора резко дешевле, чем в том же C#.

Плюс еще есть WeakReference в языке, а самое главное — миксины!

Миксины позволяют реализовать различные политики управления ресурсами лишь однажды (в неких своих миниатюрных хелперах, в т.ч. которые refcount), а затем использовать их в произвольных объектах.

В C#/Джаве такой трюк невозможен, опять же.