跳至主要內容
  • Hostloc 空間訪問刷分
  • 售賣場
  • 廣告位
  • 賣站?

4563博客

全新的繁體中文 WordPress 網站
  • 首頁
  • AQS 公平锁真的完全公平吗?
未分類
15 11 月 2020

AQS 公平锁真的完全公平吗?

AQS 公平锁真的完全公平吗?

資深大佬 : ceshi123 3

AQS 中获取公平锁的代码如下( jdk1.8 ): protected final boolean tryAcquire(int acquires) { final Thread current = Thread.currentThread(); int c = getState(); if (c == 0) { if (!hasQueuedPredecessors() && compareAndSetState(0, acquires)) { setExclusiveOwnerThread(current); return true; } } else if (current == getExclusiveOwnerThread()) { int nextc = c + acquires; if (nextc < 0) throw new Error(“Maximum lock count exceeded”); setState(nextc); return true; } return false; } }

如果有三个线程来获取公平锁,第一个线程获取成功,第二与第三个线程走到 hasQueuedPredecessors(),都判断出为 false(此时队列为空,他们都可以获取锁),第二个线程继续走(第三个线程时间片到了,停住),获取锁失败(因为锁已经被第一个线程获取了),那就乖乖的去排队,构造头结点与自己的节点,此时 sync 队列为: head → node2,node2 → head,然后第二个线程又来抢占锁(源码中有个 for 循环),走到 hasQueuedPredecessors(),判断出也为 false (因为自己就是队列中的第二个节点,是有资格抢锁的),此时线程一释放了锁,那么第二个线程与第三个线程同时抢锁,锁是有可能被三个线程抢到了。

那么这是不是违背了公平锁的概念,或者公平锁并不是绝对的公平,因为第二个线程已经在队列里面排好了队,也该是自己拿到锁,结果锁被第三个线程拿走了。

麻烦各位大神解惑一下!!!

大佬有話說 (8)

  • 主 資深大佬 : ceshi123

    我擦,大神呢

  • 資深大佬 : yamasa

    我觉得 tryAccquire 的这一段注释可以解答这个问题了:

    Likewise, it is possible for another thread to win a race to enqueue after this method has returned {@code false}, due to the queue being empty.

  • 主 資深大佬 : ceshi123

    @yamasa 那其实它在极端场景下是并不是完全公平的

  • 資深大佬 : yamasa

    @ceshi123 对 而且可以说对于绝大部分场景,非公平的 performance 都更好

  • 資深大佬 : THESDZ

    大部分的程序只会考虑绝大多数的情况,因为要考虑所有情况或者极端情况的话,成本>>收益

  • 資深大佬 : THESDZ

    @THESDZ #5 如果的确要考虑极端情况,通常情况是通过”事后”补救

  • 資深大佬 : 1194129822

    你这理解不对,首先说一下,公平只是相对的公平,所有公平模式,就是如果前面有线程排队就加入队尾,而非公平模式,就是线程直接尝试获取锁,获取失败才排队。但是线程本身的执行是没有顺序和优先级的。如果线程 2 因为 os 调度,一直得不到运行,可能一直永远排队。

  • 資深大佬 : wysnylc

    公平是相对的而且不同的角度也会有不同见解
    无序的争抢才是高效

文章導覽

上一篇文章
下一篇文章

AD

其他操作

  • 登入
  • 訂閱網站內容的資訊提供
  • 訂閱留言的資訊提供
  • WordPress.org 台灣繁體中文

51la

4563博客

全新的繁體中文 WordPress 網站
返回頂端
本站採用 WordPress 建置 | 佈景主題採用 GretaThemes 所設計的 Memory
4563博客
  • Hostloc 空間訪問刷分
  • 售賣場
  • 廣告位
  • 賣站?
在這裡新增小工具