前言
线程安全问题的主要诱因有两点，一是存在共享数据(也称临界资源)，二是存在多条线程共同操作共享数据。
因此为了解决这个问题，我们可能需要这样一个方案，当存在多个线程操作共享数据时，需要保证同一时刻有且只有一个线程在操作共享数据，其他线程必须等到该线程处理完数据后再进行，这种方式有个高尚的名称叫互斥锁，即能达到互斥访问目的的锁，也就是说当一个共享数据被当前正在访问的线程加上互斥锁后，在同一个时刻，其他线程只能处于等待的状态，直到当前线程处理完毕释放该锁。
在 Java 中，关键字 synchronized可以保证在同一个时刻，只有一个线程可以执行某个方法或者某个代码块(主要是对方法或者代码块中存在共享数据的操作)，同时我们还应该注意到synchronized另外一个重要的作用，synchronized可保证一个线程的变化(主要是共享数据的变化)被其他线程所看到（保证可见性，完全可以替代Volatile功能），这点确实也是很重要的。
synchronized三种作用范围（给对象加锁）
在静态方法上加锁；
在非静态方法上加锁；
在代码块上加锁；
public class SynchronizedSample {
private final Object lock = new Object();
private static int money = 0;
//非静态方法
public synchronized void noStaticMethod(){
money++;
}
//静态方法
public static synchronized void staticMethod(){
money++;
}
public void codeBlock(){
//代码块
synchronized (lock){
money++;
}
}
}
| 作用范围 | 锁对象 |
|---|---|
| 非静态方法 | 当前对象 => this |
| 静态方法 | 类对象 => SynchronizedSample.class （一切皆对象，这个是类对象） |
| 代码块 | 指定对象 => lock （以上面的代码为例） |
Synchronization实现原理
先理解Java对象头与Monitor
1.对象头：锁的类型和状态和对象头的Mark Word息息相关；
对象头分为二个部分，Mard Word 和 Klass Word
| 对象头结构 | 存储信息-说明 |
|---|---|
| Mard Word | 存储对象的hashCode、锁信息或分代年龄或GC标志等信息 |
| Klass Word | 存储指向对象所属类（元数据）的指针，JVM通过这个确定这个对象属于哪个类 |
其中Mark Word在默认情况下存储着对象的HashCode、分代年龄、锁标记位等以下是32位JVM的Mark Word默认存储结构
| 锁状态 | 25bit | 4bit | 1bit是否是偏向锁 | 2bit 锁标志位 |
|---|---|---|---|---|
| 无锁状态 | 对象HashCode | 对象分代年龄 | 0 | 01 |
主要分析一下重量级锁也就是通常说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;
_owner = NULL; // 当前持有锁的线程
_WaitSet = NULL; // 调用了 wait 方法的线程被阻塞 放置在这里
_WaitSetLock = 0 ;
_Responsible = NULL ;
_succ = NULL ;
_cxq = NULL ;
FreeNext = NULL ;
_EntryList = NULL ; // 等待锁 处于block的线程 有资格成为候选资源的线程
_SpinFreq = 0 ;
_SpinClock = 0 ;
OwnerIsThread = 0 ;
}
ObjectMonitor中有两个队列，_WaitSet 和 _EntryList，用来保存ObjectWaiter对象列表( 每个等待锁的线程都会被封装成ObjectWaiter对象)，_owner指向持有ObjectMonitor对象的线程，当多个线程同时访问一段同步代码时，首先会进入 _EntryList 集合，当线程获取到对象的monitor 后进入 _Owner 区域并把monitor中的owner变量设置为当前线程同时monitor中的计数器count加1，若线程调用 wait() 方法，将释放当前持有的monitor，owner变量恢复为null，count自减1，同时该线程进入 WaitSet集合中等待被唤醒。若当前线程执行完毕也将释放monitor(锁)并复位变量的值，以便其他线程进入获取monitor(锁)。如下图所示
由此看来，monitor对象存在于每个Java对象的对象头中(存储的指针的指向)，synchronized锁便是通过这种方式获取锁的，也是为什么Java中任意对象可以作为锁的原因，同时也是notify/notifyAll/wait等方法存在于*对象Object中的原因(关于这点稍后还会进行分析)。
jdk6 之后做了改进，引入了偏向锁和轻量级锁：
- 依赖底层操作系统的 mutex 相关指令实现，加锁解锁需要在用户态和内核态之间切换，性能损耗非常明显。
- 研究人员发现，大多数对象的加锁和解锁都是在特定的线程中完成。也就是出现线程竞争锁的情况概率比较低。他们做了一个实验，找了一些典型的软件，测试同一个线程加锁解锁的重复率，如下图所示，可以看到重复加锁比例非常高。早期JVM 有 19% 的执行时间浪费在锁上。
1.无锁到偏向锁转化的过程
- 首先A 线程访问同步代码块，使用CAS 操作将 Thread ID 放到 Mark Word 当中；
- 如果CAS 成功，此时线程A 就获取了锁
- 如果线程CAS 失败，证明有别的线程持有锁，例如上图的线程B 来CAS 就失败的，这个时候启动偏向锁撤销 （revoke bias）；
- 锁撤销流程：
- 让 A线程在全局安全点阻塞（类似于GC前线程在安全点阻塞）
- 遍历线程栈，查看是否有被锁对象的锁记录（ Lock Record），如果有Lock Record，需要修复锁记录和Markword，使其变成无锁状态。
- 恢复A线程
- 将是否为偏向锁状态置为 0 ，开始进行轻量级加锁流程
2.偏向锁升级轻量级
- 线程在自己的栈桢中创建锁记录 LockRecord。
- 线程A 将 Mark Word 拷贝到线程栈的 Lock Record中
- 将锁记录中的Owner指针指向加锁的对象（存放对象地址）
- 将锁对象的对象头的MarkWord替换为指向锁记录的指针。
- 这时锁标志位变成 00 ，表示轻量级锁
其实就是撤销偏向锁后，当前线程栈中会分配锁记录，并拷贝Mark Word到锁记录中。然后两个线程用CAS的方式去修改Mark Word中的指针指向自己，假如说第一个线程修改成功了，然后将锁升级为轻量级锁，去执行同步语句块中的内容。
3.轻量级到重量级
修改失败的第二个线程会进入自旋状态，自旋结束后会继续去尝试CAS修改指针指向自己。如果自旋失败超过一定次数的时候（这个次数会动态进行调整），会请求JVM将此时的锁状态升级为重量级锁，这是依赖于底层操作系统的调度库来实现的。接着将Mark Word指向重量级锁Monitor的指针，然后挂起当前第二个线程（被放在Monitor的_EntryList中）。等一个线程执行完毕后，会查看当前Mark Word中的指针是否仍然指向自己，如果是自己的话就释放锁，否则不是自己的话，说明此时已经升级成了重量级锁，除了释放锁之后，还会唤醒阻塞的线程，进行新一轮的锁竞争。在此之后，该锁就一直会是重量级锁存在了
ps：为什么设计自旋数超过一定限制设置为重量级锁？
一般来说，同步代码块内的代码应该很快就执行结束，这时候修改失败的第二个线程自旋一段时间是很容易拿到锁的，但是如果不巧，没拿到，自旋其实就是死循环，很耗CPU的，因此就直接转成重量级锁咯，这样就不用了线程一直自旋了。
源码才学疏浅只了解到：
synchronized 在代码块上是通过 monitorenter 和 monitorexit指令实现，在静态方法和 方法上加锁是在方法的flags 中加入 ACC_SYNCHRONIZED 。JVM 运行方法时检查方法的flags，遇到同步标识开始启动前面的加锁流程，在方法内部遇到monitorenter指令开始加锁。
总结
本篇文章就到这里了，希望能够给你带来帮助，也希望您能够多多关注服务器之家的更多内容！
原文链接：https://blog.csdn.net/qq_53643258/article/details/120169021