Java关键字——synchronized

大大源码 • 2023年3月8日 am12:50 • 未分类

以下内容均从网上摘抄整理而来，仅用于本人知识积累

一、认识 Synchronized

synchornized 是 Java 中的一个关键字，解决的是多个线程之间访问资源的同步性，synchronized 关键字可以保证被它修饰的方法或者代码块在任意时刻只能有一个线程执行。

另外，在 Java 早期版本中，synchronized 属于重量级锁，效率低下。

重量级锁：其他线程试图获取锁时，都会被阻塞，只有持有锁的线程释放锁之后才会唤醒这些线程，进行竞争。

二、应用场景

保证线程安全，解决多线程中的并发同步问题（实现的是阻塞型并发），具体场景如下：

在这里插入图片描述
这里的需要注意的是：如果锁的是类对象的话，尽管new多个实例对象，但他们仍然是属于同一个类依然会被锁住，即线程之间保证同步关系。

synchronized 最主要的三种使用方式：

修饰实例方法：作用于当前对象实例加锁，进入同步代码前要获得当前对象实例的锁
synchronized void method() {
   //业务代码
}
2.修饰静态方法: 也就是给当前类加锁，会作用于类的所有对象实例，进入同步代码前要获得当前 class 的锁。因为静态成员不属于任何一个实例对象，是类成员（ static 表明这是该类的一个静态资源，不管 new 了多少个对象，只有一份）。所以，如果一个线程 A 调用一个实例对象的非静态 synchronized 方法，而线程 B 需要调用这个实例对象所属类的静态 synchronized 方法，是允许的，不会发生互斥现象，因为访问静态 synchronized 方法占用的锁是当前类的锁，而访问非静态 synchronized 方法占用的锁是当前实例对象锁。
synchronized static void method() {
   //业务代码
}
3.修饰代码块：指定加锁对象，对给定对象/类加锁。synchronized(this|object) 表示进入同步代码库前要获得给定对象的锁。synchronized(类.class) 表示进入同步代码前要获得当前 class 的锁
synchronized(this) {
   //业务代码
}
总结：

synchronized 关键字加到 static 静态方法和 synchronized(class) 代码块上都是是给 Class 类上锁。

synchronized 关键字加到实例方法上是给对象实例上锁。

尽量不要使用 synchronized(String a) 因为 JVM 中，字符串常量池具有缓存功能！

三、底层原理

1. Java对象的构成

在介绍底层原理之前，先简单聊一下Java对象的构成。

在 JVM（Java虚拟机）中，对象在内存中分为三块区域：对象头、实例数据、对其填充

对象头：

Mark Word（标记字段）：默认存储对象的HashCode，分代年龄和锁标志位信息。它会根据对象的状态复用自己的存储空间，也就是说在运行期间Mark Word里存储的数据会随着锁标志位的变化而变化。

Klass Point（类型指针）：对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。

实例数据：

这部分主要是存放类的数据信息，父类的信息。

对其填充：

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

Tip：不知道大家有没有被问过一个空对象占多少个字节？就是8个字节，是因为对齐填充的关系，不到8个字节对其填充会帮我们自动补齐。

2. synchronized如何实现原子性、有序性、可见性

1）. 有序性

as-if-serial

CPU会为了优化我们的代码，会对我们程序进行重排序。不管编译器和CPU如何重排序，必须保证在单线程情况下程序的结果是正确的，还有就是有数据依赖的也是不能重排序的。

2）. 可见性

通过Java内存模型（JMM）实现

JMM并不是实际存在的，而是一套规范，这个规范描述了很多java程序中各种变量（线程共享变量）的访问规则，以及在JVM中将变量存储到内存和从内存中读取变量这样的底层细节，Java内存模型是对共享数据的可见性、有序性、和原子性的规则和保障。

3）. 原子性

其实他保证原子性很简单，确保同一时间只有一个线程能拿到锁，能够进入代码块这就够了。

