映射表原理分析与总结

在使用本地缓存时，经常用到映射表，大家都知道映射表保存数据的原理是将key做hash再取余，余数落在数组的不同索引中；利用数组的索引获取元素，时间复杂度为O(1) 。

这样查询速度很快了，但是也存在一个问题，那就是如果两个key落到同一个索引桶上时，这就叫key碰撞，细想下每个key落在一个固定数组索引上的概率是一样的，既理论上无法避免key碰撞，只能一定程度上的减少碰撞概率；最简单那的解决key碰撞的方式是采用链表法，hashMap及concurrentHashMap都是采用这样做的。

随着放入集合中的元素越来越多，key的碰撞就越来越严重，为了解决这个问题，使集合适应不同级别数量的元素，集合还有一个reSize、rehash的动作；这个动作的触发时机就是集合的使用率达到某个阀值；比如hashMap当集合的使用率达到0.75时，如果新插入的元素发生了key碰撞了，就触发集合扩容，容器的大小扩大为当前的2倍，扩容的做法其实就是，新建一个数组，将当前元素从新hash到这个新数组中。

在使用hashMap或者concurrentHashMap时候，总是会担心当元素达到一定数量级后，由于key的碰撞问题，导致新能急剧下降，其实这是多余，为了证明这个观点，我做了如下实验，就是在concurrentHashMap中，当元素在不同数量级上时，key碰撞情况的统计：

数据结构：

容器使用：ConcurrentHashMap<key,Value>()

key={两位随机数字}:{两位随机数字}:{20为随机数字或字母} + {i}

value={30为随机数字或字母}+ {i}

1) 1万数据(i=[0,1万])碰撞情况：

元素总数=10000

碰撞槽总数=2041

碰撞元素总数=4536

碰撞元素总数/碰撞槽总数=2.22244

碰撞元素总数/元素总数=0.453

2) 10万数据(i=[0,10万])碰撞情况：

元素总数=100000

碰撞槽总数=15373

碰撞元素总数=32982

碰撞元素总数/碰撞槽总数=2.1454499

碰撞元素总数/元素总数=0.329

3) 50万数据(i=[0,50万])碰撞情况：

元素总数=500000

碰撞槽总数=87212

碰撞元素总数=189299

碰撞元素总数/碰撞槽总数=2.1705613

碰撞元素总数/元素总数=0.378

4) 100万数据（(i=[0,100万])）碰撞情况：

元素总数=1000000

碰撞槽总数=175152

碰撞元素总数=380070

碰撞元素总数/碰撞槽总数=2.1699438

碰撞元素总数/元素总数=0.38

结论：不管map的数据量多少，碰撞了槽内的元素基本相同