一、synchronized关键字的基本底层原理

1. 基本使用

如下抢票的代码，如果不加锁，就会出现超卖或者一张票卖给多个人

Synchronized【对象锁】采用互斥的方式让同一时刻至多只有一个线程能持有【对象锁】，其它线程再想获取这个【对象锁】时就会阻塞住

 ​
 public class TicketDemo {
 ​
     static Object lock = new Object();
     int ticketNum = 10;
 ​
 ​
     public synchronized void getTicket() {
         synchronized (this) {
             if (ticketNum <= 0) {
                 return;
             }
             System.out.println(Thread.currentThread().getName() + "抢到一张票,剩余:" + ticketNum);
             // 非原子性操作
             ticketNum--;
         }
     }
 ​
     public static void main(String[] args) {
         TicketDemo ticketDemo = new TicketDemo();
         for (int i = 0; i < 20; i++) {
             new Thread(() -> {
                 ticketDemo.getTicket();
             }).start();
         }
     }
 ​
 ​
 }

2. Monitor

Monitor 被翻译为监视器，是由jvm提供，c++语言实现

在代码中想要体现monitor需要借助javap命令查看clsss的字节码，比如以下代码：

 public class SyncTest {
 ​
     static final Object lock = new Object();
     static int counter = 0;
     public static void main(String[] args) {
         synchronized (lock) {
             counter++;
         }
     }
 }

找到这个类的class文件，在class文件目录下执行javap -v SyncTest.class，反编译效果如下：

  • monitorenter 上锁开始的地方

  • monitorexit 解锁的地方

  • 其中被monitorenter和monitorexit包围住的指令就是上锁的代码

  • 有两个monitorexit的原因，第二个monitorexit是为了防止锁住的代码抛异常后不能及时释放锁

在使用了synchornized代码块时需要指定一个对象，所以synchornized也被称为对象锁

monitor主要就是跟这个对象产生关联，如下图

Monitor内部具体的存储结构：

  • Owner：存储当前获取锁的线程的，只能有一个线程可以获取

  • EntryList：关联没有抢到锁的线程，处于Blocked状态的线程

  • WaitSet：关联调用了wait方法的线程，处于Waiting状态的线程

具体的流程：

  • 代码进入synchorized代码块，先让lock（对象锁）关联的monitor，然后判断Owner是否有线程持有

  • 如果没有线程持有，则让当前线程持有，表示该线程获取锁成功

  • 如果有线程持有，则让当前线程进入entryList进行阻塞，如果Owner持有的线程已经释放了锁，在EntryList中的线程去竞争锁的持有权（非公平）

  • 如果代码块中调用了wait()方法，则会进去WaitSet中进行等待

参考回答：

  • Synchronized【对象锁】采用互斥的方式让同一时刻至多只有一个线程能持有【对象锁】

  • 它的底层由monitor实现的，monitor是jvm级别的对象（ C++实现），线程获得锁需要使用对象（锁）关联monitor

  • 在monitor内部有三个属性，分别是owner、entrylist、waitset

  • 其中owner是关联的获得锁的线程，并且只能关联一个线程；entrylist关联的是处于阻塞状态的线程；waitset关联的是处于Waiting状态的线程

二、synchronized关键字的底层原理-进阶

Monitor实现的锁属于重量级锁，了解过锁升级吗？

  • Monitor实现的锁属于重量级锁，里面涉及到了用户态和内核态的切换、进程的上下文切换，成本较高，性能比较低。

  • 在JDK 1.6引入了两种新型锁机制：偏向锁和轻量级锁，它们的引入是为了解决在没有多线程竞争或基本没有竞争的场景下因使用传统锁机制带来的性能开销问题。

1. 对象的内存结构

在HotSpot虚拟机中，对象在内存中存储的布局可分为3块区域：对象头（Header）、实例数据（Instance Data）和对齐填充

我们需要重点分析MarkWord对象头

