之前谈到了HashMap的存和取,这次来聊一下它的调优,以及多线程下的不用HashMap转用ConcurrentHashMap的一点浅析
重述HashMap工作原理:
- HashMap是基于hash原理,我们使用put()存储对象,使用get()获取对象
- 当我们给put方法传键值时,他会先调用hashCode方法,用于查找键值在 bucket的位置,进而存储对象的键值对
- 当两个对象的hashCode相同,在存储时候就会发生碰撞,原因就是HashMap采取集成Map和链表的存储方式,继而调用equals比较,没有就存进去,有就把之前的替换掉
HashMap调优:
先贴出HashMap源码普及一下几个概念:
public class HashMap<K,V>extends AbstractMap<K,V>implements Map<K,V>, 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<K,V> 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<K,V> 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;
}
多线程下的HashTable的缺点:
HashTable使用synchronized来保证线程安全,但是在线程竞争激烈的情况下,当一个线程访问同步方法的时候,其余的线程会被阻塞或者轮询状态,就这样干等着,啥也干不了,效率低的不行
多线程下的选择ConcurrentHashMap:
ConcurrentHashMap 采取锁分段技术,将数据分成一段一段地存储,然后把每一段数据配置一把锁,当一个线程占用锁访问其中的一段数据的时候,其他的断的数据也能被其他线程访问
以上是针对HashMap 的分析,关于ConcurrentHashMap 等多线程的部分 请见下回分解