可以毫不夸张的说，HashMap是容器类中用的最频繁的一个，而Java也对它进行优化，在jdk1.7及以前，当将相同Hash值的对象以key的身份放到HashMap中，HashMap的性能将由O(1)下降到O(N)，所以jdk1.8将相同Hash值的key以红黑树的形式进行存储。
一、简单理解
1.1 初始容量的设计
给我的感受是，给用户*，但是要在限定的范围内。
首先介绍初始容量是什么，引用Java API中的介绍：
HashMap 的实例有两个参数影响其性能：初始容量 和加载因子。容量 是哈希表中桶的数量，初始容量只是哈希表在创建时的容量。加载因子 是哈希表在其容量自动增加之前可以达到多满的一种尺度。当哈希表中的条目数超出了加载因子与当前容量的乘积时，则要对该哈希表进行 rehash 操作（即重建内部数据结构），从而哈希表将具有大约两倍的桶数。
也就是说，我们可以有远见知道HashMap中将要存入多少数据，而相应的设置初始容量，减少rehash的次数，因为每次rehash将会对HashMap进行一次重构，影响性能，因此HashMap的构造方法中提供了对初始容量的设置：
HashMap(int initialCapacity) ：构造一个带指定初始容量和默认加载因子 (0.75) 的空 HashMap。
HashMap(int initialCapacity, float loadFactor) ：构造一个带指定初始容量和加载因子的空 HashMap。
但是HashMap在设计的时候，已经考虑到要rehash，以及根据Hash值在固定数量的桶中查询数据，加上对数字的移位运算最高效，所以桶的数量被设计为2的几次方，但是用户输入初始容量是任意的，HashMap是怎么处理的呢？它是取比输入值-1大的且最近的2的几次方的值：
static final int tableSizeFor(int cap) {
int n = cap - 1;
n |= n >>> 1;
n |= n >>> 2;
n |= n >>> 4;
n |= n >>> 8;
n |= n >>> 16;
return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;
}
也就是说最终初始容量不一定安装你输入的来，就像一开始说的那样，HashMap给你一定的*，但是不是绝对的*。
以后写代码也可以这么做，当一个重要属性可能影响效率时，不能给使用者太大的*度，不然用起来慢就不好了。
1.2 列表转树的条件
首先简单说明下列表和红黑树，对它们有了基本的认识后才能知道为什么决定将列表转成红黑树：
- 所占空间：红黑树>列表
- 性能：红黑树>列表，但是当元素数量特别少时，列表的性能还是大于红黑树的
也就是，有一个阈值，当超过阈值时才会将列表转换成红黑树，为了提高性能HashMap还是考虑的很多的，主要有三个属性涉及到列表和红黑树转换：
static final int TREEIFY_THRESHOLD = 8;
static final int UNTREEIFY_THRESHOLD = 6;
static final int MIN_TREEIFY_CAPACITY = 64
TREEIFY_THRESHOLD ：当一个节点的数量大于此数量的时候，将会将此节点列表转换成一个树。
UNTREEIFY_THRESHOLD ：当已经是一个树的节点，在移除元素的时候，如果移除后小于这个值，则将树转换成列表。
MIN_TREEIFY_CAPACITY ：当一个节点准备转换成树之前，如果HashMap桶的数量小于此，则不进行转换，而是将HashMap进行扩容。
也就是说为了一个优化，相当于将HashMap一半的代码进行了重新，为了提升当元素都放置到一个桶时性能的下降。但是对于用户来说是透明的，用户在使用上完全感受不到变化，所以说优化是没有终点的，这一点我还是挺佩服他们的。
1.3 元素的大小比较
之前讲TreeMap的时候说过，放入TreeMap的key必须具备可比较性，要么本身实现Comparable接口，要么传入key的比较器，因为如果key不能比较大小，就没办法构建一棵树。而我们在放入HashMap的key时，却没有对此有要求，它是怎么实现的呢。
首先判断key的类型是否是Comparable，如果是，就通过自身的比较方法进行比较。
如果key不是Comparable，那么就通过key本身的Hash值进行比较，即便子类重写了hashCode方法，也会用最原始的，实际上是用了System的一个方法：
System.identityHashCode(Object x)
这个方法，返回给定对象的哈希码，该代码与默认的方法 hashCode() 返回的代码一样，无论给定对象的类是否重写 hashCode()。
也就是说最终总是能比较出大小，当然如果还一样，说明key是一样的，覆盖即可。
其中判断key的类型是否是Comparable中有一段代码如下：
static Class<?> comparableClassFor(Object x) {
if (x instanceof Comparable) {
Class<?> c; Type[] ts, as; Type t; ParameterizedType p;
if ((c = x.getClass()) == String.class) // bypass checks
return c;
if ((ts = c.getGenericInterfaces()) != null) {
for (int i = 0; i < ts.length; ++i) {
if (((t = ts[i]) instanceof ParameterizedType) &&
((p = (ParameterizedType)t).getRawType() ==
Comparable.class) &&
(as = p.getActualTypeArguments()) != null &&
as.length == 1 && as[0] == c) // type arg is c
return c;
}
}
}
return null;
}
说实话我一开始没有想到会这么复杂，后来我认真研究了一下发现一个类即便实现了Comparable接口，也有可能比较的是其他类：
class Dog implements Comparable<Object>{
public String name;
public Dog(String name) {
this.name = name;
}
@Override
public int compareTo(Object o) {
// TODO Auto-generated method stub
return 0;
}
}
没想到判断的这么严谨，因为印象中很少有类实现Comparable接口，而不去比较自己的，简单总结它的逻辑：
- 首先是一个Comparable
- Comparable必须是一个参数化类型，就是说指定比较类型
- 参数化有一个参数，且是它本身
看完这部分，我想了想TreeMap为什么没有借鉴HashMap的这种方式，而必须让key具有比较性，原因其实很简单，HashMap的作用就是存储快速读取，而TreeMap的额外多了个目的就是排序，如果一个key不具备可比较性，而最终使用了最原始的hashCode，那排序就没有了意义，还不如使用更高效的HashMap呢。
二、问题及总结
HashMap做为最常用的容器类，Java已经封装的足够好了，而我们使用的时候如果能做到以下两点也就能最大化的提高HashMap的性能：
- 自定义对象做为key时，重写hashCode和equals方法
- 如果能预见存入HashMap元素的数量，在初始化的时候指定
其它暂时没有遇到什么问题。