这几个是我们使用锁经常用到的特性，那synchronized他自己本身又具有哪些特性呢？

3. synchronized 本身具备的特性

1）. 可重入性

synchronized锁对象的时候有个计数器，他会记录下线程获取锁的次数，在执行完对应的代码块之后，计数器就会-1，直到计数器清零，就释放锁了。

那可重入有什么好处呢？

可以避免一些死锁的情况，也可以让我们更好封装我们的代码。

2）. 不可中断性

不可中断就是指，一个线程获取锁之后，另外一个线程处于阻塞或者等待状态，前一个不释放，后一个也一直会阻塞或者等待，不可以被中断。

值得一提的是，Lock的tryLock方法是可以被中断的。

4. 底层实现

现在我们来看看 synchronized 的具体底层实现。先写一个简单的demo:

public class Test03 {
    public static void main(String[] args) {
        synchronized (Test03.class){
			// do something
        }
        method();
    }

    public synchronized static void method(){
		// do something
    }
}

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

E:\MyWorkSpace\untitled\out\production\untitled\SynchornizedDemo>javap -v Test03.class
Classfile /E:/MyWorkSpace/untitled/out/production/untitled/SynchornizedDemo/Test03.class
  Last modified 2021年7月20日; size 570 bytes
  MD5 checksum 9b775c4dee7c6caab982a6f39ec75c85
  Compiled from "Test03.java"
public class SynchornizedDemo.Test03
  minor version: 0
  major version: 55
  flags: (0x0021) ACC_PUBLIC, ACC_SUPER
  this_class: #2                          // SynchornizedDemo/Test03
  super_class: #4                         // java/lang/Object
  interfaces: 0, fields: 0, methods: 3, attributes: 1
