综合转载自：
https://www.cnblogs.com/kubidemanong/p/9520071.html
https://blog.csdn.net/zzti_erlie/article/details/103997713

synchronized使用方式

我们知道并发编程会产生各种问题的源头是可见性，原子性，有序性。
而synchronized能同时保证可见性，原子性，有序性。所以我们在解决并发问题的时候经常用synchronized，当然还有很多其他工具，如volatile。但是volatile只能保证可见性，有序性，不能保证原子性。

synchronized可以用在如下地方

修饰实例方法，对当前实例对象this加锁
修饰静态方法，对当前类的Class对象加锁
修饰代码块，指定加锁对象，对给定对象加锁

对方法进行加锁，虚拟机会根据synchronized修饰的是实例方法还是类方法，去取对应的实例对象或者Class对象来进行加锁。

synchronized实现原理

Java对象组成

我们都知道对象是放在堆内存中的，对象大致可以分为三个部分，分别是对象头，实例变量和填充字节
在这里插入图片描述

对象头，主要包括两部分1. Mark Word （标记字段），2.Klass Pointer（类型指针）。Klass Point
是对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例**（即指向方法区类的模版信息）**。Mark Word用于存储对象自身的运行时数据
实例变量，存放类的属性数据信息，包括父类的属性信息，这部分内存按4字节对齐
填充数据，由于虚拟机要求对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐
填充数据主要是为了方便内存管理，如你想要10字节的内存，但是会给你分配16字节的内存，多出来的字节就是填充数据

synchronized不论是修饰方法还是代码块，都是通过持有修饰对象的锁来实现同步，那么synchronized锁对象是存在哪里的呢？答案是存在锁对象的对象头Mark Word，来看一下Mark Word存储了哪些内容？

由于对象头的信息是与对象自身定义的数据没有关系的额外存储成本，因此考虑到JVM的空间效率，Mark Word 被设计成为一个非固定的数据结构，以便存储更多有效的数据，它会根据对象本身的状态复用自己的存储空间，也就是说，Mark Word会随着程序的运行发生变化，变化状态如下 (32位虚拟机)：
在这里插入图片描述
其中轻量级锁和偏向锁是Java 6 对 synchronized 锁进行优化后新增加的，稍后我们会简要分析。这里我们主要分析一下重量级锁也就是通常说synchronized的对象锁，锁标识位为10，其中指针指向的是monitor对象（也称为管程或监视器锁）的起始地址。每个对象都存在着一个 monitor 与之关联。在Java虚拟机(HotSpot)中，monitor是由ObjectMonitor实现的，其主要数据结构如下（位于HotSpot虚拟机源码ObjectMonitor.hpp文件，C++实现的），省略部分属性

ObjectMonitor() {
    
    
    _count        = 0; //记录数
    _recursions   = 0; //锁的重入次数
    _owner        = NULL; //指向持有ObjectMonitor对象的线程 
    _WaitSet      = NULL; //调用wait后，线程会被加入到_WaitSet
    _EntryList    = NULL ; //等待获取锁的线程，会被加入到该列表
}

在这里插入图片描述
结合线程状态解释一下执行过程。(状态装换参考自《深入理解Java虚拟机》)

新建（New），新建后尚未启动的线程
运行（Runable），Runnable包括了操作系统线程状态中的Running和Ready
无限期等待（Waiting），不会被分配CPU执行时间，要等待被其他线程显式的唤醒。例如调用没有设置Timeout参数的Object.wait()方法
限期等待（Timed Waiting），不会被分配CPU执行时间，不过无需等待其他线程显示的唤醒，在一定时间之后会由系统自动唤醒。例如调用Thread.sleep()方法
阻塞（Blocked），线程被阻塞了，“阻塞状态”与“等待状态”的区别是：“阻塞状态”在等待获取着一个排他锁，这个事件将在另外一个线程放弃这个锁的时候发生，而“等待状态”则是在等待一段时间，或者唤醒动作的发生。在程序等待进入同步区域的时候，线程将进入这种状态
结束（Terminated）：线程结束执行

