【Java并发编程】线程安全（一）Synchronized原理

Synchronized底层实现

简单来说，Synchronized关键字的执行主体是线程对象，加锁是通过一个锁对象来完成的是，而锁对象底层关联了一个c++源码的monitor的对象，monitor对象底层又对应了操作系统级别的互斥锁，同一时刻只有一个线程能够持有这把锁

Synchronized底层依赖于jvm的monitorenter和monitorexit两个指令，这两个指令用于获取锁和释放锁

锁对象结构与sync锁升级的概念

多个线程争抢锁的时候，其实就像是在争抢锁对象，前面提到锁对象底层关联了一个monitor的对象，最终关联操作系统级别的互斥锁，这种情况其实属于申请系统空间的重量级锁，是需要完成系统调用的，因此存在性能问题。

Synchronized自身有一个锁升级的概念：在低并发的情况下先申请用户空间的锁，而不会申请系统空间的锁，也就不涉及用户内核态切换

理解锁升级，首先需要关注Java对象在内存中的存储布局，内部有一个mark-word字段是实现锁升级的关键：

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

对象头内部有一个64bit的mark-word标记字段，后面的三位代表了当前锁对象对应哪种锁：

• 00:轻量锁
• 10:重量锁
• 11:GC标记

（由于2bit不够表示5种锁类型，所以又借了前面一位）

• 001:无锁
• 101:轻量级锁

锁升级过程：

1. 无锁的情况下，第一个线程尝试获得偏向锁：尝试给对象头mark word字段指向的thread id用CAS操作替换成自己的，成功了就直接获得偏向锁
2. 如果CAS操作失败，意味着同时有多个线程抢锁，这时会在抢到锁的线程到达安全点的时候，将锁升级为轻量级锁，具体操作：拷贝mark word到lock record中，放入到所有抢锁线程的栈中，并且mark word会有指针指向当前占用的锁线程的lock record。其他抢锁的线程利用CAS操作多次自旋，尝试将mark word中的指针指向自己的lock record。
3. 自旋到一定次数升级为重量级锁，抢锁失败的线程进入阻塞状态，这时mark word中的指针将指向对象关联的monitor对象，monitor结构如下：

ObjectMonitor::ObjectMonitor() {  
  _header       = NULL;  
  _count       = 0;  
  _waiters      = 0,  
  _recursions   = 0;       //线程的重入次数
  _object       = NULL;  
  _owner        = NULL;    //标识拥有该monitor的线程
  _WaitSet      = NULL;    //等待线程组成的双向循环链表，_WaitSet是第一个节点
  _WaitSetLock  = 0 ;  
  _Responsible  = NULL ;  
  _succ         = NULL ;  
  _cxq          = NULL ;    //多线程竞争锁进入时的单向链表
  FreeNext      = NULL ;  
  _EntryList    = NULL ;    //_owner从该双向循环链表中唤醒线程结点，_EntryList是第一个节点
  _SpinFreq     = 0 ;  
  _SpinClock    = 0 ;  
  OwnerIsThread = 0 ;  
}

owner属性指向抢锁成功的线程，count记录重入个数。另外还会有入口集entrySet和等待集waitset。

ReentrantLock和Synchronized的选择

这是一个经常被提到的问题

实际上Java发展的过程中对Synchronized的性能做了优化，比如锁升级机制，所以性能上synchronized并不差。

• 考虑使用ReentrantLock的理由：

主要在一些Synchronized内置锁无法满足需求的情况下，ReentrantLock可以作为一种高级工具。

例如，Synchronized具有块结构的特性，即都是在方法/代码块开始是获取，方法/代码块结束时生效。

而ReentrantLock具有非块结构的特性，像下面这种实现就只能使用ReentrantLock

private ReentrantLock lock;

public void foo() {
  ...
  lock.lock();
  ...
}

public void bar() {
  ...
  lock.unlock();
  ...
}

总之，ReentrantLock具备一些高级功能，包括：可定时的、可轮询的与可中断的锁获取操作，公平队列，以及非块结构的锁。否则，还是应该优先使用synchronized。

• 考虑使用Synchronized的理由：

与ReentrantLock相比，内置锁的一个优点是：能给出在哪些线程调用帧中获得了哪些锁，并能够检测和识别发生死锁的线程。JVM并不知道哪些线程持有ReentrantLock，因此在调试使用ReentrantLock的线程的问题时，将起不到帮助作用。

ReentrantLock的非块结构特性仍然意味着，获取锁的操作不能与特定的栈帧关联起来，而内置锁却可以。

未来更可能会提升synchronized而不是ReentrantLock的性能。因为synchronized是JVM的内置属性，它能执行一些优化，例如对线程封闭的锁对象的锁消除优化，通过增加锁的粒度来消除内置锁的同步，而如果通过基于类库的锁来实现这些功能，则可能性不大。