Java 容器源码分析之 Map

时间 2019-12-06

标签 java 容器源码分析 map 栏目 Java 繁體版

原文原文链接

ava.util 中的集合类包含 Java 中某些最经常使用的类。最经常使用的集合类是 List 和 Map。List 的具体实现包括 ArrayList 和 Vector，它们是可变大小的列表，比较适合构建、存储和操做任何类型对象元素列表。List 适用于按数值索引访问元素的情形。html

Map 提供了一个更通用的元素存储方法。Map 集合类用于存储元素对（称做“键”和“值”），其中每一个键映射到一个值。从概念上而言，您能够将 List 看做是具备数值键的 Map。而实际上，除了 List 和 Map 都在定义 java.util 中外，二者并无直接的联系。本文将着重介绍核心 Java 发行套件中附带的 Map，同时还将介绍如何采用或实现更适用于您应用程序特定数据的专用 Map。java

了解 Map 接口和方法算法

Java 核心类中有不少预约义的 Map 类。在介绍具体实现以前，咱们先介绍一下 Map 接口自己，以便了解全部实现的共同点。Map 接口定义了四种类型的方法，每一个 Map 都包含这些方法。下面，咱们从两个普通的方法（表 1 ）开始对这些方法加以介绍。编程

表 1：覆盖的方法。咱们将这 Object 的这两个方法覆盖，以正确比较 Map 对象的等价性。数组

equals(Object o)	比较指定对象与此 Map 的等价性
hashCode()	返回此 Map 的哈希码

Map 构建安全

Map 定义了几个用于插入和删除元素的变换方法（表 2 ）。服务器

表 2：Map 更新方法：能够更改 Map 内容。多线程

clear()	从 Map 中删除全部映射
remove(Object key)	从 Map 中删除键和关联的值
put(Object key, Object value)	将指定值与指定键相关联
clear()	从 Map 中删除全部映射
putAll(Map t)	将指定 Map 中的全部映射复制到此 map

尽管您可能注意到，纵然假设忽略构建一个须要传递给 putAll() 的 Map 的开销，使用 putAll() 一般也并不比使用大量的 put() 调用更有效率，但 putAll() 的存在一点也不稀奇。这是由于，putAll() 除了迭代 put() 所执行的将每一个键值对添加到 Map 的算法之外，还须要迭代所传递的 Map 的元素。但应注意，putAll() 在添加全部元素以前能够正确调整 Map 的大小，所以若是您未亲自调整 Map 的大小（咱们将对此进行简单介绍），则 putAll() 可能比预期的更有效。并发

查看 Maporacle

迭代 Map 中的元素不存在直接了当的方法。若是要查询某个 Map 以了解其哪些元素知足特定查询，或若是要迭代其全部元素（不管缘由如何），则您首先须要获取该 Map 的“视图”。有三种可能的视图（参见表 3 ）

全部键值对 — 参见 entrySet()
全部键 — 参见 keySet()
有值 — 参见 values()

前两个视图均返回 Set 对象，第三个视图返回 Collection 对象。就这两种状况而言，问题到这里并无结束，这是由于您没法直接迭代 Collection 对象或 Set 对象。要进行迭代，您必须得到一个 Iterator 对象。所以，要迭代 Map 的元素，必须进行比较烦琐的编码

Iterator keyValuePairs = aMap.entrySet().iterator();
Iterator keys = aMap.keySet().iterator();
Iterator values = aMap.values().iterator();

值得注意的是，这些对象（Set、Collection 和 Iterator）其实是基础 Map 的视图，而不是包含全部元素的副本。这使它们的使用效率很高。另外一方面，Collection 或 Set 对象的 toArray() 方法却建立包含 Map 全部元素的数组对象，所以除了确实须要使用数组中元素的情形外，其效率并不高。

我运行了一个小测试（随附文件中的），该测试使用了 HashMap，并使用如下两种方法对迭代 Map 元素的开销进行了比较：

