Synchronized与锁升级

synchronized 锁

用锁能够实现数据的安全性，但是会带来性能下降，无锁能够基于线程并行提升程序性能，但是会带来安全性下降。
锁的升级过程：

无锁—>偏向锁----> 轻量锁----->重量锁

synchronized 锁： 由对象头中的Mark Word 更具锁标志位的不同而被复用及锁升级策略

java5以前，只有synchronized ，这个是操作系统级别的重量级操作，
重量级锁，假如锁的竞争比较激烈的话，性能下降，java5之前，用户态和内核态之间的切换

java的线程是映射到操作系统原生线程之上的，如果要阻塞或唤醒一个线程就需要操作系统介入，需要在用户态与核心态之间切换，这种切换会消耗大量的系统资源，因为用户态与内核态都有各自专用的内存空间，专用的寄存器等，用户态切换至内核态需要传递给许多变量，参数给内核，内核也需要保护好用户态在切换的时的一些寄存器、变量、
等，以便内核态调用结束后切换回用户态继续工作。

在Java早期版本中，synchronized属于重量级锁，效率低下，因为监视器锁（monitor）是依赖于底层的操作系统的Mutex Lock来实现的，挂起线程和恢复线程都需要转入内核态去完成，阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成，这种状态切换需要耗费处理器时间，如果同步代码块中内容过于简单，这种切换的时间可能比用户代码执行的时间还长”，时间成本相对较高，这也是为什么早期的synchronized效率低的原因
Java 6之后，为了减少获得锁和释放锁所带来的性能消耗，引入了轻量级锁和偏向锁

为什么每一个对象都可以成为一个锁？？？

Monitor可以理解为一种同步工具，也可以理解为一种同步机制，常常被描述为一个对象。
java对象是天生的Monitor，没一个java对象都有成为Monitor的潜质，因为java的设计中，
每一个java对象自打里出来就带了一把看不见的锁，它叫做内部锁或者Monitor锁。

Monitor 的本质是依赖于底层操作系统的MutexLock实现，操作系统实现线程之间的切换需要从用户态到内核态的转换，成本非常高、

Mutex Lock
Monitor是jvm 底层实现的，底层代码是C++。本质是依赖于底层操作系统的Mutex Lock实现，操作系统实现线程之前的切换需要从用户态到内核态的转换，状态转换需要耗费很多的处理器时间成本非常高，所以synchronized是java的一个重量级操作、
Monitor 与Java 对象以及线程是如何关联的？
1.如果java对象被某个线程锁住，则该java对象的MarkWord字段中LockWord指向monitor的起始地址
2.Monitor的Owner字段会存放拥有相关联对象锁的线程ID

Mutex Lock 的切换需要从用户态切换到核心态中，因此状态转换需要耗费很多的处理器时间。

锁的种类和升级：

synchronized 用的锁是存在java对象头里的MarkWord中锁升级功能主要依赖MarkWord中锁标志位和释放偏向锁
标志

无锁：

偏锁：
主要作用：
当一段同步代码，一直被同一个线程多次访问，由于只有一个线程那么该线程在后续访问时便会自动获得锁
同一个老顾客来访问，直接老规矩行方便，看看多线程买票，同一个线程获得
Hotspot的作者经过研究发现，大多数情况下：
多线程的情况下，锁不仅不存在多线程竞争，还存在锁由同一线程多次获得的情况，偏向锁就是在这种情况下出现的，
它的出现是为了解决只有在一个线程执行同步时提高性能。

理论落地：
在实际应用运行过程中发现，锁总是同一个线程持有，很少发生竞争，也就是说锁总被第一个占用他的线程拥有，这个线程就是锁的偏向线程。
那么只需要在锁第一次被拥有的时候，记录下偏向线程ID，这样偏向线程就一直持有着锁（后续这个线程进入和退出这段加了同步锁的代码块的时候，不需要再次加锁和释放锁，而是直接比较对象头里面是否存储了指向当前线程的偏向锁）
如果相等表示偏向锁是偏向于当前线程的，就不需要再尝试获得锁了，直到竞争发生才释放锁，以后每次同步，检查锁的偏向线程ID与当前线程ID是否一致，如果一致直接进入同步。无需每次加锁解锁都去CAS更新对象头。如果自始至终使用锁的线程只有一个，很明显偏向锁几乎没有额外开销，性能极高。
假如不一致意味着发生了竞争，锁已经不是总是偏向于同一个线程了，这时候可能需要升级变为轻量级锁，才能保证线程间公平竞争锁。偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程是不会主动释放偏向锁的。
技术实现：
一个synchronized方法被一个线程抢到了锁时，那这个方法锁所在的对象就会在其所在的MarkWord中将偏向锁修改状态位，同时还会占用前54位来存储线程指针作为标识，若该线程再次访问同一个synchronized方法时，该线程只需要去对象头的MarkWord中去判断一下是否偏向锁指向本身的ID，无需再进入Monitor去竞争对象了。

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

