synchronized原理

2、synchronized原理

在synchronized的内部包括 ContentionList、EntryList、 WaitSet、OnDeck、Owner、!Owner这6个区域每个区域的数据都代表所的不同状态。

• ContentionList：锁竞争队列，所有请求数的线程都被放在竞争队列中。
• EntryList：竞争候选列表，在ContentionList中有资格成为候选者来竞争锁资源的线程被移动到了EntryList中。
• WaitSet：等待集合，调用wait方法后把被阻塞的线程将被放在WaitSet中
• OnDeck：竞争候选者，在同一时刻最多只有一个线程在竞争锁资源，该县城的状态被称为OnDeck。
• Owner：竞争到锁资源的线程被称为Owner状态线程。
• ! Owner：在 Owner线程释放锁后，会从 Owner状态变为!Owner。

Synchronize的在收到新的锁请求时首先自旋，如果通过自旋也没有获取锁资源，则将被放入所竞争队列ContentionList中。

为了防止锁竞争时 ContentionList尾部的元素被大量的并发线程进行CAS访问而影响性能， Owner线程会在释放锁资源时，将ContantionList的部分线程移动到EntryList中并指定EntryList的某个线程。（一般是最先进入的线程）为OnDeck线程。 Owner线程并没有直接把锁传递给OnDdeck线程，而是把锁竞争的权力交给OnDeck线程重新竞争锁。在Java中把该行为称为竞争切换，该行为牺牲了公平性，但提高了性能。

获取到资源的OnDeck线程会变为Owner线程，而未获取到锁资源的线程仍然停留在EntryList中。

Owner线程被wait的方法阻塞后，会被转移到WaitSet队列中，直到某个时刻被 notify方法或者notifyAll方法唤醒，会再次进入EntryList中。ContentionList、 EntryList、WaitSet中的线程均为阻塞状态，该阻塞是由操作系统来完成的（在Linux内核下是采用 pthread_mutex_lock内核实现的）。

Owner线程在执行完毕后会释放锁的资源，并变!Owner状态如图所示：

在synchronized中，在线程进入ContentionList之前，等待的线程会先尝试以自旋的方式获取锁，如果获取不到就进入ContentionList中，该做法对于已经进入队列的线程是不公平的，因此synchronized是非公平锁。另外，自旋获取锁的线程也可以直接抢占OnDeck线程的锁资源。

synchronized是一个重量级操作，需要调用操作系统的相关接口，性能较低，给线程加锁的时间有可能超过获取锁后具体逻辑代码的操作时间。

JDK1.6对synchronized做了许多优化，引入了适应自旋、锁消除、锁粗化，轻量级锁及偏向锁等，以提高锁的效率，锁可以从偏向锁升级到轻量级锁再升级到重量级锁，这种升级过程叫做锁膨胀，在jdk1.6中默认开启了偏向锁和轻量级锁，可以通过XX:UsebiasedLocking禁用偏向锁。