2. MarkWord

  • hashcode：25位的对象标识Hash码

  • age：对象分代年龄占4位

  • biased_lock：偏向锁标识，占1位 ，0表示没有开始偏向锁，1表示开启了偏向锁

  • thread：持有偏向锁的线程ID，占23位

  • epoch：偏向时间戳，占2位

  • ptr_to_lock_record：轻量级锁状态下，指向栈中锁记录的指针，占30位

  • ptr_to_heavyweight_monitor：重量级锁状态下，指向对象监视器Monitor的指针，占30位

我们可以通过lock的标识，来判断是哪一种锁的等级

  • 后三位是001表示无锁

  • 后三位是101表示偏向锁

  • 后两位是00表示轻量级锁

  • 后两位是10表示重量级锁

3. 再说Monitor重量级锁

每个 Java 对象都可以关联一个 Monitor 对象，如果使用 synchronized 给对象上锁（重量级）之后，该对象头的Mark Word 中就被设置指向 Monitor 对象的指针

简单说就是：每个对象的对象头都可以设置monoitor的指针，让对象与monitor产生关联

4. 轻量级锁

在很多的情况下，在Java程序运行时，同步块中的代码都是不存在竞争的，不同的线程交替的执行同步块中的代码。这种情况下，用重量级锁是没必要的。因此JVM引入了轻量级锁的概念。

 static final Object obj = new Object();
 ​
 public static void method1() {
     synchronized (obj) {
         // 同步块 A
         method2();
     }
 }
 ​
 public static void method2() {
     synchronized (obj) {
         // 同步块 B
     }
 }

加锁的流程

1.在线程栈中创建一个Lock Record，将其obj字段指向锁对象。

2.通过CAS指令将Lock Record的地址存储在对象头的mark word中（数据进行交换），如果对象处于无锁状态则修改成功，代表该线程获得了轻量级锁。

3.如果是当前线程已经持有该锁了，代表这是一次锁重入。设置Lock Record第一部分为null，起到了一个重入计数器的作用。

4.如果CAS修改失败，说明发生了竞争，需要膨胀为重量级锁。

解锁过程

1.遍历线程栈,找到所有obj字段等于当前锁对象的Lock Record。

2.如果Lock Record的Mark Word为null，代表这是一次重入，将obj设置为null后continue。

3.如果Lock Record的 Mark Word不为null，则利用CAS指令将对象头的mark word恢复成为无锁状态。如果失败则膨胀为重量级锁。

5. 偏向锁

轻量级锁在没有竞争时（就自己这个线程），每次重入仍然需要执行 CAS 操作。

Java 6 中引入了偏向锁来做进一步优化：只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头，之后发现

这个线程 ID 是自己的就表示没有竞争，不用重新 CAS。以后只要不发生竞争，这个对象就归该线程所有

 static final Object obj = new Object();
 ​
 public static void m1() {
     synchronized (obj) {
         // 同步块 A
         m2();
     }
 }
 ​
 public static void m2() {
     synchronized (obj) {
         // 同步块 B
         m3();
     }
 }
 ​
 public static void m3() {
     synchronized (obj) {
 ​
     }
 }

加锁的流程

1.在线程栈中创建一个Lock Record，将其obj字段指向锁对象。

2.通过CAS指令将Lock Record的线程id存储在对象头的mark word中，同时也设置偏向锁的标识为101，如果对象处于无锁状态则修改成功，代表该线程获得了偏向锁。

3.如果是当前线程已经持有该锁了，代表这是一次锁重入。设置Lock Record第一部分为null，起到了一个重入计数器的作用。与轻量级锁不同的时，这里不会再次进行cas操作，只是判断对象头中的线程id是否是自己，因为缺少了cas操作，性能相对轻量级锁更好一些

解锁流程参考轻量级锁

6. 参考回答

