java Synchonized 锁的特性

? 可能在很多人眼里，在java中提到锁、安全性、同步，首先想到的则是java提供的大佬（synchronized）。那么为什么在多线程下，单单靠一个关键字修饰代码块就可以实现所谓的安全性呢？可以说是对初学者而言及神奇又强大的存在。也成了大多数初学者百试不爽的良药。

? 但是在逐渐对java认知的深入，我们认识到synchronized对于jvm来说是一个重量级的锁。其笨重无比，在如今人们对速度和性能极致要求的现在，现在此时并不能满足性能上的要求。

? 诚然SUN公司也认识到了这一点，在Java SE 1.6对synchronized进行了各种优化后，有些情况下它就并不那么笨重??了。在Java SE 1.6中为了减少获得锁和释放锁带来的性能开销而引入偏向锁和轻量级锁。

---

Synchonized实现同步的基础

? Java中每一个对象都可以作为锁。具体有如下三种形式：

• 对于普通同步方法，锁是当前实例对象。

• 对于静态同步方法，锁是当前类的Class对象。

• 对于同步代码块，锁是synchronized括号里配置的对象。

---

那么线程是怎么获取上述各种锁对象的呢？

先看一段简单的三种同步方式。

    public static String test03(String s1, String s2, String s3) {
        String s = s1 + s2 + s3;
        return s;
    }

  上述代码使用javap 编译结果

众所周知，StringBuffer是安全同步的。但是在上述代码中，JVM判断该段代码并不会逃逸，则将该代码带默认为线程独有的资源，则并不需要同步，所以执行了锁消除操作。（还有Vector中的各种操作也可实现锁消除。在没有逃逸出数据安全防卫内）

锁粗话

? 原则上，我们都知道在加同步锁时，尽可能的将同步块的作用范围限制到尽量小的范围（只在共享数据的实际作用域中才进行同步，这样是为了使得需要同步的操作数量尽可能变小。在存在锁同步竞争中，也可以使得等待锁的线程尽早的拿到锁）。

? 大部分上述情况是完美正确的，但是如果存在连串的一系列操作都对同一个对象反复加锁和解锁，甚至加锁操作时出现在循环体中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要地性能操作。

? 这里贴上根据上述Javap 编译地情况编写地实例java类

    public static String test04(String s1, String s2, String s3) {
        StringBuffer sb = new StringBuffer();
        sb.append(s1);
        sb.append(s2);
        sb.append(s3);
        return sb.toString();
    }

? 在上述地连续append（）操作中就属于这类情况。JVM会检测到这样一连串地操作都是对同一个对象加锁，那么JVM会将加锁同步地范围扩展（粗化）到整个一系列操作的 外部，使整个一连串地append（）操作只需要加锁一次就可以了。

轻量级锁

? 在JDK 1.6之后引入的轻量级锁，需要注意的是轻量级锁并不是替代重量级锁的，而是对在大多数情况下同步块并不会有竞争出现提出的一种优化。它可以减少重量级锁对线程的阻塞带来地线程开销。从而提高并发性能。

? 如果要理解轻量级锁，那么必须先要了解HotSpot虚拟机中对象头地内存布局。上面介绍Java对象头也详细介绍过。在对象头中（Object Header）存在两部分。第一部分用于存储对象自身的运行时数据，HashCode、GC Age、锁标记位、是否为偏向锁。等。一般为32位或者64位（视操作系统位数定）。官方称之为Mark Word，它是实现轻量级锁和偏向锁的关键。 另外一部分存储的是指向方法区对象类型数据的指针（Klass Point），如果对象是数组的话，还会有一个额外的部分用于存储数据的长度。

轻量级锁加锁

? 在线程执行同步块之前，JVM会先在当前线程的栈帧中创建一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝（JVM会将对象头中的Mark Word拷贝到锁记录中，官方称为Displaced Mark Ward）这个时候线程堆栈与对象头的状态如图：

  轻量级锁CAS操作之前堆栈与对象的状态

? 如上图所示：如果当前对象没有被锁定，那么锁标志位位01状态，JVM在执行当前线程时，首先会在当前线程栈帧中创建锁记录Lock Record的空间用于存储锁对象目前的Mark Word的拷贝。

? 然后，虚拟机使用CAS操作将标记字段Mark Word拷贝到锁记录中，并且将Mark Word更新位指向Lock Record的指针。如果更新成功了，那么这个线程就有用了该对象的锁，并且对象Mark Word的锁标志位更新位（Mark Word中最后的2bit）00，即表示此对象处于轻量级锁定状态，如图：

  轻量级锁CAS操作之后堆栈与对象的状态

? 如果这个更新操作失败，JVM会检查当前的Mark Word中是否存在指向当前线程的栈帧的指针，如果有，说明该锁已经被获取，可以直接调用。如果没有，则说明该锁被其他线程抢占了，如果有两条以上的线程竞争同一个锁，那轻量级锁就不再有效，直接膨胀位重量级锁，没有获得锁的线程会被阻塞。此时，锁的标志位为10.Mark Word中存储的时指向重量级锁的指针。

? 轻量级解锁时，会使用原子的CAS操作将Displaced Mark Word替换回到对象头中，如果成功，则表示没有发生竞争关系。如果失败，表示当前锁存在竞争关系。锁就会膨胀成重量级锁。两个线程同时争夺锁，导致锁膨胀的流程图如下：

  轻量级锁及膨胀流程图

偏向锁

? 引入背景：在大多实际环境下，锁不仅不存在多线程竞争，而且总是由同一个线程多次获取，那么在同一个线程反复获取所释放锁中，其中并还没有锁的竞争，那么这样看上去，多次的获取锁和释放锁带来了很多不必要的性能开销和上下文切换。

? 为了解决这一问题，HotSpot的作者在Java SE 1.6 中对Synchronized进行了优化，引入了偏向锁。当一个线程访问同步快并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，以后该线程在进入和推出同步块时不需要进行CAS操作来加锁和解锁。只需要简单地测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁。如果成功，表示线程已经获取到了锁。

  偏向锁、轻量级锁的状态转换

偏向锁的撤销

? 偏向锁使用了一种等待竞争出现才会释放锁的机制。所以当其他线程尝试获取偏向锁时，持有偏向锁的线程才会释放锁。但是偏向锁的撤销需要等到全局安全点（就是当前线程没有正在执行的字节码）。它会首先暂停拥有偏向锁的线程，让你后检查持有偏向锁的线程是否活着。如果线程不处于活动状态，直接将对象头设置为无锁状态。如果线程活着，JVM会遍历栈帧中的锁记录，栈帧中的锁记录和对象头要么偏向于其他线程，要么恢复到无锁状态或者标记对象不适合作为偏向锁。

  偏向锁的获得和撤销流程

锁的优缺点对比

锁	优点	缺点	使用场景
偏向锁	加锁和解锁不需要CAS操作，没有额外的性能消耗，和执行非同步方法相比仅存在纳秒级的差距	如果线程间存在锁竞争，会带来额外的锁撤销的消耗	适用于只有一个线程访问同步快的场景
轻量级锁	竞争的线程不会阻塞，提高了响应速度	如线程成始终得不到锁竞争的线程，使用自旋会消耗CPU性能	追求响应时间，同步快执行速度非常快
重量级锁	线程竞争不适用自旋，不会消耗CPU	线程阻塞，响应时间缓慢，在多线程下，频繁的获取释放锁，会带来巨大的性能消耗	追求吞吐量，同步快执行速度较长