synchronized锁优化（上）

Java提供了关键字synchronized，方便快捷的解决的线程安全问题。那么synchronized真的就那么好用吗，就没有什么缺点或者需要优化的地方吗？本文就要介绍一下synchronized锁优化。

自旋锁和适应自旋锁

锁消除

锁粗化

偏向锁、轻量级锁、重量级锁

锁的膨胀过程

1. 为什么需要优化？

synchronized监视器锁在互斥同步上对性能的影响很大。

Java的线程是映射到操作系统原生线程之上的，如果要阻塞或唤醒一个线程就需要操作系统的帮忙，这就要从用户态转换到内核态，状态转换需要花费很多的处理器时间。

所以频繁的通过Synchronized实现同步会严重影响到程序效率，这种锁机制也被称为重量级锁，为了减少重量级锁带来的性能开销，JDK对Synchronized进行了种种优化。

2. 自旋锁和适应自旋锁

大多数情况下，线程持有锁的时间都不会太长，为了这一段很短的时间频繁地阻塞和唤醒线程是非常不值得的。所以引入自旋锁。

1）自旋锁

当锁被占用时，当前想要获取锁的线程不会被立即挂起，而是做几个空循环，看持有锁的线程是否会很快释放锁。

2）自旋锁和阻塞最大的区别

主要区别：是不是放弃处理器的执行时间。

阻塞放弃了CPU时间，进入了等待区，等待被唤醒。响应慢。自旋锁一直占用CPU时间，时刻检查共享资源是否可以被访问，所以响应速度更快。

3）缺点

如果持有锁的线程很快就释放了锁，那么自旋的效率就非常好。但是如果持有锁的线程占用锁时间较长，等待锁的线程自旋一定次数后还是拿不到锁而被阻塞，那么自旋就白白浪费了CPU的资源。

4）自适应自旋锁

所谓自适应就意味着自旋的次数不再是固定的，它是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。线程如果自旋成功了，那么下次自旋的次数会更加多，因为虚拟机认为既然上次成功了，那么此次自旋也很有可能会再次成功，那么它就会允许自旋等待持续的次数更多。

有了自适应自旋锁，随着程序运行和性能监控信息的不断完善，虚拟机对程序锁的状况预测会越来越准确，虚拟机会变得越来越聪明。

3. 锁消除

如果JVM检测到某段代码不可能存在共享数据竞争，JVM会对这段代码的同步锁进行锁消除。

在动态编译同步块的时候，JIT编译器可以借助一种被称为逃逸分析（Escape Analysis）的技术来判断同步块所使用的锁对象是否只能够被一个线程访问而没有被发布到其他线程。

举例：

Vector的add方法是Synchronized修饰的。

在运行这段代码时，JVM可以明显检测到变量vector没有逃逸出方法vectorTest()之外，所以JVM可以大胆地将vector内部的加锁操作消除。

4. 锁粗化

很多时候，我们提倡尽量减小锁的粒度，可以避免不必要的阻塞。 让同步块的作用范围尽可能小，仅在共享数据的实际作用域中才进行同步，如果存在锁竞争，那么等待锁的线程也能尽快拿到锁。

但是如果在一段代码中连续的用同一个监视器锁反复的加锁解锁，甚至加锁操作出现在循环体中的时候，就会导致不必要的性能损耗，这种情况就需要锁粗化。

锁粗化就是将多个连续的加锁、解锁操作连接在一起，扩展成一个范围更大的锁。

举例：

会被粗化成：

5. 知识补充：Java对象头

对象在内存中存储的布局可以分为三块区域：对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）。

普通对象的对象头包括两部分：Mark Word和Class Metadata Address （类型指针），如果是数组对象还包括一个额外的Array length数组长度部分。

Mark Word：用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等等，占用内存大小与虚拟机位长一致。

Class Metadata Address：类型指针指向对象的类元数据，虚拟机通过这个指针确定该对象是哪个类的实例。

Mark Word

对象头信息是与对象自身定义的数据无关的额外存储成本，考虑到虚拟机的空间效率，Mark Word被设计成一个非固定的数据结构以便在极小的空间内存储尽量多的信息，它会根据对象的状态复用自己的存储空间。

下图描述了在32位虚拟机上，在对象不同状态时mark word各个比特位区间的含义。

对象头——《Java并发编程艺术》