内存与同步互斥锁不一致

Question

更新： 当我第一次发布这个时，我相当确定代码被破坏了。现在，我不再确定我观察到了什么。我遇到的最大问题是我似乎无法申请 17.4. Memory Model 并直接说明它应该还是不应该工作。

---

以下代码已损坏。

它试图实现的目标过于复杂，但此外，它是线程不安全的，因为我观察到它可以无限期地等待c。我不担心前者（可以使用ReentrantLock 或CountDownLatch 以获得更合理的代码），但我想知道后者的原因是什么？

static final ConcurrentHashMap<Integer, Object> mutex = new ConcurrentHashMap<>();


public static brokenFoo() {

    Object ourLock = new Object();

    for (;;) {
        Object theirLock = mutex.putIfAbsent(0, ourLock);
        if (theirLock == null) {
            break;
        }

        synchronized (theirLock) {                  // a
            if (mutex.get(0) != theirLock) {        // b
                continue;
            }
            theirLock.wait();                       // c
        }                                           // d
    }

    try {
        // critical section

    } finally {
        synchronized (ourLock) {                    // e
            mutex.remove(0);                        // f
            ourLock.notifyAll();                    // g
        }                                           // h
    }
}

我考虑过happens-befores：

• hb(f, h) 和 hb(h, a) 因此 hb(f, a)
• hb(c, d) 和 hb(d, e) 因此 hb(c, e)

但是，这似乎不能证明或反驳任何事情。

编辑：（上述问题未能真正解释这段代码应该做什么。）

预期：

• brokenFoo() 被多个线程调用，上面的代码应该提供对// critical section 的互斥。
• 如果两个或多个线程同时进入brokenFoo()，则只有一个线程应该继续进入// critical section，而其他线程则在之前的某个地方等待。
• // critical section 中的线程退出后，应继续使用另一个线程来代替它。

实际：

• 据观察，尽管brokenFoo() 中没有其他线程，但仍有线程在 c 处等待。

Answer 1

可能是一个线程调用 notifyAll()在另一个线程开始 wait()。这可能是由于spurious wakeup：

• 线程 1 进入临界区
• 线程 2 开始等待()
• 线程 2 中发生虚假唤醒
• 线程1进入同步块并通知锁
• 线程2进入同步块，无限等待

或者线程 1 恰好在线程 2 之前执行。虽然您的代码在 JMM 方面是正确的，但不能保证其 liveness。这就是为什么您应该使用 CountDownLatch 而不是通知/等待机制。