设计思路
此实现假定哈希函数将元素正确分布在各桶之间，可为基本操作（get和put）提供稳定的性能。迭代集合视图所需的时间与HashMap实例的“容量”（桶的数量）及其大小（键-值映射关系数）的和成比例。所以，如果迭代性能很重要，则不要将初始容量设置得太高（或将加载因子设置得太低）。HashMap的实例有两个参数影响其性能：初始容量和加载因子。容量是哈希表中桶的数量，初始容量只是哈希表在创建时的容量。加载因子是哈希表在其容量自动增加之前可以达到多满的一种尺度。当哈希表中的条目数超出了加载因子与当前容量的乘积时，通过调用rehash方法将容量翻倍。
通常，默认加载因子(.75)在时间和空间成本上寻求一种折衷。加载因子过高虽然减少了空间开销，但同时也增加了查询成本（在大多数HashMap类的操作中，包括get和put操作，都反映了这一点）。在设置初始容量时应该考虑到映射中所需的条目数及其加载因子，以便最大限度地降低rehash操作次数。如果初始容量大于最大条目数除以加载因子，则不会发生rehash操作。
如果很多映射关系要存储在HashMap实例中，则相对于按需执行自动的rehash操作以增大表的容量来说，使用足够大的初始容量创建它将使得映射关系能更有效地存储。注意，此实现不是同步的。如果多个线程同时访问此映射，而其中至少一个线程从结构上修改了该映射，则它必须保持外部同步。（结构上的修改是指添加或删除一个或多个映射关系的操作；仅改变与实例已经包含的键关联的值不是结构上的修改。）这一般通过对自然封装该映射的对象进行同步操作来完成。如果不存在这样的对象，则应该使用Collections.synchronizedMap方法来“包装”该映射。最好在创建时完成这一操作，以防止对映射进行意外的不同步访问。
因此，面对并发的修改，迭代器很快就会完全失败，而不冒在将来不确定的时间任意发生不确定行为的风险。注意，迭代器的快速失败行为不能得到保证，一般来说，存在不同步的并发修改时，不可能作出任何坚决的保证。快速失败迭代器尽最大努力抛出。编写依赖于此异常程序的方式是错误的，正确做法是：迭代器的快速失败行为应该仅用于检测程序错误。
重写原则
不必对每个不同的对象都产生一个唯一的hashcode，只要你的HashCode方法使get()能够得到put()放进去的内容就可以了。即"不唯一原则"。生成hashcode的算法尽量使hashcode的值分散一些，不要很多hashcode都集中在一个范围内，这样有利于提高HashMap的性能。即"分散原则"。
至于第二条原则的具体原因，有兴趣者可以参考BruceEckel的《ThinkinginJava》，在那里有对HashMap内部实现原理的介绍。
分析
在Java的世界里，无论类还是各种数据，其结构的处理是整个程序的逻辑以及性能的关键。
其实一个HashMap的实际容量就因子*容量，其默认值是16×0.75=12；这个很重要，对效率很一定影响！当存入HashMap的对象超过这个容量时，HashMap就会重新构造存取表。
两个关键的方法，put和get：先有这样一个概念，HashMap是声明了Map，Cloneable,Serializable接口，和继承了AbstractMap类，里面的Iterator其实主要都是其内部类HashIterator和其他几个iterator类实现，当然还有一个很重要的继承了Map.Entry的Entry内部类。
这个就是判断键值是否为空，并不很深奥，其实如果为空，它会返回一个staticObject作为键值，这就是为什么HashMap允许空键值的原因。因为hash的算法有可能令不同的键值有相同的hash码并有相同的table索引，如：key=“33”和key=Objectg的hash都是－8901334，那它经过indexfor之后的索引一定都为i，这样在new的时候这个Entry的next就会指向这个原本的table[i]，再有下一个也如此，形成一个链表，和put的循环对定e.next获得旧的值。
