本文已参与「新人创造礼」活动，一同打开创造之路。

⭐ JAVA 系列文章旨在具体解说 JAVA 开发中遇到的经典问题以及相关重要内容，深入研究，并以实战操作的方式融会贯通，让读者更好地把握。

本文已收录于 JAVA 系列专栏： JAVA 欢迎订阅，继续更新。

欢迎注重 点赞 保藏⭐ 留言

代码成果万世基，积沙镇海；愿望永在凌云意，神采飞扬；

前语

软件并发现已成为现代软件开发的基础才能，而 Java 精心设计的高效并发机制，正是构建大规模运用的基础之一。

本篇博文的重点是，synchronized 和 ReentrantLock 有什么区别？ 有人说 synchronized 最慢，这话靠谱吗？

常见回答

synchronized 是 Java 内建的同步机制，所以也有人称其为 Intrinsic Locking，它供应了互斥的语义和可见性，当一个线程现已获取其时锁时，其他妄图获取的线程只能等候或许堵塞在那里。

在 Java 5 曾经，synchronized 是仅有的同步手法，在代码中， synchronized 可以用来修饰方法，也可以运用在特定的代码块儿上，本质上 synchronized 方法等同于把方法悉数句子用 synchronized 块包起来。

ReentrantLock，一般翻译为再入锁，是 Java 5 供应的锁完结，它的语义和 synchronized 根柢相同。再入锁通过代码直接调用 lock() 方法获取，代码书写也更加灵敏。与此同时，ReentrantLock 供应了许多有用的方法，可以完结许多 synchronized 无法做到的细节操控，比方可以操控 fairness，也就是公正性，或许运用界说条件等。可是，编码中也需求留心，必需求明确调用 unlock() 方法开释，不然就会一贯持有该锁。

synchronized 和 ReentrantLock 的功用不能混为一谈，前期版本 synchronized 在许多场景下功用相差较大，在后续版本进行了较多改进，在低竞赛场景中体现或许优于 ReentrantLock。

具体分析

关于并发编程，不同公司或许面试官面试风格也不相同，有个别大厂喜爱一贯诘问你相关机制的扩展或许底层，有的喜爱从有用角度出发，所以你在预备并发编程方面需求必定的耐性。

锁作为并发的基础工具之一，至少需求把握：

• 了解什么是线程安全。
• synchronized、ReentrantLock 等机制的根柢运用与案例。

更进一步，你还需求：

• 把握 synchronized、ReentrantLock 底层完结；了解锁胀大、降级；了解偏斜锁、自旋锁、轻量级锁、重量级锁等概念。
• 把握并发包中 java.util.concurrent.lock 各种不同完结和案例分析。

实战分析

首先，我们需求了解什么是线程安全。

在 Brain Goetz 等专家撰写的《Java 并发编程实战》（Java Concurrency in Practice）中，线程安满是一个多线程环境下正确性的概念，也就是保证多线程环境下同享的、可批改的情况的正确性，这儿的情况反映在程序中其实可以看作是数据。

换个角度来看，假设情况不是同享的，或许不是可批改的，也就不存在线程安全问题，从而可以推理出保证线程安全的两个方法：

• 封装：通过封装，我们可以将目标内部情况隐藏、保护起来。
• 不可变：final 和 immutable 就是这个道理，Java 语言现在还没有真正意义上的原生不可变，可是未来或许会引入。

线程安全需求保证几个根柢特性：

• 原子性，简单说就是相关操作不会中途被其他线程搅扰，一般通过同步机制完结。
• 可见性，是一个线程批改了某个同享变量，其情况可以当即被其他线程知晓，一般被解释为将线程本地情况反映到主内存上，volatile 就是担任保证可见性的。
• 有序性，是保证线程内串行语义，避免指令重排等。

或许有点不流通，那么我们看看下面的代码段，分析一下原子性需求体现在哪里。这个比方通过取两次数值然后进行对比，来模拟两次对同享情况的操作。

你可以编译并执行，可以看到，仅仅是两个线程的低度并发，就非常简单碰到 former 和 latter 不相等的情况。这是因为，在两次取值的进程中，其他线程或许现已批改了 sharedState。

public class ThreadSafeSample {
  public int sharedState;
  public void nonSafeAction() {
      while (sharedState < 100000) {
          int former = sharedState++;
          int latter = sharedState;
          if (former != latter - 1) {
              System.out.printf("Observed data race, former is " +
                      former + ", " + "latter is " + latter);
          }
      }
  }
  public static void main(String[] args) throws InterruptedException {
      ThreadSafeSample sample = new ThreadSafeSample();
      Thread threadA = new Thread(){
          public void run(){
              sample.nonSafeAction();
          }
      };
      Thread threadB = new Thread(){
          public void run(){
              sample.nonSafeAction();
          }
      };
      threadA.start();
      threadB.start();
      threadA.join();
      threadB.join();
  }
}

以下是某次运转成果：

Observed data race, former is 9851, latter is 9853

将两次赋值进程用 synchronized 保护起来，运用 this 作为互斥单元，就可以避免其他线程并发的去批改 sharedState。

synchronized (this) {
  int former = sharedState ++;
  int latter = sharedState;
  // …
}

假设用 javap 反编译，可以看到类似片段，运用 monitorenter/monitorexit 对完结了同步的语义：