对于一个synchronized修饰的方法(代码块)来说：

当多个线程同时访问该方法，那么这些线程会先被放进_EntryList队列，此时线程处于blocked状态
当一个线程获取到了对象的monitor后，那么就可以进入running状态，执行方法，此时，ObjectMonitor对象的/_owner指向当前线程，_count加1表示当前对象锁被一个线程获取
当running状态的线程调用wait()方法，那么当前线程释放monitor对象，进入waiting状态，ObjectMonitor对象的/_owner变为null，_count减1，同时线程进入_WaitSet队列，直到有线程调用notify()方法唤醒该线程，则该线程进入_EntryList队列，竞争到锁再进入_Owner区
如果当前线程执行完毕，那么也释放monitor对象，ObjectMonitor对象的/_owner变为null，_count减1

由此看来，monitor对象存在于每个Java对象的对象头中(存储的是指针)，synchronized锁便是通过这种方式获取锁的，也是为什么Java中任意对象可以作为锁的原因，同时也是notify/notifyAll/wait等方法存在于顶级对象Object中的原因

synchronized如何获取monitor对象？

synchronized修饰代码块

public class SyncCodeBlock {
    
    
    public int count = 0;
    public void addOne() {
    
    
        synchronized (this) {
    
    
            count++;
        }
    }
}

javac SyncCodeBlock.java
javap -v SyncCodeBlock.class

反编译的字节码如下

  public void addOne();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=3, locals=3, args_size=1
         0: aload_0
         1: dup
         2: astore_1
         3: monitorenter // 进入同步方法
         4: aload_0
         5: dup
         6: getfield      #2                  // Field count:I
         9: iconst_1
        10: iadd
        11: putfield      #2                  // Field count:I
        14: aload_1
        15: monitorexit // 退出同步方法
        16: goto          24
        19: astore_2
        20: aload_1
        21: monitorexit // 退出同步方法
        22: aload_2
        23: athrow
        24: return
      Exception table:

可以看到进入同步代码块，执行monitorenter指令，退出同步代码块，执行monitorexit指令，可以看到有2个monitorexit指令，第一个是正常退出执行的，第二个是当异常发生时执行的
synchronized修饰方法

public class SyncMethod {
    
    
    public int count = 0;
    public synchronized void addOne() {
    
    
        count++;
    }
}

反编译的字节码如下

  public synchronized void addOne();
    descriptor: ()V
    // 方法标识ACC_PUBLIC代表public修饰，ACC_SYNCHRONIZED指明该方法为同步方法
    flags: ACC_PUBLIC, ACC_SYNCHRONIZED
    Code:
      stack=3, locals=1, args_size=1
         0: aload_0
         1: dup
         2: getfield      #2                  // Field count:I
         5: iconst_1
         6: iadd
         7: putfield      #2                  // Field count:I
        10: return
      LineNumberTable:

我们并没有看到monitorenter和monitorexit指令，那是怎么来实现同步的呢？
可以看到方法被标识为ACC_SYNCHRONIZED，表明这是一个同步方法

锁的升级

在Java早期版本中，synchronized属于重量级锁，效率低下，因为操作系统实现线程之间的切换时需要从用户态转换到核心态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高。

庆幸的是在jdk1.6之后Java官方对从JVM层面对synchronized较大优化，所以现在的synchronized锁效率也优化得很不错了，Jdk1.6之后，为了减少获得锁和释放锁所带来的性能消耗，引入了偏向锁和轻量级锁，简单介绍一下

synchronized锁有四种状态，无锁，偏向锁，轻量级锁，重量级锁，这几个状态会随着竞争状态逐渐升级，锁可以升级但不能降级，但是偏向锁状态可以被重置为无锁状态

锁实际上是加在对象上的，那么被加了锁的对象我们称之为锁对象，在java中，任何一个对象都能成为锁对象。对象中关于锁的信息是存在Markword里的

偏向锁

