concurrntHashMap可以同时保证真正的线程安全性和并发性吗？

问题描述

| 我们知道ConcurrentHashMap可以提供对多个线程的并发访问以提高性能，并且在此类内，段是同步的（对吗？）。问题是，这种设计可以保证线程安全吗？假设我们有30多个线程访问并更改由ConcurrentHashMap实例中的同一键映射的对象，我想是，它们仍然必须为此排队，不是吗？ 据我回忆，《 Java Concurrency in Practice》一书说ConcurrentHashMap提供并发阅读和相当水平的并发编写。在上述情况下，如果我的猜测是正确的，性能是否会比使用Collection的静态同步包装API更好？ 感谢您的澄清， 约翰     

解决方法

        您仍然必须同步对正在修改的对象的任何访问，并且您怀疑对同一密钥的所有访问仍将具有争用。性能的提高来自对不同密钥的访问，这当然是最典型的情况。     ,        

ConcurrentMap

可使您并发的是，对映射本身的修改是原子完成的，并且任何写操作都发生在任何读取之前（这很重要，因为它可以安全地发布映射中的任何引用。 安全发布意味着从映射中检索到的任何（可变）对象在被放置到映射中之前都会对其进行所有写入操作。不过，它对于发布检索后所做的修改没有帮助。 但是，如果您有多方修改的可变对象，那么并发性和线程安全性通常很难被推论和纠正。通常，您必须锁定才能正确操作。更好的方法通常是将不可变对象与ѭ0条件条件putIfAbsent / replace方法结合使用，并以此方式线性化算法。这种无锁的风格往往更容易推理。     ,           问题是，这种设计可以保证线程安全吗？ 它保证了映射的线程安全性；即，在存在多个同时执行更新的线程的情况下，对地图的访问和更新具有良好定义的有序行为。 它确实保证了键或值对象的线程安全。并且它不提供任何形式的更高级别的同步。   假设我们有30多个线程访问并更改由ConcurrentHashMap实例中的同一键映射的对象，我想是，它们仍然必须为此排队，不是吗？ 如果您有多个线程尝试使用同一密钥，那么它们的操作将不可避免地在某种程度上被序列化。那是不可避免的。 实际上，从简短地查看源代码来看，如果对于地图的特定段有太多争用，则

ConcurrentHashMap

会退回到使用常规锁。而且，如果您有多个线程尝试同时访问和更新同一密钥，则将触发锁定。     ,        首先请记住，线程安全工具并不能保证线程安全工具在其自身及其内部的使用 例如，putIfAbsent的“ 3”构造不是线程安全的 并且仍然必须使每个值访问/修改都必须独立于线程安全     ,        即使是相同的键，读取也是并发的，因此对于典型的应用程序，性能会更好。