jdk 1.6 / 1.7 / 1.8 之HashMap & ConcurrentHashMap对比
HashMap
1.6
负载因子默认0.75,默认容量是16
当容量使用占比>=(16*0.75)时，进行扩容（resize(2 * table.length)）
基于数组和链表实现,hash碰撞时，会添加到链表中
key为null时，数据添加到数组索引0的位置
缺点：
1：hash碰撞多较多时，获取数据会变慢
2：hash算法复杂
3：new HashMap时，开辟了内存空间，如果不使用，则浪费内存
1.7
同1.6基本没太大差异，不过改成了懒汉初始化,意味着new HashMap并没有开辟内存空间
容量达到负载阀值时，会扩容（resize(2 * table.length)）
1.8
相比1.7，进一步优化了new HashMap的过程
hash算法改为了XORs算法(x ^ (x>>>16))
扩容算法改为ewThr = oldThr << 1
解决了hash碰撞较多情况下的性能问题(链表长度限制为8，过长时请将链表转换为TreeNode(红黑树))
鉴于hashMap扩容问题，如果确定业务数据大于默认负载时，建议new HashMap时，指定容量，防止扩容时的性能损耗
ConcurrentHashMap
key & value都不允许为null，但是1.6/1.7没做前置检查
1.6
默认容量16，负载因子0.75，并发度16(相当于数据分片),默认构造开辟了内存空间
hash算法难看的一比，懒得去理解什么意思了
基于分片+链表数组结构（分片竟然继承了ReentrantLock，表示无奈）
根据hash值，得到对应的分片，然后将值插入分片中
插入数据时，使用了父类的lock方法(可重入锁)
不得不说ConcurrentHashMap的扩容过程是相当复杂,并且和HashMap一样，碰撞比较多时，影响性能
1.7
相比1.6，无大变化，但是数据存取依赖了UNSAFE
1.8
修正1.6/1.7，put数据时key为null没有前置检查的问题
hash算法采用XORs
丢弃了1.6/1.7中那个并发级别定义(concurrency level)，改用动态分片
分片锁采用synchronized,1.6/1.7都是可重入锁
数据结构构造采用懒汉方法，避免new但不使用的内存浪费情况
分片(链表长度)大8时，采用TreeNode(红黑树)，提高检索效率
最后的建议：如果用Map做缓存使用时，请注意扩容问题，尽量初始化指定大小，防止扩容导致的性能问题
深夜码字，很累，如有错误请指正，不喜勿喷.
