此锁定技术的名称是什么? [英] What is the name of this locking technique?

问题描述

我有一个巨大的Trove映射和一个我经常需要从多个线程中调用的方法.大多数情况下，此方法应返回 true .线程正在执行大量运算，我注意到由于以下方法而引起了一些争用(这只是一个示例，我的实际代码有些不同):

I've got a gigantic Trove map and a method that I need to call very often from multiple threads. Most of the time this method shall return true. The threads are doing heavy number crunching and I noticed that there was some contention due to the following method (it's just an example, my actual code is bit different):

synchronized boolean containsSpecial() {
   return troveMap.contains(key);
}

请注意，这是一个仅附加"地图:一旦添加了键，它就会永远留在那里(这对我认为接下来的事情很重要).

Note that it's an "append only" map: once a key is added, is stays in there forever (which is important for what comes next I think).

我注意到，通过将以上内容更改为:

I noticed that by changing the above to:

boolean containsSpecial() {
    if ( troveMap.contains(key) ) {
        // most of the time (>90%) we shall pass here, dodging lock-acquisition
        return true;
    }
    synchronized (this) {
        return troveMap.contains(key);
    }
}

我的号码处理速度提高了20％(经过多次跑步验证，长时间跑步等).

I get a 20% speedup on my number crunching (verified on lots of runs, running during long times etc.).

这种优化看起来正确吗(知道一旦有钥匙，它将永远存在在那里)?

Does this optimization look correct (knowing that once a key is there it shall stay there forever)?

这项技术叫什么名字?

编辑

更新地图的代码的调用频率比 containsSpecial()方法要少，并且看起来像这样(我已经同步了整个方法):

The code that updates the map is called way less often than the containsSpecial() method and looks like this (I've synchronized the entire method):

synchronized void addSpecialKeyValue( key, value ) {
    ....
}

推荐答案

此代码不正确.

Trove本身不处理并发使用；在这方面就像java.util.HashMap.因此，像HashMap一样，甚至看似无害的containsKey()只读方法也可能引发运行时异常，或者更糟糕的是，如果另一个线程同时修改了映射，则进入无限循环.我不了解Trove的内部原理，但是使用HashMap时，超过负载系数时会重新哈希，或者删除条目可能会导致其他仅读取线程的失败.

Trove doesn't handle concurrent use itself; it's like java.util.HashMap in that regard. So, like HashMap, even seemingly innocent, read-only methods like containsKey() could throw a runtime exception or, worse, enter an infinite loop if another thread modifies the map concurrently. I don't know the internals of Trove, but with HashMap, rehashing when the load factor is exceeded, or removing entries can cause failures in other threads that are only reading.

如果与锁定管理相比，此操作花费大量时间，请使用RWDictionary的第二个示例作为指导.

If the operation takes a significant amount of time compared to lock management, using a read-write lock to eliminate the serialization bottleneck will improve performance greatly. In the class documentation for ReentrantReadWriteLock, there are "Sample usages"; you can use the second example, for RWDictionary, as a guide.

在这种情况下，映射操作可能是如此之快，以至于锁定开销占据了主导地位.在这种情况下，您需要在目标系统上进行概要分析，以查看synchronized块或读写锁是否更快.

In this case, the map operations may be so fast that the locking overhead dominates. If that's the case, you'll need to profile on the target system to see whether a synchronized block or a read-write lock is faster.

无论哪种方式，重要的一点是您不能安全地删除所有同步，否则会遇到一致性和可见性问题.

Either way, the important point is that you can't safely remove all synchronization, or you'll have consistency and visibility problems.

这篇关于此锁定技术的名称是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！