如果只是锁定一个对象，我更喜欢使用synchronized

例子:

Lock.acquire();
doSomethingNifty(); // Throws a NPE!
Lock.release(); // Oh noes, we never release the lock!

你必须显式地在所有地方执行try{} finally{}。

而对于synchronized，它非常清楚，不可能出错:

synchronized(myObject) {
    doSomethingNifty();
}

也就是说，对于更复杂的事情，锁可能更有用，因为你无法以如此干净的方式获取和释放。老实说，我更倾向于在一开始就避免使用裸锁，而只是使用更复杂的并发控制，如CyclicBarrier或LinkedBlockingQueue，如果它们满足您的需求的话。

我从来没有使用wait()或notify()的理由，但可能有一些好的理由。

我想在Bert F答案的基础上再补充一些东西。

锁支持用于更细粒度锁控制的各种方法，这些方法比隐式监控器(同步锁)更具表现力。

Lock提供对共享资源的独占访问:一次只有一个线程可以获得锁，并且对共享资源的所有访问都要求首先获得锁。但是，有些锁可能允许对共享资源的并发访问，例如ReadWriteLock的读锁。

从文档页面来看，锁定相对于同步的优势

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 Lock implementations provide additional functionality over the use of synchronized methods and statements by providing a non-blocking attempt to acquire a lock (tryLock()), an attempt to acquire the lock that can be interrupted (lockInterruptibly(), and an attempt to acquire the lock that can timeout (tryLock(long, TimeUnit)). A Lock class can also provide behavior and semantics that is quite different from that of the implicit monitor lock, such as guaranteed ordering, non-reentrant usage, or deadlock detection

ReentrantLock:简单来说，根据我的理解，ReentrantLock允许一个对象从一个临界区重新进入到另一个临界区。由于您已经锁定进入一个临界区，您可以使用当前锁定进入同一对象的其他临界区。

ReentrantLock键的特性如本文所述

能够可中断地锁定。 能力超时，而等待锁定。 创造公平锁的权力。 API来获取等待锁的线程列表。 灵活地尝试锁定而不阻塞。

你可以使用ReentrantReadWriteLock。ReadLock ReentrantReadWriteLock。WriteLock以进一步获得对读写操作的粒度锁的控制。

除了这三个reentrantlock之外，java 8还提供了另外一个Lock

StampedLock:

Java 8附带了一种名为StampedLock的新锁，它也支持读写锁，就像上面的例子一样。与ReadWriteLock相反，StampedLock的锁定方法返回一个由长值表示的戳。

您可以使用这些戳记来释放锁或检查锁是否仍然有效。此外，戳锁支持另一种锁模式，称为乐观锁。

本文介绍了不同类型的ReentrantLock和StampedLock锁的用法。

锁让程序员的生活更轻松。以下是使用锁可以轻松实现的几种情况。

Lock in one method, and release the lock in another method. If You have two threads working on two different pieces of code, however, in the first thread has a pre-requisite on a certain piece of code in the second thread (while some other threads also working on the same piece of code in the second thread simultaneously). A shared lock can solve this problem quite easily. Implementing monitors. For example, a simple queue where the put and get methods are executed from many other threads. However, you do not want multiple put (or get) methods running simultaneously, neither the put and get method running simultaneously. A private lock makes your life a lot easier to achieve this.

同时，锁和条件建立在同步机制之上。因此，当然可以实现与使用锁相同的功能。但是，使用同步解决复杂的场景可能会使您的生活变得困难，并可能使您偏离解决实际问题的方向。

主要的区别是公平性，换句话说，请求是FIFO处理还是可以有驳船?方法级同步确保公平或FIFO分配锁。使用

synchronized(foo) {
}

or

lock.acquire(); .....lock.release();

不能保证公平。

如果您对锁有很多争用，那么您很容易遇到barging，即新请求获得锁而旧请求卡住。我曾经见过这样的情况:为了一个锁，200个线程在短时间内到达，而第二个到达的线程最后被处理。这对于某些应用程序是可行的，但对于其他应用程序则是致命的。

请参阅Brian Goetz的《Java并发实践》一书中的13.3节，以获得关于此主题的完整讨论。

Brian Goetz的《Java并发实践》一书，第13.3节: ＂...像默认的ReentrantLock一样，内在锁不提供确定性的公平性保证，但是 大多数锁定实现的统计公平性保证对于几乎所有情况都足够好……”

为什么要使用synchronized或java.util.concurrent.Lock有4个主要因素。

注意:同步锁定就是我所说的内在锁定。

When Java 5 came out with ReentrantLocks, they proved to have quite a noticeble throughput difference then intrinsic locking. If youre looking for faster locking mechanism and are running 1.5 consider j.u.c.ReentrantLock. Java 6's intrinsic locking is now comparable. j.u.c.Lock has different mechanisms for locking. Lock interruptable - attempt to lock until the locking thread is interrupted; timed lock - attempt to lock for a certain amount of time and give up if you do not succeed; tryLock - attempt to lock, if some other thread is holding the lock give up. This all is included aside from the simple lock. Intrinsic locking only offers simple locking Style. If both 1 and 2 do not fall into categories of what you are concerned with most people, including myself, would find the intrinsic locking semenatics easier to read and less verbose then j.u.c.Lock locking. Multiple Conditions. An object you lock on can only be notified and waited for a single case. Lock's newCondition method allows for a single Lock to have mutliple reasons to await or signal. I have yet to actually need this functionality in practice, but is a nice feature for those who need it.