AtomicBoolean vs synchronized块 [英] AtomicBoolean vs synchronized block

问题描述

我试图通过用 AtomicBoolean 替换一些 synchronized 块来减少代码中的线程争用。

I was trying to cut thread contention in my code by replacing some synchronized blocks with AtomicBoolean.

以下是已同步的示例：

public void toggleCondition() {
    synchronized (this.mutex) {
        if (this.toggled) {
            return;
        }

        this.toggled = true;
        // do other stuff
    }
}

替代 AtomicBoolean ：

public void toggleCondition() {
    if (!this.condition.getAndSet(true)) {
        // do other stuff
    }
}

利用 AtomicBoolean 的CAS属性应该比依赖同步更快，所以我运行了小微基准测试。

Taking advantage of AtomicBoolean's CAS property should be way faster than relying on synchronization so I ran a little micro-benchmark.

10个并发线程和1000000次迭代， AtomicBoolean 仅比 synchronized 块稍快一点。

For 10 concurrent threads and 1000000 iterations, AtomicBoolean comes in only slightly faster than synchronized block.

使用AtomicBoolean在toggleCondition（）上花费的平均时间（每个线程）：0.0338

Average time (per thread) spent on toggleCondition() with AtomicBoolean: 0.0338

在withggle上花费在toggleCondition（）上的平均时间（每个线程）：0.0357

Average time (per thread) spent on toggleCondition() with synchronized: 0.0357

我知道微基准值得他们值得，但不应该差异是否更高？

I know micro-benchmarks are worth what they're worth but shouldn't the difference be higher?

推荐答案

我知道微基准值得他们值得但是差异不应该更高吗？

I know micro-benchmarks are worth what they're worth but shouldn't the difference be higher?

我认为问题出在您的基准测试中。看起来每个线程只会切换一次条件。基准测试将花费大部分时间来创建和销毁线程。任何给定线程在任何其他线程切换的同时切换条件的可能性将接近于零。

I think the problem is in your benchmark. It looks like each thread is going to toggle the condition just once. The benchmark will spend most of its time creating and destroying threads. The chance that any given thread will be toggling a condition at the same time as any other thread is toggling it will be close to zero.

AtomicBoolean具有超过性能优势当存在对该条件的显着争用时的原始锁定。对于无条件的情况，我希望看到的差别不大。

An AtomicBoolean has a performance advantage over primitive locking when there is significant contention for the condition. For an uncontended condition, I'd expect to see little difference.

更改基准，以便每个线程切换条件数百万次。这将保证很多锁争用，我希望你会看到性能差异。

Change your benchmark so that each thread toggles the condition a few million times. That will guarantee lots of lock contention, and I expect you will see a performance difference.

编辑

如果您打算测试的场景只涉及每个线程（和10个线程）的一个切换，那么您的应用程序不太可能遇到争用，因此使用AtomicBoolean不太可能产生任何差异。

If the scenario you intended to test only involved one toggle per thread (and 10 threads), then it is unlikely that your application would experience contention, and therefore it is unlikely that using AtomicBoolean will make any difference.

此时，我应该问你为什么要把注意力集中在这个方面。您是否已分析过您的应用程序并确定确实您有锁定争用问题？或者你只是猜测？您是否接受过关于过早优化的邪恶的标准讲座？

At this point, I should ask why you are focusing your attention on this particular aspect. Have you profiled your application and determined that really you have a lock contention problem? Or are you just guessing? Have you been given the standard lecture on the evils of premature optimization yet??

这篇关于AtomicBoolean vs synchronized块的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！