当我们创建一个对象LockObject时，该对象的Markword字段，偏向锁的标志位是“01”，状态是“0”，表示该对象还没有被加上偏向锁。（“1”是表示被加上偏向锁）。该对象被创建出来的那一刻，就有了偏向锁的标志位，这也说明了所有对象都是可偏向的，但所有对象的状态都为“0”，也同时说明所有被创建的对象的偏向锁并没有生效。

不过，当线程执行到临界区（critical section）时，此时会利用CAS(Compare and Swap)操作，将线程ID插入到Markword中，同时修改偏向锁的标志位为“1”，说明对象的偏向锁生效了，当前这个线程获得了该对象的锁。

什么是偏向锁?

偏向锁是jdk1.6引入的一项锁优化，其中的“偏”是偏心的偏。它的意思就是说，这个锁会偏向于第一个获得它的线程，在接下来的执行过程中，假如该锁没有被其他线程所获取，没有其他线程来竞争该锁，那么持有偏向锁的线程将永远不需要进行同步操作。
也就是说:
在此线程之后的执行过程中，如果再次进入或者退出同一段同步块代码，并不再需要去进行加锁或者解锁操作，而是会做以下的步骤：

偏向锁升级过程

Load-and-test，也就是简单判断一下当前线程id是否与java对象头中Markword当中的线程id是否一致.
如果一致，则说明此线程已经成功获得了锁，继续执行下面的代码.
如果不一致（其他线程，如线程2要竞争锁对象，而偏向锁不会主动释放因此还是存储的线程1的threadID），那么需要查看Java对象头中记录的线程1是否存活；
如果没有存活，那么锁对象被重置为无锁状态，其它线程（线程2）可以竞争将其设置为偏向锁；如果存活，那么立刻查找该线程（线程1）的栈帧信息，如果还是需要继续持有这个锁对象，那么暂停当前线程1，撤销偏向锁，升级为轻量级锁，如果线程1 不再使用该锁对象，那么将锁对象状态设为无锁状态，重新偏向新的线程。

可以看出，偏向锁是针对于一个线程而言的，线程获得锁之后就不会再有解锁等操作了，这样可以省略很多开销。假如有两个线程来竞争该锁话，那么偏向锁就失效了，进而升级成轻量级锁了。这也就是经常所说的锁膨胀。

在Jdk1.6中，偏向锁的开关是默认开启的，适用于只有一个线程访问同步块的场景。

为什么要引入偏向锁？

因为经过HotSpot的作者大量的研究发现，大多数时候是不存在锁竞争的，常常是一个线程多次获得同一个锁，因此如果每次都要竞争锁会增大很多没有必要付出的代价，为了降低获取锁的代价，才引入的偏向锁。

轻量级锁

为什么要引入轻量级锁？

轻量级锁考虑的是竞争锁对象的线程不多，而且线程持有锁的时间也不长的情景。因为阻塞线程需要CPU从用户态转到内核态，代价较大，如果刚刚阻塞不久这个锁就被释放了，那这个代价就有点得不偿失了，因此这个时候就干脆不阻塞这个线程，让它自旋等待锁释放。

轻量级锁原理和升级过程

线程1获取轻量级锁时会先把锁对象的对象头MarkWord复制一份到线程1的栈帧中创建的用于存储锁记录的空间（称为DisplacedMarkWord），然后使用CAS把对象头中的内容替换为线程1存储的锁记录（DisplacedMarkWord）的地址；

如果在线程1复制对象头的同时（在线程1CAS之前），线程2也准备获取锁，复制了对象头到线程2的锁记录空间中，但是在线程2CAS的时候，发现线程1已经把对象头换了，线程2的CAS失败，那么线程2就尝试使用自旋锁来等待线程1释放锁。自旋锁简单来说就是让线程2在循环中不断CAS

但是如果自旋的时间太长也不行，因为自旋是要消耗CPU的，因此自旋的次数是有限制的，比如10次或者100次，如果自旋次数到了线程1还没有释放锁，或者线程1还在执行，线程2还在自旋等待，这时又有一个线程3过来竞争这个锁对象，那么这个时候轻量级锁就会膨胀为重量级锁。重量级锁把除了拥有锁的线程都阻塞，防止CPU空转。

