BiBi - 并发编程 -3- 锁

From：Java并发编程的艺术

• 目录
  BiBi - 并发编程 -0- 开篇
  BiBi - 并发编程 -1- 挑战
  BiBi - 并发编程 -2- volatile
  BiBi - 并发编程 -3- 锁
  BiBi - 并发编程 -4- 原子操作
  BiBi - 并发编程 -5- Java内存模型
  BiBi - 并发编程 -6- final关键字
  BiBi - 并发编程 -7- DCL
  BiBi - 并发编程 -8- 线程
  BiBi - 并发编程 -9- ReentrantLock
  BiBi - 并发编程 -10- 队列同步器
  BiBi - 并发编程 -11- 并发容器
  BiBi - 并发编程 -12- Fork/Join框架
  BiBi - 并发编程 -13- 并发工具类
  BiBi - 并发编程 -14- 线程池
  BiBi - 并发编程 -15- Executor框架

1. synchronized简介

synchronized内存语义

当线程释放锁时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存中。
当线程获取锁时，JMM会把该线程对应的本地内存置为无效，从主内存中读取。

synchronized在jvm中由monitorenter和monitorexit指令实现，当线程执行到monitorenter指令时，会去获取所需要锁。synchronized用的锁存在Java对象头里的Mark Word中。

Java对象头Mark Word的组成：锁状态 + 对象的hashCode + 分代年龄

2. 不同级别的锁

锁的级别：偏向锁 < 轻量级锁 < 重量级锁【只能升级不能降级】

偏向锁 【同一线程中使用】

背景：大多数情况下，锁不仅不存在竞争，而且总是由同一线程多次获得。
特点：在无竞争情况下把整个同步都消除掉，连CAS操作都不做了。
实现：当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里使用CAS操作存储偏向锁的线程ID，以后该线程进入和退出同步块时不需要进行CAS操作来加锁和解锁，只需要测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁。如果成功，表示线程已经获取了该锁；如果测试失败，则需要再测试一下Mark Word中偏向锁的标识是否设置成1：如果没有设置，则使用CAS竞争锁；如果设置了，则尝试使用CAS将对象头的偏向锁指向当前进程。
撤销：只有当其他线程尝试竞争偏向锁时，持有偏向锁的线程才会【在全局安全点，这个时间点不会执行任何字节码】释放。如果持有锁对象的线程已经结束，则将锁对象恢复到未锁定状态；如果持有锁对象的线程仍然活着，则将锁对象升级为轻量锁。

提示：Java6默认开启偏向锁，如果你的程序所有的锁通常都会处于竞争状态，最好关闭偏向锁，让程序默认进入轻量级锁状态。

轻量级锁【自旋不阻塞】

• 自旋
  背景：阻塞是互斥同步对性能最大的影响，挂起线程和恢复线程的操作需要转入到内核态中完成，这样很影响性能。
  实现：线程A持有锁，而线程B要竞争该锁。通常线程A会执行很短一段时间就会释放锁，为了这段时间让线程B去挂起阻塞是不值得。此时可以让线程B进入自旋（死循环）状态，等线程A释放锁后，线程B直接获取。【前提是在多处理器情况下，线程A和B占用不同的处理器，一直在消耗资源。阻塞不会消耗资源，但性能差】

轻量级锁的实现：线程在执行同步块之前，JVM现在当前线程的栈桢中创建用于存储锁记录的空间，并将对象头中的Mark Word复制到锁记录中，称为Dispatch Mark Word。然后线程尝试使用CAS将对象头中的Mark Word替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败，表示存在其他线程的竞争，当前线程尝试使用自旋来获取锁。

3. 不同锁的使用场景

重量级锁：线程竞争不会自旋，不会消耗CUP，但线程会阻塞，响应时间慢【适用于追求吞吐量，同步块执行时间较长的场景】
轻量级锁：竞争的线程不会阻塞，响应快，但得不到锁竞争的线程使用自旋消耗CUP【适用于追求响应时间，同步块执行时间较少的场景】
偏向锁：加锁和解锁不需要额外的消耗，但如果存在竞争会带来额外的锁撤销消耗【适用于只有一个线程，竞争少的场景】

4. 锁优化

锁消除

public void fun(){
  StringBuffer sb = new StringBuffer();
  sb.append("a");
  sb.append("b");
}

变量sb的作用域在方法fun中，不会“逃逸”，其它线程无法访问到，所以编译器会消除append()方法的同步处理。

锁粗化

对于零碎使用同一个锁的操作，编译器会把锁同步的范围进行扩展。

5. 悲观/乐观锁

悲观锁

总是假设最坏的情况，每次取数据时都认为其他线程会修改，所以都会加锁。一旦加锁，不同线程同时执行时，只能有一个线程执行，其他的线程在入口处等待，直到锁被释放。

乐观锁

乐观锁顾名思义就是在操作时很乐观，认为操作不会产生并发问题(不会有其他线程对数据进行修改)，因此不会上锁。但是在更新时会判断其他线程在这之前有没有对数据进行修改，一般会使用版本号机制或CAS算法实现。