为什么 Semaphore 实现使用 CAS (U.compareAndSetInt) 而不是等待/通知？

Question

我决定从头开始实现并发 package 的一些类，并通过等待/通知实现信号量。 这样做似乎非常容易和直观。 当我检查构建实现时，我看到他们使用 CAS（比较和交换）技术使这一切变得复杂。 他们为 ReentranceLock 实现做了同样的事情。

为什么他们决定这样做？ 是因为性能吗？ 也许我也应该避免等待/通知并在我的应用程序中使用 CAS。

public class SemaphoreX {
    private int permits;

    SemaphoreX(int permits){
        this.permits = permits;
    }

    public synchronized void acquire() throws InterruptedException{
        while(permits == 0){
            wait();
        }
        permits--;
    }

    public synchronized void release(){
        permits++;
        notify();
    }
}

Answer 1

您应该阅读AbstractQueuedSynchronizer的 javadocs。

为什么他们决定这样做？ 是因为性能吗？

我不能 100% 肯定地告诉你这是否与性能有关。 但这绝对不仅仅与性能有关。

您会注意到Semaphore使用的FairSync和UnfairSync类是基于AbstractQueuedSynchronizer的。 如果您查看 API，您会发现它提供的功能比您使用 Java 原始锁和wait / notify获得的功能更丰富。 特别是，您将看到它支持等待事件的线程的公平 (FIFO) 排队。 原始的等待/通知机制不提供任何公平保证。

公平排队是使用fair设置为true创建的Semaphore的要求。

也许我也应该避免等待/通知并在我的应用程序中使用 CAS。

可能。 这取决于你的目标是什么。

但是，如果您的主要目标是性能，那么我建议不要尝试重新实现java.util.concurrent...类。 只需按原样使用现有的类。

如果您的目标之一是获得良好的性能，您就不必害怕使用复杂的技术来实现并发原语。 或者对不同的方法和你自己的性能测量进行自己的性能分析。