共计 2751 个字符，预计需要花费 7 分钟才能阅读完成。
一、同步机制
保障共享资源的读写平安，须要一种同步机制：用于解决 2 方面问题：
线程间通信：线程间替换信息的机制
线程间同步：管制不同线程之间操作产生绝对程序的机制
二、同步机制 - 管程
2.1 意识管程
同步机制中有经典的管程计划，对于管程在在中国大学 mooc 中搜寻 管程 有些大学的操作系统课程会解说管程。管程其实就是对共享变量以及其操作的封装：
将共享资源封装起来，对外提供操作这些共享资源的办法。
线程只能通过调用管程中的办法来间接地拜访管程中的共享资源
2.2 管程如何解决同步和通信问题：
同步问题：
管程是互斥进入，管程提供了入口期待队列：存储期待进入同步代码块的线程
管程的互斥性是由编译器负责保障的。
通信问题:
管程中设置条件变量，期待 / 唤醒操作，以解决同步问题。
条件变量（java 里了解为锁对象本身）
期待操作: 能够让过程、线程在条件变量上期待（此时，应先开释管程的使用权，不然别其它线程、过程拿不到使用权）；将线程存储到条件变量的期待队列中。
发信号操作: 也能够通过发送信号将期待在条件变量上的过程、线程唤醒（将期待队列中的线程唤醒）
2.3 要害数据结构和办法：
线程队列：
入口期待队列：存储期待进入同步代码块的线程；线程进入管程后，能够执行同步块代码。java 中的_EntryList
条件期待队列：入口期待队列中的线程，进入管程后，执行同步块代码的过程中，须要期待某个条件满足之后，能力继续执行，就将线程放入此变量的期待队列中。java 是面向对象的设计，这里的条件变量即锁对象本身（线程都在期待领有这个锁），所以只有一个条件变量期待队列即_WaitSet。
同步办法：
wait()：期待条件变量，将线程放入条件变量的期待队列中。
notify()：激活某个条件变量上期待队列中的一个线程
notifyAll()：激活某个条件变量上期待队列中的所有线程
三、java 版的管程 synchronized
synchronized 是语法糖，会被编译器编译成：1 个 monitorenter 和 2 个 moitorexit（一个用于失常退出，一个用于异样退出）。monitorenter 和 失常退出的 monitorexit 两头是 synchronized 包裹的代码，如下图：
在 HotSpot 虚拟机中，monitor 是由 ObjectMonitor 实现的，ObjectMonitor 次要数据结构如下：
_count：记录 owner 线程获取锁的次数，即重入次数，也即是可重入的。
_owner：指向领有该对象的线程
_EntryList：管程的入口期待队列，即寄存期待锁而被 block 的线程。
_WaitSet：管程的条件变量期待队列，寄存领有锁后，调用了 wait() 办法的线程；
进入 EntryList 的线程须要与其余线程争抢锁，抢到锁之后以排它形式执行同步代码块的代码，当一个线程被 notify 后，将从_WaitSet 中挪动到 EntryList 中。
四、应用锁
4.1 对实例对象加锁
同步实例办法
public synchronized void fun(){
}
复制代码
同步代码块 参数是实例
public void fun(){
synchronized(this){...}}
复制代码
4.2 对类加锁
同步静态方法
class Aclass{
static synchronized void fun(){}}
复制代码
同步代码块 参数是类
class Aclass{
static void fun(){synchronized (Aclass.class){}}}
复制代码
4.3 对象的内存构造
HotSpot 虚拟机中，对象在内存中存储的布局能够分为三块区域: 对象头 (Header)、实例数据(Instance Data) 和对齐填充 (Padding)。其中对象头中的 Mark Word 区域中会存储 对象锁，锁状态标记，偏差 锁(线程)ID，偏差工夫，数组长度(数组对象) 等，Mark Word 被设计成一个非固定的数据结构以便在极小的空间内 存存储尽量多的数据，它会依据对象的状态复用本人的存储空间，也就是说，Mark Word 会随着程序的运行发生变化，32 位虚拟机中变动状态如下：
五、锁的变动
锁的性能开销的变动：无锁——> 偏差锁——> 轻量级锁——> 重量级锁，并且收缩方向不可逆。
偏差锁：线程获取锁后，锁对象的 Mark Word 标记偏差锁，通过一个字段记录以后线程 id，
本线程再次争取锁时：查看这个线程 ID 跟本人一样，就重入。
不同的线程争取锁：锁对象中的线程 ID 不是本人，且有偏差锁标识，则发动偏差锁勾销操作。
在 SafePoint 的时候，若偏差锁勾销胜利，且以后线程通过 CAS 操作争取到了锁，则持续放弃偏差锁状态.
若一次 CAS 操作未争取到锁，意味着还有其余的线程也在竞争这个锁，此时就进行锁降级，降级为轻量级锁。
轻量级锁是自适应自旋锁
自旋获取锁胜利：放弃轻量级锁状态？？
自旋获取锁失败，则进入重量级锁；
5.1 老本的差别
不同的锁性能老本不同：
1）重量级锁：线程在用户态到内核态之间切换老本高
锁不能降级，锁变成重量级锁之后，就始终要作为重量级锁应用吗？那还怎么自适应自旋？？
Java 锁优化 –JVM 锁降级里说道：锁降级的确 是会产生的，当 JVM 进入平安点（SafePoint）的时候，会查看是否有闲置的 Monitor，而后试图进行降级。
2）其余的锁都是为了更小的开销
偏差锁：一次 CAS 操作，批改一下锁中的字段，就被标识为拿失去了锁
轻量锁：一次 CAS 操作拿不到锁，，那就自旋空转屡次 CAS 操作，会稍稍费一点 CPU，然而能更快的拿到锁；自适应自旋后，还拿不到锁，那就只能应用重量级锁了。
自旋锁：许多状况下，共享数据的锁定状态持续时间较短，切换线程不值得，通过让线程执行循环期待锁的开释，不让出 CPU。如果失去锁，就顺利进入临界区。如果还不能取得锁，那就会将线程在操作系统层面挂起，这就是自旋锁的优化形式。然而它也存在毛病：如果锁被其余线程长时间占用，始终不开释 CPU，会带来许多的性能开销。
自适应自旋锁：这种相当于是对下面自旋锁优化形式的进一步优化，它的自旋的次数不再固定，其自旋的次数由前一次在同一个锁上的自旋工夫及锁的拥有者的状态来决定，这就解决了自旋锁带来的毛病。
5.2 锁打消
打消锁是虚拟机另外一种锁的优化，这种优化更彻底，在 JIT 编译时，对运行上下文进行扫描，做逃逸剖析，去除不可能存在竞争的锁（去掉了申请和开释锁的代码了）。比方上面代码的 method1 和 method2 的执行效率是一样的，因为 object 锁是公有变量，不存在所得竞争关系。
锁打消示例 (来自网络).png
5.3 锁粗化
锁粗化是虚拟机对另一种极其状况的优化解决，通过扩充锁的范畴，防止重复获取锁和开释锁。比方上面 method3 通过锁粗化优化之后就和 method4 执行效率一样了。