synchronized底层原理

1.上图涉及到3个数据结构：

  (1)._cxq: 存放阻塞的线程队列( LIFO（先进后出）的单向链表)；

  (2)._EntryList: 也是存放阻塞的线程队列( 双向链表 )；

  (3)._WaitSet: 线程进入synchronized锁后，因为要等待其他线程的同步通知，调用Object的wait()方法阻塞自己，自动放弃锁，这种被阻塞的线程就放入此结构里。(Object.notify和notifyAll唤醒的就是这里面的线程)。

2.线程竞争、加锁、解锁的流程为：

    (1)多个线程去通过CAS竞争monitor对象(竞争成功时，monitor对象的_owner会指向该线程)；

    (通过CAS去竞争的作用是，尽量不让线程去阻塞，阻塞时上下文切换成本太大了，除了这里的CAS以外，接下来还有几次CAS竞争锁的操作。)

     (2)竞争成功则直接执行代码块；竞争失败则再通过CAS插入_cxq(因为_cxq也是临界资源，而且涉及到多个线程的插入，所以要用CAS去竞争)；

     (3)进入_cxq后阻塞！

     (4)持有锁的线程不用锁了，释放锁时其他线程要进行竞争。不过不是将_cxq里的线程直接拿出来去竞争，而是将_cxq里的线程转移到_EntryList里

     (转移有几种策略，取决于QMode参数, 有的转到_EntryList的头部，有的转到_EntryList的尾部)。

     (5)取_EntryList的头部线程作为onDeck线程(预备线程)，对其解除阻塞状态，其就可以再次参与竞争锁了(有一种QMode，是直接取_cxq的线程去解除其阻塞参与竞争锁)。

     其中_cxq和_EntryList都是存放阻塞的线程队列，_EntryList的出现是为了降低线程对_cxq的竞争操作； _cxq的功能是将阻塞线程插入其中，而_cxq把唤醒阻塞线程的任务转交给了_EntryList，降低了自己的负担！

     而_WaitSet虽然也是存放阻塞的线程队列，但只存放调用了Object的wait()方法、自动阻塞自己的线程，即调用了Object.wait()后，线程进入_WaitSet了。Object.notify和notifyAll唤醒的是这里面的线程。

3.问题：为什么synchronized是非公平锁？

   答： 根据上面的介绍，底层设计根本没有考虑到公平性，不是先等待的线程就先获得锁； 线程被阻塞后，可能在_cxq里被唤醒, 可能在_EntryList里被唤醒，也可能在_WaitSet:被唤醒，都没考虑到公平性。

参考文献：深入底层源码 --- 深度理解synchronized原理 - 知乎