Constant pool:
   #1 = Methodref          #4.#22         // java/lang/Object."<init>":()V
   #2 = Class              #23            // SynchornizedDemo/Test03
   #3 = Methodref          #2.#24         // SynchornizedDemo/Test03.method:()V
   #4 = Class              #25            // java/lang/Object
   #5 = Utf8               <init>
   #6 = Utf8               ()V
   #7 = Utf8               Code
   #8 = Utf8               LineNumberTable
   #9 = Utf8               LocalVariableTable
  #10 = Utf8               this
  #11 = Utf8               LSynchornizedDemo/Test03;
  #12 = Utf8               main
  #13 = Utf8               ([Ljava/lang/String;)V
  #14 = Utf8               args
  #15 = Utf8               [Ljava/lang/String;
  #16 = Utf8               StackMapTable
  #17 = Class              #15            // "[Ljava/lang/String;"
  #18 = Class              #26            // java/lang/Throwable
  #19 = Utf8               method
  #20 = Utf8               SourceFile
  #21 = Utf8               Test03.java
  #22 = NameAndType        #5:#6          // "<init>":()V
  #23 = Utf8               SynchornizedDemo/Test03
  #24 = NameAndType        #19:#6         // method:()V
  #25 = Utf8               java/lang/Object
  #26 = Utf8               java/lang/Throwable
{
  public SynchornizedDemo.Test03();
    descriptor: ()V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: return
      LineNumberTable:
        line 7: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       5     0  this   LSynchornizedDemo/Test03;

  public static void main(java.lang.String[]);
    descriptor: ([Ljava/lang/String;)V
    flags: (0x0009) ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=3, args_size=1
         0: ldc           #2                  // class SynchornizedDemo/Test03
         2: dup
         3: astore_1
         4: monitorenter
         5: aload_1
         6: monitorexit
         7: goto          15
        10: astore_2
        11: aload_1
        12: monitorexit
        13: aload_2
        14: athrow
        15: invokestatic  #3                  // Method method:()V
        18: return
      Exception table:
         from    to  target type
             5     7    10   any
            10    13    10   any
      LineNumberTable:
        line 9: 0
        line 11: 5
        line 12: 15
        line 13: 18
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      19     0  args   [Ljava/lang/String;
      StackMapTable: number_of_entries = 2
        frame_type = 255 /* full_frame */
          offset_delta = 10
          locals = [ class "[Ljava/lang/String;", class java/lang/Object ]
          stack = [ class java/lang/Throwable ]
        frame_type = 250 /* chop */
          offset_delta = 4

  public static synchronized void method();
    descriptor: ()V
    flags: (0x0029) ACC_PUBLIC, ACC_STATIC, ACC_SYNCHRONIZED
    Code:
      stack=0, locals=0, args_size=0
         0: return
      LineNumberTable:
        line 17: 0
}
SourceFile: "Test03.java"

在这里插入图片描述

如图，上面红色框的部分就是需要注意的部分了，这也是添 synchronized 关键字之后独有的。执行同步代码块后首先要先执行 monitorenter 指令，退出的时候 monitorexit 指令。

同步代码：

当我们进入一个方法的时候，执行monitorenter，就会获取当前对象的一个所有权，这个时候monitor进入数为1，当前的这个线程就是这个monitor的owner。

如果你已经是这个monitor的owner了，你再次进入，就会把进入数+1.

同理，当他执行完monitorexit，对应的进入数就-1，直到为0，才可以被其他线程持有。

所有的互斥，其实在这里，就是看你能否获得monitor的所有权，一旦你成为owner就是获得者。

同步方法：

不知道大家注意到方法那的一个特殊标志位没，ACC_SYNCHRONIZED。
同步方法的时候，一旦执行到这个方法，就会先判断是否有标志位，然后，ACC_SYNCHRONIZED会去隐式调用刚才的两个指令：monitorenter和monitorexit。

所以归根究底，还是monitor对象的争夺。

通过分析之后可以看出，使用 synchronized 进行同步，其关键就是必须要对对象的监视器 monitor 进行获取，当线程获取 monitor 后才能继续往下执行，否则就只能等待。而这个获取的过程是互斥的，即同一时刻只有一个线程能够获取到 monitor。

5. monitor

每一个JAVA对象都会与一个监视器monitor关联，我们可以把它理解成为一把锁，当一个线程想要执行一段被 synchronized 圈起来的同步方法或者代码块时，该线程得先获取到synchronized修饰的对象对应的monitor。

我们的java代码里不会显示地去创造这么一个monitor对象，我们也无需创建，事实上可以这么理解：我们是通过 synchronized 修饰符告诉JVM需要为我们的某个对象创建关联的monitor对象。

说了这么多次这个对象，大家是不是以为就是个虚无的东西，其实不是，monitor监视器源码是C++写的，在虚拟机的ObjectMonitor.hpp文件中。

源码中，他的数据结构长这样：

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;
  }

下图表现了对象，对象监视器，同步队列以及执行线程状态之间的关系：

在这里插入图片描述

6. synchronized的happens-before关系

在整理的JMM内存模型笔记中说明过happens-before规则，抱着学以致用的原则我们现在来看一看synchronized的happens-before规则，即监视器锁规则：对同一个监视器的解锁，happens-before对该监视器的加锁。继续来看代码：

public class MonitorDemo {
    private int a = 0;

    public synchronized void writer() {     // 1
        a++;                                // 2
    }                                       // 3

    public synchronized void reader() {    // 4
        int i = a;                         // 5
    }                                      // 6
}

该代码的happens-before关系如图所示：

在这里插入图片描述
在图中每一个箭头连接的两个节点就代表之间的happens-before关系，黑色的是通过程序顺序规则推导出来，红色的为监视器锁规则推导而出：线程A释放锁happens-before线程B加锁，蓝色的则是通过程序顺序规则和监视器锁规则推测出来happens-befor关系，通过传递性规则进一步推导的happens-before关系。现在我们来重点关注2 happens-before 5，通过这个关系我们可以得出什么？

根据happens-before的定义中的一条：如果A happens-before B，则A的执行结果对B可见，并且A的执行顺序先于B。线程A先对共享变量A进行加一，由2 happens-before 5关系可知线程A的执行结果对线程B可见即线程B所读取到的a的值为1。

7. 锁获取和锁释放的内存语义

JMM核心为两个部分：happens-before规则以及内存抽象模型。我们分析完synchronized的happens-before关系后，还是不太完整的，我们接下来看看基于Java内存抽象模型的synchronized的内存语义。

废话不多说依旧先上图。

在这里插入图片描述
从上图可以看出，线程A会首先先从主内存中读取共享变量a=0的值然后将该变量拷贝到自己的本地内存，进行加一操作后，再将该值刷新到主内存，整个过程即为线程A 加锁–>执行临界区代码–>释放锁相对应的内存语义。

在这里插入图片描述
线程B获取锁的时候同样会获取主内存中共享变量a的值，这个时候就是最新的值1，然后将该值拷贝到线程B的工作内存中去，释放锁的时候同样会重写到主内存中。

从整体上来看，线程A的执行结果（a=1）对线程B是可见的，实现原理为：释放锁的时候会将值刷新到主内存中，其他线程获取锁时会强制从主内存中获取最新的值。另外也验证了2 happens-before 5，2的执行结果对5是可见的。

从横向来看，这就像线程A通过主内存中的共享变量和线程B进行通信，A 告诉 B 我们俩的共享数据现在为1啦，这种线程间的通信机制正好吻合Java的内存模型，正好是共享内存的并发模型结构。

四、 synchronized优化

在 Java 早期版本中，synchronized 属于重量级锁，效率低下。

为什么呢？

因为监视器锁（monitor）是依赖于底层的操作系统的 Mutex Lock 来实现的，Java 的线程是映射到操作系统的原生线程之上的。如果要挂起或者唤醒一个线程，都需要操作系统帮忙完成，而操作系统实现线程之间的切换时需要从用户态转换到内核态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高。

庆幸的是在 Java 6 之后 Java 官方对从 JVM 层面对 synchronized 较大优化，所以现在的 synchronized 锁效率也优化得很不错了。JDK1.6 对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。

所以，在讨论 synchronized 优化之前需要了解什么是用户态和内核态。

1. 用户态和内核态

内核态：cpu可以访问内存的所有数据，包括外围设备，例如硬盘，网卡，cpu也可以将自己从一个程序切换到另一个程序。

用户态：只能受限的访问内存，且不允许访问外围设备，占用cpu的能力被剥夺，cpu资源可以被其他程序获取。

为什么要有用户态和内核态？
由于需要限制不同的程序之间的访问能力, 防止他们获取别的程序的内存数据, 或者获取外围设备的数据, 并发送到网络, CPU划分出两个权限等级 – 用户态和内核态。

2. 用户态和内核态的切换

所有用户程序都是运行在用户态的, 但是有时候程序确实需要做一些内核态的事情, 例如从硬盘读取数据, 或者从键盘获取输入等. 而唯一可以做这些事情的就是操作系统, 所以此时程序就需要先操作系统请求以程序的名义来执行这些操作.

这时需要一个这样的机制: 用户态程序切换到内核态, 但是不能控制在内核态中执行的指令

这种机制叫系统调用, 在CPU中的实现称之为陷阱指令(Trap Instruction)

他们的工作流程如下:

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

当一个任务（进程）执行系统调用而陷入内核代码中执行时，我们就称进程处于内核运行态（或简称为内核态）。此时处理器处于特权级最高的（0级）内核代码中执行。当进程处于内核态时，执行的内核代码会使用当前进程的内核栈。每个进程都有自己的内核栈。当进程在执行用户自己的代码时，则称其处于用户运行态（用户态）。即此时处理器在特权级最低的（3级）用户代码中运行。当正在执行用户程序而突然被中断程序中断时，此时用户程序也可以象征性地称为处于进程的内核态。因为中断处理程序将使用当前进程的内核栈。这与处于内核态的进程的状态有些类似。

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

3. CAS 和对象头

通过上面的讨论现在我们对synchronized应该有所印象了，它最大的特征就是在同一时刻只有一个线程能够获得对象的监视器（monitor），从而进入到同步代码块或者同步方法之中，即表现为互斥性（排它性）。这种方式肯定效率低下，每次只能通过一个线程，既然每次只能通过一个，这种形式不能改变的话，那么我们能不能让每次通过的速度变快一点了。

比如你想要做一盘土豆丝，需要把3个土豆去皮切丝，对于刀功不好的人来说去皮切丝很耗费时间，但是用了工具之后（擦子 cǎ zi）土豆一蹭就会变成粗细均匀的丝，这样效率就大大的提高了。

在聊到锁的优化也就是锁的几种状态前，有两个知识点需要先关注：（1）CAS操作（2）Java对象头，这是理解下面知识的前提条件。

3.1 CAS

1）. CAS介绍

Compare And Swap，即比较并交换，是一种解决并发操作的乐观锁。

它假设所有线程访问共享资源的时候不会出现冲突，既然不会出现冲突自然而然就不会阻塞其他线程的操作。因此，线程就不会出现阻塞停顿的状态。那么，如果出现冲突了怎么办？无锁操作是使用CAS(compare and swap)又叫做比较交换来鉴别线程是否出现冲突，出现冲突就重试当前操作直到没有冲突为止。

synchronized 锁住的代码块：同一时刻只能由一个线程访问，属于悲观锁

2）. 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指令实现。

cmpxchg是汇编指令
作用：比较并交换操作数.

3）. `CAS` VS `Synchronized`

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

4）. CAS的应用场景

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

5）. CAS的问题

ABA问题
因为CAS会检查旧值有没有变化，这里存在这样一个有意思的问题。比如一个旧值A变为了成B，然后再变成A，刚好在做CAS时检查发现旧值并没有变化依然为A，但是实际上的确发生了变化。解决方案可以沿袭数据库中常用的乐观锁方式，添加一个版本号可以解决。原来的变化路径A->B->A就变成了1A->2B->3C。Java这么优秀的语言，当然在Java 1.5后的atomic包中提供了AtomicStampedReference来解决ABA问题，解决思路就是这样的。
自旋时间过长
使用CAS时非阻塞同步，也就是说不会将线程挂起，会自旋（无非就是一个死循环）进行下一次尝试，如果这里自旋时间过长对性能是很大的消耗。如果JVM能支持处理器提供的pause指令，那么在效率上会有一定的提升。
只能保证一个共享变量的原子操作
当对一个共享变量执行操作时CAS能保证其原子性，如果对多个共享变量进行操作，CAS就不能保证其原子性。有一个解决方案是利用对象整合多个共享变量，即一个类中的成员变量就是这几个共享变量。然后将这个对象做CAS操作就可以保证其原子性。atomic中提供了AtomicReference来保证引用对象之间的原子性。

6）. CAS底层原理

CAS底层是通过c++实现的，通过 lock cmpxchg 指令，加 lock 是因为该指令不保证原子性，多核CPU时通过加lock保证原子性。

3.2 Java对象头

在同步的时候是获取对象的monitor，即获取到对象的锁。那么对象的锁怎么理解？无非就是类似对对象的一个标志，那么这个标志就是存放在Java对象的对象头。Java对象头里的Mark Word里默认的存放的对象的hashcode，对象分代年龄和锁标记位。32位JVM Mark Word默认存储结构为：

在这里插入图片描述
如图在Mark Word会默认存放hasdcode，年龄值以及锁标志位等信息。

Java SE 1.6中，锁一共有4种状态，级别从低到高依次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，这几个状态会随着竞争情况逐渐升级。锁可以升级但不能降级，意味着偏向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略，目的是为了提高获得锁和释放锁的效率。对象的MarkWord变化为下图：

在这里插入图片描述

4. 锁升级

我们就来看一下升级后的锁升级过程：

在这里插入图片描述
升级方向：

在这里插入图片描述
看完他的升级，我们就来好好聊聊每一步怎么做的吧。

5. 偏向锁

对象头是由Mark Word和klass pointer 组成，锁争夺也就是对象头指向的Monitor对象的争夺，一旦有线程持有了这个对象，标志位修改为1，就进入偏向模式，同时会把这个线程的ID记录在对象的Mark Word中。

这个过程是采用了CAS乐观锁操作的，每次同一线程进入，虚拟机就不进行任何同步的操作了，对标志位+1就好了，不同线程过来，CAS会失败，也就意味着获取锁失败。

偏向锁在1.6之后是默认开启的，1.5中是关闭的，需要手动开启参数是xx:-UseBiasedLocking=false。

在这里插入图片描述
偏向锁关闭，或者多个线程竞争偏向锁怎么办呢？

6. 轻量级锁

还是跟Mark Work 相关，如果这个对象是无锁的，jvm就会在当前线程的栈帧中建立一个叫锁记录（Lock Record）的空间，用来存储锁对象的Mark Word 拷贝，然后把Lock Record中的owner指向当前对象。

JVM接下来会利用CAS尝试把对象原本的Mark Word 更新回Lock Record的指针，成功就说明加锁成功，改变锁标志位，执行相关同步操作。

如果失败了，就会判断当前对象的Mark Word是否指向了当前线程的栈帧，是则表示当前的线程已经持有了这个对象的锁，否则说明被其他线程持有了，继续锁升级，修改锁的状态，之后等待的线程也阻塞。

在这里插入图片描述

7. 自旋锁

线程的等待唤起过程，会消耗大量资源，那怎么才能减少这种消耗呢？

自旋，过来的现在就不断自旋，防止线程被挂起，一旦可以获取资源，就直接尝试成功，直到超出阈值，自旋锁的默认大小是10次，-XX：PreBlockSpin可以修改。

自旋都失败了，那就升级为重量级的锁，像1.5的一样，等待唤起咯。

在这里插入图片描述

原文链接：https://blog.csdn.net/weixin_42547014/article/details/118928263

THE END

大大搜源码

搜索内容

Java关键字——synchronized

一、认识 Synchronized

二、应用场景

三、底层原理

1. Java对象的构成

2. synchronized如何实现原子性、有序性、可见性

1）. 有序性

2）. 可见性

3）. 原子性

3. synchronized 本身具备的特性

1）. 可重入性

2）. 不可中断性

4. 底层实现

5. monitor

6. synchronized的happens-before关系

7. 锁获取和锁释放的内存语义

四、 synchronized优化

1. 用户态和内核态

2. 用户态和内核态的切换

3. CAS 和对象头

3.1 CAS

1）. CAS介绍

2）. CAS操作过程

3）. `CAS` VS `Synchronized`

4）. CAS的应用场景

5）. CAS的问题

6）. CAS底层原理

3.2 Java对象头

4. 锁升级

5. 偏向锁

6. 轻量级锁

7. 自旋锁

Java关键字——synchronized

一、认识 Synchronized

二、应用场景

三、底层原理

1. Java对象的构成

2. synchronized如何实现原子性、有序性、可见性

1）. 有序性

2）. 可见性

3）. 原子性

3. synchronized 本身具备的特性

1）. 可重入性

2）. 不可中断性

4. 底层实现

5. monitor

6. synchronized的happens-before关系

7. 锁获取和锁释放的内存语义

四、 synchronized优化

1. 用户态和内核态

2. 用户态和内核态的切换

3. CAS 和 对象头

3.1 CAS

1）. CAS介绍

2）. CAS操作过程

3）. CAS VS Synchronized

4）. CAS的应用场景

5）. CAS的问题

6）. CAS底层原理

3.2 Java对象头

4. 锁升级

5. 偏向锁

6. 轻量级锁

7. 自旋锁

3. CAS 和对象头

3）. `CAS` VS `Synchronized`