А чего вы хотите добиться? Я имею ввиду, что возможно вы идете окружным путем, а решение проще и элегантней. Что касается того кода что вы привели, выполнить какой-то код, основываясь на параметре, то да, можно завести коллекцию, не обязательно ConcurrentHashMap, в цикле делать CAS, ожидая пока ячейка освободиться, и когда освободиться выполнить свой код, Только опять же иногда CAS намного хуже чем обычный Lock, если contention большой. Можете описать задачу конкретней?

Я так полагаю что это какое-то подобие кэша, который поддерживает работу с несколькими потоками? Тогда вам определенно надо скачать Java Concurrency in practice, там целая глава посвящена кэшам, и есть там хороший пример с Future и Computable

авторВо-вторых, что из себя представляет эта сущность? Если это объект внутри JVM, то синхронизируйтесь прям на нем. Если это строчка в базе данных, то захватывайте лок на этой строчке в БД (это происходит автоматически при update или delete).

Я тоже так думаю, может топикстартер чего-то недоговаривает?

OOsalivanshainsky,

Еще вариант


Зачем эта мутотень если уже 5 лет есть Lock?

BlazkowiczLock рекомедуют к использованию вместо wait/notify. Но мне любопытно на счет производительности. Lock устроен горзда сложнее с кучей вызовов методов.

Насчет производительности - многое зависит от имплементации JVM, но если брать HotSpot, то рекомендуют использовать synchronized в случае если с кодом работает в основном один поток, причем если синхронизация происходит все время по одному объекту(так как возможно применить так называемый biased locking), в данном случае это не наблюдается. Вариант когда с кодом работает один поток, но синхронизация по разным объектам и количество "столкновений на мониторе" невысоко, то оба подхода дают примерно одинаковый результат, так как оба работают на CASе, а вот выигрывать Lock начинает при большом столкновении, так как synch сразу раздувается до OS-level монитора, а Lock имплементирован так, что может адаптивно подстраиваится, и перейти на OS-level и обратно при определенных условиях. Все это более подробно описывается тут - http://www.javaspecialist.ru/2011/11/synchronized-vs-reentrantlock.html#more

BlazkowiczА ещё вопрос, все ведь строки на одном локе висят. Тогда если две разных строки в 2х потоках уже существуею, они ещё и с друг другом будут бодаться за lock?
И ещё вопрос к коду. Как отработает re-entrancy, если метод вызовется для той же строки, но в том же потоке?

Вот именно поэтому я и говорю, что надо использовать ReentrantLock, причем он должен быть не глобальным, а содержаться в Map




и лочить надо именно не глобальный лок, а тот что доступен по ключу-строке, тогда столкновений на разных строках на одном мониторе не будет, что значительно увеличит производительность, как вы и заметили.