Map
上一篇我们详细了解了Java容器中的Collection体系,今天我们来对Java容器的另一个重要接口Map
进行详细分析。
Map
接口存在于java.util
包中,它用于表示键和值之间的映射,Map的键是唯一的。
Map
十分适用于需要键值对映射的场景。
Map的特点
Map
中不能包含重复的键,每个键最多可以映射到一个值。Map
接口下的一些子接口允许空键和空值。(下文介绍)Map
中元素的顺序取决于具体接口的实现。例如:TreeMap
和LinkedHashMap
中的元素具有先进先出的规则,而HashMap
没有。
下图为Map
的接口关系图片。
通过图片可以看出,Map
接口下包含了Hashtable
、HashMap
、LinkedHashMap
、TreeMap
的具体实现。
Hashtable
Hashtable
是Map
的早期实现类,它是线程安全的,因为其源码内部的方法基本都有synchronized
修饰。也因为其大量使用同步锁,高并发的场景下效率较低。Hashtable
如今基本被淘汰,在代码中若要保证线程安全请使用JUC
包中的ConcurrentHashMap
代替。
在实际场景中,我们使用较多的是HashMap
类,HashMap
类也是Map
接口的重要实现。下文我们将详细讲解HashMap
。
HashMap
HashMap
是Map
中的重要实现类,它是一个散列表,存储的内容是键值对(key=>value)映射。HashMap
是非线程安全的。HashMap
中允许存储null
的键和值,键是唯一的。
在JDK1.8以前,HashMap
的底层数据结构是纯粹的数组+链表结构。由于数组具有读取快,增删慢的特点,而链表具有读取慢,增删快的特点,HashMap
将二者相结合,并且没有使用同步锁进行修饰,它的性能较好。数组是HashMap
的主体,链表则是为了解决哈希冲突而引入。此处解决哈希冲突的具体方法为:拉链法。下文我们继续讨论。
HashMap
的默认数组长度为16,每个数组存储的是链表的头结点。扩容后的容量每次扩展为原来的2倍。HashMap
总是使用2的幂次方来作为哈希表的大小,具体为什么是2的幂次方,我们将在下文进行讨论。HashMap
通过key
的hashCode
经过hash
函数处理后得到哈希值,然后通过(n - 1) & hash(key.hashCode)
(n为数组长度length)得到元素下标。此处算法等价于:hash(key.hashCode) % n
,使用位运算的效率比直接使用取模运算效率高。JDK1.8后的扰动函数hash()
相较于之前有所改进,但原理是相同的。
为了更加直观理解拉链法,我画了HashMap
的数组+链表存储结构图。
拉链法:将数组和链表进行组合,每个数组中就是一个链表,数组元素(如图中元素1、元素2等)存储链表的头结点。然后按照上文讲的算法,将key
的长度经过扰动过后确定出数组元素的下标,存放到数组中对应的地方。在某些情况下,扰动函数hash()
计算出的哈希值可能一样,那么“拉链法”就会将出现哈希冲突的值存放到链表中。这就是所谓的“拉链法”。
但单纯使用数组+链表有个问题。因为在极端情况下,我们添加入HashMap
的不同value
的key
计算出来的哈希值可能相同,那么就会一直存放到一条链表上,导致链表长度过长,时间复杂度有可能从O(1)恶化为O(n)。由于链表的查询需要从头遍历,链表长度过长会造成大量的性能损失,所以在JDK1.8之后,HashMap
的底层数据结构增加了红黑树,它的存在更好地解决了哈希冲突,时间复杂度从O(n)提高到O(logn)。具体方法是:当链表长度大于阈值(默认为8)时,会将链表转化成红黑树以提高搜索的效率,防止链表过长而导致搜索效率低下。不过,在数组长度小于默认值64是,HashMap
会优先选择数组扩容,而不会转化为红黑树。
下面我们开始进行HashMap
源码分析。
源码分析
此处代码均为JDK1.8版本
transient Node<K,V>[] table;
transient Set<Map.Entry<K,V>> entrySet;
通过源码可以看出HashMap
底层是由数组Node<K,V>
的table
和链表entrySet组成的复合结构。在JDK1.8之前,数组中的元素名称是Entry
,而JDK1.8引入了树形结构,无论是树还是链表,其元素都统称为结点,故更名为Node
更为贴切。
final int hash;
final K key;
V value;
Node<K,V> next;
Node(int hash, K key, V value, Node<K,V> next) {
this.hash = hash;
this.key = key;
this.value = value;
this.next = next;
}
进入Node
中,我们可以发现Node
是由哈希值hash
,键值对key
,value
和下一个结点next
组成的。数组被分为一个个的bucket(可参考拉链法的图),通过哈希值决定了键值对在数组中的寻址。哈希值相同的键值对则以链表的形式存储。
/**
* The default initial capacity - MUST be a power of two.
*/
static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16
从此处可以看出HashMap
的数组默认初始化容量为1 << 4
,即16。使用位移运算保证容量始终为2的幂次方。
/**
* The bin count threshold for using a tree rather than list for a
* bin. Bins are converted to trees when adding an element to a
* bin with at least this many nodes. The value must be greater
* than 2 and should be at least 8 to mesh with assumptions in
* tree removal about conversion back to plain bins upon
* shrinkage.
*/
static final int TREEIFY_THRESHOLD = 8;
/**
* The bin count threshold for untreeifying a (split) bin during a
* resize operation. Should be less than TREEIFY_THRESHOLD, and at
* most 6 to mesh with shrinkage detection under removal.
*/
static final int UNTREEIFY_THRESHOLD = 6;
在JDK1.8中,我们可以看到一个静态常量TREEIFY_THRESHOLD
,值为8,也就是上文讲述的,当链表长度大于8时,HashMap
内部数据结构会“树化”,也就是转换成红黑树结构。同时,在元素被删除后,长度重新小于6时,红黑树会重新变回链表结构。
接下来,我们来解释为什么HashMap
能够保证哈希表的容量是2的幂次方。
/**
* Returns a power of two size for the given target capacity.
*/
static final int tableSizeFor(int cap) {
int n = cap - 1;
n |= n >>> 1;
n |= n >>> 2;
n |= n >>> 4;
n |= n >>> 8;
n |= n >>> 16;
return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;
}
继续阅读源码,我们可以看到tableSizeFor()
函数。这个函数将传入的cap
即容量进行减一运算,然后依次:将n右移1位,取“或”,右移两位,取“或”,右移4位,取“或”······以此类推。直到右移16位再取“或”,这时就能得到32个1。最后,进行判断。若n < 0时,则n取1,否则判断n是否大于最大容量,若大于最大容量,则取最大,否则取n + 1
的值。为了更清楚地演示,我将得到的结果表示在以下表格。
2的幂次方 | 二进制 | 十进制 |
---|---|---|
2^0 | 1 | (1-1)+1 |
2^1 | 10 | (2-1)+1 |
2^2 | 100 | (4-1)+1 |
2^3 | 1000 | (8-1)+1 |
2^4 | 10000 | (16-1)+1 |
2^5 | 100000 | (32-1)+1 |
从表中我们可以清晰地看出,经过运算,n的值肯定是2的幂次方。这也就解释了哈希表的容量是2的幂次方。
继续查看源码。HashMap
提供4个构造函数,如下所示:
/**
* 指定容量和负载因子的构造函数
*/
public HashMap(int initialCapacity, float loadFactor) {
if (initialCapacity < 0)
throw new IllegalArgumentException("Illegal initial capacity: " +
initialCapacity);
if (initialCapacity > MAXIMUM_CAPACITY)
initialCapacity = MAXIMUM_CAPACITY;
if (loadFactor <= 0 || Float.isNaN(loadFactor))
throw new IllegalArgumentException("Illegal load factor: " +
loadFactor);
this.loadFactor = loadFactor;
this.threshold = tableSizeFor(initialCapacity);
}
/**
* 指定容量的构造函数
*/
public HashMap(int initialCapacity) {
this(initialCapacity, DEFAULT_LOAD_FACTOR);
}
/**
* 默认构造函数
*/
public HashMap() {
this.loadFactor = DEFAULT_LOAD_FACTOR; // all other fields defaulted
}
/**
* 传入另一个Map的构造函数
*
* @param m the map whose mappings are to be placed in this map
* @throws NullPointerException if the specified map is null
*/
public HashMap(Map<? extends K, ? extends V> m) {
this.loadFactor = DEFAULT_LOAD_FACTOR;
putMapEntries(m, false);
}
在构造函数中,我们可以看到一个float
类型的loadFactor
变量。这个变量是HashMap
的负载因子。什么是负载因子?负载因子可以控制数组存放数据的疏密程度。负载因子越接近于1,发生哈希冲突的概率越大,也就是数组中存放的数据就越多(密),即链表的长度会增加。相反,负载因子越接近于0,数组中存放的数据越少(疏)。
loadFactor
取多少合适?
/**
* The load factor used when none specified in constructor.
*/
static final float DEFAULT_LOAD_FACTOR = 0.75f;
loadFactor
过大会导致链表的搜索效率变低,因为链表太长。而过小又会导致数组利用率低,存放的数据分散。所以官方经过测试给出了一个合理的默认值0.75f
,所以一般我们不需要修改。
loadFactor
体现在哪里?
举个例子。当默认容量为16,负载因子为0.75时,则桶的扩容阈值为:16 * 0.75 = 12。也就是说,当数量达到12时,bucket就会满,就需要将当前16的容量调用resize()进行扩容。
接下来我们查看put()
方法。
public V put(K key, V value) {
return putVal(hash(key), key, value, false, true);
}
可以发现put
方法调用了putVal
方法。putVal
方法仅供put
方法调用,并没有提供给用户使用。我们进入到putVal
方法中。
/**
* Implements Map.put and related methods.
*
* @param hash hash for key
* @param key the key
* @param value the value to put
* @param onlyIfAbsent if true, don't change existing value
* @param evict if false, the table is in creation mode.
* @return previous value, or null if none
*/
final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
boolean evict) {
Node<K,V>[] tab; Node<K,V> p; int n, i;
// table没有初始化或长度为0,则进行扩容。
// 此处的resize()方法不仅能够进行扩容,也能够进行初始化工作。
// 由此可推断,table的初始化方式是懒加载,在有元素插入时才调用resize()
if ((tab = table) == null || (n = tab.length) == 0)
n = (tab = resize()).length;
// (n - 1) & hash操作,如上文所述
// 若桶为空,则新生成的结点放桶里,这个地方的结点放在数组中,即头结点。
if ((p = tab[i = (n - 1) & hash]) == null)
tab[i] = newNode(hash, key, value, null);
// 桶不为空的情况
else {
Node<K,V> e; K k;
// 比较桶中第一个元素(即数组中的结点)的hash值,key值是否相等
// 若相等,则赋值:e = p
if (p.hash == hash &&
((k = p.key) == key || (key != null && key.equals(k))))
e = p;
// 若不相等,判断是否为红黑树结点
else if (p instanceof TreeNode)
// 是:存储结点到红黑树中
e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
// 为链表的情况
else {
//循环遍历到链表最后插入结点
for (int binCount = 0; ; ++binCount) {
// 已经遍历到最后一个元素
if ((e = p.next) == null) {
// 在尾部插入新结点
p.next = newNode(hash, key, value, null);
// 如上文所示,链表结点数若大于默认树化阈值8,则转为红黑树结构
// 同样如上文所示,只有数组长度大于阈值64,才会转换为红黑树。在treeifyBin中可见。
if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
treeifyBin(tab, hash);
// 完成逻辑,跳出死循环
break;
}
// 判断链表中的结点元素key与插入的元素key是否相等
// 若相等则直接跳出循环,否则赋值:p = e
if (e.hash == hash &&
((k = e.key) == key || (key != null && key.equals(k))))
break;
p = e;
}
}
if (e != null) { // 存在相同的key
//记录已存在的旧值
V oldValue = e.value;
// 如果onlyIfAbsent设为false或oldValue为空,则用新值进行替换。
if (!onlyIfAbsent || oldValue == null)
e.value = value;
// 访问结点后回调,主要用于LinkedHashMap
afterNodeAccess(e);
return oldValue;
}
}
// 修改次数 + 1
++modCount;
// 扩容!
if (++size > threshold)
resize();
//插入结点后回调,主要用于LinkedHashMap
afterNodeInsertion(evict);
return null;
}
请结合注释仔细阅读代码。我将其put
逻辑总结为以下步骤:
- 如果
HashMap
未被初始化,则调用resize()
初始化HashMap
。 - 对元素的
key
求hash
,然后计算出其下标。 - 如果没有出现哈希碰撞,则将元素放入bucket(桶)中。
- 如果出现哈希碰撞,则以链表的形式进行连接。
- 如果链表长度超过了默认阈值8,则将链表转换为红黑树。
- 如果链表长度重新低于阈值6,则将红黑树转回链表。
- 如果节点已经存在,则替换旧值。
- 如果bucket已满,(容量16 * 负载因子0.75),就需要resize()扩容。
HashMap
扩容带来的问题:
- 多线程环境下,调整大小会存在条件竞争,容易造成死锁。
- resize方法涉及hash的重新分配,并且会遍历hash表中所有元素,是耗时操作。在实际开发中,应尽量避免resize。
我们继续分析resize的源码。
/**
* Initializes or doubles table size. If null, allocates in
* accord with initial capacity target held in field threshold.
* Otherwise, because we are using power-of-two expansion, the
* elements from each bin must either stay at same index, or move
* with a power of two offset in the new table.
*
* @return the table
*/
final Node<K,V>[] resize() {
Node<K,V>[] oldTab = table;
int oldCap = (oldTab == null) ? 0 : oldTab.length;
int oldThr = threshold;
int newCap, newThr = 0;
if (oldCap > 0) {
if (oldCap >= MAXIMUM_CAPACITY) {
// 超过最大值阈值则设为整型的最大值。
threshold = Integer.MAX_VALUE;
return oldTab;
}
// 扩容为原来的两倍
else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
oldCap >= DEFAULT_INITIAL_CAPACITY)
newThr = oldThr << 1; // double threshold
}
// 旧阈值 > 0直接初始化新容量为oldThr
else if (oldThr > 0) // initial capacity was placed in threshold
newCap = oldThr;
else { // zero initial threshold signifies using defaults
// 否则新容量为默认初始化容量:16
newCap = DEFAULT_INITIAL_CAPACITY;
// 新阈值为:负载因子 * 默认初始化容量,即 0.75 * 16 = 12
newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
}
// 计算新的resize上限
if (newThr == 0) {
float ft = (float)newCap * loadFactor;
newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
(int)ft : Integer.MAX_VALUE);
}
threshold = newThr;
@SuppressWarnings({"rawtypes","unchecked"})
Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
table = newTab;
if (oldTab != null) {
// 将bucket中的元素移动到新的bucket中
for (int j = 0; j < oldCap; ++j) {
Node<K,V> e;
if ((e = oldTab[j]) != null) {
oldTab[j] = null;
if (e.next == null)
newTab[e.hash & (newCap - 1)] = e;
else if (e instanceof TreeNode)
((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
else { // preserve order
Node<K,V> loHead = null, loTail = null;
Node<K,V> hiHead = null, hiTail = null;
Node<K,V> next;
do {
next = e.next;
if ((e.hash & oldCap) == 0) {
if (loTail == null)
loHead = e;
else
loTail.next = e;
loTail = e;
}
else {
if (hiTail == null)
hiHead = e;
else
hiTail.next = e;
hiTail = e;
}
} while ((e = next) != null);
if (loTail != null) {
loTail.next = null;
newTab[j] = loHead;
}
if (hiTail != null) {
hiTail.next = null;
newTab[j + oldCap] = hiHead;
}
}
}
}
}
return newTab;
}
分析完put
方法和resize
扩容方法,我们继续分析get
方法。
public V get(Object key) {
// 定义一个Node结点
Node<K,V> e;
return (e = getNode(hash(key), key)) == null ? null : e.value;
}
final Node<K,V> getNode(int hash, Object key) {
Node<K,V>[] tab; Node<K,V> first, e; int n; K k;
if ((tab = table) != null && (n = tab.length) > 0 &&
(first = tab[(n - 1) & hash]) != null) {
// 数组中元素相等的情况
if (first.hash == hash && // always check first node
((k = first.key) == key || (key != null && key.equals(k))))
return first;
// bucket中不止一个结点
if ((e = first.next) != null) {
//判断是否为TreeNode树结点
if (first instanceof TreeNode)
//通过树的方法获取结点
return ((TreeNode<K,V>)first).getTreeNode(hash, key);
do {
//通过链表遍历获取结点
if (e.hash == hash &&
((k = e.key) == key || (key != null && key.equals(k))))
return e;
} while ((e = e.next) != null);
}
}
// 找不到就返回null
return null;
}
ConcurrentHashMap
ConcurrentHashMap
位于JUC
包中,是HashMap
的线程安全实现,常用于在对并发有较高要求的场景下。本文我们重点来分析一下ConcurrentHashMap
处理多线程的具体方法。
在JDK1.7时,ConcurrentHashMap
底层采用分段数组+链表实现,而1.8后的数据结构和HashMap
的1.8版本相同,都是采用数组+链表+红黑树的结构。
ConcurrentHashMap
在JDK1.7时,采用的是分段锁来实现线程安全。为了更加直观地理解,我画了分段锁的示意图。
从示意图中可以看出,分段锁对桶里的数组进行了分段,相当于分割成多个子数组,每个子数组配置一把锁,当多线程访问容器中不同数据段的数据,就不会存在锁竞争,有效提高了并发访问的速率。举个例子:当一个线程操作分段中2
所对应的子数组时,它只能操作2
中的数据段,当其他线程同时来操作2
时,线程就会被阻塞。但此时,其他数据段并没有被占用,依然能够正常访问,提高了效率。ConcurrentHashMap
默认分配了16个Segments。理论上,它的效率比Hashtable
的效率提升了16倍。
在JDK1.8后,ConcurrentHashMap
被再次优化。不再使用Segment
分段锁,而是采用synchronized
和CAS
来使锁更加细粒度化。并且数据结构上也同步升级为HashMap
的数组+链表+红黑树结构。
源码分析
通过源码可以看出,ConcurrentHashMap
和HashMap
的实现有许多相似之处。ConcurrentHashMap
也有一些特有的成员变量,这里我们对较为重要的成员变量单独进行分析。
/**
* Table initialization and resizing control. When negative, the
* table is being initialized or resized: -1 for initialization,
* else -(1 + the number of active resizing threads). Otherwise,
* when table is null, holds the initial table size to use upon
* creation, or 0 for default. After initialization, holds the
* next element count value upon which to resize the table.
*/
private transient volatile int sizeCtl;
sizeCtl
顾名思义就是用于控制大小的变量。它是哈希表扩容时或初始化时的一个控制变量。-1
代表正在初始化,-n
代表有n-1
个线程正在进行扩容操作。正数
或0
代表还未进行初始化。0为默认值。初始化完成后,sizeCtl
将表示初始化或下一次进行扩容的大小。同时,volatile
修饰符使得sizeCtl
的值可在多线程之间共享,它的改动对其他线程立即可见。
/*
* Encodings for Node hash fields. See above for explanation.
*/
static final int MOVED = -1; // hash for forwarding nodes
static final int TREEBIN = -2; // hash for roots of trees
static final int RESERVED = -3; // hash for transient reservations
static final int HASH_BITS = 0x7fffffff; // usable bits of normal node hash
ConcurrentHashMap
还有其它用于多线程控制的变量,感兴趣可自行查看源码进行研究。
ConcurrentHashMap
是利用CAS
+synchronized
进行高效同步更新数据。接下来我们对其put
方法源码进行分析。
public V put(K key, V value) {
return putVal(key, value, false);
}
与Hashmap
相同,put
调用了putVal
进行值插入。
/** Implementation for put and putIfAbsent */
final V putVal(K key, V value, boolean onlyIfAbsent) {
// ConcurrentHashMap不允许插入null键,否则将抛出空指针异常。
// 而HashMap允许
if (key == null || value == null) throw new NullPointerException();
// 计算hash
int hash = spread(key.hashCode());
int binCount = 0;
// 此处使用CAS机制进行更新,需要不断进行失败重试,故此处for循环为死循环
// 建议先具体了解CAS机制
for (Node<K,V>[] tab = table;;) {
Node<K,V> f; int n, i, fh;
//先判断数组是否为空或长度为0
if (tab == null || (n = tab.length) == 0)
//初始化table
tab = initTable();
// 不等于0,就通过hash值找到f,f表示链表或红黑二叉树的头结点,即数组中的元素
else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {
// 先查找结点是否存在,若不存在,则尝试通过CAS机制进行添加,添加失败则直接break,进入下一次循环
if (casTabAt(tab, i, null,
new Node<K,V>(hash, key, value, null)))
break; // no lock when adding to empty bin
}
// 若其它线程正在移动元素,则协助线程进行移动
else if ((fh = f.hash) == MOVED)
tab = helpTransfer(tab, f);
else {
V oldVal = null;
// 若发生碰撞,则锁住f
synchronized (f) {
// 判断f是否为链表的头结点,若是,则初始化链表计数器,并遍历链表
if (tabAt(tab, i) == f) {
if (fh >= 0) {
binCount = 1;
for (Node<K,V> e = f;; ++binCount) {
K ek;
// 此处与HashMap逻辑相似,可查阅对应HashMap源码
if (e.hash == hash &&
((ek = e.key) == key ||
(ek != null && key.equals(ek)))) {
oldVal = e.val;
if (!onlyIfAbsent)
e.val = value;
break;
}
Node<K,V> pred = e;
if ((e = e.next) == null) {
pred.next = new Node<K,V>(hash, key,
value, null);
break;
}
}
}
// 若是红黑树的结点,则使用红黑树的方法进行结点插入
else if (f instanceof TreeBin) {
Node<K,V> p;
binCount = 2;
if ((p = ((TreeBin<K,V>)f).putTreeVal(hash, key,
value)) != null) {
oldVal = p.val;
if (!onlyIfAbsent)
p.val = value;
}
}
}
}
if (binCount != 0) {
if (binCount >= TREEIFY_THRESHOLD)
treeifyBin(tab, i);
if (oldVal != null)
return oldVal;
break;
}
}
}
addCount(1L, binCount);
return null;
}
总结以上源码,ConcurrentHashMap
的put
逻辑如下:
-
判断
Node[]
数组是否初始化,没有则进行初始化操作。 -
通过
hash
定位数组的索引坐标,判断是否有Node
结点,若没有,则使用CAS
进行添加(链表的头结点),添加失败则进入下一次循环。 -
若检测到其它线程正在进行扩容(移动),则协助扩容。
-
若
f != null
,则使用synchronized
锁住f
元素(f
为链表或红黑二叉树的头元素)。4.1 如果是
Node
类型则进行链表的添加操作。4.2 如果是
TreeNode
类型则执行树的添加操作。 -
判断链表长度是否已达到阈值(默认为8),若已经达到则将链表转换为树结构。
可以发现,put
逻辑与HashMap
类似,无非增加了一些CAS、多线程相关的操作。
比起使用Segments
方式,锁拆得更细。具体体现在它首先使用无锁操作CAS插入头结点,若失败则进行循环重试。若头结点存在,则尝试获取头结点的同步锁,再进行操作。这样做的好处是在hash
不冲突的情况下,就不会存在多个线程并发获得一把锁的情况。相比于Segments
锁性能再次大幅提升。
HashMap与Hashtable的区别
- JDK1.8后的
HashMap
数据结构是数组+链表+红黑树。在链表长度大于默认值8时,会进行树化,即转换成红黑树。(转换前会先判断数组长度是否小于64,如果小于64会优先进行数组扩容,大于64才转换为红黑树)Hashtable
数据结构是数组+链表。 HashMap
不是线程安全的,而Hashtable
是线程安全的。HashMap
的效率高于Hashtable
。HashMap
可以存储null
的键和值,而Hashtable
不允许有null
的键和null
的值,否则将抛出NullPointerException
。HashMap
的默认初始容量为16,经过扩容,容量变为原来的2倍。Hashtable
初始容量大小为11,经过扩容,容量变为原来的2n + 1
。并且在手动指定初始容量的情况下,HashMap
每次扩容都会扩容为2的幂次方大小(这一机制取决于前文讲到的tableSizeFor()
方法),而Hashtable
会直接使用给定的容量大小。
ConcurrentHashMap 和 Hashtable 的区别
- 底层数据结构不同:
ConcurrentHashMap
在JDK1.7采用分段的数组+链表实现,而JDK1.8后使用的数据结构与HashMap
JDK1.8的相同,都是采用数组+链表+红黑树的结构。Hashtable
采用的是数组+链表的形式。 - 实现线程安全方式不同:
ConcurrentHashMap
在JDK1.7时使用的是Segments
分段锁,而在1.8后使用CAS
和synchronized
实现,性能更好(具体上文有讲到)。Hashtable
采用纯synchronized
同步锁保证线程安全,效率较低。
HashMap如何减少有效碰撞
- 扰动函数:扰动函数使元素位置分布均匀,减少碰撞的几率。
- 使用final对象,并采用合适的
equals()
和hashCode()
方法。
如何优化Hashtable
- 将锁细粒度化,即将整个锁拆解为多个锁进行优化。早期的
ConcurrentHashMap
就是通过这种方式实现多线程下性能的优化。(具体查看上文)
最后通过一张表总结HashMap
、Hashtable
、ConcurrentHashMap
总结
类型 | 数据结构 | 线程安全 | 对null的支持 | 实现线程安全的方式 |
---|---|---|---|---|
HashMap | < JDK1.8:数组+链表 >=JDK1.8: 数组+链表+红黑树 | 否 | 允许null键和null值 | 无 |
Hashtable | 数组+链表 | 是 | 不允许null键和null值 | synchronized |
ConcurrentHashMap | < JDK1.8:数组+链表 >=JDK1.8: 数组+链表+红黑树 | 是 | 不允许null键和null值 | < JDK1.8:Segments分段锁 >=JDK1.8: CAS+synchronized |