Коллеги, помогите вспомнить один термин. Дано:


Этот код вызывается с нескольких потоков. И если вы посмотрите на аутпут этого кода, то увидите странную картину, когда один и тот же поток может последовательно входить в synchonized секцию сотни и тысячи раз, не передавая контроль другим потокам. Starvation налицо.

Стал я думать, в чем может быть причина.
1) Понятно, что synchornized не fair, никто никаких гарантий не дает. Но не до такого же маразма, что один поток может напрочь подавить все остальные. Не катит.
2) Есть такая штука, как lock coarsening. Может быть JIT раздвинул границы synchronized за пределы цикла while? Нет, то же не катит. Во-первых, JIT бы это просек не сразу, и сначала я скорее всего увидел бы нормальное переключение потоков. Во-вторых, переключения все таки иногда происходят. Наконец, волшебная опция -XX:-EliminateLocks не помогает.
3) Наконец, я вспомнил, что на какой-то презентации из JUG парни из Оракла (то ли Шипилев, то ли Иванов - не помню) рассказывали, что на ХотСпоте есть такая фигня, что если тред отпускает монитор и почти сразу же пытается снова его захватить, то этот тред оказывается в приоритете относительно остальных ждущих, дабы сэкономить на cas-ах.

И они как-то называли эту технику, каким-то термином. А я не помню его, потому и не могу загуглить деталей. Может быть кто-нибудь в курсе, как по научному называется эта чертовщина? Уж ооочень лень пересматривать эти многочасовые презенташки.

Не, biased в моем случае ни при чем, я их и трейсил, и отключал - ноль эффекта. Хотя это было понятно с самого начала, ибо контеншн есть.

Собственно, ответ мне более-менее понятен.

Реальной задачи под эту проблему нет, я просто делал пример для тренинга по многопоточности и наткнулся на эту хрень.

Кстати, я тут в одной холиварной теме просил народ написать мне striped-lock. Моя решение выглядело вот так:
То есть у нас один экземпляр хэндлера, и многие треды вызывают на нем process(E event). Если !event1.equals(event2) то они должны выполняться в параллель, иначе - последовательно.
Так вот, бенчмарки с одним единственным событием показывали, что это решение так же страдает от starvation, хотя и не так выражено. Здесь я до сути пока не докопался. Вероятнее всего, где в методе unlock() собака порылась аналогичным образом, как это происходит в начале топика.

Usman"Greedy" threads.Нет! Нашел!!! Barging ! Monitor barging !
И знаете, как я это нашел? Пишу я, значит, очередной пример для тренинга - один распространенный паттерн на основе ReadWriteLock. Много потоков делают readLock(). tryLock() , один поток делает writeLock.lock(). И тут я вижу, что writeLock у меня уходит в старвейшн - не пускают его ридеры. Я такой немного охереваю - ведь я всегда думал, что ожидающий врайтер должен брать приоритет над ридерами, это логично! И я много раз на это полагался. А тут бац - и не работает.
Ну окей, думаю, дай попробую выставить fair = true. Пробую - нифига, все по старому, ридеры полностью подавили врайтера.
Начинаю читать доку по tryLock(), и вижу, там заветное слово - barging. То есть семантика tryLock() такова, что плевал он на врайтеров, плевал он fairness, если может захватить лок - захватит. А вот tryLock(long, TimeUnit) - уже работает нормально.

ААА! Как я мог не знать этого! ПИПЕЦ! Пишу тренинги для вас, а в итоге сам учусь Круто.

maxkariMove,

У вас пример интересный. Он еще показывает различные "уровни" синхронизации в JVM. На семерке/восьмерке первые 5 тысяч строк выводятся достаточно случайно. Там еще работает spin lock. К концу пятой тысячи JVM этот бардак надоедает и она переходит на более сложную синхронизацию (с использованием OS-зависимых операций). Потоки перестают крутить циклы и встают в очередь. А там уже как раз из-за monitor barging текущий поток имеет приоритет при следующем захвате монитора. На однопроцессорной системе он просто выполняется дальше, на многопроцессорной - другие потоки не успевают запуститься до следующего захвата монитора.Очень сомневаюсь, что там есть biased locking, про который вы говорите. Во-первых, там есть контеншн. Во-вторых, biased locking изначально отключен, он включается только после некоторого прогрева JVM. Попробуйте сделать следующее:
1) Отключите биасы: -XX:-UseBiasedLocking , и посмотрите на результаты
2) Включите биасы так, чтобы они работали с самого начала: -XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0 -XX:+TraceBiasedLocking -XX:+TraceMonitorInflation
Я думаю, что у вас ничего не изменится.

Возможно, там какой-то замут со спинингом на обычных мониторах (-XX:+UseSpinning и связанные с ним ключики)