11: astore_1
12: monitorenter
13: aload_0
14: dup
15: getfield    #2                // Field sharedState:I
18: dup_x1
…
56: monitorexit

代码中运用 synchronized 非常便利，假设用来修饰静态方法，其等同于运用下面代码将方法体包含进来：

synchronized (ClassName.class) {}

再来看看 ReentrantLock。你或许猎奇什么是再入？它是表示当一个线程妄图获取一个它现已获取的锁时，这个获取动作就自动成功，这是对锁获取粒度的一个概念，也就是锁的持有是以线程为单位而不是根据调用次数。Java 锁完结强调再入性是为了和 pthread 的行为进行区分。

再入锁可以设置公正性（fairness），我们可在创建再入锁时选择是否是公正的。

ReentrantLock fairLock = new ReentrantLock(true);

这儿所谓的公正性是指在竞赛场景中，当公正性为真时，会倾向于将锁赋予等候时刻最久的线程。公正性是削减线程“饥饿”（个别线程长时间等候锁，但一贯无法获取）情况产生的一个方法。

假设运用 synchronized，我们根柢无法进行公正性的选择，其永远是不公正的，这也是主流操作系统线程调度的选择。通用场景中，公正性未必有幻想中的那么重要，Java 默认的调度战略很少会导致 “饥饿”产生。与此同时，若要保证公正性则会引入额定开支，自然会导致必定的吞吐量下降。所以，我建议只有当你的程序的确有公正性需求的时分，才有必要指定它。

我们再从日常编码的角度学习下再入锁。为保证锁开释，每一个 lock() 动作，我建议都当即对应一个 try-catch-finally，典型的代码结构如下，这是个出色的习气。

ReentrantLock fairLock = new ReentrantLock(true);// 这儿是演示创建公正锁，一般情况不需求。
fairLock.lock();
try {
  // do something
} finally {
   fairLock.unlock();
}

ReentrantLock 比较 synchronized，因为可以像普通目标相同运用，所以可以运用其供应的各种便利方法，进行精细的同步操作，甚至是完结 synchronized 难以表达的用例，如：

• 带超时的获取锁尝试。
• 可以判别是否有线程，或许某个特定线程，在排队等候获取锁。
• 可以呼应中断请求。
• …

这儿我特别想强调条件变量（java.util.concurrent.Condition），假设说 ReentrantLock 是 synchronized 的替代选择，Condition 则是将 wait、notify、notifyAll 等操作转化为相应的目标，将凌乱而不流通的同步操作转变为直观可控的目标行为。

条件变量最为典型的运用场景就是标准类库中的 ArrayBlockingQueue 等。

参阅下面的源码，首先，通过再入锁获取条件变量：

/** Condition for waiting takes */
private final Condition notEmpty;
/** Condition for waiting puts */
private final Condition notFull;
public ArrayBlockingQueue(int capacity, boolean fair) {
  if (capacity <= 0)
      throw new IllegalArgumentException();
  this.items = new Object[capacity];
  lock = new ReentrantLock(fair);
  notEmpty = lock.newCondition();
  notFull =  lock.newCondition();
}

两个条件变量是从同一再入锁创建出来，然后运用在特定操作中，如下面的 take 方法，判别和等候条件满足：

public E take() throws InterruptedException {
  final ReentrantLock lock = this.lock;
  lock.lockInterruptibly();
  try {
      while (count == 0)
          notEmpty.await();
      return dequeue();
  } finally {
      lock.unlock();
  }
}

当队列为空时，妄图 take 的线程的正确行为应该是等候入队产生，而不是直接回来，这是 BlockingQueue 的语义，运用条件 notEmpty 就可以典雅地完结这一逻辑。

那么，怎样保证入队触发后续 take 操作呢？请看 enqueue 完结：

private void enqueue(E e) {
  // assert lock.isHeldByCurrentThread();
  // assert lock.getHoldCount() == 1;
  // assert items[putIndex] == null;
  final Object[] items = this.items;
  items[putIndex] = e;
  if (++putIndex == items.length) putIndex = 0;
  count++;
  notEmpty.signal(); // 告诉等候的线程，非空条件现已满足
}

通过 signal/await 的组合，完结了条件判别和告诉等候线程，非常顺畅就完结了情况流转。留心，signal 和 await 成对调用非常重要，不然假定只有 await 动作，线程会一贯等候直到被打断（interrupt）。

从功用角度，synchronized 前期的完结比较低效，对比 ReentrantLock，大多数场景功用都相差较大。可是在 Java 6 中对其进行了非常多的改进，可以参阅功用对比，在高竞赛情况下，ReentrantLock 依然有必定优势。我在下一讲进行具体分析，会更有助于了解功用差异产生的内涵原因。在大多数情况下，无需纠结于功用，仍是考虑代码书写结构的便利性、可保护性等。

后记

以上就是Java：synchronized 和 ReentrantLock 有什么区别呢？的所有内容了;

介绍了什么是线程安全，对比和分析了 synchronized 和 ReentrantLock，并针对条件变量等方面结合案例代码进行了介绍。

上篇精讲：【JAVA】对比 Hashtable、HashMap、TreeMap 有什么不同？

我是，等待你的注重；

创造不易，请多多支持；

系列专栏：JAVA