[Henry]: There are no places where the synchronized keyword can be used but the reentrant lock class cannot. The only exception I can think of is if you've got a system where part of the code (outside your control) is already designed to require external synchronization (sync blocks) for safe use. An example is found in
Collections.synchronizedList() and similar methods. "It is imperative that the user manually synchronize on the returned list when iterating over it." (Not to mention manually synchronizing for any other action involving two or more successive method calls which must not be disrupted in between calls, e.g. getting the first element if the size is not zero, or accessing the last element in the list.) My point is, replacing synchronization with a concurrent lock will not work here, since you can't alter the code in java.util.Collections (well, not without some very unusual hacking), That code uses sync locks internally, and expects external code to do the same when internal synchronization is not enough (as often happens for this API). External code cannot simply use concurrent util locks instead of sync locks and expect one type of lock to interact well with the other. They're like two separate, parallel systems - they provide similar functionality, but they aren't directly interchangeable at a low level. Once part of a program is designed to depend on sync blocks for safe access to a particular class, the rest of the program must follow suit when accessing that class. Likewise for java.util.concurrent locks.