锁标志位”00”表示轻量级锁
轻量级锁主要有两种

自旋锁
自适应自旋锁

自旋锁

所谓自旋，就是指当有另外一个线程来竞争锁时，这个线程会在原地循环等待，而不是把该线程给阻塞，直到那个获得锁的线程释放锁之后，这个线程就可以马上获得锁的。
注意，锁在原地循环的时候，是会消耗cpu的，就相当于在执行一个啥也没有的for循环。
所以，轻量级锁适用于那些同步代码块执行的很快的场景，这样，线程原地等待很短很短的时间就能够获得锁了。
经验表明，大部分同步代码块执行的时间都是很短很短的，也正是基于这个原因，才有了轻量级锁这么个东西。

自旋锁的局限性

如果同步代码块执行的很慢，需要消耗大量的时间，那么这个时侯，其他线程在原地等待空消耗cpu，这会让人很难受。
本来一个线程把锁释放之后，当前线程是能够获得锁的，但是假如这个时候有好几个线程都在竞争这个锁的话，那么有可能当前线程会获取不到锁，还得原地等待继续空循环消耗cup，甚至有可能一直获取不到锁。

基于这个问题，我们必须给线程空循环设置一个次数，当线程超过了这个次数，我们就认为，继续使用自旋锁就不适合了，此时锁会再次膨胀，升级为重量级锁。
默认情况下，自旋的次数为10次，用户可以通过-XX:PreBlockSpin来进行更改。

自旋锁是在JDK1.4.2的时候引入的

自适应自旋锁

所谓自适应自旋锁就是线程空循环等待的自旋次数并非是固定的，而是会动态着根据实际情况来改变自旋等待的次数。
其大概原理是这样的：
假如一个线程1刚刚成功获得一个锁，当它把锁释放了之后，线程2获得该锁，并且线程2在运行的过程中，此时线程1又想来获得该锁了，但线程2还没有释放该锁，所以线程1只能自旋等待，但是虚拟机认为，由于线程1刚刚获得过该锁，那么虚拟机觉得线程1这次自旋也是很有可能能够再次成功获得该锁的，所以会延长线程1自旋的次数。
另外，如果对于某一个锁，一个线程自旋之后，很少成功获得该锁，那么以后这个线程要获取该锁时，是有可能直接忽略掉自旋过程，直接升级为重量级锁的，以免空循环等待浪费资源。

轻量级锁也被称为非阻塞同步、乐观锁，因为这个过程并没有把线程阻塞挂起，而是让线程空循环等待，串行执行。

重量级锁

轻量级锁膨胀之后，就升级为重量级锁了。重量级锁是依赖对象内部的monitor锁来实现的，而monitor又依赖操作系统的MutexLock(互斥锁)来实现的，所以重量级锁也被成为互斥锁。
当轻量级所经过锁撤销等步骤升级为重量级锁之后，它的Markword的锁标志位变为10

为什么说重量级锁开销大

主要是，当系统检查到锁是重量级锁之后，会把等待想要获得锁的线程进行阻塞，被阻塞的线程不会消耗cup。但是阻塞或者唤醒一个线程时，都需要操作系统来帮忙，这就需要从用户态转换到内核态，而转换状态是需要消耗很多时间的，有可能比用户执行代码的时间还要长。

互斥锁(重量级锁)也称为阻塞同步、悲观锁

几种锁的优缺点

在这里插入图片描述

错误的加锁姿势1

synchronized (new Object())

每次调用创建的是不同的锁，相当于无锁
错误的加锁姿势2

private Integer count;
synchronized (count)

String，Boolean在实现了都用了享元模式，即值在一定范围内，对象是同一个。所以看似是用了不同的对象，其实用的是同一个对象。会导致一个锁被多个地方使用

ConcurrentHashMap在jdk1.7的时候，实现用的是分段锁，用ReentrantLock来保证并发安全。
而在jdk1.8的时候，抛弃了原有的分段锁，而采用了 CAS + synchronized 来保证并发安全性，也可以说明synchronized的的效率现在确实很高了。

Synchronized底层实现，锁升级的具体过程