本篇主要是针对 synchronized锁的优化过程来介绍，针对synchronized的加锁优化过程来了解上篇所提到的synchronized的锁特性。
目录
1. synchronized锁的特性
2.synchronized 锁的升级过程
2.1 总过程：
2.2 偏向锁
2.3 轻量级锁
2.3.1自旋锁vs自适应自旋锁
2.4 重量级锁
2.5 锁的其他优化
2.5.1 锁消除
2.5.2 锁粗化
2.6 图表总结：
1. synchronized锁的特性
1. 既是乐观锁，也是悲观锁
2.即使轻量级锁，也是重量级锁
3. 是非公平锁
4. 是可重入锁
5. 不是读写锁
提示：了解这些锁策略的可以移步：http://t.csdn.cn/HmbsY
2.synchronized 锁的升级过程
2.1 总过程：
锁对象状态优化过程：
无锁->偏向锁->轻量级锁->重量级锁
锁的状态一共分为四组：无锁状态，偏向锁，轻量级锁，重量级锁。
1.当还没有线程进行加锁时，当前对象锁处于无锁状态，
2.当有一个线程进行加锁操作时该锁会升级至偏向锁状态，
3.如果此时再来一个线程进行加锁操作，此时就锁冲突了，那么锁立即升级为轻量级锁，针对前面偏向的线程立刻进行加锁，避免线程不安全；
4.如果此时锁冲突较大，且线程每次加锁的时间较长，那么锁就会升级为重量级锁，直接依赖于操作系统底层的metux（互斥锁），使得同一时间只有一个线程在执行加锁代码，其他没抢到锁的线程会挂起等待（堵塞）
注意：锁升级是不可逆的，升级了之后策锁略不会向前退化
synchronized 加锁的线程对象是存储在锁对象的对象头中的，其中对象头中有一个对象标记（Mark Word）来标记当前锁执行的是哪种锁策略（例如偏向锁，轻量级锁等），并且记录了持有锁的线程对象。当然Mark Word中还有其他的标记状态，大致如下图所示
2.2 偏向锁
偏向锁主要是针对没有多线程竞争的场景做出的优化，当前锁总是只有同一个线程在获取锁，并不会有线程安全问题，所以也就不需要加锁去浪费CUP资源
当锁只有一个线程来加锁时，次数Mark Word 的偏向锁标记就会标记当前加锁线程，该锁也顺势升级为偏向锁，在此之后这个线程再来尝试获取该锁则不需要进行任何操作就可直接获取到锁，这样也就省去了中间申请锁操作的各种流程，进而提升了效率
2.3 轻量级锁
轻量级锁主要针对线程竞争不激烈时，避免锁使用重量级锁造成资源的情况下做出的优化
当存在锁竞争时，synchronized锁将会从偏向锁升级为轻量级锁保证线程安全
轻量级锁顾名思义针对重量级锁它是更轻量的，轻量级锁的锁竞争并不会直接去申请使用底层的mutex锁，而是把锁对象的Mark word信息交给到线程让线程去执行CAS操作，此时竞争失败的线程则进行基于CAS的自旋（自旋锁策略）
2.3.1自旋锁vs自适应自旋锁
轻量级锁前期是的锁策略是CAS自旋转来解决，但是旋转多少次是一个直接深究的问题，当线程占用锁的时间很长时，此时多线程一直在进行无实际意义自旋无疑是大大的消耗了CPU的资源，此时还不如直接升级为重量级锁
那么刚开始的JDK1.6版本轻量级锁的自旋策略每次是旋转固定的次数，如果自旋最大次数之后还没执行，那么锁便会升级为重量级锁
但是在JDK1.7时优化自旋的次数优化为自适应次数，意思就是自旋的次数会根据前面线程旋转的次数而进行自适应调整，使得锁自旋的次数不再固定，怎么做的原因就是，避免极端情况下有线程自旋次数过多导致并不激烈的竞争状态直接升级为重量级锁
总而言之还是那句话：真正意义上的线程堵塞等待永远是下策，因为线程阻塞以为着多线程并发变成了串行，效率肯定会大受影响。属于是牺牲效率保证安全。
2.4 重量级锁
当轻量级锁自旋等待时间过长锁竞争过大，此时就不能一直自旋去一直无效的占用着cpu的内核资源了，那么锁会膨胀为重量级锁，每次加锁都会真正的去调用操作系统的mutex（互斥锁）那么竞争失败的线程会挂起等待（放·弃CPU资源堵塞等待），直到加锁的线程解锁后再去重新尝试加锁。
优点是确保了线程安全
缺点：每次加锁都是从用户态去内核态申请加锁，加锁失败则堵塞等待，加锁成功则从内核态返回到用户态，我们都知道用户态和内核态的频繁切换对计算机来说已经是沧海桑田了
那么一套操作下来，如果加锁线程解锁了，然后等到操作系统去唤醒加锁的线程去重新尝试加锁效率就很低下
2.5 锁的其他优化
2.5.1 锁消除
锁消除是编译器和JVM底层的一种优化机制
通过编译编译器会提前衡量一下当前锁是否会存在竞争，如果加锁解锁在单线程执行下，此时是没必要的，所以编译器和JVM会判定当前锁可以消除
此时就会不执行加锁操作就执行加锁代码，减少了一定的开销
例子：
StringBuffer str = new StringBuffer();//线程安全的字符串对象
sb.append("a");
sb.append("b");
sb.append("c");
sb.append("d");
上诉代码中定义了一个StringBuffer对象str，而StringBuffer是一个可修改的，并且内部的关键方法使用了synchronized加锁保证了线程安全，此时我们在单个线程中对str进行修改，此时编译器和JVM就会判断当前操作并不存在线程安全，属于无效加锁，那么就会把加锁的过程给优化了，那么下面的那些append方法，虽然它内部是使用了synchronized方法，但本质并没有进行加锁操作。这些过程就是编译器和JVM进行的锁消除优化
2.5.2 锁粗化
锁粗化也是编译器和JVM做出的一种优化。
当一段代码中，在较短时间内前后多次执行对同一锁对象进行加锁操作，频繁加锁导致锁的粒度较细，那么编译器和JVM就会把当前的多个锁进行整合，让这些操作在一次加锁过程中执行完，使得锁的粒度边粗
例子：
public class Demo2 {
private static final Object lock = new Object();
public static void main(String[] args) {
int num1 = 0;
int num2 = 0;
synchronized (lock){
num1++;
}
synchronized (lock){
num2++;
}
}
}中间的加锁优化成：
public class Demo2 {
private static final Object lock = new Object();
public static void main(String[] args) {
int num1 = 0;
int num2 = 0;
synchronized (lock){
num1++;
num2++;
}
System.out.println(num1+num2);
}
}经过编译器加JVM的判定，锁的粒度过细，那么此时就会进行优化，整合锁，避免频繁的加减锁，使得资源浪费，进而提高效率
2.6 图表总结：
本章的内容介绍到这里就差不多结束了，希望各位看官老爷都能有所收获；
有写错或者不足的地方也欢迎指正
