我们已经了解了Java内存模型的一些知识，并且已经知道出现线程安全的主要问题来源于JMM的设计，主要集中在主内存和线程的工作内存而导致的内存可见性问题，以及重排序导致的问题，进一步知道了happens-before规则。线程运行时拥有自己的栈空间，会在自己的栈空间运行，如果多线程间没有共享的数据也就是说多线程间并没有协作完成一件事情，那么，多线程就不能发挥优势，不能带来巨大的价值。那么共享数据的线程安全问题怎样处理？很自然而然的想法就是每一个线程依次去读写这个共享变量，这样就不会有任何数据安全的问题，因为每个线程所操作的都是当前最新的版本数据。那么，在Java关键字synchronized就具有使每个线程依次排队操作共享变量的功能。很显然，这种同步机制效率很低，但synchronized是其他并发容器实现的基础，对它的理解也会大大提升对并发编程的感觉，从功利的角度来说，这也是面试高频的考点。好了，下面，就来具体说说这个关键字。

文章目录

  • synchronized的知识结构图谱
  • synchronized的作用
  • synchronized的使用
    • synchronized修饰实例方法
    • synchronized修饰静态方法
    • synchronized修饰同步代码块(实例对象)
    • synchronized修饰同步代码块(this对象和class对象)
  • synchronized实现原理
    • 理解Java对象头
    • Monitor对象
    • Synchronized核心组件
    • Synchronized实现细节
    • 操作系统的用户态和内核态
    • 对象锁（monitor）机制
  • JVM对synchronized的锁优化
    • 锁升级简化过程
    • 无锁状态(CAS)
      • 什么是CAS
      • CAS的操作过程
      • CAS的应用场景
      • CAS的问题
    • 偏向锁
    • 轻量级锁
    • 各种锁的比较
  • synchronized相关
    • synchronized的可重入性
  • 本文小结

synchronized的知识结构图谱

下面给出synchronized的知识结构图谱，让大家在宏观上对synchronized有个理解，然后步步深入，彻底掌握synchronized。

synchronized的作用

线程安全是并发编程中的重要关注点，应该注意到的是，造成线程安全问题的主要诱因有两点，一是存在共享数据(也称临界资源)，二是存在多条线程共同操作共享数据。因此为了解决这个问题，我们可能需要这样一个方案，当存在多个线程操作共享数据时，需要保证同一时刻有且只有一个线程在操作共享数据，其他线程必须等到该线程处理完数据后再进行，这种方式有个高尚的名称叫互斥锁，即能达到互斥访问目的的锁，也就是说当一个共享数据被当前正在访问的线程加上互斥锁后，在同一个时刻，其他线程只能处于等待的状态，直到当前线程处理完毕释放该锁。在 Java 中，关键字 synchronized可以保证在同一个时刻，只有一个线程可以访问临界资源，同时我们还应该注意到synchronized另外一个重要的作用，synchronized可保证一个线程的变化(主要是共享数据的变化)被其他线程所看到（保证可见性，完全可以替代Volatile功能），这点确实也是很重要的。Java关键字synchronized具有使每个线程依次排队操作共享变量的功能，保证了并发场景下的线程安全问题，synchronized是对共享资源的独占，是一种悲观锁的思想，因此效率很差，而且容易造成线程的死锁，但synchronized是其他并发容器实现的基础。

synchronized解决线程安全问题

  • 原子性：synchronized保证语句块内操作是原子的
  • 可见性：synchronized保证可见性（通过“在执行unlock之前，必须先把此变量同步回主内存”实现）
  • 有序性：synchronized保证有序性（通过“一个变量在同一时刻只允许一条线程对其进行lock操作”）

synchronized的使用

synchronized是Java中的关键字，是一种同步锁。它修饰的对象有以下几种：

  1. 修饰一个实例方法，被修饰的方法称为同步方法，其作用的范围是整个方法，作用的对象是调用这个方法的对象；
  2. 修改一个静态方法，其作用的范围是整个静态方法，作用的对象是这个类的所有对象；
  3. 修饰一个代码块，被修饰的代码块称为同步语句块，其作用的范围是大括号{}括起来的代码，作用的对象是调用这个代码块的对象；
  4. 修改一个类(class对象)，其作用的范围是synchronized后面括号括起来的部分，作用主的对象是这个类的所有对象。

synchronized修饰实例方法

两个线程访问同一个实例对象的临界资源

package com.thread;public class SyncInstance implements Runnable{//共享资源(临界资源)private static int count=0;/*** synchronized 修饰实例方法*/public synchronized void increase(){count++;}@Overridepublic void run() {for(int i=0;i<500000;i++){increase();}}/*** join方法的作用是将子线程加入主线* 程，等子线程结束以后，主线程才结束* @param args* @throws InterruptedException*/public static void main(String[] args) throws InterruptedException{//一个实例对象SyncInstance instance=new SyncInstance();//两个线程Thread t1=new Thread(instance);Thread t2=new Thread(instance);t1.start();t2.start();t1.join();t2.join();System.out.println(count);}
}

运行结果：

运行结果分析：

上述代码中，我们开启两个线程操作同一个共享资源即变量count，由于count++;操作并不具备原子性，该操作是先读取值，然后写回一个新值，相当于原来的值加上1，分两步完成，如果第二个线程在第一个线程读取旧值和写回新值期间读取i的域值，那么第二个线程就会与第一个线程一起看到同一个值，并执行相同值的加1操作，这也就造成了线程安全失败，因此对于increase方法必须使用synchronized修饰，以便保证线程安全。此时我们应该注意到synchronized修饰的是实例方法increase，在这样的情况下，当前线程的锁便是实例对象instance，注意Java中的线程同步锁可以是任意对象。从代码执行结果来看确实是正确的，倘若我们没有使用synchronized关键字，其最终输出结果就很可能小于1000000，这便是synchronized关键字的作用。