Java中的synchronized有偏向锁、轻量级锁、重量级锁三种形式，分别对应了锁只被一个线程持有、不同线程交替持有锁、多线程竞争锁三种情况。

描述

重量级锁

底层使用的Monitor实现，里面涉及到了用户态和内核态的切换、进程的上下文切换，成本较高，性能比较低。

轻量级锁

线程加锁的时间是错开的（也就是没有竞争），可以使用轻量级锁来优化。轻量级修改了对象头的锁标志，相对重量级锁性能提升很多。每次修改都是CAS操作，保证原子性

偏向锁

一段很长的时间内都只被一个线程使用锁，可以使用了偏向锁，在第一次获得锁时，会有一个CAS操作，之后该线程再获取锁，只需要判断mark word中是否是自己的线程id即可，而不是开销相对较大的CAS命令

一旦锁发生了竞争，都会升级为重量级锁

三、ReentrantLock的实现原理

1. 概述

ReentrantLock翻译过来是可重入锁，相对于synchronized它具备以下特点：

  • 可中断

  • 可以设置超时时间

  • 可以设置公平锁

  • 支持多个条件变量

  • 与synchronized一样，都支持重入

2. 实现原理

ReentrantLock主要利用CAS+AQS队列来实现。它支持公平锁和非公平锁，两者的实现类似

关于CAS和AQS可参考：JUC基础 | 东的博客 (dongtech.eu.org)

构造方法接受一个可选的公平参数（默认非公平锁），当设置为true时，表示公平锁，否则为非公平锁。公平锁的效率往往没有非公平锁的效率高，在许多线程访问的情况下，公平锁表现出较低的吞吐量。

查看ReentrantLock源码中的构造方法：

提供了两个构造方法，不带参数的默认为非公平

如果使用带参数的构造函数，并且传的值为true，则是公平锁

其中NonfairSync和FairSync这两个类父类都是Sync

而Sync的父类是AQS，所以可以得出ReentrantLock底层主要实现就是基于AQS来实现的

3. 工作流程

  • 线程来抢锁后使用cas的方式修改state状态，修改状态成功为1，则让exclusiveOwnerThread属性指向当前线程，获取锁成功

  • 假如修改状态失败，则会进入双向队列中等待，head指向双向队列头部，tail指向双向队列尾部

  • 当exclusiveOwnerThread为null的时候，则会唤醒在双向队列中等待的线程

  • 公平锁则体现在按照先后顺序获取锁，非公平体现在不在排队的线程也可以抢锁

四、synchronized和Lock的区别

  • 语法层面

    • synchronized 是关键字，源码在 jvm 中，用 c++ 语言实现

    • Lock 是接口，源码由 jdk 提供，用 java 语言实现

    • 使用 synchronized 时，退出同步代码块锁会自动释放，而使用 Lock 时，需要手动调用 unlock 方法释放锁

  • 功能层面

    • 二者均属于悲观锁、都具备基本的互斥、同步、锁重入功能

    • Lock 提供了许多 synchronized 不具备的功能，例如获取等待状态、公平锁、可打断、可超时、多条件变量

    • Lock 有适合不同场景的实现，如 ReentrantLock， ReentrantReadWriteLock

  • 性能层面

    • 在没有竞争时，synchronized 做了很多优化，如偏向锁、轻量级锁，性能不赖

    • 在竞争激烈时，Lock 的实现通常会提供更好的性能

五、死锁产生的条件是什么？

死锁：两个或多个线程互相持有对方所需的资源，而且由于彼此之间的等待而导致所有线程无法继续执行的状态。

死锁的条件通常被称为死锁的四个必要条件，它们是：

  • 互斥条件（Mutual Exclusion）： 至少有一个资源必须处于非共享模式，即一次只能被一个线程使用。

  • 持有和等待条件（Hold and Wait）： 一个线程必须持有至少一个资源并等待另一个资源，而此时被持有的资源可能被其他线程占用。

  • 不可抢占条件（No Preemption）： 资源不能被强制从一个线程中抢占，只能由持有它的线程显式释放。

  • 循环等待条件（Circular Wait）： 一系列进程形成环路，每个进程都在等待下一个进程所持有的资源。

