Synchronized
Posted java_wxid
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Synchronized相关的知识，希望对你有一定的参考价值。
文章目录
定义
Synchronized是Java语言的关键字，它保证同一时刻被Synchronized修饰的代码最多只有1个线程执行。
应用场景
synchronized如果加在方法上/对象上，那么，它作用的对象是非静态的，它取得的锁是对象锁；
synchronized如果作用的对象是一个静态方法或一个类，它取到的锁是类锁，这个类所有的对象用的是同一把锁。每个对象只有一个锁，谁拿到这个锁，谁就可以运行它所控制的那段代码。
对象在JVM中对象的布局
介绍synchronized底层原理需要先了解Java对象在Jvm中的布局。
在JVM中，对象在内存中的布局分为三块区域：对象头、实例数据和对齐填充。
实例数据：存放类的属性数据信息，包括父类的属性信息；
对齐填充：仅仅是为了字节对齐，虚拟机要求对象起始地址必须是8字节的整数倍。填充的数据不是必须存在的；
对象头：Java对象头一般占有2个机器码，但是如果对象是数组类型，则需要3个机器码，因为JVM虚拟机可以通过Java对象的元数据信息确定Java对象的大小，但是无法从数组的元数据来确认数组的大小，所以用一块来记录数组长度。
- 虚拟机的对象头主要包括两部分数据：Mark Word（标记字段）、Class Pointer（类型指针）。
ClassPointer是对象指向类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例
MarkWord则是用于存储对象自身的运行时数据，比如：哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等等。
在Java的设计中，每一个Java对象就带了一把看不见的锁，可以叫做内部锁或者Monitor锁。Synchronized在JVM里的实现基于进入和退出Monitor对象来实现方法同步和代码块同步的。Monitor可以把它理解为一个同步工具，它通常被描述为一个对象，所有的Java对象是天生的Monitor，每一个Java对象都有成为Monitor的潜质。Monitor监视器对象就是存在于每个Java对象的对象头MarkWord里面，也就是存储指针的指向，Synchronized锁便是通过这种方式获取锁的。
对象头的最后两位存储了锁的标志位，01是初始状态，没加锁状态，对象头里存储的是对象本身的哈希码。01是偏向锁状态，存储的是当前占用对象的线程ID。00是轻量级锁状态，存储指向线程栈中锁记录的指针。10是重量级锁状态，存储的就是重量级锁的指针了。
64位JVM下的对象结构描述：
锁主要存在四种状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁。但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级。JDK5引进CAS自旋，JDK6开始又引入了自适应的CAS自旋、锁消除、锁粗化、偏向锁、轻量级锁这些优化策略，这些优化使得Synchronized性能极大提高。
JVM通过 synchronized 在对象上加锁实现原理
JDK6以前
Synchronized加锁是通过对象内部的监视器锁来实现的，监视器锁本质又是依赖于底层的操作系统的Mutex Lock来实现的，操作系统实现线程之间的切换这就需要从用户态转换到核心态，这个成本非常高，状态之间的转换需要比较长的时间。
实现步骤
第一步，当有二个线程A、线程B都要开始给变量+1，要进行操作的时候，发现方法上加了Synchronized锁，这时线程调度到A线程执行，A线程就抢先拿到了锁，当前已经获取到锁资源的线程被称为Owner，将MonitorObject中的_owner设置成A线程。
第二步，将mark word设置为Monitor对象地址，锁标志位改为10；
第三步，将B线程阻塞，放到ContentionList队列中。因为JVM每次从Waiting Queue的尾部取出一个线程放到OnDeck中，作为候选者，但是如果并发比较高，WaitingQueue会被大量线程执行CAS操作，为了降低对尾部元素的竞争，将WaitingQueue拆分成ContentionList和EntryList二个队列，所有请求锁的线程首先尝试自旋获取锁，如果获取不到，被放在ContentionList这个竞争队列中，ContentionList中那些有资格成为候选资源的线程被移动到EntryList中。ContentionList、EntryList、WaitSet中的线程都处于阻塞状态，该阻塞是由操作系统来完成的，Linux内核下采用pthread_mutex_lock内核函数实现的。
第四步，作为Owner的A线程执行过程中，可能调用wait释放锁，这个时候A线程进入WaitSet，等待被唤醒。
JDK6版本及以后
Sun程序员发现大部分程序大多数时间都不会发生多个线程同时访问竞态资源的情况，大多数对象的加锁和解锁都是在特定的线程中完成，出现线程竞争锁的情况概率比较低。通过软件测试同一个线程加锁解锁的重复率，早期 JVM有19%的执行时间浪费在锁上，重复加锁比例非常高。每次线程都加锁解锁，每次这么搞都要操作系统在用户态和内核态之前来回切，太耗性能了，所以引入了偏向锁和轻量级锁。
对象从无锁到偏向锁转化的过程
（JVM -XX:+UseBiasedLocking 开启偏向锁）
当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，以后该线程进入和退出同步块时不需要花费CAS操作来争夺锁资源，只需要检查是否为偏向锁、锁标识为以及ThreadID就可以了。具体的流程是这样的：
第一步，检测MarkWord是否为可偏向状态，是偏向锁是1，锁标识位是01。
第二步，如果是可偏向状态，测试线程ID是不是当前线程ID。如果是，就直接执行同步代码块。
第三步，如果测试线程ID不是当前线程ID，就通过CAS操作竞争锁，竞争成功，就把MarkWord的线程ID替换为当前线程ID。
第四步，如果CAS竞争锁失败，证明有别的线程持有锁，假设线程B来CAS失败了，这个时候启动偏向锁撤销（revokebias），让A线程在全局安全点阻塞，获得偏向锁的线程被挂起，有点类似于GC前线程在安全点阻塞。
第五步，接着遍历线程栈，查看有没有锁对象的锁记录LockRecord，如果有LockRecord，需要修复锁记录和Markword，让它变成无锁状态。恢复A线程，将是否为偏向锁状态改为0，偏向锁升级为轻量级锁，然后被阻塞在安全点的线程，继续往下执行同步代码块。
安全点是jvm为了保证在垃圾回收的过程中引用关系不会发生变化，设置的安全状态，在这个状态上会暂停所有线程工作。一般有循环的末尾，方法临返回前，调用方法的call指令后，可能抛异常的位置，这些位置都可以算是安全点。
如果确定竞态资源会被高并发的访问，通过
-XX:-UseBiasedLocking //关闭偏向锁
关闭偏向锁，偏向锁的好处是并发度很低的情况下，同一个线程获取锁不需要内存拷贝的操作，免去了轻量级锁的在线程栈中建LockRecord，拷贝MarkDown的内容，也免了重量级锁的底层操作系统用户态到内核态的切换，节省毫无意义的请求锁的时间。另外Hotspot也做了另一项优化，基于锁对象的epoch批量偏移和批量撤销偏移，这样大大降低了偏向锁的CAS和锁撤销带来的损耗。因为基于epoch批量撤销偏向锁和批量加偏向锁能大幅提升吞吐量，但是并发量特别大的时候性能就没有什么特别的提升了。
另一方面偏向锁是为了消除CAS，降低Cache一致性流量，CAS操作会延迟本地调用。为什么这么说呢？这要从SMP（对称多处理器）架构说起，所有的CPU会共享一条系统总线BUS，靠此总线连接主内存，每个核都有自己的一级缓存，每个核相对于BUS对称分布。
举个例子，我电脑是六核的，假设一个核是Core1，一个核是Core2，这二个核可能会同时把主存中某个位置的值Load到自己的一级缓存中。当Core1在自己的L1Cache中修改这个位置的值时，会通过总线，使Core2中L1Cache对应的值“失效”，而Core2一旦发现自己L1Cache中的值失效，也就是所谓的Cache命中缺失，一旦发现失效就会通过总线从内存中加载该地址最新的值，大家通过总线的来回通信叫做“Cache一致性流量”。
如果Cache一致性流量过大，总线将成为瓶颈。而当Core1和Core2中的值再次一致时，称为“Cache一致性”，从这个层面来说，锁设计的终极目标便是减少Cache一致性流量。而CAS恰好会导致Cache一致性流量，如果有很多线程都共享同一个对象，当某个CoreCAS成功时必然会引起总线风暴，这就是所谓的本地延迟。
轻量级锁升级
轻量级锁升级过程是，在当前线程的栈帧中建立一个名为锁记录的空间，用于存储锁对象目前的MarkWord的拷贝，拷贝无锁状态对象头中的MarkWord复制到锁记录中，这么做是因为在申请对象锁时，需要以该值作为CAS的比较条件。同时在升级到重量级锁的时候，能通过这个比较，判定是否在持有锁的过程中，这个锁被其他线程申请过，如果被其他线程申请了，在释放锁的时候要唤醒被挂起的线程。无锁的markword中可能存有hashCode，锁撤销之后必须恢复，这个markword要用于锁撤销后的还原。如果轻量级锁解锁为无锁状态，直接将拷贝的markword CAS修改到锁对象的markword里面就可以了。
拷贝成功后，虚拟机将使用CAS操作把对象中对象头MarkWord替换为指向锁记录的指针，然后把锁记录空间里的owner指针指向加锁的对象，如果这个更新动作成功了，那么当前线程就拥有了该对象的锁，并且对象MarkWord的锁标志位设置为“00”，即表示此对象处于轻量级锁定状态。
如果这个更新操作失败了，虚拟机首先会检查对象MarkWord中的Lock Word是否指向当前线程的栈帧，如果是，就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行。如果不是说明多个线程竞争锁，进入自旋，若自旋结束时仍未获得锁，轻量级锁就要膨胀为重量级锁，锁标志的状态值变为“10”，MarkWord中存储的就是指向重量级锁（互斥量）的指针，当前线程以及后面等待锁的线程也要进入阻塞状态。
当锁升级为轻量级锁之后，如果依然有新线程过来竞争锁，首先新线程会自旋尝试获取锁，尝试到一定次数（默认10次）依然没有拿到，锁就会升级成重量级锁。一般来说，同步代码块内的代码应该很快就执行结束，这时候线程B自旋一段时间是很容易拿到锁的，但是如果不巧，没拿到，自旋其实就是死循环，很耗CPU的，因此就直接转成重量级锁咯，这样就不用了线程一直自旋了。
自旋锁
自旋锁不是一种锁状态，而是一种策略。线程的阻塞和唤醒需要CPU从用户态转为核心态，频繁的阻塞和唤醒对CPU来说是一件负担很重的工作。所以引入自旋锁，当一个线程尝试获取某个锁时，如果该锁已被其他线程占用，就一直循环检测锁是否被释放，而不是进入线程挂起或睡眠状态。自旋等待不能替代阻塞，虽然它可以避免线程切换带来的开销，但是它占用了CPU处理器的时间。
自旋锁适用于锁保护的临界区很小的情况，临界区很小的话，锁占用的时间就很短。如果持有锁的线程很快就释放了锁，那么自旋的效率就非常好。自旋的次数必须要有一个限度，如果自旋超过了定义的限度仍然没有获取到锁，就应该被挂起。但是这个限度不能固定，程序锁的状况是不可预估的，所以JDK1.6引入自适应的自旋锁，线程如果自旋成功了，那么下次自旋的次数会更加多，因为虚拟机认为既然上次成功了，那么此次自旋也很有可能会再次成功，那么它就会允许自旋等待持续的次数更多。如果对于某个锁，很少有自旋能够成功，那么在以后要或者这个锁的时候自旋的次数会减少，甚至省略掉自旋过程，以免浪费处理器资源。
通过–XX:+UseSpinning参数来开启自旋（JDK1.6之前默认关闭自旋）。
通过–XX:PreBlockSpin修改自旋次数，默认值是10次。
重量级锁
重量级锁状态：
当一个线程在等锁时会不停的自旋（底层就是一个while循环），当自旋的线程达到CPU核数的1/2时，就会升级为重量级锁。
将锁标志为置为10，将MarkWord中指针指向重量级的monitor，阻塞所有没有获取到锁的线程。Synchronized是通过对象内部的监视器锁（Monitor）来实现的，监视器锁本质又是依赖于底层的操作系统的MutexLock来实现的，操作系统实现线程之间的切换这就需要从用户态转换到核心态，状态之间的转换需要比较长的时间，这就是为什么Synchronized效率低的原因，这种依赖于操作系统MutexLock所实现的锁我们称之为“重量级锁”。
重量级锁的加锁-等待-撤销流程：
曾经获得过锁的线程，被唤醒后，优先得到锁。举个例子，假设有A，B，C三个线程依次进入synchronized区，并且A已经膨胀成重量级锁。如果有一个线程 a 先进入 synchronized , 但是调用了 wait释放锁，这是线程 b 进入了 synchronized，b还在synchronized中执行，c线程又进来了。此时 a 在 wait_set ，b 不在任何队列，c 在 cxq_list ，假如 b 调用 notify唤醒线程，会把 a 插到 c 前面，也就是 b 退出synchronized的时候，会唤醒 a，a退出之后再唤醒 c。
重量级锁撤销之后是无锁状态，撤销锁之后会清除创建的monitor对象并修改markword，这个过程需要一段时间。Monitor对象是通过GC来清除的。GC清除掉monitor对象之后，就会撤销为无锁状态。
总结一下
偏向锁：加锁和解锁不需要额外的消耗，和执行非同步方法相比，性能相差不大。但是如果线程间存在锁竞争，会有额外的锁撤销的消耗，所以适合只有一个线程访问同步块的场景。
轻量级锁：竞争的线程不会阻塞，提高程序的响应速度，但是如果始终得不到锁竞争的线程，会自旋消耗CPU资源，追求响应时间，同步块执行速度比较快的场景。
重量级锁：线程竞争不使用自旋，不会消耗CPU，但是会有线程阻塞，响应时间慢，追求吞吐量，同步块执行时间较长的场景。
以上是关于Synchronized的主要内容，如果未能解决你的问题，请参考以下文章