synchronized 底层实现原理笔记与质问

• 调用wait方法被阻塞的线程放在Wait Set里（wait set就是阻塞队列？）；
• 所有请求锁的线程首先被放在Contention List竞争队列里（所以尚未进入contention list的线程不会和OnDeck竞争锁？）；
• Contention List中那些有资格成为候选竞争者的线程被移动到Entry List中；（看来Contention List和Entry List联合组成等待队列）
• 在任意时刻最多只有一个线程正在竞争锁资源，该线程就叫OnDeck；（所以Entry List里的线程还是只是在等待被选为OnDeck，不能参与竞争？还是说它参与的是被选为OnDeck的竞争？OnDeck只是一个线程，一个线程获取锁怎么叫竞争呢？奇怪）
• 当前已经获取到锁资源的线程叫做 Owner；
• 当前释放锁的线程叫!Owner。
  
• JVM每次从队列的尾部（这里指的是Entry List吧？）取出一个数据用于锁竞争候选者(OnDeck)，但是并发情况下Contention List会被大量并发线程（指的是Entry List里面的线程还是前面的thread01、thread02啥的，操）进行CAS访问，为了降低对其尾部元素（这里的尾部元素指的什么东西？）的竞争，JVM会将一部分线程移动到Entry List中作为候选竞争线程。
• Owner线程会在unLock时，将Contention List 中的部分线程迁移到 Entry List 中，并指定（Owner线程指定？不是随机的吗？还是说随机指定？） Entry List 中的某个线程为 OnDeck 线程。
• Owner· 线程并不直接把锁传递给 OnDeck 线程（看来这是描述Owner释放锁后的过程）,而是把锁竞争的权利（什么叫锁竞争的权利？为什么叫竞争，还有其他线程跟它竞争吗，正在自旋的线程？因为是非公平锁？）交给 OnDeck, OnDeck 需要重新竞争锁（为什么说重新？是因为它本来就是在第一次竞争的时候被阻塞了，也就是第一次竞争失败了才又第二次成为OnDeck竞争吗？）。这样虽然牺牲了一些公平性（synchronized是非公平锁嘛，不过到底是在哪里牺牲了？）, 但是能极大的提升系统的吞吐量, 在 JVM 中, 这种行为称之为 竞争切换。
• OnDeck 线程获取到锁资源后会变成 Owner 线程, 而没有获取到锁的线程仍然停留在 Entry List 中。如果 Owner 线程被 wait() 方法阻塞,则转移到 Wait Set 队列中，直到某个时刻通过 notify()/notifyAll() 方法唤醒, 会重新进入到 Entry List 中（所以Entry List中某些线程是从曾经获取过锁的Owner线程（当然它最开始也是从contention List来的）调用wait阻塞后到了阻塞队列又从阻塞队列加进来的，这种线程又成为OnDeck，所以叫重新竞争？那么刚从contention List来的还没有获取过锁的OnDeck叫不叫重新竞争呢？如果叫那么它第一次是在哪里竞争的锁？）。
• 处于 Contention List、Entry List、Wait Set 中的线程都处于阻塞状态, 该阻塞是由操作系统来完成的。
• synchronized 是非公平锁, synchronized （这里的主语是synchronized？还是说这是个状语？）在线程进入 Contention List 的时候(这里只是描述一个多线程正在并发), 等待的线程（等待的线程到底是指哪些线程？是wait Set里的线程？还是等待队列里的线程？它自旋失败会进入等待队列，所以不是等待队列里的线程，所以是指wait set里的线程？说清楚啊操）会先尝试自旋获取锁（这里自旋获取锁是在跟OnDeck竞争吧？所以说明明是后来的线程，却要自旋着跟先来的第一次竞争失败进入等待队列好不容易才被选为OnDeck的线程竞争）, 如果获取不到锁就进入 Contention List 中, 这明显对于已经进入到队列的线程是不公平的, 还有一个不公平的事情就是自旋获取锁的线程还可能直接抢占 OnDeck 线程的锁资源。
• 每个对象都有个monitor对象（对象内的对象？），加锁就是在竞争monitor对象，代码块加锁是在前后分别加上monitorenter和monitorexit指令实现的，方法加锁是通过一个标记位判断的