synchronized 是 Java 内建的同步机制，所以也有人称其为 Intrinsic Locking，它供应了互斥的语义和可见性，当一个线程已经获取当前锁时，其他试图获取的线程只能守候或许壅塞在那边。
在 Java 5 以前，synchronized 是仅有的同步手段，在代码中， synchronized 能够用来润饰方式，也能够使用在特定的代码块儿上，素质上 synchronized 方式等同于把方式悉数语句用 synchronized 块包起来。
ReentrantLock，平日翻译为再入锁，是 Java 5 供应的锁实现，它的语义和 synchronized 根基沟通。再入锁经由代码直接挪用 lock() 方式获取，代码书写也加倍天真。与此同时， ReentrantLock 供应了好多实用的方式，可以实现好多 synchronized 无法做到的细节掌握，好比能够掌握 fairness，也就是平正性，或许行使界说前提等。然则，编码中也需要注重，必需要明确挪用 unlock() 方式释放，否则就会一向持有该锁。
synchronized 和 ReentrantLock 的机能不克一概而论，早期版本 synchronized 在好多场景下机能相差较大，在后续版本进行了较多改善，在低竞争场景中示意或者优ReentrantLock。
首先，我们需要懂得什么是线程平安。
我建议阅读 Brain Goetz 等专家撰写的《Java 并发编程实战》（Java Concurrency in Practice），固然或者稍显学究，但弗成否认这是一本非常系统和周全的 Java 并发编程书籍。按照个中的界说，线程平安是一个多线程情况下准确性的概念，也就是包管多线程情况下共享的、可点窜的状况的准确性，这里的状况反映在法式中其实能够看作是数据。
换个角度来看，若是状况不是共享的，或许不是可点窜的，也就不存在线程平安问题，进而能够推理出包管线程平安的两个法子：
1)封装：经由封装，我们能够将对象内部状况隐藏、珍爱起来。
2)弗成变：之前强调的 final 和 immutable ，就是这个事理，Java 说话今朝还没有真正意义上的原生弗成变，然则将来或许会引入。
线程平安需要包管几个根基特征：
1）原子性，简洁说就是相关把持不会半途被其他线程干扰，一样经由同步机制实现。
2）可见性，是一个线程点窜了某个共享变量，其状况可以立刻被其他线程知晓，平日被注释为将线程内陆状况反映到主内存上，volatile 就是负责包管可见性的。
3）有序性，是包管线程内串行语义，避免指令重排等。
或者有点艰涩，那么我们看看下面的代码段，剖析一下原子性需求施展在哪里。这个例子经由取两次数值然后进行对比，来模拟两次对共享状况的把持。
你能够编译并执行，能够看到，仅仅是两个线程的低度并发，就非常轻易碰着 former 和 latter 不相等的情形。这是因为，在两次取值的过程中，其他线程或者已经点窜了 sharedState。
下面是在我的电脑上的运行究竟：
将两次赋值过程用 synchronized 珍爱起来，使用 this 作为互斥单元，就能够避免其余线程并发的去点窜 sharedState。
代码中使用 synchronized 非常便当，若是用来润饰静态方式，其等同于行使下面代码将方式体囊括进来：synchronized (ClassName.class) {}
再来看看 ReentrantLock。你或者好奇什么是再入？它是透露当一个线程试图获取一个它已经获取的锁时，这个获取动作就主动成功，这是对锁获取粒度的一个概念，也就是锁的持有是以线程为单元单子而不是基于挪用次数。Java 锁实现强调再入性是为了和 pthread 的行为进行区分。
再入锁能够设置平正性（fairness），我们可在建立再入锁时选择是否是平正的。
ReentrantLock fairLock = new ReentrantLock(true);
这里所谓的平正性是指在竞争场景中，当平正性为真时，会倾向于将锁付与守候时间最久的线程。平正性是削减线程“饥饿”（个体线程历久守候锁，但始终无法获取）情形发生的一个法子。
若是使用 synchronized，我们基本无法进行平正性的选择，其永远是不平正的，这也是主流把持系统线程调剂的选择。通用场景中，平正性未必有想象中的那么主要，Java 默认的调剂策略很少会导致 “饥饿”发生。与此同时，若要包管平正性则会引入额外开销，天然会导致必然的吞吐量下降。所以，我建议只有当你的法式的确有平正性需要的时候，才有需要指定它。
我们再从平常编码的角度进修下再入锁。为包管锁释放，每一个 lock() 动作，我建议都立刻对应一个 try-catch-finally，典型的代码构造如下，这是个精巧的习惯。
ReentrantLock 比拟 synchronized，因为能够像通俗对象一般使用，所以能够行使其供应的各类便当方式，进行精美的同步把持，甚至是实现 synchronized 难以表达的用例，如：
1）带超时的获取锁测验。
2）能够判断是否有线程，或许某个特定线程，在列队守候获取锁。
3）能够响应休止恳求。
...
这里我稀奇想强调前提变量（java.util.concurrent.Condition），若是说 ReentrantLock 是 synchronized 的替代选择，Condition 则是将 wait、notify、notifyAll 等把持转化为响应的对象，将复杂而艰涩的同步把持改变为直观可控的对象行为。
前提变量最为典型的应用场景就是尺度类库中的 ArrayBlockingQueue 等。
我们参考下面的源码，首先，经由再入锁获取前提变量：
两个前提变量是从统一再入锁建立出来，然后使用在特定把持中，如下面的 take 方式，判断和守候前提知足：
当队列为空时，试图 take 的线程的准确行为应该是守候入队发生，而不是直接返回，这是 BlockingQueue 的语义，使用前提 notEmpty 就能够优雅地实现这一逻辑。
那么，怎么包管入队触发后续 take 把持呢？请看 enqueue 实现：
经由 signal/await 的组合，完成了前提判断和通知守候线程，非常顺畅就完成了状况流转。注重，signal 和 await 成对换用非常主要，否则假设只有 await 动作，线程会一向守候直到被打断（interrupt）。
从机能角度，synchronized 早期的实现对照低效，对比 ReentrantLock，大多数场景机能都相差较大。然则在 Java 6 中对其进行了非常多的改善，能够参考机能对比，在高竞争情形下， ReentrantLock 仍然有必然优势。
