我正在实现一个请求实例的 FIFO 队列(为速度而预先分配的请求对象)，并开始使用 add 方法上的“同步”关键字。该方法很短(检查固定大小缓冲区中是否有空间，然后将值添加到数组)。使用visualVM，线程似乎比我喜欢的更频繁地阻塞(准确地说是“监视器”)。因此，我将代码转换为使用 AtomicInteger 值来跟踪当前大小，然后在 while 循环中使用 compareAndSet()(就像 AtomicInteger 在内部对 incrementAndGet() 等方法所做的那样)。代码现在看起来更长了。

我想知道的是，使用同步且较短的代码与不带 synchronized 关键字的较长代码相比，性能开销是多少(因此永远不应阻塞锁定)。

这是带有 synchronized 关键字的旧 get 方法:

public synchronized Request get()
{
    if (head == tail)
    {
        return null;
    }
    Request r = requests[head];
    head = (head + 1) % requests.length;
    return r;
}

这里是没有 synchronized 关键字的新 get 方法:

public Request get()
{
    while (true)
    {
        int current = size.get();
        if (current <= 0)
        {
            return null;
        }
        if (size.compareAndSet(current, current - 1))
        {
            break;
        }
    }

    while (true)
    {
        int current = head.get();
        int nextHead = (current + 1) % requests.length;
        if (head.compareAndSet(current, nextHead))
        {
            return requests[current];
        }
    }
}

我的猜测是 synchronized 关键字更糟，因为有阻塞锁的风险(可能导致线程上下文切换等)，即使代码更短。

谢谢!

最佳答案

My guess was the synchronized keyword is worse because of the risk of blocking on the lock (potentially causing thread context switches etc)

是的，一般情况下你是对的。 Java Concurrency in Practice在第 15.3.2 节中对此进行了讨论:

[...] at high contention levels locking tends to outperform atomic variables, but at more realistic contention levels atomic variables outperform locks. This is because a lock reacts to contention by suspending threads, reducing CPU usage and synchronization traffic on the shared memory bus. (This is similar to how blocking producers in a producer-consumer design reduces the load on consumers and thereby lets them catch up.) On the other hand, with atomic variables, contention management is pushed back to the calling class. Like most CAS-based algorithms, AtomicPseudoRandom reacts to contention by trying again immediately, which is usually the right approach but in a high-contention environment just creates more contention.

Before we condemn AtomicPseudoRandom as poorly written or atomic variables as a poor choice compared to locks, we should realize that the level of contention in Figure 15.1 is unrealistically high: no real program does nothing but contend for a lock or atomic variable. In practice, atomics tend to scale better than locks because atomics deal more effectively with typical contention levels.

The performance reversal between locks and atomics at differing levels of contention illustrates the strengths and weaknesses of each. With low to moderate contention, atomics offer better scalability; with high contention, locks offer better contention avoidance. (CAS-based algorithms also outperform lock-based ones on single-CPU systems, since a CAS always succeeds on a single-CPU system except in the unlikely case that a thread is preempted in the middle of the read-modify-write operation.)

(在文中提到的数字上，图 15.1 显示了 AtomicInteger 和 ReentrantLock 在竞争高时的性能或多或少相等，而图 15.2 显示在中等竞争下前者的性能比后者高出 1 倍2-3.)

更新:关于非阻塞算法

正如其他人所指出的，非阻塞算法虽然可能更快，但更复杂，因此更难正确处理。 JCiA 第 15.4 节的提示:

Good nonblocking algorithms are known for many common data structures, including stacks, queues, priority queues, and hash tables, though designing new ones is a task best left to experts.

Nonblocking algorithms are considerably more complicated than their lock-based equivalents. The key to creating nonblocking algorithms is figuring out how to limit the scope of atomic changes to a single variable while maintaining data consistency. In linked collection classes such as queues, you can sometimes get away with expressing state transformations as changes to individual links and using an AtomicReference to represent each link that must be updated atomically.

关于java - 在 Java 中，AtomicInteger compareAndSet() 与 synchronized 关键字的性能如何？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3556283/