JavaEE-常见的锁策略和synchronized的锁机制

常见的锁策略

乐观锁和悲观锁

乐观锁和悲观锁主要是看主要是锁竞争的激烈程度.

• 乐观锁预测锁竞争不是很激烈, 做的准备工作相对更少, 开销更小, 效率更高.
• 悲观锁预测锁竞争会很激烈, 做的准备工作相对更多, 开销更大, 效率更低.
• 
  

  乐观锁一般应用在线程的冲突比较少, 也就是说读操作比较多, 写操作比较少; 而悲观锁则相反, 一般应用在线程冲突比较多, 写操作比较多的情况下.

  轻量级锁和重量级锁

  轻量级锁和重量级锁看的是锁操作的开销大不大.

• 重量级锁: 加锁解锁的开销比较的大, 需要在内核态中进行完成, 多数情况下悲观锁是一个重量级锁, 但并不绝对.
• 轻量级锁: 它的开销比较小, 在用户态中完成就行, 多数情况下乐观锁是一个轻量级锁, 但并不绝对.

  轻量级锁一般都是通过版本号机制或CAS算法进行实现的, 但对用重量级锁来说不是, 这与操作系统的内核有关, cpu一般会提供一些特殊指令, 操作系统会对这些指令进行封装一层, 提供一个mutex(互斥量), 在Linux种就会提供一个这样的接口供用户进行加锁解锁; 一般来说, 如果锁是通过调用mutex来进行实现的, 那么这个锁就是一个重量级锁.
  

• 自旋锁和挂起等待锁

• 自旋锁: 是一种典型的轻量级锁, 在线程获取不到锁的情况下, 不会立刻放弃CPU, 而是会一直快速频繁进行获取, 直到获取到锁; 这种策略的优势在于节省线程调度的开销并且更能及时的获取到锁, 缺点就是更加浪费cpu资源.
• 挂起等待锁: 是一种典型的重量级锁, 线程在获取不到锁的情况下会堵塞等待(放弃CPU,进入等待队列), 然后等到锁被释放的时候再有操作系统调度.

• 普通互斥锁和读写锁

  Java中synchronized的锁就是一个普通的互斥锁, 只涉及两个操作：

  1. 加锁
  2. 解锁

  多线程针对同一个变量并发读, 这个时候没有线程安全问题的, 也不需要加锁控制, 对于读写锁来说, 分成了三个操作:

  加读锁:如果代码只进行了读操作,就加读锁
  加写锁:如果代码进行了修改操作,就加写锁
  解锁: 针对读锁和读锁之间,是不存在互斥关系的
  

  读锁和读锁之间是没有互斥的, 读锁和写锁之间, 写锁和写锁之间, 才需要互斥
  在java中有读写锁的标准类, 位于java.util.concurrent.locks.ReentrantReadWriteLock, 其中ReentrantReadWriteLock.ReadLock为读锁, ReentrantReadWriteLock.WriteLock为写锁.

  公平锁和非公平锁

• 公平锁: 多个线程在等待一把锁的时候, 遵循先来后到原则, 谁是先来的, 谁就先获得这把锁.
• 非公平锁: 多个线程等待同一把锁, 不遵守先来后到原则, 每个人等待线程获取锁的概率是均等的.

• 操作系统中原生的锁都是 “非公平锁”, 操作系统中的针对加锁的控制, 是依赖于线程调度顺序的, 这个调度顺序是随机的, 不会考虑到这个线程等待锁多久了, 如果想要实现公平锁, 就得在这个基础上加额外的数据结构(比如引入一个队列), 来记录线程的先后顺序.

  可重入锁和不可重入锁

• 可重入锁: 一个线程针对同一把锁连续加锁两次，不会出现死锁
• 不可重入锁: 一个线程针对同一把锁连续加锁两次，会出现死锁

• synchronized的锁机制

  synchronized特性

  Synchronized 具有如下特性：

  既是乐观锁也是悲观锁, 当锁竞争较小时它就是乐观锁(默认), 锁竞争较大时它就是悲观锁.
  是普通互斥锁。
  既是轻量级锁(默认)也是重量级锁, 根据锁竞争激烈程度自适应.
  轻量级锁部分基于自旋锁实现, 重量级锁部分基于挂起等待锁实现.
  是非公平锁.
  是可重入锁.
  

  锁升级/锁膨胀

  JVM 将 synchronized 锁分为 无锁, 偏向锁, 轻量级锁, 重量级锁 状态; 会根据情况, 进行依次升级.

  

  1. 当没有线程加锁的时候, 此时为无锁状态.

  2. 当首个线程进行加锁的时候, 此时进入偏向锁的状态, 偏向锁不是真的加锁, 而是在对象头做个标记(这个过程是非常轻量的).

     偏向锁并不是真的加锁, 只是做了一个标记, 这样带来的好处就是, 后续如果没人竞争的时候, 就一直不去确立关系(节省了确立关系/分手的开销), 如果没有其他的线程来竞争这个锁, 就不必真的加锁(节省了加锁解锁的开销), 如果在执行代码过程中, 并没有其他线程来尝试加锁, 那么在执行完synchronized之后, 取消偏向锁即可.

  3. 当有其他线程进行加锁, 导致产生了锁竞争时, 此时进入轻量级锁状态(迅速的把偏向锁升级成真正的加锁状态).

     此处的轻量级锁是通过 CAS 来实现的, 如果其他的线程很快的释放锁, 那么我们的自旋锁是非常合适的, 但是如果其他线程长时间占用锁, 自旋锁就不太合适了, 自旋操作是一直让 CPU 空转, 比较浪费 CPU 资源, 因此此处的自旋不会一直持续进行, 而是达到一定的时间/重试次数, 就不再自旋了, 也就是所谓的 “自适应”.

  4. 如果竞争进一步加剧, 进入重量级锁状态(挂起等待锁).

     重量级锁是基于操作系统原生的一组API(mutex)来进行加锁了, 当我们自旋不能快速获取到锁时, 锁竞争加剧, 就会升级为重量级锁, 我们的线程就会被放到阻塞队列中, 暂时不参与CPU调度, 当锁被释放了之后, 线程才有机会被调度, 从而有机会获取到锁, 一旦线程被切换出cpu, 这就是比较低效的事情了.

  锁消除

  锁消除是编译器的智能判定, 有些代码, 编译器认为没有加锁的必要, 就会自动把你加的锁自动去除, 比如字符串相关的线程安全类StringBuffer, 这个类中的关键方法都带有synchronized, 但是当我们在单线程环境下使用StringBuffer, 不会涉及到线程安全问题, 此时编译器就会直接把这些加锁操作去除了.

  锁粗化

  锁粗化就是将synchronized的加锁代码块范围增大, 加锁的代码块中的代码越多, 锁的粒度就越粗, 否则锁的粒度就越细.

  通常情况下, 认为锁的粒度细一点比较好, 加锁的部分的代码, 是不能并发执行的, 锁的粒度越细, 能并发的代码就越多, 反之就越少.

  但是有些情况下, 锁的粒度粗一些反而更好, 如果我们两次加锁解锁的时间间隙非常小, 分开加锁会造成额外的资源开销, 而且中间间隙很小, 就算并发效果也不是很明显, 这种情况下不如直接一把大锁搞定.