issue_3171637

3月21日深圳｜OpenClaw 线下实战沙龙：招聘、资讯、项目协同三大场景实操，VS ZeroClaw 横向对比评测，别再只会装，来现场跑通真实业务！

待办的

成员

创建于

2020-09-21 03:14

内容可能含有违规信息

从这期开始，将进入 Java并发学习阶段。软件并发已经成为现代软件开发的基础能力，而Java精心设计的高效并发机制，正是构建大规模应用的基础之一，所以考察并发基本功也成为各个公司面试 Java 工程师的必选项。

今天要讨论的是，synchronized和 ReentrantLock有什么区别?有人说 synchronized 最慢，这话靠谱吗?
### 考点分析
今天的题目是考察并发编程的常见基础题，下面给出的问题回答算是一个相对全面的总结。

对于并发编程，不同公司或者面试官面试风格也不一样，有个别大厂喜欢一直追问你相关机制的扩展或者底层，有的喜欢从实用角度出发，所以你在准备并发编程方面需要一定的耐心。

锁作为并发的基础工具之一，你至少需要掌握∶
 - 理解什么是线程安全。
 - synchronized、ReentrantLock等机制的基本使用与案例。

更近一步，你还需要∶
 - 掌握 synchronized、ReentrantLock底层实现;理解锁膨胀、降级;理解偏斜锁、自旋锁、轻量级锁、重量级锁等概念。
 - 掌握并发包中java.util.concurrent.lock 各种不同实现和案例分析。

### 问题回答
synchronized是Java 内建的同步机制，所以也有人称其为 Intrinsic Locking，它提供了互斥的语义和可见性，当一个线程已经获取当前锁时，其他试图获取的线程只能等待或者阻塞在那里。

在Java 5以前，synchronized是仅有的同步手段，在代码中，synchronized可以用来修饰方法，也可以使用在特定的代码块儿上，本质上 synchronized方法等同于把方法全部语句用synchronized 块包起来。

ReentrantLock，通常翻译为再入锁，是Java5提供的锁实现，它的语义和synchronized基本相同。再入锁通过代码直接调用lock()方法获取，代码书写也更加灵活。与此同时，ReentrantLock 提供了很多实用的方法，能够实现很多synchronized无法做到的细节控制，比如可以控制fairness，也就是公平性，或者利用定义条件等。但是，编码中也需要注意，必须要明确调用 unlock()方法释放，不然就会一直持有该锁。

synchronized和ReentrantLlock的性能不能一概而论，早期版本 synchronized在很多场景下性能相差较大，在后续版本进行了较多改进，在低竞争场景中表现可能优于ReentrantLock。

### 后续扩展

首先，我们需要理解什么是线程安全。

线程安全是一个多线程环境下正确性的概念，也就是保证多线程环境下共享的、可修改的状态的正确性，这里的状态反映在程序中其实可以看作是数据。

换个角度来看，如果状态不是共享的，或者不是可修改的，也就不存在线程安全问题，进而可以推理出保证线程安全的两个办法∶
 - 封装∶通过封装，我们可以将对象内部状态隐藏、保护起来。
 - 不可变∶还记得我们在专栏第3讲强调的 final和immutable 吗，就是这个道理，Java语言目前还没有真正意义上的原生不可变，但是未来也许会引入。

线程安全需要保证几个基本特性∶
 - 原子性，简单说就是相关操作不会中途被其他线程干扰，一般通过同步机制实现。
 - 可见性，是一个线程修改了某个共享变量，其状态能够立即被其他线程知晓，通常被解释为将线程本地状态反映到主内存上，volatile就是负责保证可见性的。
 - 有序性，是保证线程内串行语义，避免指令重排等。

可能有点晦涩，那么我们看看下面的代码段，分析一下原子性需求体现在哪里。这个例子通过取两次数值然后进行对比，来模拟两次对共享状态的操作。
你可以编译并执行，可以看到，仅仅是两个线程的低度并发，就非常容易碰到 former和 latter 不相等的情况。这是因为，在两次取值的过程中，其他线程可能已经修改了 sharedState。

public class ThreadsafeSample｛
        public int shared state;
        public void nonsafeAction(){
          while(sharedstate<100e90)｛
            int former = sharedstate+t;
            int latter = shared state;
            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();
       }
      }
下面是在我的电脑上的运行结果∶
     C:\>c: jdk-9\bin\java ThreadsafeSample
     Observed data race,former is 13097,latter is 13099

