ConcurrentHashMap 在多线程应用程序中被广泛使用。多线程应用程序的例子包括在线游戏应用程序和聊天应用程序，这些应用程序为应用程序增加了并发性的好处。为了使应用程序更具并发性，ConcurrentHashMap 引入了一个称为“并行性”的概念。

在本文中，我们将更多地了解并发哈希映射中的并行性。

什么是并行性？

基本上，并行计算将问题分解为子问题，同时解决这些子问题，最后合并子问题的结果。在这里，子问题将在单独的线程中运行。

Java 对ConcurrentHashMap的并行性支持

为了利用 ConcurrentHashMap 中的并行性，我们需要使用 Java 1.8 版本及以上。在低于 1.8 版本的 Java 中不支持并行性。

并行处理的常见框架

Java 引入了一个称为“分支和合并”的框架，它将实现并行计算。它利用 java.util.concurrent.ForkJoinPool API 来实现 ConcurrentHashMap 中的并行计算。

ConcurrentHashMap中的并行方法

ConcurrentHashMap 利用并行计算有效地使用并行性阈值。这是一个数值，其默认值为 2。

以下是 ConcurrentHashMap 中具有并行性能力的方法。

• forEach()
• reduce()
• reduceEntries()
• forEachEntry()
• forEachKey()
• forEachValue()

ConcurrentHashMap 处理并行性的方式略有不同，如果你看一下这些方法的参数，你就会明白。这些方法中的每一个都可以将并行性阈值作为参数。

首先，并行性是一个可选特性。我们可以通过在代码中添加适当的并行阈值来启用此特性。

在没有并行性的情况下使用ConcurrentHashMap

让我们以一个例子来说明如何替换 concurrenthashmap 中所有字符串值。这是在不使用并行性的情况下完成的。

例子：

concurrentHashMap.forEach((k,v) -> v=””);

这很简单，我们正在迭代 concurrenthashmap 中的所有条目，并将值替换为一个空字符串。在这种情况下，我们没有使用并行性。

在具有并行性的情况下使用ConcurrentHashMap

例子：

concurrentHashMap.forEach(2, (k,v) -> v=””);

上面的例子迭代了一个 ConcurrentHashMap，并用空字符串替换了映射的值。forEach() 方法的参数是并行性阈值和一个函数接口。在这种情况下，问题将被分解为子问题。

问题是用一个空字符串替换并发哈希映射的值。这是通过将这个问题分解为子问题来实现的，即为子问题创建单独的线程，每个线程将专注于用一个空字符串替换值。

当启用并行性时会发生什么？

当启用并行性阈值时，JVM 将创建线程，每个线程将运行以解决问题，并加入所有线程的结果。这个值的重要性在于，如果记录的数量达到一定水平（阈值），那么 JVM 才会在上面的例子中启用并行处理。如果映射中的记录多于一个，则应用程序将启用并行处理。

这是一个很酷的特性；我们可以通过调整阈值来控制并行性。这样，我们就可以在应用程序中利用并行处理。

看下面的另一个例子：

concurrentHashMap.forEach(10000, (k,v) -> v=””);

在这种情况下，并行性阈值为 10,000，这意味着如果记录的数量少于 10,000，JVM 将不会在替换值为空字符串时启用并行性。

在上面的例子中，并行性阈值为 10,000。

并行处理性能比较

以下代码将所有映射中的值替换为空字符串。这个 concurrenthash 映射中包含超过 100,000 个条目。让我们比较下面的代码在没有并行性和有并行性的情况下的性能。

运行上面的代码后，你会发现在普通的 forEach 操作中性能有所提升。

没有并行性的时间->20 毫秒

有并行性的时间->30 毫秒

这是因为映射中的记录数量相当少。

但是，如果我们向映射中添加 1000 万条记录，那么并行性真的会胜出！它需要更少的时间来处理数据。看一下下面的代码：

上面的代码用空字符串替换了 concurrenthashmap 中的所有值，而没有使用并行性。接下来，它使用并行性将 concurrenthashmap 的所有值替换为字符串一。这是输出：

没有并行性的时间->537 毫秒

有并行性的时间->231 毫秒

你可以看到，在并行性的情况下，只需要一半的时间。

注意：上述值不是固定的。在不同的系统中可能会产生不同的结果。

用于并行性的线程转储分析

当我们在代码中启用并行性时，JVM 使用 ForkJoinPool 框架来启用并行处理。这个框架根据当前处理的需求创建一些工作线程。让我们使用 fastthread.io 工具来分析上面的代码中启用并行性时的线程转储。

从上面的图片中你可以理解它正在使用更多的线程。

运行线程太多的原因是它使用了 ForkJoinPool API。这个 API 负责在后台实现“并行性”。当你看下一节时，你就会理解这种差异。

查看报告。

没有并行性的线程转储分析

让我们了解一下在没有启用并行性时的线程转储分析。

如果你仔细看上面的图片，你会发现只使用了少量的线程。在这种情况下，与之前的图片相比，只有 35 个线程。在这种情况下，有 32 个可运行的线程。但是，等待和定时等待的线程分别为 2 和 1。在这种情况下可运行线程数量减少的原因是它没有调用 ForkJoinPool API。

查看报告。

这样，fastthread.io 工具可以很聪明地提供对线程转储内部的深入洞察。

总结

我们关注了 concurrenthashmap 中的并行性以及如何在应用程序中使用这个特性。此外，我们了解了在启用此特性时 JVM 发生了什么。并行性是一个很酷的特性，可以在现代并发应用程序中很好地使用。