java - 为什么要在多线程环境下使用HashMap？

Question

今天我正在阅读 HashMap 在 Java 中的工作原理。我遇到了一个博客，我直接从博客的文章中引用。我经历了this关于堆栈溢出的文章。仍然我想知道详情。

So the answer is Yes there is potential race condition exists whileresizing HashMap in Java, if two thread at the same time found thatnow HashMap needs resizing and they both try to resizing. on theprocess of resizing of HashMap in Java , the element in bucket whichis stored in linked list get reversed in order during there migrationto new bucket because java HashMap doesn't append the new element attail instead it append new element at head to avoid tail traversing.If race condition happens then you will end up with an infinite loop.

它声明由于在调整 HashMap 大小时 HashMap 不是线程安全的，因此可能会出现潜在的竞争条件。我什至在我们的办公室项目中看到，人们广泛使用 HashMaps 知道它们不是线程安全的。如果不是线程安全的，那为什么还要用HashMap呢？是否只是开发人员缺乏知识，因为他们可能不知道像 ConcurrentHashMap 这样的结构或其他原因。谁能阐明这个难题。

Answer 1

我可以自信地说 ConcurrentHashMap 是一个很容易被忽略的类。没有多少人知道它，也没有多少人愿意使用它。该类提供了一种非常强大且快速的方法来同步 Map 集合。在网上看了一些HashMap和ConcurrentHashMap的比较。我只想说他们完全错了。您无法比较两者，一个提供同步方法来访问 map ，而另一个不提供任何同步。

我们大多数人没有注意到的是，虽然我们的应用程序(尤其是 Web 应用程序)在开发和测试阶段运行良好，但它们通常会在重(甚至中等重)负载下倾斜。这是因为我们期望我们的 HashMap 以某种方式表现，但在负载下它们通常表现不佳。 Hashtable 提供对其条目的并发访问，但有一个小警告，整个映射被锁定以执行任何类型的操作。

虽然这种开销在正常负载下的 Web 应用程序中可以忽略，但在重负载下，它可能会无缘无故地导致响应时间延迟和服务器负担过重。这就是 ConcurrentHashMap 介入的地方。它们提供了 Hashtable 的所有功能，性能几乎与 HashMap 一样好。 ConcurrentHashMap 通过一种非常简单的机制来实现这一点。

该集合默认维护一个包含 16 个锁的列表，而不是 map 范围的锁，每个锁都用于保护(或锁定) map 的单个存储桶。这实际上意味着 16 个线程可以同时修改集合(只要它们都在不同的桶上工作)。事实上，这个集合没有执行锁定整个 map 的操作。