前几天工作忙得焦头烂额时，同事问了一下关于Map的特性，刹那间懵了一下，紧接着就想起来了一些关于Map的一些知识，因为只要涉及到Collection集合类时，就会谈及Map类，因此理解好Map相关的知识是灰常重要的。
Collection集合类 与 Map类的层次结构，如下图：
Map是用来存储 Key-Value（K-V）键值对，且不允许Key重复。（JDK 1.8）
Map的子类包含Hashtable，HashMap，LinkedHashMap，TreeMap，EnumMap，J.U.C并发包下面包含ConcurrentHashMap，ConcurrentSkipListMap。
注：Hashtable是通过“synchronized”来实现同步，ConcurrentHashMap是通过“分段锁”来实现并发，ConcurrentSkipListMap是通过“跳表”来实现并发。
数据结构对比
JDK 1.7及之前，HashMap的底层是数组和链表结合使用，可以说其结构是单向链表构成的数组，即链表散列，又称拉链法，即数组中的每一个序列空间代表一链表，若在插入新元素时，如果哈希冲突，则将新的元素插入到冲突的序列空间的链表头部。
JDK 1.8之后，HashMap的底层是数组链表和二叉树结合使用，其结构是先以链表结构进行存储，如果当链表的节点数（阈值）大于等于8时，再将其转换为二叉树结构，若该二叉树结构的节点数大于64，则再次resize，触发rehash操作，重新分布节点。
JDK 1.7 | 1.8 HashMap 方法分析
1. hashmap在JDK1.7|1.8中hash()方法优化：此处参考博客链接_hashmap冲突的解决方法以及原理分析
其实关于hash优化以及为什么是2的次幂，能理解，但是总归没有辣么详细，所以就参考了其他博主的博客，如果不合适，还请提出，会进行删除的。
2. hashmap在JDK中resize()方法
当HashMap的长度超过临界值时（默认16*0.75=12），就会进行扩容。
通过调用resize()方法重新创建一个原HashMap大小的两倍的元素数组newTable，最大扩容到 MAXIMUM_CAPACITY = 1 << 30，并将原先table的元素全部移到newTable里面，重新计算hash，然后再重新根据hash分配位置。这个过程叫作rehash（最消耗性能的操作），因为它重新调用hash方法找到新的bucket位置。所以创建HashMap的时候，如果能预知元素个数，应尽量指定初始容量，这样可以提高HashMap的性能，避免重复resize()、rehash造成的性能损耗。
若在多线程情况下，多个线程同时出发resize()方法，会造成死循环操作
通过上面的解析，可以得到使用的是2次幂的扩展(指长度扩为原来2倍)，所以，元素的位置要么是在原位置，要么是在原位置再移动2次幂的位置。
因此，我们在扩充HashMap的时候，不需要像JDK1.7的实现那样重新计算hash，通过使用（e.hash & oldCap）来计算高位和低位的hash值，来把原来在一个槽位上面的链表拆分成两个链表即可。
有一点注意区别，JDK1.7中rehash的时候，旧链表迁移新链表的时候，如果在新表的数组索引位置相同，则链表元素会倒置，但是从上图可以看出，JDK1.8不会倒置。
3. hashmap线程不安全，效率高
HashMap线程是不安全的，如果在多线程环境下，会出现未知异常（谨记）。
如果要在多线程情况下使用Map，有以下几种可供选择：
①、使用Hashtable（类中方法全是synchronized，效率特低，没有过这种）；
②、使用Collections.synchronizedMap(new HashMap(…));实现，但不建议使用，使用迭代器遍历的时候修改映射结构容易出错；
③、使用guava中ImmutableMap，它是线程安全的，且方便快捷的组装键值对（建议）；
ImmutableMap<String, Integer> map1 = ImmutableMap.<String, Integer>builder().put(“A”, 1) .put(“B”2) .put(“C”, 3) .build();
ImmutableMap<String, Integer> map2 = ImmutableMap .<String, String>of(“X”, 0);
④、使用java.util.concurrent.ConcurrentHashMap，采用分段锁(JDK1.7) / CAS(JDK1.8)、相对安全，效率高（建议）；
4. hashmap其他方法解析
其他方法后续有时间在进行补充…
JDK 中 HashMap 的其他问题
暂未想到，如有错误，还请指正 …
