前言

线程安全是并发编程中的重要关注点。

造成线程安全问题的主要诱因有两点，一是存在共享数据(也称临界资源)，二是存在多条线程共同操作共享数据。

为了解决这个问题，我们可能需要这样一个方案，当存在多个线程操作共享数据时，需要保证同一时刻有且只有一个线程在操作共享数据，其他线程必须等到该线程处理完数据后再进行。

在 Java 中，关键字 Synchronized可以保证在同一个时刻，只有一个线程可以执行某个方法或者某个代码块(主要是对方法或者代码块中存在共享数据的操作)。

下面来一起探索Synchronized的基本使用、实现机制。

面试题来自：[社招一年半面经分享(含阿里美团头条京东滴滴)]

喜欢的话，之后会分享更多系列文章！

觉得有收获，希望帮忙点赞，转发下哈，谢谢，谢谢

用法

两类锁：

对象锁：包括方法锁（默认锁对象为this当前实例对象）和同步代码块锁（自己指定锁对象）。

类锁：指Synchronized修饰静态的方法或指定锁为Class对象。

当一个线程试图访问同步代码块时，它首先必须得到锁，而退出或抛出异常时必须释放锁。

• 给普通方法加锁时，上锁的对象是 this；
• 给静态方法加锁时，锁的是 class 对象；
• 给代码块加锁，可以指定一个具体的对象作为锁。

代码示例如下：

public class SynchronizedTest {

    /**
     * 修饰静态方法, 等同于下面注释的方法
     */
    public synchronized static void test1() {
        System.out.println("月伴飞鱼");
    }


//    public static void test1() {
//        synchronized (SynchronizedTest.class){
//            System.out.println("月伴飞鱼");
//        }
//    }


    /**
     * 修饰实例方法, 等同于下面注释的方法
     */
    public synchronized void test2(){
        System.out.println("月伴飞鱼");
    }

//    public void test2(){
//        synchronized (this){
//            System.out.println("月伴飞鱼");
//        }
//    }

    /**
     * 修饰代码块
     */
    public void test3(){
        synchronized (this){
            System.out.println("月伴飞鱼");
        }
    }

}

多线程访问同步方法的几种情况：

两个线程同时访问一个对象的同步方法。

由于同步方法锁使用的是this对象锁，同一个对象的this锁只有一把，两个线程同一时间只能有一个线程持有该锁，所以该方法将会串行运行。

两个线程访问的是两个对象的同步方法。

由于两个对象的this锁互不影响，Synchronized将不会起作用，所以该方法将会并行运行。

两个线程访问的是Synchronized的静态方法。

Synchronized修饰的静态方法获取的是当前类模板对象的锁，该锁只有一把，无论访问多少个该类对象的方法，都将串行执行。

同时访问同步方法与非同步方法

非同步方法不受影响。

访问同一个对象的不同的普通同步方法。

由于this对象锁只有一个，不同线程访问多个普通同步方法将串行运行。

同时访问静态Synchronized和非静态Synchronized方法

静态Synchronized方法的锁为class对象的锁，非静态Synchronized方法锁为this的锁，它们不是同一个锁，所以它们将并行运行。

使用优化

大家在使用synchronized关键字的时候，可能经常会这么写：

synchronized (this) {
  ...
}

它的作用域是当前对象，锁的就是当前对象，谁拿到这个锁谁就可以运行它所控制的代码。

当有一个明确的对象作为锁时，就可以这么写，但是当没有一个明确的对象作为锁，只想让一段代码同步时，可以创建一个特殊的变量（对象）来充当锁：

public class Demo {
    private final Object lock = new Object();

    public void methonA() {
      synchronized (lock) {
        ...
      }
    }
}

这样写没问题。但是用new Object()作为锁对象是否是一个最佳选择呢？

我在StackOverFlow看到这么一篇文章：object-vs-byte0-as-lock

大意就是用new byte[0]作为锁对象更好，会减少字节码操作的次数。

public class Demo {
    private final byte[] lock = new byte[0];
}

具体细节大家，可以看看这篇文章，算提供一种思路吧！

实现原理

因为Synchronized锁的是对象，在讲解原理之前先介绍下对象结构相关知识。

HotSpot虚拟机中，对象在内存中存储的布局可以分为三块区域：对象头、实例数据和对齐填充。

对象头

对象头包括两部分信息：运行时数据Mark Word和类型指针

如果对象是数组对象，那么对象头占用3个字宽（Word）(需要记录数组长度)，如果对象是非数组对象，那么对象头占用2个字宽（1word = 2Byte = 16bit）

对象头的类型指针指向该对象的类元数据，虚拟机通过这个指针可以确定该对象是哪个类的实例

Mark Word

用于存储对象自身的运行时数据， 如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等等，它是实现轻量级锁和偏向锁的关键。

这部分数据的长度在32位和64位的虚拟机（暂不考虑开启压缩指针的场景）中分别为32个和64个Bits。

Synchronized锁对象就存储在MarkWord中，下面是MarkWord的布局：

