通过各类教科书，我们可以总结HashMap和LinkedHashMap的区别：
- LinkedHashMap可保持顺序，HashMap无法保持顺序
- 数据量大、loadFactor比较小的时候，遍历HashMap比LinkedHashMap效率低、耗时
- 查找定位无差别，速度飞快，hash值无冲突的情况下一步到位
实际对大多数应用场景来说，我们只要记住第一个区别就可以了。如果某一场景要求按照存储时的顺序获取数据，那我们一定要记得不能用HashMap，必须用LinkedHashMap。
本着二杆子程序员精神，我们假设你一定想知道所以然。
所以我们还是从两者底层数据结构开始分析。
再次分析两者底层数据结构
现在假设我们把如下数据按顺序分别放入到HashMap和LinkeHashMap中：
hm.put("Li si","45"); /**节点1**/
hm.put("Zhang san","20");/**节点2**/
hm.put("Zhao liu","70");/**节点3**/
hm.put("Wang wu","30");/**节点4**/我们希望用下图来解释HashMap和LinkeHashMap在保存上述数据时的数据结构。当然，我们只是为了说明问题，hash桶是随意分配的，实际分配的hash桶一定不是这样的。
我们假设存入节点1时HashMap得到的hash桶是table[3],所以节点1放置在该桶中。
节点2获得的hash桶是table[1],并假设节点3与节点2的hash值冲突，也放入到table[1]中。节点4放置在table[15]中。
由前两节的分析我们知道，存放数据到LinkedHashMap中与存放数据到HashMap中的算法基本相同，因此其存放到table数组中的位置、也就是获取到的hash桶是相同的。
不同的是LinkedHashMap存放在table数组中的对象是双向链表结构，通过before和after指针记录了上一节点和下一节点，上图简单明了的反应了该结构。
需要注意的是，LinkedHashMap用双向链表结构记录所有的节点，与是否发生hash冲突无关。
HashMap和LinkHashMap对发生hash冲突后的处理方式是一致的：数据会放置在同一个桶中、采用单项链表（next指向下一节点）结构进行记录。
你当然可以这么理解，HashMap（包括LinkedHashMap）的table数组中只保留没有发生hash冲突的数据，发生hash冲突后的数据并没有保存在table数组中，只是通过table数组中的对象可以找到所有的其他冲突对象。
HashMap为啥不能保持顺序
通过上述分析，答案已经显而易见了，我们再啰嗦一下。
第一点是：由于HashMap存储数据的时候是通过数据key值的hash值确定其在table数组中的存储位置，而不是顺序存放在table数组中的，所以存储是没有顺序的。
如果你现在脑海中非要冒出来这样一个问题：那为啥不顺序存放、而非要去哈什么希？
那我只能弱弱的回答一下，HashMap具有快速获取数据的特性...
第二点是：HashMap键值遍历算法是依次遍历table数组，并跳过空桶。
结合以上第一、第二点以及结构图，HashMap不能保持顺序应该是显而易见了。
LinkedHashMap为啥能保持顺序
第一点：LinkedHashMap通过table数组与双向链表的方式保存数据，链表结构保持了存储顺序。
第二点：LinkedHashMap遍历key值得算法是从head开始遍历链表直到tail。所以我们也可以看到，LinkedHashMap不需要遍历空桶，是实打实的遍历，效率更高。
结合第一点、第二点以及结构图，LinkeHashMap遍历key值时能保持顺序也是显而易见的了。
顺便说一句，LinkedHashMap这种table数组加双向列表的结构，能够达到：快速顺序遍历（使用双向链表）、快速定位（通过table数组、hash算法）。
真的是太NB了。
就到这儿了，再深入研究一段时间后，关于HashMap，你就可以吊打面试官了。