mirror of
https://github.com/Snailclimb/JavaGuide
synced 2025-06-20 22:17:09 +08:00
增加了对 hash方法的理解
This commit is contained in:
Snailclimb
GitHub
parent
2a14332b0e
commit
63d436e33f
@ -1,31 +1,62 @@
|
||||
<!-- MarkdownTOC -->
|
||||
|
||||
- [简介](#简介)
|
||||
- [内部结构分析](#内部结构分析)
|
||||
- [JDK1.8之前](#jdk18之前)
|
||||
- [JDK1.8之后](#jdk18之后)
|
||||
- [HashMap 简介](#hashmap-简介)
|
||||
- [底层数据结构分析](#底层数据结构分析)
|
||||
- [JDK1.8之前](#jdk18之前)
|
||||
- [JDK1.8之后](#jdk18之后)
|
||||
- [HashMap源码分析](#hashmap源码分析)
|
||||
- [构造方法](#构造方法)
|
||||
- [put方法](#put方法)
|
||||
- [get方法](#get方法)
|
||||
- [resize方法](#resize方法)
|
||||
- [构造方法](#构造方法)
|
||||
- [put方法](#put方法)
|
||||
- [get方法](#get方法)
|
||||
- [resize方法](#resize方法)
|
||||
- [HashMap常用方法测试](#hashmap常用方法测试)
|
||||
|
||||
<!-- /MarkdownTOC -->
|
||||
|
||||
## HashMap 简介
|
||||
HashMap 主要用来存放键值对，它基于哈希表的Map接口实现</font>，是常用的Java集合之一。
|
||||
|
||||
## <font face="楷体" id="1">简介</font>
|
||||
<font color="red">HashMap</font>主要用来存放<font color="red">键值对</font>，它<font color="red">基于哈希表的Map接口实现</font>，是常用的Java集合之一。与HashTable主要区别为<font color="red">不支持同步和允许null作为key和value</font>，所以如果你想要保证线程安全，可以使用<font color="red">ConcurrentHashMap</font>代替而不是线程安全的HashTable，因为HashTable基本已经被淘汰。
|
||||
## <font face="楷体" id="2">内部结构分析
|
||||
### <font face="楷体" id="2.1">JDK1.8之前</font>
|
||||
JDK1.8之前HashMap底层是<font color="red">数组和链表</font>结合在一起使用也就是<font color="red">链表散列</font>。HashMap通过key的hashCode来计算hash值，当hashCode相同时，通过<font color="red">“拉链法”</font>解决冲突。
|
||||
JDK1.8 之前 HashMap 由 数组+链表 组成的，数组是 HashMap 的主体，链表则是主要为了解决哈希冲突而存在的（“拉链法”解决冲突）.JDK1.8 以后在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）时，将链表转化为红黑树，以减少搜索时间。
|
||||
|
||||
所谓<font color="red">“拉链法”</font>就是：将链表和数组相结合。也就是说创建一个链表数组，数组中每一格就是一个链表。若遇到哈希冲突，则将冲突的值加到链表中即可。
|
||||
## 底层数据结构分析
|
||||
### JDK1.8之前
|
||||
JDK1.8 之前 HashMap 底层是 **数组和链表** 结合在一起使用也就是 **链表散列**。**HashMap 通过 key 的 hashCode 经过扰动函数处理过后得到 hash 值，当 hash 值相同时，通过拉链法解决冲突。**
|
||||
|
||||
**所谓扰动函数指的就是 HashMap 的 hash 方法。使用 hash 方法也就是扰动函数是为了防止一些实现比较差的 hashCode() 方法 换句话说使用扰动函数之后可以减少碰撞。**
|
||||
|
||||
**JDK 1.8 HashMap 的 hash 方法源码:**
|
||||
|
||||
JDK 1.8 的 hash方法 相比于 JDK 1.7 hash 方法更加简化，但是原理不变。
|
||||
|
||||
```java
|
||||
static final int hash(Object key) {
|
||||
int h;
|
||||
// key.hashCode()：返回散列值也就是hashcode
|
||||
// ^ ：按位异或
|
||||
// >>>:无符号右移，忽略符号位，空位都以0补齐
|
||||
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
|
||||
}
|
||||
```
|
||||
对比一下 JDK1.7的 HashMap 的 hash 方法源码.
|
||||
|
||||
```java
|
||||
static int hash(int h) {
|
||||
// This function ensures that hashCodes that differ only by
|
||||
// constant multiples at each bit position have a bounded
|
||||
// number of collisions (approximately 8 at default load factor).
|
||||
|
||||
h ^= (h >>> 20) ^ (h >>> 12);
|
||||
return h ^ (h >>> 7) ^ (h >>> 4);
|
||||
}
|
||||
```
|
||||
|
||||
相比于 JDK1.8 的 hash 方法 ，JDK 1.7 的 hash 方法的性能会稍差一点点，因为毕竟扰动了 4 次。
|
||||
|
||||
所谓 **“拉链法”** 就是：将链表和数组相结合。也就是说创建一个链表数组，数组中每一格就是一个链表。若遇到哈希冲突，则将冲突的值加到链表中即可。
|
||||
|
||||
|
||||
|
||||
简单来说，JDK1.8之前HashMap由<font color="red">数组+链表组成的，数组是HashMap的主体，链表则是主要为了解决哈希冲突而存在的，如果定位到的数组位置不含链表（当前entry的next指向null）,那么对于查找，添加等操作很快，仅需一次寻址即可；如果定位到的数组包含链表，对于添加操作，其时间复杂度依然为O(1)，因为最新的Entry会插入链表头部，急需要简单改变引用链即可，而对于查找操作来讲，此时就需要遍历链表，然后通过key对象的equals方法逐一比对查找.</font>
|
||||
### <font face="楷体" id="2.2">JDK1.8之后</font>
|
||||
如果定位到的数组位置不含链表（当前entry的next指向null）,那么对于查找，添加等操作很快，仅需一次寻址即可；如果定位到的数组包含链表，对于添加操作，其时间复杂度依然为O(1)，因为最新的Entry会插入链表头部，急需要简单改变引用链即可，而对于查找操作来讲，此时就需要遍历链表，然后通过key对象的equals方法逐一比对查找.
|
||||
### JDK1.8之后
|
||||
相比于之前的版本，jdk1.8在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为8）时，将链表转化为红黑树，以减少搜索时间。
|
||||
|
||||
**类的属性：**
|
||||
@ -59,15 +90,15 @@ public class HashMap<K,V> extends AbstractMap<K,V> implements Map<K,V>, Cloneabl
|
||||
final float loadFactor;
|
||||
}
|
||||
```
|
||||
<font color="red">(1)loadFactor加载因子</font>
|
||||
- **(1)loadFactor加载因子**
|
||||
|
||||
loadFactor加载因子是控制数组存放数据的疏密程度，loadFactor越趋近于1，那么 数组中存放的数据(entry)也就越多，也就越密，也就是会让链表的长度增加，load Factor越小，也就是趋近于0，
|
||||
loadFactor加载因子是控制数组存放数据的疏密程度，loadFactor越趋近于1，那么 数组中存放的数据(entry)也就越多，也就越密，也就是会让链表的长度增加，load Factor越小，也就是趋近于0，
|
||||
|
||||
**loadFactor太大导致查找元素效率低，太小导致数组的利用率低，存放的数据会很分散。loadFactor的默认值为0.75f是官方给出的一个比较好的临界值**。
|
||||
**loadFactor太大导致查找元素效率低，太小导致数组的利用率低，存放的数据会很分散。loadFactor的默认值为0.75f是官方给出的一个比较好的临界值**。
|
||||
|
||||
<font color="red">(2)threshold</font>
|
||||
- **(2)threshold**
|
||||
|
||||
**threshold = capacity * loadFactor**，**当Size>=threshold**的时候，那么就要考虑对数组的扩增了，也就是说，这个的意思就是 **衡量数组是否需要扩增的一个标准**。
|
||||
**threshold = capacity * loadFactor**，**当Size>=threshold**的时候，那么就要考虑对数组的扩增了，也就是说，这个的意思就是 **衡量数组是否需要扩增的一个标准**。
|
||||
|
||||
**Node节点类源码:**
|
||||
```java
|
||||
@ -130,8 +161,8 @@ static final class TreeNode<K,V> extends LinkedHashMap.Entry<K,V> {
|
||||
r = p;
|
||||
}
|
||||
```
|
||||
## <font face="楷体" id="3">HashMap源码分析</font>
|
||||
### <font face="楷体" id="3.1">构造方法</font>
|
||||
## HashMap源码分析
|
||||
### 构造方法
|
||||
|
||||
```java
|
||||
// 默认构造函数。
|
||||
@ -162,7 +193,9 @@ static final class TreeNode<K,V> extends LinkedHashMap.Entry<K,V> {
|
||||
this.threshold = tableSizeFor(initialCapacity);
|
||||
}
|
||||
```
|
||||
putMapEntries方法：
|
||||
|
||||
**putMapEntries方法：**
|
||||
|
||||
```java
|
||||
final void putMapEntries(Map<? extends K, ? extends V> m, boolean evict) {
|
||||
int s = m.size();
|
||||
@ -189,7 +222,7 @@ final void putMapEntries(Map<? extends K, ? extends V> m, boolean evict) {
|
||||
}
|
||||
}
|
||||
```
|
||||
### <font face="楷体" id="3.2">put方法</font>
|
||||
### put方法
|
||||
HashMap只提供了put用于添加元素，putVal方法只是给put方法调用的一个方法，并没有提供给用户使用。
|
||||
```java
|
||||
public V put(K key, V value) {
|
||||
@ -295,7 +328,7 @@ final Node<K,V> getNode(int hash, Object key) {
|
||||
return null;
|
||||
}
|
||||
```
|
||||
### <font face="楷体" id="3.4">resize方法</font>
|
||||
### resize方法
|
||||
进行扩容，会伴随着一次重新hash分配，并且会遍历hash表中所有的元素，是非常耗时的。在编写程序中，要尽量避免resize。
|
||||
```java
|
||||
final Node<K,V>[] resize() {
|
||||
@ -379,7 +412,7 @@ final Node<K,V>[] resize() {
|
||||
return newTab;
|
||||
}
|
||||
```
|
||||
## <font face="楷体" id="4">HashMap常用方法测试</font>
|
||||
## HashMap常用方法测试
|
||||
```java
|
||||
package map;
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user