int mapsize = aMap.size();

                                     
Iterator keyValuePairs1 = aMap.entrySet().iterator();
for (int i = 0; i < mapsize; i++)
{
  Map.Entry entry = (Map.Entry) keyValuePairs1.next();
  Object key = entry.getKey();
  Object value = entry.getValue();
  ...
}

                                     
Object[] keyValuePairs2 = aMap.entrySet().toArray();
for (int i = 0; i < rem; i++) {
{
  Map.Entry entry = (Map.Entry) keyValuePairs2[i];
  Object key = entry.getKey();

Profilers in Oracle JDeveloper

Oracle JDeveloper 包含一嵌入的监测器，它测量内存和执行时间，使您可以快速识别代码中的瓶颈。我曾使用 Jdeveloper 的执行监测器监测 HashMap 的 containsKey() 和 containsValue() 方法，并很快发现 containsKey() 方法的速度比 containsValue() 方法慢不少（实际上要慢几个数量级！）。（参见图 1 和图 2，以及随附文件中的类）。

  Object value = entry.getValue();
  ...
}

此测试使用了两种测量方法：一种是测量迭代元素的时间，另外一种测量使用 toArray 调用建立数组的其余开销。第一种方法（忽略建立数组所需的时间）代表，使用已从 toArray 调用中建立的数组迭代元素的速度要比使用 Iterator 的速度大约快 30%-60%。但若是将使用 toArray 方法建立数组的开销包含在内，则使用 Iterator 实际上要快 10%-20%。所以，若是因为某种缘由要建立一个集合元素的数组而非迭代这些元素，则应使用该数组迭代元素。但若是您不须要此中间数组，则不要建立它，而是使用 Iterator 迭代元素。

表 3：返回视图的 Map 方法：使用这些方法返回的对象，您能够遍历 Map 的元素，还能够删除 Map 中的元素。

entrySet()	返回 Map 中所包含映射的 Set 视图。Set 中的每一个元素都是一个 Map.Entry 对象，可使用 getKey() 和 getValue() 方法（还有一个 setValue() 方法）访问后者的键元素和值元素
keySet()	返回 Map 中所包含键的 Set 视图。删除 Set 中的元素还将删除 Map 中相应的映射（键和值）
values()	返回 map 中所包含值的 Collection 视图。删除 Collection 中的元素还将删除 Map 中相应的映射（键和值）

访问元素

表 4 中列出了 Map 访问方法。Map 一般适合按键（而非按值）进行访问。Map 定义中没有规定这确定是真的，但一般您能够指望这是真的。例如，您能够指望 containsKey() 方法与 get() 方法同样快。另外一方面，containsValue() 方法极可能须要扫描 Map 中的值，所以它的速度可能比较慢。

表 4：Map 访问和测试方法：这些方法检索有关 Map 内容的信息但不更改 Map 内容。

get(Object key)	返回与指定键关联的值
containsKey(Object key)	若是 Map 包含指定键的映射，则返回 true
containsValue(Object value)	若是此 Map 将一个或多个键映射到指定值，则返回 true
isEmpty()	若是 Map 不包含键-值映射，则返回 true
size()	返回 Map 中的键-值映射的数目

对使用 containsKey() 和 containsValue() 遍历 HashMap 中全部元素所需时间的测试代表，containsValue() 所需的时间要长不少。实际上要长几个数量级！（参见图 1 和图 2 ，以及随附文件中的。所以，若是 containsValue() 是应用程序中的性能问题，它将很快显现出来，并能够经过监测您的应用程序轻松地将其识别。这种状况下，我相信您可以想出一个有效的替换方法来实现 containsValue() 提供的等效功能。但若是想不出办法，则一个可行的解决方案是再建立一个 Map，并将第一个 Map 的全部值做为键。这样，第一个 Map 上的 containsValue() 将成为第二个 Map 上更有效的 containsKey()。

图 1：使用 JDeveloper 建立并运行 Map 测试类

图 2：在 JDeveloper 中使用执行监测器进行的性能监测查出应用程序中的瓶颈

核心 Map

Java 自带了各类 Map 类。这些 Map 类可归为三种类型：

通用 Map，用于在应用程序中管理映射，一般在 java.util 程序包中实现
- HashMap
- Hashtable
- Properties
- LinkedHashMap
- IdentityHashMap
- TreeMap
- WeakHashMap
- ConcurrentHashMap
专用 Map，您一般没必要亲自建立此类 Map，而是经过某些其余类对其进行访问
- java.util.jar.Attributes
- javax.print.attribute.standard.PrinterStateReasons
- java.security.Provider
- java.awt.RenderingHints
- javax.swing.UIDefaults
一个用于帮助实现您本身的 Map 类的抽象类
- AbstractMap

内部哈希：哈希映射技术

几乎全部通用 Map 都使用哈希映射。这是一种将元素映射到数组的很是简单的机制，您应了解哈希映射的工做原理，以便充分利用 Map。

哈希映射结构由一个存储元素的内部数组组成。因为内部采用数组存储，所以必然存在一个用于肯定任意键访问数组的索引机制。实际上，该机制须要提供一个小于数组大小的整数索引值。该机制称做哈希函数。在 Java 基于哈希的 Map 中，哈希函数将对象转换为一个适合内部数组的整数。您没必要为寻找一个易于使用的哈希函数而大伤脑筋：每一个对象都包含一个返回整数值的 hashCode() 方法。要将该值映射到数组，只需将其转换为一个正值，而后在将该值除以数组大小后取余数便可。如下是一个简单的、适用于任何对象的 Java 哈希函数

int hashvalue = Maths.abs(key.hashCode()) % table.length;

（% 二进制运算符（称做模）将左侧的值除以右侧的值，而后返回整数形式的余数。）

实际上，在 1.4 版发布以前，这就是各类基于哈希的 Map 类所使用的哈希函数。但若是您查看一下代码，您将看到

int hashvalue = (key.hashCode() & 0x7FFFFFFF) % table.length;

它其实是使用更快机制获取正值的同一函数。在 1.4 版中，HashMap 类实现使用一个不一样且更复杂的哈希函数，该函数基于 Doug Lea 的 util.concurrent 程序包（稍后我将更详细地再次介绍 Doug Lea 的类）。

图 3：哈希工做原理

该图介绍了哈希映射的基本原理，但咱们尚未对其进行详细介绍。咱们的哈希函数将任意对象映射到一个数组位置，但若是两个不一样的键映射到相同的位置，状况将会如何？这是一种必然发生的状况。在哈希映射的术语中，这称做冲突。Map 处理这些冲突的方法是在索引位置处插入一个连接列表，并简单地将元素添加到此连接列表。所以，一个基于哈希的 Map 的基本 put() 方法可能以下所示

public Object put(Object key, Object value) {
  //咱们的内部数组是一个 Entry 对象数组
  //Entry[] table;

  //获取哈希码，并映射到一个索引
  int hash = key.hashCode();
  int index = (hash & 0x7FFFFFFF) % table.length;

  //循环遍历位于 table[index] 处的连接列表，以查明
  //咱们是否拥有此键项 — 若是拥有，则覆盖它
  for (Entry e = table[index] ; e != null ; e = e.next) {
    //必须检查键是否相等，缘由是不一样的键对象
    //可能拥有相同的哈希
    if ((e.hash == hash) && e.key.equals(key)) {
      //这是相同键，覆盖该值
      //并从该方法返回 old 值
      Object old = e.value;
      e.value = value;
      return old;
    }
  }

  //仍然在此处，所以它是一个新键，只需添加一个新 Entry
  //Entry 对象包含 key 对象、 value 对象、一个整型的 hash、
  //和一个指向列表中的下一个 Entry 的 next Entry

  //建立一个指向上一个列表开头的新 Entry，
  //并将此新 Entry 插入表中
  Entry e = new Entry(hash, key, value, table[index]);
  table[index] = e;

  return null;
}

若是看一下各类基于哈希的 Map 的源代码，您将发现这基本上就是它们的工做原理。此外，还有一些须要进一步考虑的事项，如处理空键和值以及调整内部数组。此处定义的 put() 方法还包含相应 get() 的算法，这是由于插入包括搜索映射索引处的项以查明该键是否已经存在。（即 get() 方法与 put() 方法具备相同的算法，但 get() 不包含插入和覆盖代码。）使用连接列表并非解决冲突的惟一方法，某些哈希映射使用另外一种“开放式寻址”方案，本文对其不予介绍。

优化 Hasmap

若是哈希映射的内部数组只包含一个元素，则全部项将映射到此数组位置，从而构成一个较长的连接列表。因为咱们的更新和访问使用了对连接列表的线性搜索，而这要比 Map 中的每一个数组索引只包含一个对象的情形要慢得多，所以这样作的效率很低。访问或更新连接列表的时间与列表的大小线性相关，而使用哈希函数问或更新数组中的单个元素则与数组大小无关 — 就渐进性质（Big-O 表示法）而言，前者为 O(n)，然后者为 O(1)。所以，使用一个较大的数组而不是让太多的项汇集在太少的数组位置中是有意义的。

调整 Map 实现的大小

在哈希术语中，内部数组中的每一个位置称做“存储桶”(bucket)，而可用的存储桶数（即内部数组的大小）称做容量 (capacity)。为使 Map 对象有效地处理任意数目的项，Map 实现能够调整自身的大小。但调整大小的开销很大。调整大小须要将全部元素从新插入到新数组中，这是由于不一样的数组大小意味着对象如今映射到不一样的索引值。先前冲突的键可能再也不冲突，而先前不冲突的其余键如今可能冲突。这显然代表，若是将 Map 调整得足够大，则能够减小甚至再也不须要从新调整大小，这颇有可能显著提升速度。

使用 1.4.2 JVM 运行一个简单的测试，即用大量的项（数目超过一百万）填充 HashMap。表 5 显示告终果，并将全部时间标准化为已预先设置大小的服务器模式（关联文件中的。对于已预先设置大小的 JVM，客户端和服务器模式 JVM 运行时间几乎相同（在放弃 JIT 编译阶段后）。但使用 Map 的默认大小将引起屡次调整大小操做，开销很大，在服务器模式下要多用 50% 的时间，而在客户端模式下几乎要多用两倍的时间！

表 5：填充已预先设置大小的 HashMap 与填充默认大小的 HashMap 所需时间的比较

	客户端模式	服务器模式
预先设置的大小	100%	100%
默认大小	294%	157%

使用负载因子

为肯定什么时候调整大小，而不是对每一个存储桶中的连接列表的深度进行记数，基于哈希的 Map 使用一个额外参数并粗略计算存储桶的密度。Map 在调整大小以前，使用名为“负载因子”的参数指示 Map 将承担的“负载”量，即它的负载程度。负载因子、项数（Map 大小）与容量之间的关系简单明了：

若是（负载因子）x（容量）>（Map 大小），则调整 Map 大小

例如，若是默认负载因子为 0.75，默认容量为 11，则 11 x 0.75 = 8.25，该值向下取整为 8 个元素。所以，若是将第 8 个项添加到此 Map，则该 Map 将自身的大小调整为一个更大的值。相反，要计算避免调整大小所需的初始容量，用将要添加的项数除以负载因子，并向上取整，例如，

对于负载因子为 0.75 的 100 个项，应将容量设置为 100/0.75 = 133.33，并将结果向上取整为 134（或取整为 135 以使用奇数）

奇数个存储桶使 map 可以经过减小冲突数来提升执行效率。虽然我所作的测试（关联文件中的并未代表质数能够始终得到更好的效率，但理想情形是容量取质数。1.4 版后的某些 Map（如 HashMap 和 LinkedHashMap，而非 Hashtable 或 IdentityHashMap）使用须要 2 的幂容量的哈希函数，但下一个最高 2 的幂容量由这些 Map 计算，所以您没必要亲自计算。

负载因子自己是空间和时间之间的调整折衷。较小的负载因子将占用更多的空间，但将下降冲突的可能性，从而将加快访问和更新的速度。使用大于 0.75 的负载因子多是不明智的，而使用大于 1.0 的负载因子确定是不明知的，这是由于这一定会引起一次冲突。使用小于 0.50 的负载因子好处并不大，但只要您有效地调整 Map 的大小，应不会对小负载因子形成性能开销，而只会形成内存开销。但较小的负载因子将意味着若是您未预先调整 Map 的大小，则致使更频繁的调整大小，从而下降性能，所以在调整负载因子时必定要注意这个问题。

选择适当的 Map

应使用哪一种 Map？它是否须要同步？要得到应用程序的最佳性能，这多是所面临的两个最重要的问题。当使用通用 Map 时，调整 Map 大小和选择负载因子涵盖了 Map 调整选项。

如下是一个用于得到最佳 Map 性能的简单方法

将您的全部 Map 变量声明为 Map，而不是任何具体实现，即不要声明为 HashMap 或 Hashtable，或任何其余 Map 类实现。
```
Map criticalMap = new HashMap(); //好

HashMap criticalMap = new HashMap(); //差
```
这使您可以只更改一行代码便可很是轻松地替换任何特定的 Map 实例。
下载 Doug Lea 的 util.concurrent 程序包 (http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html)。将 ConcurrentHashMap 用做默认 Map。当移植到 1.5 版时，将 java.util.concurrent.ConcurrentHashMap 用做您的默认 Map。不要将 ConcurrentHashMap 包装在同步的包装器中，即便它将用于多个线程。使用默认大小和负载因子。
监测您的应用程序。若是发现某个 Map 形成瓶颈，则分析形成瓶颈的缘由，并部分或所有更改该 Map 的如下内容：Map 类；Map 大小；负载因子；关键对象 equals() 方法实现。专用的 Map 的基本上都须要特殊用途的定制 Map 实现，不然通用 Map 将实现您所需的性能目标。

Map 选择

也许您曾指望更复杂的考量，而这其实是否显得太容易？好的，让咱们慢慢来。首先，您应使用哪一种 Map？答案很简单：不要为您的设计选择任何特定的 Map，除非实际的设计须要指定一个特殊类型的 Map。设计时一般不须要选择具体的 Map 实现。您可能知道本身须要一个 Map，但不知道使用哪一种。而这偏偏就是使用 Map 接口的意义所在。直到须要时再选择 Map 实现 — 若是随处使用“Map”声明的变量，则更改应用程序中任何特殊 Map 的 Map 实现只须要更改一行，这是一种开销不多的调整选择。是否要使用默认的 Map 实现？我很快将谈到这个问题。

同步 Map

同步与否有何差异？（对于同步，您既可使用同步的 Map，也可使用 Collections.synchronizedMap() 将未同步的 Map 转换为同步的 Map。后者使用“同步的包装器”）这是一个异常复杂的选择，彻底取决于您如何根据多线程并发访问和更新使用 Map，同时还须要进行维护方面的考虑。例如，若是您开始时未并发更新特定 Map，但它后来更改成并发更新，状况将如何？在这种状况下，很容易在开始时使用一个未同步的 Map，并在后来向应用程序中添加并发更新线程时忘记将此未同步的 Map 更改成同步的 Map。这将使您的应用程序容易崩溃（一种要肯定和跟踪的最糟糕的错误）。但若是默认为同步，则将因随之而来的可怕性能而序列化执行多线程应用程序。看起来，咱们须要某种决策树来帮助咱们正确选择。

Doug Lea 是纽约州立大学奥斯威戈分校计算机科学系的教授。他建立了一组公共领域的程序包（统称 util.concurrent），该程序包包含许多能够简化高性能并行编程的实用程序类。这些类中包含两个 Map，即 ConcurrentReaderHashMap 和 ConcurrentHashMap。这些 Map 实现是线程安全的，而且不须要对并发访问或更新进行同步，同时还适用于大多数须要 Map 的状况。它们还远比同步的 Map（如 Hashtable）或使用同步的包装器更具伸缩性，而且与 HashMap 相比，它们对性能的破坏很小。util.concurrent 程序包构成了 JSR166 的基础；JSR166 已经开发了一个包含在 Java 1.5 版中的并发实用程序，而 Java 1.5 版将把这些 Map 包含在一个新的 java.util.concurrent 程序包中。

全部这一切意味着您不须要一个决策树来决定是使用同步的 Map 仍是使用非同步的 Map，而只需使用 ConcurrentHashMap。固然，在某些状况下，使用 ConcurrentHashMap 并不合适。但这些状况不多见，而且应具体状况具体处理。这就是监测的用途。

结束语

能够很是轻松地建立一个用于比较各类 Map 性能的测试类。更重要的是，集成良好的监测器能够在开发过程当中快速、轻松地识别性能瓶颈 - 集成到 IDE 中的监测器一般被较频繁地使用，以便帮助构建一个成功的工程。如今，您已经拥有了一个监测器并了解了有关通用 Map 及其性能的基础知识，能够开始运行您本身的测试，以查明您的应用程序是否因 Map 而存在瓶颈以及在何处须要更改所使用的 Map。