【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:轻量级锁
锁升级过程：
- 无锁的情况下，第一个线程尝试获得偏向锁：尝试给对象头mark word字段指向的thread id用CAS操作替换成自己的，成功了就直接获得偏向锁
- 如果CAS操作失败，意味着同时有多个线程抢锁，这时会在抢到锁的线程到达安全点的时候，将锁升级为轻量级锁，具体操作：拷贝mark word到lock record中，放入到所有抢锁线程的栈中，并且mark word会有指针指向当前占用的锁线程的lock record。其他抢锁的线程利用CAS操作多次自旋，尝试将mark word中的指针指向自己的lock record。
- 自旋到一定次数升级为重量级锁，抢锁失败的线程进入阻塞状态，这时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的内置属性，它能执行一些优化，例如对线程封闭的锁对象的锁消除优化，通过增加锁的粒度来消除内置锁的同步，而如果通过基于类库的锁来实现这些功能，则可能性不大。