将两次赋值过程用 synchronized 保护起来，使用 this 作为互斥单元，就可以避免别的线程并发的去修改 sharedState。

synchronized (this){
        int former= sharestate +;
        int lter = sharedstate;
        //...
     }
   
如果用javap反编译，可以看到类似片段，利用monitorenter/monitorexit对实现了同步的语义∶

11: astore_1 
       12: monitorenter 
       13: aload_9 
       14:dup 
       15:getfield    #2 //Field sharedState:I 
       18:dup_x1
       ...
       S6:monitorexit
      
在下一讲，对synchronized和其他锁实现的更多底层细节进行深入分析。
代码中使用synchronized非常便利，如果用来修饰静态方法，其等同于利用下面代码将方法体囊括进来∶

synchronized(ClassName.class){}
     
再来看看Reentrantlock。你可能好奇什么是再入?它是表示当一个线程试图获取一个它已经获取的锁时，这个获取动作就自动成功，这是对锁获取粒度的一个概念，也就是锁的持有是以线程为单位而不是基于调用次数。Java锁实现强调再入性是为了和pthread的行为进行区分。

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

ReentrantLock fairLock= new ReentrantLock(true);

这里所谓的公平性是指在竞争场景中，当公平性为真时，会倾向于将锁赋予等待时间最久的线程。公平性是减少线程"饥饿"（个别线程长期等待锁，但始终无法获取）情况发生的一个办法。

如果使用 synchronized，我们根本无法进行公平性的选择，其永远是不公平的，这也是主流操作系统线程调度的选择。通用场景中，公平性未必有想象中的那么重要，Java 默认的调度策略很少会导致"饥饿"发生。与此同时，若要保证公平性则会引入额外开销，自然会导致一定的吞吐量下降。所以，我建议只有当你的程序确实有公平性需要的时候，才有必要指定它。

我们再从日常编码的角度学习下再入锁。为保证锁释放，每一个 lock（）动作，我建议都立即对应一个 try-catch-finally，典型的代码结构如下，这是个良好的习惯。

ReentrantLock fairLock =new ReentrantLock（true）;
      // 这里是演示创建公平锁，一般情况不需要。
      try{
         //do something 
      }finally(
        fairLock.unmlock();
      }

ReentrantLock相比 synchronized，因为可以像普通对象一样使用，所以可以利用其提供的各种便利方法，进行精细的同步操作，甚至是实现 synchronized难以表达的用例，如∶
 - 带超时的获取锁尝试。
 - 可以判断是否有线程，或者某个特定线程，在排队等待获取锁。
 - 可以响应中断请求。
 - ...

这里特别想强调条件变量（javautilconcurrent.Condition），如果说ReentrantLock是synchronized的替代选择，Condition则是将wait、notify、ntifyAll等操作转化为相应的对象，将复杂而晦涩的同步操作转变为直观可控的对象行为。

条件变量最为典型的应用场景就是标准类库中的ArayBlockingQueue等。我们参考下面的源码，

首先，通过再入锁获取条件变量∶

```
       /** 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 llegalArgumentxception();
          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;
         cout+;
        notempty.signal（）;//通知等待的线程，非空条件已经满足
｝
```

通过 signal/await 的组合，完成了条件判断和通知等待线程，非常顺畅就完成了状态流转。注意，signal和await 成对调用非常重要，不然假设只有await 动作，线程会一直等待直到被打断（interrupt ）。

从性能角度，synchronized 早期的实现比较低效，对比 ReentrantLock，大多数场景性能都相差较大。但是在Java6中对其进行了非常多的改进，可以参考性能对此，在高竞争情况ReentrantLock 仍然有一定优势。在大多数情况下，无需纠结于性能，还是考虑代码书写结构的便利性、可维护性等。

登录后才可以发表评论

状态

负责人

里程碑

Pull Requests

关联的 Pull Requests 被合并后可能会关闭此 issue

分支

开始日期 - 截止日期

置顶选项

优先级

参与者（1）

https://gitee.com/beike-java-interview-alliance/java-interview.git

git@gitee.com:beike-java-interview-alliance/java-interview.git

beike-java-interview-alliance

java-interview

Java技术提升库

Java技术交流/Java技术提升库

内容风险标识

评论 (0)

Java技术交流/Java技术提升库 .gitee-modal { width: 500px !important; }

内容风险标识

issue_3171637

评论 (0)

搜索帮助

Java技术交流/Java技术提升库