1 线程安全
1.1 什么是线程安全问题
“线程安全”相信稍有经验的程序员都会听说过，但是如何描述线程安全呢？在网上查到以下两点比较符合线程安全的定义：
- 如果一个对象可以安全地被多个线程同时使用，那它就是线程安全的
- 当多个线程访问同一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那么这个对象是线程安全的。
总的来说，它要求线程安全的代码都必须具备一个特征：代码本身封装了所有必要的正确性保障手段（如互斥同步等），令调用者无需关心多想你的问题，更无需自己采取任何措施来保证多线程的正确调用。
2 synchronized实现线程安全
2.1 synchronized实现同步的基础
Java中每一个对象都能作为一个锁。具体体现有以下三种形式：
- 普通同步方法，锁对象是对象本身
- 静态同步方法，锁对象是当前类的class类对象
- 同步代码块，可以自己定义锁对象
2.2 synchronized获取锁的三种形式
public class SynchronizedDemo { /** * 普通同步方法 */ public synchronized void testSynchronizedFun() { System.out.println("test Synchronized Fun"); } /** * 静态同步方法 */ public synchronized static void testSynchronizedStatic() { System.out.println("test Synchronized static Fun"); } /** * 同步代码块 */ public void testSynchronizedBlock(){ synchronized (this) { System.out.println("test synchronized block"); } } }
2.1.3 synchronized实现互斥同步的原理
synchronized关键字经过编译之后，会在同步块的前后分别形成monitorenter和monitorexit这两个字节码指令，这两个字节码都需要一个refrence类型的参数来指明要锁定和解锁的对象。如果没有明确指定，那就根据synchronized修饰的是实例方法还是类方法，去获取对应的对象实例或Class对象来作为锁对象。在执行monitorenter指令时，首先要尝试获取对象的锁。如果这个对象没有被锁定，尝试获取锁；如果当前线程已经拥有了这个对象的锁，就把锁的计数器加1。相应的，在执行monitorexit指令是会将锁计数器减1，当计数器为0时，锁就被释放。如果获取对象锁失败，那当前线程就要阻塞等待，直到对象锁被另外一个线程释放为止。
3 synchronized锁优化、锁升级
3.1 锁优化
高效并发是从JDK 1.5到JDK 1.6的一个重要改进，HotSpot虚拟机开发团队在这个版本上
花费了大量的精力去实现各种锁优化技术，如适应性自旋（Adaptive Spinning）、锁消除
（Lock Elimination）、锁粗化（Lock Coarsening）、轻量级锁（Lightweight Locking）和偏向
锁等，这些技术都是为了在线程之间更高效地共享数据，以及解决竞争问
题，从而提高程序的执行效率。
- 锁粗化（Lock Coarsening）：也就是减少不必要的紧连在一起的unlock，lock操作，将多个连续的锁扩展成一个范围更大的锁。
- 锁消除（Lock Elimination）：通过运行时JIT编译器的逃逸分析来消除一些没有在当前同步块以外被其他线程共享的数据的锁保护，通过逃逸分析也可以在线程本地Stack上进行对象空间的分配（同时还可以减少Heap上的垃圾收集开销）。
- 轻量级锁（Lightweight Locking）：这种锁实现的背后基于这样一种假设，即在真实的情况下我们程序中的大部分同步代码一般都处于无锁竞争状态（即单线程执行环境），在无锁竞争的情况下完全可以避免调用操作系统层面的重量级互斥锁，取而代之的是在monitorenter和monitorexit中只需要依靠一条CAS原子指令就可以完成锁的获取及释放。当存在锁竞争的情况下，执行CAS指令失败的线程将调用操作系统互斥锁进入到阻塞状态，当锁被释放的时候被唤醒（具体处理步骤下面详细讨论）。
- 偏向锁（Biased Locking）：是为了在无锁竞争的情况下避免在锁获取过程中执行不必要的CAS原子指令，因为CAS原子指令虽然相对于重量级锁来说开销比较小但还是存在非常可观的本地延迟
- 适应性自旋（Adaptive Spinning）：当线程在获取轻量级锁的过程中执行CAS操作失败时，在进入与monitor相关联的操作系统重量级锁（mutex semaphore）前会进入忙等待（Spinning）然后再次尝试，当尝试一定的次数后如果仍然没有成功则调用与该monitor关联的semaphore（即互斥锁）进入到阻塞状态。
3.2 锁升级
锁膨胀方向： 无锁 → 偏向锁 → 轻量级锁 → 重量级锁 （此过程是不可逆的）
3.2.1 无锁到偏向锁
3.2.2 偏向锁到轻量级锁
- 首先线程2会先检查偏向锁标记，如果是1，说明当前是偏向锁，那么JVM会找到线程1，看线程1是否还存活着
- 如果线程1已经执行完毕，就是说线程1不存在了（线程1自己是不会去释放偏向锁的），那么先将偏向锁置为0，对象头设置成为无锁的状态，用CAS的方式尝试将线程2的ID放入对象头中，不进行锁升级，还是偏向锁
- 如果线程1还活着，先暂停线程1，将锁标志位变成00（轻量级锁）然后在线程1的栈帧中开辟出一块空间（Display Mark Word）将对象头的Mark Word置换到线程一的栈帧当中，而对象头中此时存储的是指向当前线程栈帧的指针。此时就变成了轻量级锁。继续执行线程1，然后线程2采用CAS的方式尝试获取锁。
3.2.3 轻量级锁到重量级锁
以下是关于各种锁的对比以及使用场景：
| 锁 | 优点 | 缺点 | 使用场景 |
|---|---|---|---|
| 偏向锁 | 加锁和解锁不需要CAS操作，没有额外的性能消耗，和执行非同步方法相比仅存在纳秒级的差距 | 如果线程间存在锁竞争，会带来额外的锁撤销的消耗 | 适用于只有一个线程访问同步快的场景 |
| 轻量级锁 | 竞争的线程不会阻塞，提高了响应速度 | 如线程成始终得不到锁竞争的线程，使用自旋会消耗CPU性能 | 追求响应时间，同步快执行速度非常快 |
| 重量级锁 | 线程竞争不适用自旋，不会消耗CPU | 线程阻塞，响应时间缓慢，在多线程下，频繁的获取释放锁，会带来巨大的性能消耗 | 追求吞吐量，同步快执行速度较长 |