32位虚拟机

实例数据

实例数据就是在程序代码中所定义的各种类型的字段，包括从父类继承的

对齐填充

由于HotSpot的自动内存管理要求对象的起始地址必须是8字节的整数倍，即对象的大小必须是8字节的整数倍，对象头的数据正好是8的整数倍，所以当实例数据不够8字节整数倍时，需要通过对齐填充进行补全

意思是每次分配的内存大小一定是8的倍数，如果对象头+实例数据的值不是8的倍数，那么会重新计算一个较大值，进行分配

底层实现

下面的代码，在命令行执行 javac，然后再执行javap -v -p，就可以看到它具体的字节码。

可以看到，在字节码的体现上，它只给方法加了一个 flag：ACC_SYNCHRONIZED。

synchronized void syncMethod() {
        System.out.println("syncMethod");
}

synchronized void syncMethod();
    descriptor: ()V
    flags: ACC_SYNCHRONIZED
    Code:
      stack=2, locals=1, args_size=1
         0: getstatic     #4
         3: ldc           #5
         5: invokevirtual #6
         8: return

我们再来看下同步代码块的字节码。可以看到，字节码是通过 monitorenter 和monitorexit 两个指令进行控制的。

void syncBlock(){
    synchronized (Test.class){
    }
}

void syncBlock();
    descriptor: ()V
    flags:
    Code:
      stack=2, locals=3, args_size=1
         0: ldc           #2 
         2: dup
         3: astore_1
         4: monitorenter
         5: aload_1
         6: monitorexit // 两个monitorexit是表示正常退出和异常退出的场景
         7: goto          15
        10: astore_2
        11: aload_1
        12: monitorexit
        13: aload_2
        14: athrow
        15: return
      Exception table:
         from    to  target type
             5     7    10   any
            10    13    10   any

这两者虽然显示效果不同，但他们都是通过 monitor 来实现同步的。

其中在Java虚拟机（HotSpot）中，Monitor是由ObjectMonitor实现的，其主要数据结构如下（位于HotSpot虚拟机源码ObjectMonitor.hpp文件，C++实现的）：

ObjectMonitor() {
    _header       = NULL;
    _count        = 0; // 用来记录该对象被线程获取锁的次数，这也说明了synchronized是可重入的
    _waiters      = 0,
    _recursions   = 0;
    _object       = NULL;
    _owner        = NULL;  // 指向持有ObjectMonitor对象的线程
    _WaitSet      = NULL;  // 处于wait状态的线程，会被加入到_WaitSet，调用了wait方法之后会进入这里
    _WaitSetLock  = 0 ;
    _Responsible  = NULL ;
    _succ         = NULL ;
    _cxq          = NULL ;
    FreeNext      = NULL ;
    _EntryList    = NULL ; // 处于等待锁block状态的线程，会被加入到该列表
    _SpinFreq     = 0 ;
    _SpinClock    = 0 ;
    OwnerIsThread = 0 ;
  }

每个 Java 对象在 JVM 的对等对象的头中保存锁状态，指向 ObjectMonitor。

ObjectMonitor 保存了当前持有锁的线程引用，EntryList 中保存目前等待获取锁的线程，WaitSet 保存 wait 的线程。

还有一个计数器count，每当线程获得 monitor 锁，计数器 +1，当线程重入此锁时，计数器还会 +1。当计数器不为 0 时，其它尝试获取 monitor 锁的线程将会被保存到EntryList中，并被阻塞。

当持有锁的线程释放了monitor 锁后，计数器 -1。当计数器归位为 0 时，所有 EntryList 中的线程会尝试去获取锁，但只会有一个线程会成功，没有成功的线程仍旧保存在 EntryList 中。

详细流程：

1. 加锁时，即遇到Synchronized关键字时，线程会先进入monitor的_EntryList队列阻塞等待。
2. 如果monitor的_owner为空，则从队列中移出并赋值与_owner。
3. 如果在程序里调用了wait()方法，则该线程进入_WaitSet队列。我们都知道wait方法会释放monitor锁，即将_owner赋值为null并进入_WaitSet队列阻塞等待。这时其他在_EntryList中的线程就可以获取锁了。
4. 当程序里其他线程调用了notify/notifyAll方法时，就会唤醒_WaitSet中的某个线程，这个线程就会再次尝试获取monitor锁。如果成功，则就会成为monitor的owner。
5. 当程序里遇到Synchronized关键字的作用范围结束时，就会将monitor的owner设为null，退出。

Java对象如何与Monitor关联

锁优化

相比于 JDK 1.5，在 JDK 1.6 中 HotSopt 虚拟机对 Synchronized 内置锁的性能进行了很多优化，包括自适应的自旋、锁消除、锁粗化、偏向锁、轻量级锁等。

自适应的自旋锁

在 JDK 1.6 中引入了自适应的自旋锁来解决长时间自旋的问题。

