ConcurrentHashMap（put()、remove() 等）上的所有非检索操作是否需要包装在 synchronized(this) 块中？我知道所有这些操作都是线程安全的，那么这样做有什么真正的好处/需要吗？唯一使用的操作是put() 和remove()。
protected final Map<String, String> mapDataStore = new ConcurrentHashMap<String, String>();
public void updateDataStore(final String key, final String value) {
...
synchronized (this) {
mapDataStore.put(key, value);
}
...
}
【问题讨论】：
标签： java synchronized concurrenthashmap
不，这样做会失去ConcurrentHashMap 的好处。您也可以使用HashMap 和synchronized 或synchronizedMap() 来锁定整个表（这是您在synchronized 中包装操作时所做的，因为隐含的监视器是整个对象实例。）
ConcurrentHashMap 的目的是通过允许对表进行并发读/写而不锁定整个表来增加并发代码的吞吐量。该表通过使用锁条带在内部支持这一点（多个锁而不是一个，每个锁分配给一组哈希桶 - 参见 Goetz 等人的Java Concurrency in Practice）。
一旦您使用ConcurrentHashMap，所有标准映射方法（put()、remove() 等）都将由于实现中的锁条带化等而成为原子方法。唯一的权衡是size() 和isEmpty() 之类的方法不一定会返回准确的结果，因为它们的唯一方法是让所有操作锁定整个表。
ConcurrentMap interface 接口还添加了新的原子复合操作，例如 putIfAbsent()（仅当键不在映射中时才放置内容），remove() 同时接受键和值（仅当其值时删除条目等于您传递的参数）等。这些操作过去需要锁定整个表，因为它们需要两个方法调用才能完成（例如，putIfAbsent() 需要同时调用containsKey() 和put()，包裹在一个synchronized 中块，如果您使用的是标准的 Map 实现。）再一次，通过避免锁定整个表，您可以使用这些方法获得更大的吞吐量。
【讨论】：
同步这些操作在这里没有任何好处 - 如果您不需要同步，它实际上会降低性能。
创建ConcurrentHashMap 的原因是同步映射（在问题中手动实现或使用Collections.synchronizedMap(map) 以通常的方式实例化）在被许多线程访问时表现出糟糕的性能。 put 和 get 操作是阻塞的，所以所有其他线程都必须等待并且不能同时访问 map。 ConcurrentHashMap - 顾名思义 - 另一方面允许并发访问。如果添加同步，您将失去此优势。
【讨论】：
putIfAbsent 或 computeIfAbsent 方法（它们都是 ConcurrentMap 的原子操作），而不是同步。