我是廖志伟，一名Java开发工程师、幕后大佬社区创始人、Java领域优质创作者、CSDN博客专家。拥有多年一线研发经验，研究过各种常见框架及中间件的底层源码，对于大型分布式、微服务、三高架构（高性能、高并发、高可用）有过实践架构经验。
@TOC
本文的大概内容：
HashMap优化使用
- 不能用==判断或者可能有哈希冲突时，尽量减少长度，一旦冲突也会少用点时间。如果hashCode 不冲突，那查找效率很高，但是如果hashCode一旦冲突，要调用equals一个字节一个自己的去比较，key越短效率越高。
- 建议采用String，Integer这样的类作为键。特别是String，他是不可变的，也是final的，而且已经重写了equals 和hashCode方法，这个和HashMap 要求的计算hashCode的不可变性要求不谋而合，核心思想就是保证键值的唯一性，不变性，其次是不可变性还有诸如线程安全的问题，以上这么定义键，可以最大限度的减少碰撞的出现。
- 迭代器遍历Map，在各个数量级效率稳定且较高，一般采用Iterator迭代器遍历Map。数据量为10000以下时，迭代器遍历entrySet，迭代器遍历keySet()后map.get(key)，for循环遍历keySet()后Map.get(key)这三种遍历方式效率较高，数据量为10000以上时，for循环遍历entrySet，迭代器遍历entrySet这二种方式效率较高。
- concurrentHashMap或迭代器Iterator遍历删除，当遍历Map需要删除的时候，不可以for循环遍历，否则会产生并发修改异常CME，只能使用迭代器iterator.remove()来删除元素，或者使用线程安全的concurrentHashMap来删除Map中的元素。
- 考虑加载因子地设定初始大小，设定时一定要考虑加载因子的存在。使用的时候最好估算存储的大小，如果初始桶为16，等到满16个元素才扩容，某些桶里可能就有不止一个元素了。所以加载因子默认为0.75，也就是说大小为16的HashMap，到了第13个元素，就会扩容成32。Guava的做法则是加上如下计算
(int) ((float) expectedSize / 0.75F 1.0F); - 减小加载因子，如果你的Map是一个长期存在而不是每次动态生成的，而里面的key又是没法预估的，那可以适当加大初始大小，同时减少加载因子，降低冲突的机率。毕竟如果是长期存在的map，浪费点数组大小不算啥，降低冲突概率，减少比较的次数更重要。
- 使用IntObjectHashMap，HashMap的结构是 Node[] table; Node 下面有Hash，Key，Value，Next四个属性。而IntObjectHashMap的结构是int[] keys 和 Object[] values。在插入时，同样把int先取模落桶，如果遇到冲突，则不采样HashMap的链地址法，而是用开放地址法（线性探测法）index＋1找下一个空桶，最后在keys[index]，values[index]中分别记录。在查找时也是先落桶，然后在key[index ]中逐个比较key。所以，对比整个数据结构，省的不止是int vs Integer，还有每个Node的内容。性能IntObjectHashMap还是稳赢一点的，随便测了几种场景，耗时至少都有24ms vs 28ms的样子，好的时候甚至快1/3。
总结
以上就是今天要讲的内容，还希望各位读者大大能够在评论区积极参与讨论，给文章提出一些宝贵的意见或者建议，合理的内容，我会采纳更新博文，重新分享给大家。
给读者大大的话
我本身是一个很普通的程序员，放在人堆里，除了与生俱来的盛世美颜、所剩不多的发量，就剩下180的大高个了。就是我这样的一个人，默默坚持写博文也有好多年了，有句老话说的好，牛逼之前都是傻逼式的坚持。希望自己可以通过大量的作品，时间的积累，个人魅力、运气和时机，可以打造属于自己的技术影响力。同时也希望自己可以成为一个懂技术，懂业务，懂管理的综合型人才，作为项目架构路线的总设计师，掌控全局的团队大脑，技术团队中的绝对核心是我未来几年不断前进的目标。
