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

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

A>>https://github.com/android/platform_dalvik/blob/master/vm/oo/Object.h
D>А, ну так вы уточняйте, что говорите про Андроид В Java информация о мониторе хранится в mark word, потенциально вместе с кэшированным identity hash code, и служебной информацией GC.

В данном случае у меня, видимо, устаревшая информация — в Oracle/Open JDK все сложнее, там куча оптимизаций поверх этих блокировок — типа переписывания части заголовка объекта при блокировки

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

D>Ну на не-final поляк синхронизироваться то как раз абсолютно нормально.
Почему?

D>А вот возможность синхронизации на некоторых классах java.* может сбить с толку некоторых новичков в многопоточности, да.
Даже на классах своего проекта. Если они публичные, да ещё и используются слишком интенсивно, то шанс выхватить косяк аналогичный.

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

H_C>Кто-нибудь знает истинную причину почему разработчики языка не ввели отдельный объкт монитор, а объеденили его с Object?

Не совсем по теме, но наверняка будет кому-то интересно: http://msmvps.com/blogs/jon_skeet/archive/2008/12/05/redesigning-system-object-java-lang-object.aspx — Скит рассуждает о наличии слишком обобщённых методов в Java:java.lang.Object, так и в .NET:System.Object, который, к сожалению, повторил те же ошибки.

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

H>Не совсем по теме, но наверняка будет кому-то интересно: http://msmvps.com/blogs/jon_skeet/archive/2008/12/05/redesigning-system-object-java-lang-object.aspx — Скит рассуждает о наличии слишком обобщённых методов в Java:java.lang.Object, так и в .NET:System.Object, который, к сожалению, повторил те же ошибки.
Очень по теме. Полностью повторяет моё мнение высказаное выше.

Monitors and threading

This is possibly my biggest gripe. The fact that every object has a monitor associated with it was a mistake in Java, and was unfortunately copied in .NET. This promotes the bad practice of locking on "this" and on types — both of which are typically publicly accessible references. I believe that unless a reference is exposed explicitly for the purpose of locking (like ICollection.SyncRoot) then you should avoid locking on any reference which other code knows about. I typically have a private read-only variable for locking purposes. If you're following these guidelines, it makes no sense to be able to lock on absolutely any reference — it would be better to make the Monitor class instantiable, and make Wait/Pulse/PulseAll instance members. (In Java this would mean creating a new class and moving Object.wait/notify/notifyAll members to that class.)