例如：

t1 线程获得A对象锁，接下来想获取B对象的锁

t2 线程获得B对象锁，接下来想获取A对象的锁

代码如下：

 package com.itheima.basic;
 ​
 import static java.lang.Thread.sleep;
 ​
 public class Deadlock {
 ​
     public static void main(String[] args) {
         Object A = new Object();
         Object B = new Object();
         Thread t1 = new Thread(() -> {
             synchronized (A) {
                 System.out.println("lock A");
                 try {
                     sleep(1000);
                 } catch (InterruptedException e) {
                     throw new RuntimeException(e);
                 }
                 synchronized (B) {
                     System.out.println("lock B");
                     System.out.println("操作...");
                 }
             }
         }, "t1");
 ​
         Thread t2 = new Thread(() -> {
             synchronized (B) {
                 System.out.println("lock B");
                 try {
                     sleep(500);
                 } catch (InterruptedException e) {
                     throw new RuntimeException(e);
                 }
                 synchronized (A) {
                     System.out.println("lock A");
                     System.out.println("操作...");
                 }
             }
         }, "t2");
         t1.start();
         t2.start();
     }
 }

控制台输出结果

此时程序并没有结束，这种现象就是死锁现象...线程t1持有A的锁等待获取B锁，线程t2持有B的锁等待获取A的锁。

六、如何进行死锁诊断？

当程序出现了死锁现象，我们可以使用jdk自带的工具：jps和 jstack

步骤如下：

第一：查看运行的线程

第二：使用jstack查看线程运行的情况，下图是截图的关键信息

运行命令：jstack -l 46032

其他解决工具，可视化工具

  • jconsole

用于对jvm的内存，线程，类 的监控，是一个基于 jmx 的 GUI 性能监控工具

打开方式：java 安装目录 bin目录下 直接启动 jconsole.exe 就行

  • VisualVM：故障处理工具

能够监控线程，内存情况，查看方法的CPU时间和内存中的对 象，已被GC的对象，反向查看分配的堆栈

打开方式：java 安装目录 bin目录下 直接启动 jvisualvm.exe就行

七、ConcurrentHashMap

ConcurrentHashMap 是一种线程安全的高效Map集合

底层数据结构：

  • JDK1.7底层采用分段的数组+链表实现

  • JDK1.8 采用的数据结构跟HashMap1.8的结构一样，数组+链表/红黑二叉树。

（1） JDK1.7中concurrentHashMap

数据结构

  • 提供了一个segment数组，在初始化ConcurrentHashMap 的时候可以指定数组的长度，默认是16，一旦初始化之后中间不可扩容

  • 在每个segment中都可以挂一个HashEntry数组，数组里面可以存储具体的元素，HashEntry数组是可以扩容的

  • 在HashEntry存储的数组中存储的元素，如果发生冲突，则可以挂单向链表

存储流程

  • 先去计算key的hash值，然后确定segment数组下标

  • 再通过hash值确定hashEntry数组中的下标存储数据

  • 在进行操作数据的之前，会先判断当前segment对应下标位置是否有线程进行操作，为了线程安全使用的是ReentrantLock进行加锁，如果获取锁是被会使用cas自旋锁进行尝试

（2） JDK1.8中concurrentHashMap

在JDK1.8中，放弃了Segment臃肿的设计，数据结构跟HashMap的数据结构是一样的：数组+红黑树+链表

采用 CAS + Synchronized来保证并发安全进行实现

  • CAS控制数组节点的添加

  • synchronized只锁定当前链表或红黑二叉树的首节点，只要hash不冲突，就不会产生并发的问题 , 效率得到提升