比如，如果最近尝试自旋获取某一把锁成功了，那么下一次可能还会继续使用自旋，并且允许自旋更长的时间；但是如果最近自旋获取某一把锁失败了，那么可能会省略掉自旋的过程，以便减少无用的自旋，提高效率。

锁消除

经过逃逸分析之后，如果发现某些对象不可能被其他线程访问到，那么就可以把它们当成栈上数据，栈上数据由于只有本线程可以访问，自然是线程安全的，也就无需加锁，所以会把这样的锁给自动去除掉。

锁粗化

按理来说，同步块的作用范围应该尽可能小，仅在共享数据的实际作用域中才进行同步，这样做的目的是为了使需要同步的操作数量尽可能缩小，缩短阻塞时间，如果存在锁竞争，那么等待锁的线程也能尽快拿到锁。

但是加锁解锁也需要消耗资源，如果存在一系列的连续加锁解锁操作，可能会导致不必要的性能损耗。

锁粗化就是将多个连续的加锁、解锁操作连接在一起，扩展成一个范围更大的锁，避免频繁的加锁解锁操作。

偏向锁/轻量级锁/重量级锁

JVM 默认会优先使用偏向锁，如果有必要的话才逐步升级，这大幅提高了锁的性能。

锁升级

锁的状态总共有四种，无锁状态、偏向锁、轻量级锁和重量级锁

随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁，但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级

从JDK 1.6中默认是开启偏向锁，可以通过-XX:-UseBiasedLocking来禁用偏向锁

偏向锁

在只有一个线程使用了锁的情况下，偏向锁能够保证更高的效率。

具体过程是这样的：当第一个线程第一次访问同步块时，会先检测对象头 Mark Word 中的标志位 Tag 是否为 01，以此判断此时对象锁是否处于无锁状态或者偏向锁状态。

线程一旦获取了这把锁，就会把自己的线程 ID 写到 MarkWord 中，在其他线程来获取这把锁之前，锁都处于偏向锁状态。

当下一个线程参与到偏向锁竞争时，会先判断 MarkWord 中保存的线程 ID 是否与这个线程 ID 相等，如果不相等，会立即撤销偏向锁，升级为轻量级锁。

轻量级锁

当锁处于轻量级锁的状态时，就不能够再通过简单地对比标志位 Tag 的值进行判断，每次对锁的获取，都需要通过自旋。

当然，自旋也是面向不存在锁竞争的场景，比如一个线程运行完了，另外一个线程去获取这把锁；但如果自旋失败达到一定的次数，锁就会膨胀为重量级锁。

重量级锁

重量级锁，这种情况下，线程会挂起，进入到操作系统内核态，等待操作系统的调度，然后再映射回用户态。系统调用是昂贵的，所以重量级锁的名称由此而来。

如果系统的共享变量竞争非常激烈，锁会迅速膨胀到重量级锁，这些优化就名存实亡。

如果并发非常严重，可以通过参数-XX:-UseBiasedLocking 禁用偏向锁，理论上会有一些性能提升，但实际上并不确定。

锁	优点	缺点	适用场景
偏向锁	加锁和解锁不需要额外的消耗，和执行非同步方法比仅存在纳秒级的差距	如果线程间存在锁竞争，会带来额外的锁撤销的消耗	基本没有线程竞争锁的场景
轻量级锁	竞争的线程不会阻塞，提高了程序的响应速度	如果始终得不到锁竞争的线程使用自旋会消耗CPU	适用于少量线程竞争锁对象，且线程持有锁时间不长，追求响应时间的场景。
重量级锁	线程竞争不使用自旋，不会消耗CPU	线程阻塞，响应时间缓慢	追求吞吐量。竞争比较激烈，锁持有时间较长的场景

常见面试题

Synchronized和Lock的区别：

• Synchronized属于JVM层面，底层通过 monitorenter 和 monitorexit 两个指令实现，Lock是API层面的东西，JUC提供的具体类
• Synchronized不需要用户手动释放锁，当Synchronized代码执行完毕之后会自动让线程释放持有的锁，Lock需要一般使用try-finally模式去手动释放锁
• Synchronized是不可中断的，除非抛出异常或者程序正常退出，Lock可中断，使用lockInterruptibly，调用interrupt方法可中断
• Synchronized是非公平锁，Lock默认是非公平锁，但是可以通过构造函数传入boolean类型值更改是否为公平锁
• 锁是否能绑定多个条件，Synchronized没有condition的说法，要么唤醒所有线程，要么随机唤醒一个线程，Lock可以使用condition实现分组唤醒需要唤醒的线程，实现精准唤醒
• Synchronized 锁只能同时被一个线程拥有，但是 Lock 锁没有这个限制，例如在读写锁中的读锁，是可以同时被多个线程持有的，可是 Synchronized做不到
• 性能区别：在 Java 5 以及之前Synchronized的性能比较低，但是到了 Java 6 以后 JDK 对 Synchronized 进行了很多优化，比如自适应自旋、锁消除、锁粗化、轻量级锁、偏向锁等