HashMap

最新推荐文章于 2025-06-03 19:06:05 发布

翻译最新推荐文章于 2025-06-03 19:06:05 发布 · 777 阅读

文章标签：

#hashmap

编程技术专栏收录该内容

19 篇文章

订阅专栏

HashMap是基于哈希表算法对Map接口的一种实现。它提供了所有的Map的操作，并且不允许有空键和空值。（除去非同步和不允许空，HashMap类和Hastable基本上是等同的）。此类并不能保证内部元素的顺序，特别是，随着时间变化，它不能保证元素的顺序是一成不变的。

假定哈希函数准确的把元素散列到了桶中，那么HashMap的基本操作（get和put)在性能上是常量级的（时间复杂度是O(1)）。在HashMap上迭代遍历操作的时间和实例的容量（桶的数量）以及大小（键值对的数量）有关系。因此，如果你比较看重迭代遍历的性能，那么初始的容量就不要设置的太大（或者装载因子不能太小）。

有两个参数会影响HashMap的性能:初始的容量和装载因子。容量就是在哈希表里面当前桶的数量，而初始容量就是哈希表在刚刚创建的时桶的数量。而装载因子就是决定哈希表在容量自动增长之前可以允许有多满的一个测量因子。当哈希表里的数据个数超过了当前容量和装载因子的乘积，哈希表就会被再哈希（内部的数据结构会重新组建一遍），哈希表的桶数量会增加到两倍。

以下是节选的HashMap的源码，可以看到在扩容的时候，用到了移位操作，变成原来的两倍大小。

    else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
        oldCap >= DEFAULT_INITIAL_CAPACITY)
    newThr = oldThr << 1; // double threshold

有一个普遍的规律，那就是装载因子是0.75的时候，刚好达到了时间和空间上消耗平衡。更高的值可以减少空间的消耗但是也会增加查找的成本（这会影响大部分的Hashmap操作，包括get和put）。如果要减少再哈希操作的次数，当你设定初始化容量的时候一定也要考虑可能的存放元素数目和装载因子。如果：
$初始化容量> 存储元素的最大数量/装载因子$
再哈希的操作将不会发生。

如果一个HashMap要存储很多数据，创建时给它足够大的容量能够有效的存储元素，而不需要HashMap自动再哈希，自动增长表。请注意，如果很多键都有相同的hashCode()一定会降低任何哈希表的性能。为了改善这种影响，当key是可比较的时候（实现了Comparable接口），Hashmap会用键值的比较顺序来帮助打破这种僵局（hashCode相同的僵局）

注意，Hashmap的实现方式不是同步的，如果多个线程同时访问一个Hashmap并且至少有一个线程从结构上修改它，那么Hashmap必有在外部强制声明成同步的。（结构上修改指的是任何添加或者删除一个多个元素的操作，仅仅改变一个已经存在的键所对应的值不算结构上的修改）。看下面的例子：

import java.util.HashMap;
/**
 * Created by sli on 12/9/2016.
 */
public class HashMapTest {
    public static void main(String[] args) {
        HashMap<String, String> hashMap = new HashMap<>();
        for (int i = 0; i < 8; i++) {
            hashMap.put("Key "+i, "HashMap Test Value"+i);
        }
        //线程1只读只看操作
        Thread thread1 = new Thread(() -> {
            for (String key : hashMap.keySet()
                    ) {
                System.out.println("Thread 1 access hash map->" + key + ":" + hashMap.get(key));
            }
        });

        //线程2只读只看操作
        Thread thread2 = new Thread(() -> {
            for (String key : hashMap.keySet()
                    ) {
                System.out.println("Thread 2 access hash map->" + key + ":" + hashMap.get(key));

            }

        });
        //线程3改变结构
        Thread thread3 = new Thread(() -> {
            for (int i=8;i<16;i++) {
                System.out.println("Thread 3 put Key"+i);
                hashMap.put("Key "+i, "HashMap Test Value"+i);
            }
        });

        thread1.start();
        thread2.start();
        thread3.start();
    }
}

示例中我们用了三个线程，两个是只读操作，第三个线程改变了结构，运行时就会报错：

Exception in thread "Thread-0" Exception in thread "Thread-1" java.util.ConcurrentModificationException
    at java.util.HashMap$HashIterator.nextNode(HashMap.java:1437)
    at java.util.HashMap$KeyIterator.next(HashMap.java:1461)
    at Test.lambda$main$1(Test.java:28)
    at java.lang.Thread.run(Thread.java:745)
java.util.ConcurrentModificationException
    at java.util.HashMap$HashIterator.nextNode(HashMap.java:1437)
    at java.util.HashMap$KeyIterator.next(HashMap.java:1461)
    at Test.lambda$main$0(Test.java:18)
    at java.lang.Thread.run(Thread.java:745)

一般情况下，只要同步自然包装了这个Map的一些对象就可以了。如果这样的对象不存在，那么我们需要使用 Collections.synchronizedMap方法来同步。最好是在创建的时候就处理，以防止意外的非同步访问：

Map m = Collections.synchronizedMap(new HashMap(...));

上面这个方法好像也不灵，测试了一下还是报错，具体原因还要调查。

Hashmap的所有集合查看方法（集合查看方法：keySet,values,entrySet）返回的迭代都是fail-fast模式的。什么是fail-fast:当迭代创建后的任何时间里任何方式Map的结构变了，迭代都会抛出 ConcurrentModificationException异常（如果迭代只是自己调用了remove,不会有异常）。因此，一旦碰到并发改动，迭代就快速干脆的失败报错了，而不是把这种不定的风险，无法预料的行为留在未知后期。