HashMap调优和ConcurrentHashMap分析

之前谈到了HashMap的存和取，这次来聊一下它的调优，以及多线程下的不用HashMap转用ConcurrentHashMap的一点浅析

重述HashMap工作原理：

• HashMap是基于hash原理，我们使用put()存储对象，使用get()获取对象
• 当我们给put方法传键值时，他会先调用hashCode方法，用于查找键值在 bucket的位置，进而存储对象的键值对
• 当两个对象的hashCode相同，在存储时候就会发生碰撞，原因就是HashMap采取集成Map和链表的存储方式，继而调用equals比较，没有就存进去，有就把之前的替换掉

HashMap调优：

先贴出HashMap源码普及一下几个概念：

public class HashMapextends AbstractMapimplements Map, Cloneable, Serializable
{
    //  默认的初始容量（容量为HashMap中桶的数目）是16，且实际容量必须是2的整数次幂。 
    static final int DEFAULT_INITIAL_CAPACITY = 16;

    // 最大容量（必须是2的幂且小于2的30次方，传入容量过大将被这个值替换）
    static final int MAXIMUM_CAPACITY = 1 << 30;

    // 默认加载因子
    static final float DEFAULT_LOAD_FACTOR = 0.75f;

    // 存储数据的Entry数组，长度是2的幂。
    // HashMap是采用拉链法实现的，每一个Entry本质上是一个单向链表
    transient Entry[] table;

    // HashMap的大小，它是HashMap保存的键值对的数量
    transient int size;

    // HashMap的阈值，用于判断是否需要调整HashMap的容量（threshold = 容量*加载因子）
    int threshold;

    // 加载因子实际大小
    final float loadFactor;

    // HashMap被改变的次数
    transient volatile int modCount;

通过以上源码可以看到在源码中定义了一下几个常量：

• 默认加载因子：这东西说白了就是用来划分整个HashMap容量的百分比，这里默认0.75就是说占用总容量的75%
• 默认初始容量：如果你不在构造函数中传值，new一个HashMap,他的容量就是2的4次方（16），并且增长也得是2的整数次方（幂）
• 阀值：首先这个值等于默认加载因子和初始容量的乘机；他的作用是用来预警的，如果HashMap中的容量超过这个阀值了，那就会执行扩容操作，低于则没事

容量调优：

如果你要在HashMap中存20个元素，他默认只有16 当你存储到13时候就会执行扩容（rehashing）这个是很费资源的操作，并且还会出现死循环，建议你在知道你要存储的容量的时候，直接这样定义：

 

Map mapBest = new HashMap((int) ((float) 拟存的元素个数 / 0.75F + 1.0F));

这样一次到位，虽然存在些资源浪费，但是比起重新扩容还是效率高很多

减小负载因子：

• 首先这个负载因子不建议定义成比0.75 大了，因为如果等到没有空间了再分配可能抛出error
• 但是也不建议吧负载因子调的过低，造成资源大面积浪费
• 在构造函数里，设定加载因子是0.5甚至0.25。如果你的Map是一个长期存在而不是每次动态生成的，而里面的key又是没法预估的，那可以适当加大初始大小，同时减少加载因子，降低冲突的机率。毕竟如果是长期存在的map，浪费点数组大小不算啥，降低冲突概率，减少比较的次数更重要。

优化Key设计：

看一下获取key对应value的源码

    // 获取key对应的value
    public V get(Object key) {
        if (key == null)
            return getForNullKey();
        // 获取key的hash值
        int hash = hash(key.hashCode());
        // 在“该hash值对应的链表”上查找“键值等于key”的元素
        for (Entry e = table[indexFor(hash, table.length)];
             e != null;
             e = e.next) {
            Object k;
            if (e.hash == hash && ((k = e.key) == key || key.equals(k)))
                return e.value;
        }
        return null;
    }

由源码可知，如果hashCode 不冲突，那查找效率很高，但是如果hashCode一旦冲突，叫调用equals一个字节一个自己的去比较

• 所以你把key设计的尽量短，一旦冲突也会少用点时间
• 建议采用String,Integer 这样的类作为键，原因如下：

特别是String，他是不可变的，也是final的，而且已经重写了equals 和hashCode 方法，这个和HashMap 要求的计算hashCode的不可变性要求不谋而合，核心思想就是保证键值的唯一性，不变性，

其次是不可变性还有诸如线程安全的问题，以上这么定义键，可以最大限度的减少碰撞的出现

Hash攻击：

HashMap中当调用HashCode 方法时，如果值相同就会存在碰撞，攻击者利用不同输入会产生相同HashCode 的漏洞进行缓慢攻击，等到碰撞得到一定程度，cpu会拿出打分开销开处理碰撞，这时候服务可能宕机 这就是Hash攻击

具体的例如String 转Json就用到了HashMap ，但是这个情况 在Java8中有锁改善

多线程下的选择：

HashMap 缺点：

看下HashMap put方法的源码：

// 将“key-value”添加到HashMap中
    public V put(K key, V value) {
        // 若“key为null”，则将该键值对添加到table[0]中。
        if (key == null)
            return putForNullKey(value);
        // 若“key不为null”，则计算该key的哈希值，然后将其添加到该哈希值对应的链表中。
        int hash = hash(key.hashCode());
        int i = indexFor(hash, table.length);
        for (Entry e = table[i]; e != null; e = e.next) {
            Object k;
            // 若“该key”对应的键值对已经存在，则用新的value取代旧的value。然后退出！
            if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
                V oldValue = e.value;
                e.value = value;
                e.recordAccess(this);
                return oldValue;
            }
        }
        // 若“该key”对应的键值对不存在，则将“key-value”添加到table中
        modCount++;
        addEntry(hash, key, value, i);
        return null;
    }

HashMap 在并发执行put操作的时候会引起死循环，是因为多线程会导致hashMap的Entry 链表形成唤醒数据结构，一旦形成唤醒的数据结构，Entry的next节点永远不为空，就会产生死循环获取Entry

多线程下的HashTable的缺点：

HashTable使用synchronized来保证线程安全，但是在线程竞争激烈的情况下，当一个线程访问同步方法的时候，其余的线程会被阻塞或者轮询状态，就这样干等着，啥也干不了，效率低的不行

多线程下的选择ConcurrentHashMap：

ConcurrentHashMap 采取锁分段技术，将数据分成一段一段地存储，然后把每一段数据配置一把锁，当一个线程占用锁访问其中的一段数据的时候，其他的断的数据也能被其他线程访问

以上是针对HashMap 的分析，关于ConcurrentHashMap  等多线程的部分 请见下回分解