Java-API简析_java.util.HashTable＜K, V＞类（基于 Latest JDK）（浅析源码）

【版权声明】未经博主同意，谢绝转载！（请尊重原创，博主保留追究权）
https://blog.csdn.net/m0_69908381/article/details/132522445
出自【进步*于辰的博客】

因为我发现目前，我对Java-API的学习意识比较薄弱，需要慢慢习惯使用Java-API，乃至剖析源码来提升自己的源码阅读能力和编码素质。
大家如果需要Java-API文档，我上传了【https://download.csdn.net/download/m0_69908381/87691693】。

1、概述

继承关系：

• java.lang.Object
  • java.util.Dictionary
    • java.util.Hashtable

所有已实现的接口：
Serializable、Cloneable、Map

直接已知子类：
Properties、UIDefaults

---

public class Hashtable extends Dictionary implements Map, Cloneable, Serializable

此类实现一个哈希表，该哈希表将键映射到相应的值。任何非 null 对象都可以用作键或值。

为了成功地在哈希表中存储和检索对象，用作键的对象必须实现 hashCode() 方法和 equals() 方法。

Hashtable 的实例有两个参数影响其性能：初始容量 和 加载因子。容量 是哈希表中桶 的数量，初始容量 就是哈希表创建时的容量。注意，哈希表的状态为 open()：在发生“哈希冲突”的情况下，单个桶会存储多个条目，这些条目必须按顺序搜索。加载因子 是对哈希表在其容量自动增加之前可以达到多满的一个尺度。初始容量 和加载因子 这两个参数只是对该实现的提示。关于何时以及是否调用 rehash() 方法的具体细节则依赖于该实现。 （关于“加载因子”，详述可参考博文【关于对【Hashtable数据结构以及对象在JVM堆中的存储过程】的理解与简述】的第3.1项）

通常，默认加载因子(0.75)在时间和空间成本上寻求一种折中。加载因子过高虽然减少了空间开销，但同时也增加了查找某个条目的时间（在大多数 Hashtable 操作中，包括 get() 和 put() 操作，都反映了这一点）。

初始容量主要控制空间消耗与执行 rehash() 操作所需要的时间损耗之间的平衡。如果初始容量大于 Hashtable 所包含的最大条目数除以加载因子，则永远 不会发生 rehash() 操作。但是，将初始容量设置太高可能会浪费空间。

如果很多条目要存储在一个 Hashtable 中，那么与根据需要执行自动 rehashing() 操作来增大表的容量的做法相比，使用足够大的初始容量创建哈希表或许可以更有效地插入条目。

下面这个示例创建了一个数字的哈希表。它将数字的名称用作键：

Hashtable numbers = new Hashtable();
numbers.put("one", new Integer(1));
numbers.put("two", new Integer(2));
numbers.put("three", new Integer(3));

要检索一个数字，可以使用以下代码：

Integern = (Integer)numbers.get("two");
if (n != null) {
    System.out.println("two = " + n);
}

自 Java 2 平台 v1.2 以来，此类已经改进为可以实现 Map，因此它变成了 Java Collections Framework 的一部分。与新集合的实现不同，Hashtable 是同步的。

由迭代器返回的 Iterator() 和由所有 Hashtable 的“collection 视图方法”返回的 Collection 的 listIterator() 方法都是快速失败 的：在创建 Iterator 之后，如果从结构上对 Hashtable 进行修改，除非通过 Iterator 自身的移除或添加方法，否则在任何时间以任何方式对其进行修改，Iterator 都将抛出 ConcurrentModificationException。因此，面对并发的修改，Iterator 很快就会完全失败，而不冒在将来某个不确定的时间发生任意不确定行为的风险。由 Hashtable 的键和值方法返回的 Enumeration() 不是快速失败的。

注意，迭代器的快速失败行为无法得到保证，因为一般来说，不可能对是否出现不同步并发修改做出任何硬性保证。快速失败迭代器会尽最大努力抛出 ConcurrentModificationException。因此，为提高这类迭代器的正确性而编写一个依赖于此异常的程序是错误做法：迭代器的快速失败行为应该仅用于检测程序错误。

此类是 Java Collections Framework 的成员。

从以下版本开始：
JDK1.0
另请参见：
Object.equals(java.lang.Object)、Object.hashCode()、rehash()、Collection、Map、HashMap、TreeMap、序列化表格

2、构造方法摘要

2.1 null

用默认的初始容量 (11) 和加载因子（0.75）构造一个新的空哈希表。

2.2 int initialCapacity

用指定初始容量和默认的加载因子（0.75）构造一个新的空哈希表。

2.3 int initialCapacity, float loadFactor

用指定初始容量和指定加载因子构造一个新的空哈希表。

2.4 Map t

构造一个与给定的 Map 具有相同映射关系的新哈希表。

3、方法摘要

3.1 void clear()

将此哈希表清空，使其不包含任何键。

3.2 Object clone()

创建此哈希表的浅表复制。

3.3 boolean contains(Object value)

测试此映射表中是否存在与指定值关联的键。

3.4 boolean containsKey(Object key)

测试指定对象是否为此哈希表中的键。

3.5 boolean containsValue(Object value)

如果此 Hashtable 将一个或多个键映射到此值，则返回 true。

3.6 Enumeration elements()

返回此哈希表中的值的枚举。

3.7 Set> entrySet()

返回此 Hashtable 中所包含的键的 Set 视图。

3.8 boolean equals(Object o)

按照 Map 接口的定义，比较指定 Object 与此 Map 是否相等。

3.9 V get(Object key)

返回此哈希表中指定键所映射到的值。

3.10 int hashCode()

按照 Map 接口的定义，返回此 Map 的哈希码值。

3.11 boolean isEmpty()

测试此哈希表是否没有键映射到值。

3.12 Enumeration keys()

返回此哈希表中的键的枚举。

3.13 Set keySet()

返回此 Hashtable 中所包含的键的 Set 视图。

3.14 V put(K key, V value)

将指定 key 映射到此哈希表中的指定 value。

3.15 void putAll(Map t)

将指定 Map 的所有映射关系复制到此 Hashtable 中，这些映射关系将替换此 Hashtable 拥有的、针对当前指定 Map 中所有键的所有映射关系。

3.16 protected void rehash()

增加此哈希表的容量并在内部对其进行重组，以便更有效地容纳和访问其元素。

3.17 V remove(Object key)

从哈希表中移除该键及其相应的值。

3.18 int size()

返回此哈希表中的键的数量。

3.19 String toString()

返回此 Hashtable 对象的字符串表示形式，其形式为 ASCII 字符 ", " （逗号加空格）分隔开的、括在括号中的一组条目。

3.20 Collection values()

返回此 Hashtable 中所包含值的 Collection 视图。

---

本文持续更新中。。。