我的苹果分析法

1.苹果--hashmap

2.外观：形状、颜色、大小、构造--实现了哪些接口，接口的用法，应用场景

3.内在：切开后是什么样子，心长什么样--内部构造，用到哪些数据结构，算法

4.口感：吃起来甜不甜，脆不脆--导出接口的时间空间复杂度，执行起来快不快

5.好处：an Apple a day ，keep doctor away--使用这个类的优点，为什么使用

6.时机：适合什么时候吃，腹泻的时候不能吃？---应用场景，任何事物都有适合自己生存的最优环境

7.优化：什么原因造成苹果现在的口感，可以让苹果更甜更脆吗？---这个类的功能还有没有优化空间

8.同类：苹果种类也非常多，以上各个维度其他苹果又是怎么样的？---hashmap也有几个兄弟类，有什么特点，优点，又适合哪些场景

 

hashMap实现的是map接口，基本上实现了对map中元素的增、删、改、查接口

hashMap内部使用hash table作为存储元素的数据结构，所谓hash table 也是基于数组的一个数据结构，新增的k-v键值对元素通过对k取hash值映射到hash table中，对应的存储单元也叫作buckets，若有重复的元素则以链表的形式存储在这个bucket。对于元素的put/get,基本可以达到O(1)的时间复杂度（元素hash值需要能够均匀分布在hash table bucket中）（什么hash算法能够产生较均匀的hash）。对于存储在里面的元素，不保证有序。迭代的性能与初始capacity相关，所以capacity应设置一个合适的值。影响hashmap性能的两个重要因素是initial capacity和load factor ，capacity表示hash table中buckets数量，initial capacity* load factor 是衡量hashmap中承载元素数量的指标。capacity值会根据当前元素数量自动扩增，当元素数量超过capacity* load factor 时扩容至capacity*2（每次扩容为原来2倍），直至Integer.MAXVALUE。扩增后原来的元素也就根据新的hash table 重新映射到新的buckets（耗性能的地方）。hashmap使用0.75作为默认的负载因子（基于时间、空间复杂度得出的一个折中值），较高的负载因子能够减少空间消耗，但同时也会提高查询消耗（为什么会提高查询消耗？），使用时可以预测元素数量设置capacity值，从而减少rehash的次数，如果初始capacity大于最大entry数除以负载因子，则不会产生rehash操作。如果hashmap实例中存储的键值对量比较大，创建实例时使用足够大的capacity会使hashmap的性能 比他自己rehash来增加hash表数量的要好。

put---O(1)

remove---O(1)

get---O(1)

适用于存储k-v关系的值，对元素顺序要求不高，需要快速存取的场景

优化方向：hash值更均匀，rehash次数减少，没有自动缩容？

TreeMap/LinkedHashMap