Народ поделитесь, пожалуйста, опытом. Назовите один-два лучших по вашему мнению вопроса, которые когда либо попадались вам на интервью (по java разумеется)? Вопросы, об устройстве hashmap'а, специфики имплементации класса String, чем отличается interface от class'а, базовое ООП -- всего этого не надо, будем считать это базовыми вопросами. В этом топике только интересные вопросы.

"Что вам больше всего не нравится в джава?"

на каком объекте происходит синхронизация статического метода
знаю ли я функциональное программирование (спросили на собеседование по java)

как серелиазовать несереализуемое

Назовите механическое воплощение преобразования стека в очередь - ответ был автомат Калашникова  Позабавило.

"Как производительность synchronized в хотспоте зависит от реализации hashCode в мониторе?"

И каков ответ?

Собственно блокировка на synchronized может реально принимать три формы: 
- Biased: На монитор записывается идентификатор потока один раз при помощи CAS и затем после выполнения критических секций только проверяется, что он еще там, если же нет (то бишь состязание за ресурс имеет место быть), то блокировка сваливается в lighweight или даже fat
- Lightweight: CAS на входе и выходе для привязки монитора к потоку только на время критической секции
- Fat: использование нативного мьютекса операционнной системы

А вот чего я не знал, когда отвечал, так это того, куда для biased записывается идентификатор потока. Он записывается в заголовок объекта на место, в котором хранится нативный хэшкод. И если hashCode() не переопределен, то значение нативного хэшкода в заголовке перетирать нельзя и biased вообще не будет использоваться.

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

Biased Locking in HotSpot
Т.е. даже имплементация hashCode не гарантирует что biased locking будет использоваться. Плюс статья довольно старая (2006 год), возможно в 7-ке уже это исправлено. А то получается, что синхронизация на Object будет медленней, например тот же Swing синхронизируется на Object.

Разве я говорил про гарантии его использования?  Речь о том, что без хэшкода biased точно не будет. Впрочем на новых процах CAS дешевеет помаленьку, так что это софтверное решение хардверной проблемы дорогого CAS'a должно скоро стать историей.


Swing - однопоточный toolkit. Большинство его компонент не thread safe и синхронизации никакой не имеют, то есть для Swing это обсуждение вряд ли актуально. Кроме того, у меня сильное подозрение, что его синхронизация писалась тогда, когда biased locking'а и в помине еще не было.
Не стали же, например, JAX-RPC переписывать под стандартный JABX-маппинг, так и оставили свой велосипед.

Посмотри как работает invalidate.

Посмотрел, оказывается тяжелое наследие awt никуда не делось. Был неправ, спасибо.

Но вот чего я не понимаю, так это синхронизации на Object в этом коде. Равно как и вот этих фокусов:

Ну я так понимаю, что это просто выделенный класс/объект для синхронизации, который виден только внутри класса и нигде не референсится наружу. Этакая защита от глупых deadlock'ов (в особенности из-за синхронизировации на this)

Это сообщение отредактировал(а) Royan - 27.6.2012, 04:28

Я бы тоже так подумал, если бы там был модификатор private. А так оно открыто потомкам и в пределах пакета, что не сильно похоже на спрятанный мьютектс.

package private потомкам не доступен, а учитывая что в пакаджи java и javax ты так просто классы не загрузишь, то спрятан он достаточно надежно.
А вот зачем нужен специальный класс я не понимаю. Если я как-то получу ссылку на этот LOCK (например через рефлексию вытащу) я могу спокойно захватывать на нем монитор, даже если класс объекта мне не доступен.