这里我们还需要意识到，当一个线程正在访问一个对象的 synchronized 实例方法，那么其他线程不能访问该对象的其他 synchronized 方法，毕竟一个对象只有一把锁，当一个线程获取了该对象的锁之后，其他线程无法获取该对象的锁，所以无法访问该对象的其他synchronized实例方法，但是其他线程还是可以访问该实例对象的其他非synchronized方法，当然如果是一个线程 A 需要访问实例对象 obj1 的 synchronized 方法 f1(当前对象锁是obj1)，另一个线程 B 需要访问实例对象 obj2 的 synchronized 方法 f2(当前对象锁是obj2)，这样是允许的，因为两个实例对象锁并不同相同，此时如果两个线程操作数据并非共享的，线程安全是有保障的，遗憾的是如果两个线程操作的是共享数据，那么线程安全就有可能无法保证了，如下代码将演示出该现象

两个线程访问两个(不同)实例对象的临界资源

package com.thread;public class SyncInstanceError implements Runnable{private static int count=0;public synchronized void increase(){count++;}@Overridepublic void run(){for(int i=0;i<5000;i++){increase();}}public static void main(String[] args) throws InterruptedException {//第一个实例对象Thread t1=new Thread(new SyncInstanceError());//第二个实例对象Thread t2=new Thread(new SyncInstanceError());//两个线程对象t1.start();t2.start();t1.join();t2.join();System.out.println(count);}
}

运行结果：

上述代码与前面不同的是我们同时创建了两个新实例SyncInstanceError，然后启动两个不同的线程对共享变量count进行操作，但很遗憾操作结果是721296而不是期望结果1000000，因为上述代码犯了严重的错误，虽然我们使用synchronized修饰了increase方法，但却new了两个不同的实例对象，这也就意味着存在着两个不同的实例对象锁，因此t1和t2都会进入各自的对象锁，也就是说t1和t2线程使用的是不同的锁，因此线程安全是无法保证的。解决这种困境的的方式是将synchronized作用于静态的increase方法，这样的话，对象锁就当前类对象，由于无论创建多少个实例对象，但对于的类对象拥有只有一个，所有在这样的情况下对象锁就是唯一的。下面我们看看如何使用将synchronized作用于静态的increase方法。

synchronized修饰静态方法

当synchronized作用于静态方法时，其锁就是当前类的class对象锁。由于静态成员不专属于任何一个实例对象，是类成员，因此通过class对象锁可以控制静态成员的并发操作。看如下代码

package com.thread;public class StaticSyncInstance implements Runnable{private static int count=0;public static synchronized void increase(){count++;}@Overridepublic void run(){for(int i=0;i<500000;i++){increase();}}public static void main(String[] args) throws InterruptedException {//第一个实例对象Thread t1=new Thread(new StaticSyncInstance());//第二个实例对象Thread t2=new Thread(new StaticSyncInstance());t1.start();t2.start();t1.join();t2.join();System.out.println(count);}}

运行结果：

需要注意的是如果一个线程A调用一个实例对象的非static synchronized方法，而线程B需要调用这个实例对象所属类的静态 synchronized方法，是允许的，不会发生互斥现象，因为访问静态 synchronized 方法占用的锁是当前类的class对象，而访问非静态 synchronized 方法占用的锁是当前实例对象锁。

synchronized修饰同步代码块(实例对象)

除了使用关键字修饰实例方法和静态方法外，还可以使用同步代码块，在某些情况下，我们编写的方法体可能比较大，同时存在一些比较耗时的操作，而需要同步的代码又只有一小部分，如果直接对整个方法进行同步操作，可能会得不偿失，此时我们可以使用同步代码块的方式对需要同步的代码进行包裹，这样就无需对整个方法进行同步操作了，同步代码块的使用示例如下：

package com.thread;public class SynInstancePiece implements Runnable{private static SynInstancePiece instance =new SynInstancePiece();private static int count = 0;@Overridepublic void run() {//省略其他耗时操作....//锁对象为instancesynchronized(instance){for(int i=0;i<500000;i++){count++;}}}public static void main(String[] args) throws InterruptedException {Thread t1=new Thread(instance);Thread t2=new Thread(instance);t1.start();t2.start();t1.join();t2.join();System.out.println(count);}}

运行结果：

从代码看出，将synchronized作用于一个给定的实例对象instance，即当前实例对象就是锁对象，每次当线程进入synchronized包裹的代码块时就会要求当前线程持有instance实例对象锁，如果当前有其他线程正持有该对象锁，那么新到的线程就必须等待，这样也就保证了每次只有一个线程执行count++;操作。

synchronized修饰同步代码块(this对象和class对象)

当然除了instance作为对象外，我们还可以使用this对象(代表当前实例)或者当前类的class对象作为锁，如下代码：

this对象:

package com.thread;public class SynInstancePiece implements Runnable{private static SynInstancePiece instance =new SynInstancePiece();private static int count=0;@Overridepublic void run() {//省略其他耗时操作....//锁对象为instancesynchronized(this){for(int i=0;i<500000;i++){count++;}}}public static void main(String[] args) throws InterruptedException {Thread t1=new Thread(instance);Thread t2=new Thread(instance);t1.start();t2.start();t1.join();t2.join();System.out.println(count);}}

运行结果：

class对象

package com.thread;public class SynInstancePiece implements Runnable{private static SynInstancePiece instance =new SynInstancePiece();private static int count=0;@Overridepublic void run() {//省略其他耗时操作....//锁对象为instancesynchronized(SynInstancePiece.class){for(int i=0;i<500000;i++){count++;}}}public static void main(String[] args) throws InterruptedException {Thread t1=new Thread(instance);Thread t2=new Thread(instance);t1.start();t2.start();t1.join();t2.join();System.out.println(count);}
}

运行结果：

synchronized实现原理

在Java代码中，synchronized可使用在代码块和方法中，根据synchronized用的位置可以有这些使用场景：

如图，synchronized可以用在方法上也可以使用在代码块中，其中方法是实例方法和静态方法分别锁的是该类的实例对象和该类的对象。而使用在代码块中也可以分为三种，具体的可以看上面的表格。这里的需要注意的是：如果锁的是类对象的话，尽管new多个实例对象，但他们仍然是属于同一个类依然会被锁住，即线程之间保证同步关系。

现在我们已经初步了解了synchronized，看起来很简单，下面来分析下synchronized底层是怎样实现的。

理解Java对象头

在JVM中，对象在内存中的布局分为三块区域：对象头、实例数据和对齐填充。


实例变量：存放类的属性数据信息，包括父类的属性信息，如果是数组的实例部分还包括数组的长度，这部分内存按4字节对齐。

填充数据：由于虚拟机要求对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐。

HotSpot虚拟机的对象头分为两部分信息，第一部分用于存储对象自身运行时数据，如哈希码、GC分代年龄等，这部分数据的长度在32位和64位的虚拟机中分别为32位和64位。官方称为Mark Word。另一部分用于存储指向对象类型数据的指针(Klass pointer )，如果是数组对象的话，还会有一个额外的部分存储数组长度。对象头会关联到一个monitor对象。

Java头对象

由于对象头的信息是与对象自身定义的数据没有关系的额外存储成本，因此考虑到JVM的空间效率，Mark Word 被设计成为一个非固定的数据结构，以便存储更多有效的数据，它会根据对象本身的状态复用自己的存储空间。

Mark Word如下图

Monitor对象

Monitor：可以理解为一种同步工具或同步机制

1）互斥，一个Monitor在同一时间只能被一个线程持有，即Monitor中的所有方法都是互斥的
2）signal机制：如果条件变量不满足，允许正在持有Monitor的线程暂时释放特权，当变量条件满足时，当前线程可以唤醒正在等待该条件变量的线程，然后重新获取Monitor的持有权

所有的Java对象是天生的Monitor，每一个Java对象都有成为Monitor的潜质，因为在Java的设计中 ，每一个Java对象自打娘胎里出来就带了一把看不见的锁，它叫做内部锁或者Monitor锁(Monitor可以与对象一起创建销毁或当线程试图获取对象锁时自动生成)。
Monitor的本质是依赖于底层操作系统的Mutex Lock实现，操作系统实现线程之间的切换需要从用户态到内核态的转换，成本非常高。

其中轻量级锁和偏向锁是Java 6 对 synchronized 锁进行优化后新增加的，稍后我们会简要分析。这里我们主要分析一下重量级锁也就是通常说synchronized的对象锁，锁标识位为10，其中指针指向的是monitor对象（也称为管程或监视器锁）的起始地址。每个对象都存在着一个 monitor 与之关联，对象与其 monitor 之间的关系有存在多种实现方式，如monitor可以与对象一起创建销毁或当线程试图获取对象锁时自动生成，但当一个 monitor 被某个线程持有后，它便处于锁定状态。在Java虚拟机(HotSpot)中，monitor是由ObjectMonitor实现的，其主要数据结构如下（位于HotSpot虚拟机源码ObjectMonitor.hpp文件，C++实现的）

 ObjectMonitor() {_header       = NULL;_count        = 0;_waiters      = 0,_recursions   = 0;  // 线程重入次数_object       = NULL;  // 存储Monitor对象_owner        = NULL;  // 持有当前线程的owner_WaitSet      = NULL;  // wait状态的线程列表_WaitSetLock  = 0 ;_Responsible  = NULL ;_succ         = NULL ;_cxq          = NULL ;  // 单向列表FreeNext      = NULL ;_EntryList    = NULL ;  // 处于等待锁状态block状态的线程列表_SpinFreq     = 0 ;_SpinClock    = 0 ;OwnerIsThread = 0 ;_previous_owner_tid = 0;}

synchronized底层的源码就是引入了ObjectMonitor，大家说熟悉的锁升级过程，其实就是在源码里面，调用了不同的实现去获取获取锁，失败就调用更高级的实现，最后升级完成。

ObjectMonitor中有两个队列，_WaitSet 和 _EntryList，用来保存ObjectWaiter对象列表( 每个等待锁的线程都会被封装成ObjectWaiter对象)，_owner指向持有ObjectMonitor对象的线程，当多个线程同时访问一段同步代码时，首先会进入 _EntryList 集合，当线程获取到对象的monitor 后进入 _Owner 区域并把monitor中的owner变量设置为当前线程同时monitor中的计数器count加1，若线程调用 wait() 方法，将释放当前持有的monitor，owner变量恢复为null，count自减1，同时该线程进入 WaitSe t集合中等待被唤醒。若当前线程执行完毕也将释放monitor(锁)并复位变量的值，以便其他线程进入获取monitor(锁)。如下图所示


由此看来，monitor对象存在于每个Java对象的对象头中(存储的指针的指向)，synchronized锁便是通过这种方式获取锁的，也是为什么Java中任意对象可以作为锁的原因，同时也是notify/notifyAll/wait等方法存在于顶级对象Object中的原因，有了上述知识基础后，下面我们将进一步分析synchronized在字节码层面的具体语义实现。

Synchronized核心组件

  1. Wait Set：哪些调用 wait 方法被阻塞的线程被放置在这里；
  2. Contention List：竞争队列，所有请求锁的线程首先被放在这个竞争队列中；
  3. Entry List：Contention List 中那些有资格成为候选资源的线程被移动到 Entry List 中；
  4. OnDeck：任意时刻，最多只有一个线程正在竞争锁资源，该线程被成为 OnDeck；
  5. Owner：当前已经获取到所资源的线程被称为 Owner；
  6. !Owner：当前释放锁的线程。

Synchronized实现细节

  1. JVM 每次从队列的尾部取出一个数据用于锁竞争候选者（OnDeck），但是并发情况下，ContentionList 会被大量的并发线程进行 CAS 访问，为了降低对尾部元素的竞争，JVM 会将一部分线程移动到 EntryList 中作为候选竞争线程。
  2. Owner 线程会在 unlock 时，将 ContentionList 中的部分线程迁移到 EntryList 中，并指定EntryList 中的某个线程为 OnDeck 线程（一般是最先进去的那个线程）。
  3. Owner 线程并不直接把锁传递给 OnDeck 线程，而是把锁竞争的权利交给 OnDeck，OnDeck 需要重新竞争锁。这样虽然牺牲了一些公平性，但是能极大的提升系统的吞吐量，在JVM 中，也把这种选择行为称之为“竞争切换”。
  4. OnDeck 线程获取到锁资源后会变为 Owner 线程，而没有得到锁资源的仍然停留在 EntryList中。如果 Owner 线程被 wait 方法阻塞，则转移到 WaitSet 队列中，直到某个时刻通过notify或者 notifyAll 唤醒，会重新进去 EntryList 中。
  5. 处于 ContentionList、EntryList、WaitSet 中的线程都处于阻塞状态，该阻塞是由操作系统来完成的（Linux 内核下采用 pthread_mutex_lock 内核函数实现的）。
  6. Synchronized 是非公平锁。 Synchronized 在线程进入 ContentionList 时，等待的线程会先尝试自旋获取锁，如果获取不到就进入 ContentionList，这明显对于已经进入队列的线程是不公平的，还有一个不公平的事情就是自旋获取锁的线程还可能直接抢占 OnDeck 线程的锁资源。
  7. 每个对象都有个 monitor 对象，加锁就是在竞争 monitor 对象，代码块加锁是在前后分别加上 monitorenter 和 monitorexit 指令来实现的，方法加锁是通过一个标记位来判断的
  8. synchronized 是一个重量级操作，需要调用操作系统相关接口，性能是低效的，有可能给线程加锁消耗的时间比有用操作消耗的时间更多。
  9. Java1.6，synchronized 进行了很多的优化，有适应自旋、锁消除、锁粗化、轻量级锁及偏向锁等，效率有了本质上的提高。在之后推出的 Java1.7 与 1.8 中，均对该关键字的实现机理做了优化。引入了偏向锁和轻量级锁。都是在对象头中有标记位，不需要经过操作系统加锁。
  10. 锁可以从偏向锁升级到轻量级锁，再升级到重量级锁。这种升级过程叫做锁膨胀；
  11. JDK 1.6 中默认是开启偏向锁和轻量级锁，可以通过-XX:-UseBiasedLocking 来禁用偏向锁。

操作系统的用户态和内核态

Linux系统的体系结构大家大学应该都接触过了，分为用户空间（应用程序的活动空间）和内核。

我们所有的程序都在用户空间运行，进入用户运行状态也就是（用户态），但是很多操作可能涉及内核运行，比我I/O，我们就会进入内核运行状态（内核态）。


这个过程是很复杂的，也涉及很多值的传递，我简单概括下流程：

  1. 用户态把一些数据放到寄存器，或者创建对应的堆栈，表明需要操作系统提供的服务。
  2. 用户态执行系统调用（系统调用是操作系统的最小功能单位）。
  3. CPU切换到内核态，跳到对应的内存指定的位置执行指令。
  4. 系统调用处理器去读取我们先前放到内存的数据参数，执行程序的请求。
  5. 调用完成，操作系统重置CPU为用户态返回结果，并执行下个指令。

所以大家一直说，1.6之前是重量级锁，没错，但是他重量的本质，是ObjectMonitor调用的过程，以及Linux内核的复杂运行机制决定的，大量的系统资源消耗，所以效率才低。

还有两种情况也会发生内核态和用户态的切换：异常事件和外围设备的中断，大家也可以了解下。

对象锁（monitor）机制

现在我们来看看synchronized的具体底层实现。先写一个简单的测试例子

public class SynchronizedTest {//注意方法为public的public static synchronized void method() {System.out.println("hello");}public static void main(String[] args) {synchronized (SynchronizedTest.class) {System.out.println("world");}method();}
}

编译以后得到字节码文件，查看synchronized底层结构

synchronizedTest类的完整字节码文件

Classfile /D:/SynchronizedTest.classLast modified 2021-4-6; size 654 bytesMD5 checksum 7c70ddf4884c347a24d6553d969fb830Compiled from "SynchronizedTest.java"
public class SynchronizedTestminor version: 0major version: 52flags: ACC_PUBLIC, ACC_SUPER
Constant pool:#1 = Methodref          #8.#22         // java/lang/Object."<init>":()V#2 = Fieldref           #23.#24        // java/lang/System.out:Ljava/io/PrintStream;#3 = String             #25            // hello#4 = Methodref          #26.#27        // java/io/PrintStream.println:(Ljava/lang/String;)V#5 = Class              #28            // SynchronizedTest#6 = String             #29            // world#7 = Methodref          #5.#30         // SynchronizedTest.method:()V#8 = Class              #31            // java/lang/Object#9 = Utf8               <init>#10 = Utf8               ()V#11 = Utf8               Code#12 = Utf8               LineNumberTable#13 = Utf8               method#14 = Utf8               main#15 = Utf8               ([Ljava/lang/String;)V#16 = Utf8               StackMapTable#17 = Class              #32            // "[Ljava/lang/String;"#18 = Class              #31            // java/lang/Object#19 = Class              #33            // java/lang/Throwable#20 = Utf8               SourceFile#21 = Utf8               SynchronizedTest.java#22 = NameAndType        #9:#10         // "<init>":()V#23 = Class              #34            // java/lang/System#24 = NameAndType        #35:#36        // out:Ljava/io/PrintStream;#25 = Utf8               hello#26 = Class              #37            // java/io/PrintStream#27 = NameAndType        #38:#39        // println:(Ljava/lang/String;)V#28 = Utf8               SynchronizedTest#29 = Utf8               world#30 = NameAndType        #13:#10        // method:()V#31 = Utf8               java/lang/Object#32 = Utf8               [Ljava/lang/String;#33 = Utf8               java/lang/Throwable#34 = Utf8               java/lang/System#35 = Utf8               out#36 = Utf8               Ljava/io/PrintStream;#37 = Utf8               java/io/PrintStream#38 = Utf8               println#39 = Utf8               (Ljava/lang/String;)V
{public SynchronizedTest();descriptor: ()Vflags: ACC_PUBLICCode:stack=1, locals=1, args_size=10: aload_01: invokespecial #1                  // Method java/lang/Object."<init>":()V4: returnLineNumberTable:line 1: 0public static synchronized void method();descriptor: ()Vflags: ACC_PUBLIC, ACC_STATIC, ACC_SYNCHRONIZEDCode:stack=2, locals=0, args_size=00: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;3: ldc           #3                  // String hello5: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V8: returnLineNumberTable:line 4: 0line 5: 8public static void main(java.lang.String[]);descriptor: ([Ljava/lang/String;)Vflags: ACC_PUBLIC, ACC_STATICCode:stack=2, locals=3, args_size=10: ldc           #5                  // class SynchronizedTest2: dup3: astore_14: monitorenter5: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;8: ldc           #6                  // String world10: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V13: aload_114: monitorexit15: goto          2318: astore_219: aload_120: monitorexit21: aload_222: athrow23: invokestatic  #7                  // Method method:()V26: returnException table:from    to  target type5    15    18   any18    21    18   anyLineNumberTable:line 9: 0line 10: 5line 11: 13line 12: 23line 13: 26StackMapTable: number_of_entries = 2frame_type = 255 /* full_frame */offset_delta = 18locals = [ class "[Ljava/lang/String;", class java/lang/Object ]stack = [ class java/lang/Throwable ]frame_type = 250 /* chop */offset_delta = 4
}
SourceFile: "SynchronizedTest.java"D:\>

分析字节码源码可知：

同步代码块源码解析

同步代码块是使用MonitorEnter和MoniterExit指令实现的，在编译时，MonitorEnter指令被插入到同步代码块的开始位置，MoniterExit指令被插入到同步代码块的结束位置和异常位置。任何对象都有一个Monitor与之关联，当Monitor被持有后将处于锁定状态。MonitorEnter指令会尝试获取Monitor的持有权，即尝试获取锁。

同步方法源码解析

同步方法依赖flags标志ACC_SYNCHRONIZED实现。ACC_SYNCHRONIZED标志表示方法为同步方法，非静态方法（没有ACC_STATIC标志），使用调用该方法的对象作为对象锁；如果为静态方法（有ACC_STATIC标志），使用该方法所属的Class类在JVM的内部对象作为类锁。

下面是摘自《Java虚拟机规范》的话：

Java虚拟机可以支持方法级的同步和方法内部一段指令序列的同步，这两种同步结构都是使用管程（Monitor）来支持的。
方法级的同步是隐式，即无需通过字节码指令来控制的，它实现在方法调用和返回操作之中。虚拟机可以从方法常量池中的方法表结构中的ACC_SYNCHRONIZED访问标志区分一个方法是否同步方法。当方法调用时，调用指令将会检查方法的ACC_SYNCHRONIZED访问标志是否被设置，如果设置了，执行线程将先持有管程，然后再执行方法，最后在方法完成（无论是正常完成还是非正常完成）时释放管程。在方法执行期间，执行线程持有了管程，其他任何线程都无法再获得同一个管程。如果一个同步方法执行期间抛出了异常，并且在方法内部无法处理此异常，那这个同步方法所持有的管程将在异常抛到同步方法之外时自动释放。
同步一段指令集序列通常是由Java语言中的synchronized块来表示的，Java虚拟机的指令集中有monitorenter和monitorexit两条指令来支持synchronized关键字的语义，正确实现synchronized关键字需要编译器与Java虚拟机两者协作支持。
Java虚拟机中的同步（Synchronization）基于进入和退出管程（Monitor）对象实现。无论是显式同步（有明确的monitorenter和monitorexit指令）还是隐式同步（依赖方法调用和返回指令实现的）都是如此
编译器必须确保无论方法通过何种方式完成，方法中调用过的每条monitorenter指令都必须有执行其对应monitorexit指令，而无论这个方法是正常结束还是异常结束。为了保证在方法异常完成时monitorenter和monitorexit指令依然可以正确配对执行，编译器会自动产生一个异常处理器，这个异常处理器声明可处理所有的异常，它的目的就是用来执行monitorexit指令。

上面的代码中有一个同步代码块，锁住的是类对象，并且还有一个同步静态方法，锁住的依然是该类的类对象。编译之后，切换到SynchronizedTest.class的同级目录之后，然后用javap -v SynchronizedTest.class查看字节码文件：


如图，上面用红色标识的部分就是需要注意的部分了，这也是添synchronized关键字之后独有的。执行同步代码块后首先要先执行monitorenter指令，退出的时候monitorexit指令。通过分析之后可以看出，使用synchronized进行同步，其关键就是必须要对对象的监视器monitor进行获取，当线程获取monitor后才能继续往下执行，否则就只能等待。而这个获取的过程是互斥的，即同一时刻只有一个线程能够获取到monitor。上面的demo中在执行完同步代码块之后紧接着再会去执行一个静态同步方法，而这个方法锁的对象依然就这个类对象，那么这个正在执行的线程还需要获取该锁吗？答案是不必的，从上图中就可以看出来，执行静态同步方法的时候就只有一条monitorexit指令，并没有monitorenter获取锁的指令。这就是锁的重入性，即在同一锁程中，线程不需要再次获取同一把锁。synchronized先天具有重入性。每个对象拥有一个计数器，当线程获取该对象锁后，计数器就会加一，释放锁后就会将计数器减一。任意一个对象都拥有自己的监视器，当这个对象由同步块或者这个对象的同步方法调用时，执行方法的线程必须先获取该对象的监视器才能进入同步块和同步方法，如果没有获取到监视器的线程将会被阻塞在同步块和同步方法的入口处，进入到BLOCKED状态。

JVM对synchronized的锁优化

Synchronized是通过对象内部的一个叫做监视器锁（monitor）来实现的，监视器锁本质又是依赖于底层的操作系统的Mutex Lock（互斥锁）来实现的。而操作系统实现线程之间的切换需要从用户态转换到核心态，这个成本非常高，状态之间的转换需要相对比较长的时间，这就是为什么Synchronized效率低的原因。因此，这种依赖于操作系统Mutex Lock所实现的锁我们称之为“重量级锁”。

Java SE 1.6为了减少获得锁和释放锁带来的性能消耗，引入了“偏向锁”和“轻量级锁”：锁一共有4种状态，级别从低到高依次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态。锁可以升级但不能降级。

锁升级简化过程

锁的状态总共有四种，无锁状态、偏向锁、轻量级锁和重量级锁。随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁，但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级，关于重量级锁，前面我们已详细分析过，下面我们将介绍偏向锁和轻量级锁以及JVM的其他优化手段，这里并不打算深入到每个锁的实现和转换过程更多地是阐述Java虚拟机所提供的每个锁的核心优化思想，毕竟涉及到具体过程比较繁琐，如需了解详细过程可以查阅《深入理解Java虚拟机原理》。


升级方向：


对象创建出来是无锁；第一个线程访问它，就变成偏向锁；再有其他线程来访问，就有了竞争，升级为cas；cas转几次，说明竞争比较激烈，升级为重量级锁。整个过程是单向的不可逆。

无锁状态(CAS)

什么是CAS

使用锁时，线程获取锁是一种悲观锁策略，即假设每一次执行临界区代码都会产生冲突，所以当前线程获取到锁的时候同时也会阻塞其他线程获取该锁。而CAS操作（又称为无锁操作）是一种乐观锁策略，它假设所有线程访问共享资源的时候不会出现冲突，既然不会出现冲突自然而然就不会阻塞其他线程的操作。因此，线程就不会出现阻塞停顿的状态。那么，如果出现冲突了怎么办？无锁操作是使用CAS(compare and swap)又叫做比较交换来鉴别线程是否出现冲突，出现冲突就重试当前操作直到没有冲突为止。

CAS的操作过程

CAS比较交换的过程可以通俗的理解为CAS(V,O,N)，包含三个值分别为：V 内存地址存放的实际值；O 预期的值（旧值）；N 更新的新值。当V和O相同时，也就是说旧值和内存中实际的值相同表明该值没有被其他线程更改过，即该旧值O就是目前来说最新的值了，自然而然可以将新值N赋值给V。反之，V和O不相同，表明该值已经被其他线程改过了则该旧值O不是最新版本的值了，所以不能将新值N赋给V，返回V即可。当多个线程使用CAS操作一个变量时，只有一个线程会成功，并成功更新，其余会失败。失败的线程会重新尝试，当然也可以选择挂起线程。

CAS的实现需要硬件指令集的支撑，在JDK1.5后虚拟机才可以使用处理器提供的CMPXCHG指令实现。

synchronized VS CAS

元老级的synchronized(未优化前)最主要的问题是：在存在线程竞争的情况下会出现线程阻塞和唤醒锁带来的性能问题，因为这是一种互斥同步（阻塞同步）。而CAS并不是武断的间线程挂起，当CAS操作失败后会进行一定的尝试，而非进行耗时的挂起唤醒的操作，因此也叫做非阻塞同步。这是两者主要的区别。

CAS的应用场景

在J.U.C包中利用CAS实现类有很多，可以说是支撑起整个java.util.concurrent包的实现，在Lock实现中会有CAS改变state变量，在atomic包中的实现类也几乎都是用CAS实现。

CAS的问题

1. ABA问题

因为CAS会检查旧值有没有变化，这里存在这样一个有意思的问题。比如一个旧值A变为了成B，然后再变成A，刚好在做CAS时检查发现旧值并没有变化依然为A，但是实际上的确发生了变化。解决方案可以沿袭数据库中常用的乐观锁方式，添加一个版本号可以解决。原来的变化路径A->B->A就变成了1A->2B->3C。Java这么优秀的语言，当然在Java 1.5后的atomic包中提供了AtomicStampedReference来解决ABA问题，解决思路就是这样的。

2. 自旋时间过长

使用CAS时非阻塞同步，也就是说不会将线程挂起，会自旋（无非就是一个死循环）进行下一次尝试，如果这里自旋时间过长对性能是很大的消耗。如果JVM能支持处理器提供的pause指令，那么在效率上会有一定的提升。

3. 只能保证一个共享变量的原子操作

当对一个共享变量执行操作时CAS能保证其原子性，如果对多个共享变量进行操作，CAS就不能保证其原子性。有一个解决方案是利用对象整合多个共享变量，即一个类中的成员变量就是这几个共享变量。然后将这个对象做CAS操作就可以保证其原子性。atomic中提供了AtomicReference来保证引用对象之间的原子性。

偏向锁

偏向锁是Java 6之后加入的新锁，它是一种针对加锁操作的优化手段，经过研究发现，在大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，因此为了减少同一线程获取锁(会涉及到一些CAS操作,耗时)的代价而引入偏向锁。偏向锁的核心思想是，如果一个线程获得了锁，那么锁就进入偏向模式，此时Mark Word 的结构也变为偏向锁结构，当这个线程再次请求锁时，无需再做任何同步操作，即获取锁的过程，这样就省去了大量有关锁申请的操作，从而也就提供程序的性能。所以，对于没有锁竞争的场合，偏向锁有很好的优化效果，毕竟极有可能连续多次是同一个线程申请相同的锁。但是对于锁竞争比较激烈的场合，偏向锁就失效了，因为这样场合极有可能每次申请锁的线程都是不相同的，因此这种场合下不应该使用偏向锁，否则会得不偿失，需要注意的是，偏向锁失败后，并不会立即膨胀为重量级锁，而是先升级为轻量级锁。

偏向锁的获取

当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，以后该线程在进入和退出同步块时不需要进行CAS操作来加锁和解锁，只需简单地测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁。如果测试成功，表示线程已经获得了锁。如果测试失败，则需要再测试一下Mark Word中偏向锁的标识是否设置成1（表示当前是偏向锁）：如果没有设置，则使用CAS竞争锁；如果设置了，则尝试使用CAS将对象头的偏向锁指向当前线程。

偏向锁的撤销

偏向锁使用了一种等到竞争出现才释放锁的机制，所以当其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁。


如图，偏向锁的撤销，需要等待全局安全点（在这个时间点上没有正在执行的字节码）。它会首先暂停拥有偏向锁的线程，然后检查持有偏向锁的线程是否活着，如果线程不处于活动状态，则将对象头设置成无锁状态；如果线程仍然活着，拥有偏向锁的栈会被执行，遍历偏向对象的锁记录，栈中的锁记录和对象头的Mark Word要么重新偏向于其他线程，要么恢复到无锁或者标记对象不适合作为偏向锁，最后唤醒暂停的线程。

下图线程1展示了偏向锁获取的过程，线程2展示了偏向锁撤销的过程。

如何关闭偏向锁

偏向锁在Java 6和Java 7里是默认启用的，但是它在应用程序启动几秒钟之后才激活，如有必要可以使用JVM参数来关闭延迟：-XX:BiasedLockingStartupDelay=0。如果你确定应用程序里所有的锁通常情况下处于竞争状态，可以通过JVM参数关闭偏向锁：-XX:-UseBiasedLocking=false，那么程序默认会进入轻量级锁状态。

轻量级锁

倘若偏向锁失败，虚拟机并不会立即升级为重量级锁，它还会尝试使用一种称为轻量级锁的优化手段(1.6之后加入的)，此时Mark Word 的结构也变为轻量级锁的结构。轻量级锁能够提升程序性能的依据是“对绝大部分的锁，在整个同步周期内都不存在竞争”，注意这是经验数据。需要了解的是，轻量级锁所适应的场景是线程交替执行同步块的场合，如果存在同一时间访问同一锁的场合，就会导致轻量级锁膨胀为重量级锁。

加锁

线程在执行同步块之前，JVM会先在当前线程的栈桢中创建用于存储锁记录的空间，并将对象头中的Mark Word复制到锁记录中，官方称为Displaced Mark Word。然后线程尝试使用CAS将对象头中的Mark Word替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败，表示其他线程竞争锁，当前线程便尝试使用自旋来获取锁。

解锁

轻量级解锁时，会使用原子的CAS操作将Displaced Mark Word替换回到对象头，如果成功，则表示没有竞争发生。如果失败，表示当前锁存在竞争，锁就会膨胀成重量级锁。下图是两个线程同时争夺锁，导致锁膨胀的流程图。


因为自旋会消耗CPU，为了避免无用的自旋（比如获得锁的线程被阻塞住了），一旦锁升级成重量级锁，就不会再恢复到轻量级锁状态。当锁处于这个状态下，其他线程试图获取锁时，都会被阻塞住，当持有锁的线程释放锁之后会唤醒这些线程，被唤醒的线程就会进行新一轮的夺锁之争。

轻量级锁分类：自旋锁、自适应自旋锁

轻量级锁失败后，虚拟机为了避免线程真实地在操作系统层面挂起，还会进行一项称为自旋锁的优化手段。这是基于在大多数情况下，线程持有锁的时间都不会太长，如果直接挂起操作系统层面的线程可能会得不偿失，毕竟操作系统实现线程之间的切换时需要从用户态转换到核心态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，因此自旋锁会假设在不久将来，当前的线程可以获得锁，因此虚拟机会让当前想要获取锁的线程做几个空循环(这也是称为自旋的原因)，一般不会太久，可能是50个循环或100循环，在经过若干次循环后，如果得到锁，就顺利进入临界区。如果还不能获得锁，那就会将线程在操作系统层面挂起，这就是自旋锁的优化方式，这种方式确实也是可以提升效率的。最后没办法也就只能升级为重量级锁了。

自旋锁

当有另外一个线程来竞争锁时，这个线程会在原地循环等待，而不是把该线程给阻塞，直到那个获得锁的线程释放锁之后，这个线程就可以马上去竞争获取锁
自旋锁问题：
1）性能：当同步代码执行时间过长，其它自旋转等待的线程会一直消耗cpu
2）无法连续获取锁：当持有锁的线程释放锁，其它等待的线程会和当前线程一起来竞争锁，当前线程不一定能再次获取到锁，可能一直获取不到，需要一直在原地旋转消耗cpu
问题解决：
给线程设置空旋转次数，超过设置的次数，轻量级锁膨胀升级为重量级锁，默认情况下，自旋的次数为10次，用户可以通过-XX:PreBlockSpin来进行更改

自适应自旋锁

线程空循环等待的自旋次数并非是固定的，而是会动态着根据实际情况来改变自旋等待的次数
1）当线程1刚刚释放了锁，线程2获得了锁，当线程1在线程2执行过程中，想再次获取锁，线程1只能原地等待，但jvm认为线程1刚获取到锁，会增加线程1的自旋次数
2）当某个线程自旋后，很少成功获取到锁，那么以后这个线程想要再获取锁时，可能直接忽略自旋，直接升级为重量级锁，以免空旋转浪费资源

各种锁的比较

synchronized相关

synchronized的可重入性

从互斥锁的设计上来说，当一个线程试图操作一个由其他线程持有的对象锁的临界资源时，将会处于阻塞状态，但当一个线程再次请求自己持有对象锁的临界资源时，这种情况属于重入锁，请求将会成功，在java中synchronized是基于原子性的内部锁机制，是可重入的，因此在一个线程调用synchronized方法的同时在其方法体内部调用该对象另一个synchronized方法，也就是说一个线程得到一个对象锁后再次请求该对象锁，是允许的，这就是synchronized的可重入性。如下：

package cn.wideth.util;public class AccountSync implements Runnable{private static AccountSync instance=new AccountSync();private static int count=0;private static int j=0;@Overridepublic void run() {for(int i=0;i<500000;i++){//this,当前实例对象锁synchronized(this){count++;//synchronized的可重入性increase();}}}public synchronized void increase(){j = j + 2;}public static void main(String[] args) throws InterruptedException {Thread t1=new Thread(instance);t1.start();t1.join();System.out.println("count -->" + count);System.out.println("j -->" + j);}}

运行结果


正如代码所演示的，在获取当前实例对象锁后进入synchronized代码块执行同步代码，并在代码块中调用了当前实例对象的另外一个synchronized方法，再次请求当前实例锁时，将被允许，进而执行方法体代码，这就是重入锁最直接的体现，需要特别注意另外一种情况，当子类继承父类时，子类也是可以通过可重入锁调用父类的同步方法。注意由于synchronized是基于monitor实现的，因此每次重入，monitor中的计数器仍会加1。

本文小结

synchronized是来解决线程安全最原始的解决方案，本文详细介绍了synchronized的应用，底层原理以及synchronized锁升级相关的知识。

深入理解并发的关键字-synchronized相关推荐

  1. 深入理解并发的关键字-volatile

    volatile是Java提供的一种轻量级的同步机制.Java 语言包含两种内在的同步机制:同步块(或方法)和 volatile 变量,相比于synchronized(synchronized通常称为 ...

  2. 深入理解并发内存模型||JMM与内存屏障||多核并发缓存架构 ||JMM内存模型||volatile 关键字的作用 ||JMM 数据原子操作||JMM缓存不一致的问题

    深入理解并发内存模型||JMM与内存屏障 多核并发缓存架构 JMM内存模型 volatile 关键字的作用 JMM 数据原子操作 JMM缓存不一致的问题

  3. Java 并发编程：Synchronized 及其实现原理

    作者:liuxiaopeng 原文链接: www.cnblogs.com/paddix/p/5367116.html 一.Synchronized的基本使用 Synchronized是Java中解决并 ...

  4. 【java】java 关键字: synchronized详解

    1.概述 转载:关键字: synchronized详解 [Java]Synchronized 有几种用法 [java] 从hotspot底层对象结构理解锁膨胀升级过程 [java]动态高并发时为什么推 ...

  5. 深入理解Java并发之synchronized实现原理

    [版权申明]未经博主同意,谢绝转载!(请尊重原创,博主保留追究权) http://blog.csdn.net/javazejian/article/details/72828483 出自[zejian ...

  6. date对象加十分钟_一张图讲解对象锁和关键字synchronized修饰方法(代码块)

    做一个积极的人 编码.改bug.提升自己 我有一个乐园,面向编程,春暖花开! 每个对象在出生的时候就有一把钥匙(监视器Monitor),那么被synchronized 修饰的方法相当于给方法加了一个锁 ...

  7. 自顶向下彻底理解 Java 中的 Synchronized

    阅读本文至少要知道 synchronized 用来是干什么的... 需要的前置知识还有 Java 对象头和 Java 字节码的部分知识. synchronized 的使用 synchronized 有 ...

  8. Java并发编程实例(synchronized）

    此处用一个小程序来说明一下,逻辑是一个计数器(int i):主要的逻辑功能是,如果同步监视了资源i,则不输出i的值,但如果没有添加关键字synchronized,因为是两个线程并发执行,所以会输出i的 ...

  9. java并发中的Synchronized关键词

    文章目录 为什么要同步 Synchronized关键词 Synchronized Instance Methods Synchronized Static Methods Synchronized B ...

最新文章

  1. easyui datagrid 表头 sort 排序
  2. [JSOI2008]火星人
  3. hdu 2005 第几天？（c语言）
  4. mysql 自定义函数function，函数和存储过程的区别
  5. php webview,Android：控件WebView显示网页 – tinyphp – 博客园
  6. 创意设计师变圆周率为彩色艺术品
  7. 深度学习-tensorflow1.x- 理解 经过softmax_cross_entropy_with_logit后 随机梯度下降的过程
  8. 【作者面对面问答】包邮送《Redis 5设计与源码分析》5本
  9. 以用户为中心的SNS站点数据库设计及实现
  10. windows编译python扩展Unable to find vcvarsall
  11. 考研调剂 计算机科学 软件,2020年四川大学计算机学院（软件学院）考研调剂信息...
  12. java计算机毕业设计家庭安防系统MyBatis+系统+LW文档+源码+调试部署
  13. 联想服务器重装系统后usb无法启动,联想启天装win7系统的详细教程完美解决USB不能用的问题...
  14. python画k线_python下画k线
  15. 《经济学原理》——读书笔记（二）
  16. 彻底关闭win10的自动更新
  17. 炒股怎么炒？新手怎么学炒股？
  18. USB 传输方式（控制）
  19. Linux下minikube启动失败(It seems like the kubelet isn't running or healthy)
  20. Ubuntu 20.04 LTS 关闭 Swap 分区

热门文章

  1. 最好的计划是略有闲余的计划，用于缓冲必然出现的错误与突发事件(转)
  2. 戴尔XPS-13超级本赏析
  3. 一起谈.NET技术，ASP.NET MVC2.0在Tab页中实现异步无刷新分页
  4. 在CentOS5.4上安装Git
  5. Best Friend Forever
  6. Firefox Test Pilot 计划正式关闭
  7. 查看ftp创建的用户
  8. 使用Spire.Barcode程序库生成二维码
  9. oracle 学习之：建视图时报ora-01031
  10. 如何使用Database2Sharp进行代码生成