【并发编程】synchronized底层实现原理

synchronized

原子性、可见性、有序性

应用

加锁的三种方式：

1、普通同步方法，锁的是实例对象

2、静态同步方法，锁的是当前类的对象。

3、同步方法块，锁的是synchronized括号里的对象

synchronized的字节码指令：

对于同步块的实现使用了monitorenter和monitorexit指令，前面我 们在讲JMM的时候，提到过这两个指令，他们隐式的执行了Lock和UnLock操作，用于提供原子性保证。monitorenter指令插入到同步代码块开始的位置、monitorexit指令插入到同步代码块结束位置，jvm需要保证每 个monitorenter都有一个monitorexit对应。

这两个指令，本质上都是对一个对象的监视器(monitor)进行获取，这个过程是排他的，也就是说同一时刻只能有 一个线程获取到由synchronized所保护对象的监视器

线程执行到monitorenter指令时，会尝试获取对象所对应的monitor所有权，也就是尝试获取对象的锁;而执行monitorexit，就是释放monitor的所有权。

Java对象头

对象在内存中的布局分为三块区域:对象头、实例数据和对齐填充;Java对象头是实现synchronized的锁对象的基础，一般而言，synchronized使用的锁对象是存储在Java对象头里。它是轻量级锁和偏 向锁的关键。

synchronized的锁升级和获取过程

无锁->偏向锁->轻量 级锁->重量级锁.

自旋锁(CAS)

自旋锁就是让不满足条件的线程等待一段时间，而不是立即挂起。看持有锁的线程是否能够很快释放锁。怎么自旋

呢?其实就是一段没有任何意义的循环。

虽然它通过占用处理器的时间来避免线程切换带来的开销，但是如果持有锁的线程不能在很快释放锁，那么自旋的

线程就会浪费处理器的资源，因为它不会做任何有意义的工作。所以，自旋等待的时间或者次数是有一个限度的，

如果自旋超过了定义的时间仍然没有获取到锁，则该线程应该被挂起

偏向锁

大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了 偏向锁。当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，以后该线程在 进入和退出同步块时不需要进行CAS操作来加锁和解锁，只需简单地测试一下对象头的Mark Word里是否存储着指 向当前线程的偏向锁。如果测试成功，表示线程已经获得了锁。如果测试失败，则需要再测试一下Mark Word中偏 向锁的标识是否设置成1(表示当前是偏向锁):如果没有设置，则使用CAS竞争锁;如果设置了，则尝试使用CAS将对象头的偏向锁指向当前线程

轻量级锁

引入轻量级锁的主要目的是在多没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消

耗。当关闭偏向锁功能或者多个线程竞争偏向锁导致偏向锁升级为轻量级锁，则会尝试获取轻量级锁

重量级锁

重量级锁通过对象内部的监视器(monitor)实现，其中monitor的本质是依赖于底层操作系统的Mutex Lock实 现，操作系统实现线程之间的切换需要从用户态到内核态的切换，切换成本非常高。

Monitor

每个object的对象里 markOop->monitor() 里可以保存ObjectMonitor的对象。从源码层面分析一下monitor对象

Ø oop.hpp下的oopDesc类是JVM对象的顶级基类，所以每个object对象都包含markOop img

Ø markOop.hpp中 markOopDesc继承自oopDesc，并扩展了自己的monitor方法，这个方法返回一个ObjectMonitor指针对象

img

Ø objectMonitor.hpp,在hotspot虚拟机中，采用ObjectMonitor类来实现monitor。

wait和notify的原理

wait和notify为什么需要在synchronized里面

wait方法的语义有两个，一个是释放当前的对象锁、另一个是使得当前线程进入阻塞队列， 而这些操作都和监视器是

相关的，所以wait必须要获得一个监视器锁

而对于notify来说也是一样，它是唤醒一个线程，既然要去唤醒，首先得知道它在哪里?所以就必须要找到这个对 象获取到这个对象的锁，然后到这个对象的等待队列中去唤醒一个线程。

cas

ABA问题：

变量前边加上版本号。