Na detailech urcite zalezi. A na kontextu take. I kdyz JVM implementuje synchronizaci vzdy stejne, napr. pomoci instrukce Compare-And-Swap (CAS), je zde prostor pro optimalizaci: JVM si napr. muze vsimnout, ze zamek je pouzivan jen jednim vlaknem a zcela jej eliminovat. Nebo muze sdruzit vice kritickych sekci do jedne a tim usetrit jednu instrukci CAS na ukor toho, ze vlakno bude drzet zamek dele. Nebo v okamziku, kdy chce vlakno zamek a zamek neni k dispozici, bude vlakno chvilku cekat aktivne (tzv. spinning), misto toho, aby doslo k prepnuti kontextu (toto je vyhodne, protoze prepnuti kontextu je nakladna operace). [Takze pokud vas ve skole ucili, ze lepsi je pasivni cekani, tak tady najdete vzacnou vyjimku.] Tyto optimalizace umela JVM pouze pro zamky synchronized, protoze o zamcich ReentrantLock nevi. Mozna, ze uz se to ale zmenilo a optimalizace se delaji i pro ReentrantLock.
Nicmene i presto vsechno si myslim, ze programator by mel uprednostnovat java.util.concurrent. Proc? Vyborne to napsal Joshua Bloch v Effective Java na strane 277: "In summary, using wait and notify directly is like programming in 'concurrency assembly language', as compared to the higher-level language provided by java.util.concurrent. There is seldom, if ever, a reason to use wait and notify in new code." Kdyz k tomu pridame to, ze michani java.util.concurrent a synchronized neni dobry napad, zbyva pro pouziti synchronized opravdu velmi maly prostor. Z. -- Zdenek Tronicek FIT CTU in Prague Roman Pichlík napsal(a): >> ReentrantLock je nejen intuitivni a mocnejsi nez synchronized (ma napr. fair policy), ale je take rychlejsi. > to neni tak uplne pravda, velky rozdil je mezi Javou 5 a Javou 6. V sestce uz je ten rozdil mensi. Zalezi na strasne moc detailech, jestli je ten lock fair atd. Opet je to o nejakem micro benchamrku jehoz vysledky by se mely posuzovat prave a jenom v kontextu toho micro benchmarku. Jinak k problematice synchornized vs. reentrantlock viz zminovana Java Concurrency in practice kapitola 13.4. Takze bych volil podle pripadu uziti :-). > -- > S pozdravem Roman "Dagi" Pichlik > /* http://dagblog.cz/ Blog pro kodery */