The use of synchronized methods or statements provides access to the implicit monitor lock associated with every object, but forces all lock acquisition and release to occur in a block-structured way: when multiple locks are acquired they must be released in the opposite order, and all locks must be released in the same lexical scope in which they were acquired. They allow more flexible structuring, may have quite different properties, and may support multiple associated Condition objects. Lock implementations provide more extensive locking operations than can be obtained using synchronized methods and statements. I think the JavaDoc does a good job of describing the distinction between Lock and synchronized (the emphasis is mine): But using this higher level constructs requires more explicit and careful management in the code. Its these more complex scenarios that the concurrent package was created to help address. In a nutshell, the simple model and scope-oriented nature of synchronized helps protect me from bugs in my code, but those same advantages are sometimes hindrances in more complex scenarios.

I don't think one is really 'better' than the other, but rather each is a better fit for different problems.

However, my old claw hammer still sees its share of use. Several of those awkward situations became much simpler once I added more tools to my toolbox: a rubber mallet, a ball-peen hammer, a prybar, and some nail punches. I could do most everything I needed with my old claw hammer (the synchronized keyword), but it was awkward to use in some situations.

I've found that Lock and Condition (and other new concurrent classes) are just more tools for the toolbox. I am wondering which one of these is better in practice and why?

Android synchronizacja