• 实际上偏向锁在JDK1.6之后是默认开启的，但是启动时间有延迟，
• 所以需要添加参数-XX:BiasedLockingStartupDelay=0，让其在程序启动时立刻启动。
• 开启偏向锁：
• -XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0
• 关闭偏向锁：关闭之后程序默认会直接进入------------------------------------------>>>>>>>> 轻量级锁状态。
• -XX:-UseBiasedLocking

偏向锁的撤销

当有另外线程逐步来竞争锁的时候，就不能再使用偏向锁了，要升级为轻量锁
竞争线程尝试CAS更新对象头失败，会等待到全局安全点（此时不会执行任何代码）撤销偏向锁。

偏向锁使用一种等到**竞争出现才释放锁的机制，**只有当其他线程竞争锁时，持有偏向锁的原来线程才会被撤销。
撤销需要等待全局安全点（该时间点上没有字节码正在执行），同时检查持有偏向锁的线程是否还在执行：

1.第一个线程正在执行synchronized方法（处于同步块），它还没有执行完，其他线程来抢夺，该偏向锁会被取消并出现锁升级。
此时轻量级锁由原来持有偏向锁线程加持，继续执行其同步代码，而正在竞争的线程会进入自选等待获得该轻量级锁
2.第一个线程执行完成synchronized方法（退出同步块），则将对象头设置成无锁状态并撤销偏向锁，重新偏向。

轻锁
主要作用：有线程来参与锁的竞争，但是获取锁的冲突时间极短，本质就是自选锁

轻量锁是为了在线程近乎交替执行同步代快时提高性能、
主要目的： 在没有多线程竞争的前提下，通过CAS减少重量级锁使用操作系统互斥量产生的性能消耗，说白了先自选再阻塞
**升级时机：**当关闭偏向锁功能或多线程竞争偏向锁会导致偏向锁升级为轻量级锁

假如线程A已经拿到锁，这时线程B又来抢该对象的锁，由于该对象的锁已经被线程A拿到，当前该锁已是偏向锁了。
而线程B在争抢时发现对象头Mark Word中的线程ID不是线程B自己的线程ID(而是线程A)，那线程B就会进行CAS操作希望能获得锁。
此时线程B操作中有两种情况：
如果锁获取成功，直接替换Mark Word中的线程ID为B自己的ID(A → B)，重新偏向于其他线程(即将偏向锁交给其他线程，相当于当前线程"被"释放了锁)，该锁会保持偏向锁状态，A线程Over，B线程上位；

如果锁获取失败，则偏向锁升级为轻量级锁，此时轻量级锁由原持有偏向锁的线程持有，继续执行其同步代码，而正在竞争的线程B会进入自旋等待获得该轻量级锁。

自选达到一定的次数和程度：

java6之前：

默认启用，默认情况下自选的次数是10次，-XX:PreBlockSpin=10来修改
或者自选线程数超过CPU核数一半

java6之后：
自适应，自适应意味着自选的次数不是固定不变的，而是根据同一个锁上一次自选的时间，拥有锁线程的状态来决定

轻量锁与偏向锁的区别和不同：
争夺轻量级锁失败时，自选尝试抢占锁，轻量级锁每次退出同步块都需要释放锁，而偏向锁是在竞争发生时才释放锁。

重锁：
大量的线程参与锁的竞争，冲突性很高

锁的优缺点的对比：

synchronized锁升级过程总结：一句话，就是先自选，不行再阻塞
实际上是把之前的悲观锁（重量级锁）变成在一定条件下使用偏向锁以及使用轻量级（自选锁CAS）的形式
synchronized 在修饰方法和代码块在字节码上实现方式有很大差异，但是内部实现还是基于对象头的MarkWord实现的
JDK1.6之前synchronized使用的是重量级锁，JDK1.6之后进行了优化，拥有了无锁---->偏向锁----->轻量锁----->重量锁的升级过程，而不是无论什么情况都使用重量锁

**偏向锁：**适用于单线程使用情况，在不存在锁竞争的时候进入同步方法、代码块使用偏向锁
**轻量锁：**适用于竞争不激烈的情况（这和乐观锁的使用范围类似），存在竞争时升级为轻量锁，轻量锁采用的是自选锁，如果同步方法、代码执行时间很短的话，采用轻量锁虽然会占用CPU资源但是相对比使用重量锁还是高效
**重量锁：**适用于竞争激烈的情况，如果同步方法、代码块执行时间长，那么使用轻量锁自旋带来的性能消耗就比使用重量级锁更严重，这个时候就需要升级为重量级锁