文章目录
- 1、synchronized关键字的底层原理：Monitor
- 2、synchronized相关
- 2.1 为什么说synchronized是重量级锁
- 2.2 synchronized锁升级之偏向锁
- 2.3 synchronized锁升级之轻量级锁
- 3、Java内存模型JMM
- 4、CAS
- 4.1 CAS流程
- 4.2 CAS底层实现
- 5、volatile关键字的理解
- 5.1 可见性
- 5.2 禁止指令重排
1、synchronized关键字的底层原理：Monitor
synchronized互斥锁，同一时刻，最多只有一个线程能持有对象锁。用javap拿到synchronized示例代码的字节码信息：
javap -v SyncTest.class
可以看到synchronized底层自己上锁、解锁（解锁两次是怕出现异常后导致锁不能释放，第二个解锁相当于finally里释放锁）
Monitor，监视器，由JVM提供，c++实现。每个对象实例都会有一个Monitor对象，Monitor的结构：
线程Thread1执行到synchronized代码块，如果对象的Monitor对象的Owner属性为null，则抢锁成功，后面其他线程再进来抢锁，就进入EntryList阻塞，直到Thread1执行完释放锁，EntryList里的线程又开始争抢锁（并非先来后到的排队），WaitSet即存调用了wait方法的线程
2、synchronized相关
2.1 为什么说synchronized是重量级锁
Java应用中的线程是用Thread对象来操作的，JVM负责维护Java线程和操作系统原生线程之间的映射关系。阻塞和唤醒一个线程，都需要CPU参与，而调用硬件资源CPU只能是内核态操作，且Java对象锁通过Monitor实现，Monitor又通过操作系统的互斥量Mutex Lock实现。
因此，加解锁、阻塞线程、唤醒线程等就涉及到了用户态和内核态的频繁切换（两个空间的一些变量的值拷贝），synchronized代码块短的话，可能切换的时间比代码执行时间还长。所以synchronized称为重量级锁。
鉴于此，JDK6以后，为synchronized引入轻量级锁和偏向锁的概念，避免一下就捅到重量级锁，以尽量减少用户态和内核态的切换次数。
2.2 synchronized锁升级之偏向锁
优化场景：一个锁一直被一个线程持有。如买票时发现线程t3一直在执行卖票的synchronized代码块
偏向锁会偏向于第一个访问锁的线程，如果在接下来的运行过程中，该锁没有被其他的线程访问，则持有偏向锁的线程将永远不需要触发同步，也即偏向锁在资源没有竞争情况下消除了同步语句。
【syncoronized偏向锁】
2.3 synchronized锁升级之轻量级锁
优化场景：两个线程近乎可以错开交替执行, 或者说是有锁竞争, 但竞争不激烈的情况，获取锁的冲突时间极端，本质就是CAS自旋锁，不要直接往重锁走。
【syncoronized轻量锁】
总之, synchronized的偏向锁和轻量级锁都是为了缓冲, 尽量避免走Monitor + 操作系统的互斥变量来实现加解锁, 以减少用户态和内核态的切换, 实现性能提升
3、Java内存模型JMM
定义了线程工作内存和主内存之间读写操作的规范
每个线程有自己的工作内存, 每块线程的工作内存之间相互隔离, 操作同一个变量时, 可通过主内存分别save和load
【JMM】
4、CAS
4.1 CAS流程
比较再交换，Compare And Swap，一种乐观锁的思想，在无锁的状态下保证线程操作数据的原子性，CAS广泛用于AQS框架、AtomicXXX类
- 当前工作内存的值V
- 旧的预期值A
- 即将更新，写回主内存的值B
示意代码:
t1线程从主内存读到i=5，+1后准备把6写回主内存，此时，比较期望值5和内存中的实际i值，若相等，则乐观的认为自己运算的期间没有其他线程修改i，就将i写回主内存。反之，比如主内存i=6，那t1就再来一次，i=6，i+1，期望6，此时如果主内存i=6，则写回成功，反之继续自旋。
CAS的优势是没有加锁，线程不会陷入阻塞，效率高，反之，如果竞争激烈，频繁失败自旋重试，效率低且消耗CPU
4.2 CAS底层实现
底层通过Unsafe类来直接调用操作系统底层的CAS指令，来保证原子性，CAS对应在底层是CPU的一条原子指令cmpxchg
最后，CAS体现乐观锁的思想是，不担心自己操作期间别的线程修改了共享变量，如果被改了就吃点亏再重执行一次，反正我从主内存读数据、在工作内存读数据、写回主内存三步不可再分，有原子性保证，撑死多试几次才能修改数据成功
反之，synchronized则是悲观锁，自己操作时要防着其他线程改共享变量，上个锁，我改完解锁之后，别的线程才有机会
5、volatile关键字的理解
volatile修饰的变量 :
- 保证线程间的可见性
- 禁止进行指令重排序
5.1 可见性
volatile的可见性，即保证不同线程对某一个变量一旦完成更改，其他线程立即可见，因为会从线程的工作内存立马刷到主内存
执行结果:
结果分析：三个线程操作一个共享变量stop，线程1改了stop的值，一会儿线程2就读到了这个变化，但线程3却一直在循环，这是因为JVM的即时编译器JIT对一直执行的热点代码做了优化：
可加JVM参数-Xint禁用掉即时编译器，但得不偿失，可给共享变量加stop，JIT不会对volatile变量做优化且volatile变量会立即刷回主内存
static volatile boolean stop = true;
重新运行，显示循环16038233次后，读到stop变量变为true了：
5.2 禁止指令重排
看个案例：用@Actor注解保证方法内u的代码在同一个线程下执行
以上代码，并发测试下出现1 ,0 的结果，说明发生了重排序：
用volatile修饰变量，在读写共享变量时加入屏障，阻止其他读写操作越过屏障，以阻止指令重排序
//改为这样
int x;
volatile int y;
此时，并发测试下不再有1 ,0 的结果，屏障如下：
如果给x加volatile，则还是有1, 0 的结果
//改为这样
volatile int x;
int y;
因为此时的插入的屏障位置如下：
上面，volatile修饰x还是y，这是一个volatile的使用技巧问题：
- 写变量让 volatile 修饰的变量的在代码最后位置
- 读变量让 volatile 修饰的变量的在代码最开始位置
详见：volatile读写屏障
