多线程与高并发系列二（Synchronized和volatile）
多线程与高并发系列二（Synchronized和volatile）
- synchronized 加锁方式
- 锁是如何存储的
- 对象在内存中的布局
- synchronized底层原理
- synchronized修饰代码块的情况
- synchronized 修饰方法的的情况
- synchronized 锁的升级
- 偏向锁
- 轻量级锁
- 自旋锁/自适应自旋锁
- volatile
- synchronized 关键字和 volatile 关键字的区别
欢迎大家观看我对于多线程与高并发这一系列的博客：
多线程与高并发系列一（多线程基本知识）
多线程与高并发系列二（Synchronized和volatile）
多线程与高并发系列三（ThreadLocal）
多线程与高并发系列四（线程池）
多线程与高并发系列五（ReentrantLock）
多线程与高并发系列六（并发工具）
多线程与高并发系列七（阻塞队列和Atomic 原子类）
synchronized关键字解决的是多个线程之间访问资源的同步性，synchronized关键字可以保证被它修饰的方法或者代码块在任意时刻只能有⼀个线程执行。
synchronized 加锁方式
- 修饰实例方法，作用于当前实例加锁，进入同步代码前要获得当前实例的锁；
- 静态方法，作用于当前类对象加锁，进入同步代码前要获得当前类对象的锁；
- 修饰代码块，指定加锁对象，对给定对象加锁，进入同步代码库前要获得给定对象的锁。
锁是如何存储的
要理解synchronized的底层实现原理，需要先了解java对象的内存布局。
对象在内存中的布局
在 Hotspot 虚拟机中，对象在内存中的存储布局，可以分为三个区域:对象头(Header)、实例数据(Instance Data)、对齐填充(Padding)。
- 实例变量：存放类的属性数据信息，包括父类的属性信息，如果是数组的实例部分还包括数组的长度，这部分内存按4字节对齐。
- 填充数据：由于虚拟机要求对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐。
而对于顶部，则是Java头对象，它实现synchronized的锁对象的基础，synchronized使用的锁对象是存储在Java对象头里的，jvm中采用2个字来存储对象头(如果对象是数组则会分配3个字，多出来的1个字记录的是数组长度)，其主要结构是由Mark Word 和 Class Metadata Address 组成，其结构说明如下表：
| 头对象结构 | 说明 |
|---|---|
| Mark Word | 存储对象的hashcode，锁信息， 分代年龄、GC标志等信息 |
| Class Metadata Address | 类型指针指向对象的类元数据，JVM通过这个指针确定该对象是哪个类的实例 |
Mark word 记录了对象和锁有关的信息，当某个对象被synchronized 关键字当成同步锁时，那么围绕这个锁的一系列操作都和 Mark word 有关系。Mark Word 在 32 位虚拟机的长度是 32bit、在 64 位虚拟机的长度是 64bit。Mark Word 里面存储的数据会随着锁标志位的变化而变化，Mark Word 可能变化为存储以下 5 中情况：
线程在获取锁的时候，实际上就是获得一个监视器对象(monitor) ,monitor 可以认为是一个同步对象，所有的Java 对象是天生携带 monitor。在 hotspot 源码的markOop.hpp 文件中，可以看到下面这段代码。
多个线程访问同步代码块时，相当于去争抢对象监视器修改对象中的锁标识,上面的代码中ObjectMonitor这个对象和线程争抢锁的逻辑有密切的关系。
synchronized底层原理
synchronized修饰代码块的情况
我们定义一个synchronized修饰的同步代码块，在代码块中操作共享变量i，如下：
public class SyncDemo {
public int i;
public void syncTest(){
//同步代码块
synchronized (this){
i++;
}
}
}
通过 JDK 自带的 javap 命令查看 SyncDemo 类的相关字节码信息：首先切换到类的对应目录执行javac SyncDemo.java 命令生成编译后的 .class 文件，然后执行javap -c -s -v -l SyncDemo.class。
0: aload_0
1: dup
2: astore_1
3: monitorenter //注意此处，进入同步方法
4: aload_0
5: dup
6: getfield #2
9: iconst_1
10: iadd
11: putfield #2
14: aload_1
15: monitorexit //注意此处，退出同步方法
从上面我们可以看出：
synchronized 同步语句块的实现使用的是 monitorenter 和 monitorexit 指令，其中 monitorenter 指令指向同步代码块的开始位置，monitorexit 指令则指明同步代码块的结束位置。每一个 JAVA 对象都会与一个监视器 monitor 关联，我们可以把它理解成为一把锁，当一个线程想要执行一段被
synchronized 修饰的同步方法或者代码块时，该线程得先获取到 synchronized 修饰的对象对应的 monitor。monitorenter 表示去获得一个对象监视器。monitorexit 表示释放 monitor 监视器的所有权，使得其他被阻塞的线程可以尝试去获得这个监视器。monitor 依赖操作系统的 MutexLock(互斥锁)来实现的, 线程被阻塞后便进入内核（Linux）调度状态，这个会导致系统在用户态与内核态之间来回切换，严重影响锁的性能。
synchronized 修饰方法的的情况
public class SynchronizedDemo2 {
public synchronized void method() {
System.out.println("synchronized 方法");
}
}
编译成JVM源码后，需要关注的是：
descriptor: ()V
//方法标识ACC_PUBLIC代表public修饰，ACC_SYNCHRONIZED指明该方法为同步方法
flags: ACC_PUBLIC, ACC_SYNCHRONIZED
synchronized 修饰的方法是 ACC_SYNCHRONIZED 标识，该标识指明了该方法是一个同步方法，JVM 通过该 ACC_SYNCHRONIZED 访问标志来辨别一个方法是否声明为同步方法，从而执行相应的同步调用。
在 Java 早期版本中，synchronized 属于重量级锁，效率低下，因为监视器锁（monitor）是依赖于底层的操作系统的 Mutex Lock 来实现的，Java 的线程是映射到操作系统的原生线程之上的。如果要挂起或者唤醒一个线程，都需要操作系统帮忙完成，而操作系统实现线程之间的切换时需要从用户态转换到内核态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，这也是为什么早期的 synchronized 效率低的原因。庆幸的是在 Java 6 之后 Java 官方对从 JVM 层面对synchronized 较大优化，所以现在的 synchronized 锁效率也优化得很不错了。JDK1.6对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。
synchronized 锁的升级
在分析 markword 时，提到了偏向锁、轻量级锁、重量级锁。在分析这几种锁的区别时，我们先来思考一个问题：使用锁能够实现数据的安全性，但是会带来性能的下降。不使用锁能够基于线程并行提升程序性能，但是却不能保证线程安全性。这两者之间似乎是没有办法达到既能满足性能也能满足安全性的要求。
hotspot 虚拟机的作者经过调查发现，大部分情况下，加锁的代码不仅仅不存在多线程竞争，而且总是由同一个线程多次获得。所以基于这样一个概率，使得 synchronized 在JDK1.6 之后做了一些优化，为了减少获得锁和释放锁带来的性能开销，引入了偏向锁、轻量级锁的概念。因此大家会发现在 synchronized 中，锁存在四种状态分别是：无锁、偏向锁、轻量级锁、重量级锁； 锁的状态根据竞争激烈的程度从低到高不断升级。（只会升级不会降级）
偏向锁
引入偏向锁是为了没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。偏向锁在无竞争的情况下会把整个同步都消除掉，连CAS操作都不会去做了。
偏向锁的“偏”就是偏心的偏，它的意思是会偏向于第一个获得它的线程，如果在接下来的执行中，该锁没有被其他线程获取，那么持有偏向锁的线程就不需要进行同步！但是对于锁竞争比较激烈的场合，偏向锁就失效了，因为这样场合极有可能每次申请锁的线程都是不相同的，因此这种场合下不应该使用偏向锁，否则会得不偿失，需要注意的是，偏向锁失败后，并不会立即膨胀为重量级锁，而是先升级为轻量级锁。
轻量级锁
轻量级锁不是为了代替重量级锁，它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗，因为使用轻量级锁时，不需要申请互斥量。另外，轻量级锁的加锁和解锁都用到了CAS操作。
轻量级锁能够提升程序同步性能的依据是“对于绝大部分锁，在整个同步周期内都是不存在竞争的”，这是一个经验数据。如果没有竞争，轻量级锁使用 CAS 操作避免了使用互斥操作的开销。但如果存在锁竞争，除了互斥量开销外，还会额外发生CAS操作，因此在有锁竞争的情况下，轻量级锁比传统的重量级锁更慢！如果锁竞争激烈，那么轻量级将很快膨胀为重量级锁！
自旋锁/自适应自旋锁
轻量级锁失败后，虚拟机为了避免线程真实地在操作系统层面挂起，还会进行一项称为自旋锁的优化手段。互斥同步对性能最大的影响就是阻塞的实现，因为挂起线程/恢复线程的操作都需要转入内核态中完成（用户态转换到内核态会耗费时间）。
一般线程持有锁的时间都不是太长，所以仅仅为了这一点时间去挂起线程/恢复线程是得不偿失的。 所以，虚拟机的开发团队就这样去考虑：“我们能不能让后面来的请求获取锁的线程等待一会而不被挂起呢？看看持有锁的线程是否很快就会释放锁”。为了让一个线程等待，我们只需要让线程执行一个忙循环（自旋），这项技术就叫做自旋。
另外,在 JDK1.6 中引入了自适应的自旋锁。自适应的自旋锁带来的改进就是：自旋的时间不在固定了，而是和前一次同一个锁上的自旋时间以及锁的拥有者的状态来决定，虚拟机变得越来越“聪明”了。
volatile
说到volatile关键字，不得不提Java内存模型。详细参见Java内存模型。并发编程的三个重要特性分别是有序性，可见性，原子性。而volatile 关键字的主要作用就是保证变量的可见性然后还有⼀个作用是防止指令重排序。
synchronized 关键字和 volatile 关键字的区别
- volatile关键字是线程同步的轻量级实现，所以volatile性能肯定比synchronized关键字要好。但是volatile关键字只能用于变量而synchronized关键字可以修饰方法以及代码块。synchronized关键字在JavaSE1.6之后进⾏了主要包括为了减少获得锁和释放锁带来的性能消耗而引⼊的偏向锁和轻量级锁以及其它各种优化之后执⾏效率有了显著提升，实际开发中使用synchronized 关键字的场景还是更多⼀些；
- 多线程访问volatile关键字不会发生阻塞，而synchronized关键字可能会发生阻塞；
- volatile关键字能保证数据的可见性，但不能保证数据的原⼦性。synchronized关键字两者都能
保证。 - volatile关键字主要用于解决变量在多个线程之间的可见性，而 synchronized关键字解决的是
多个线程之间访问资源的同步性。