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




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