Hash表和链表实现Map接口，具有可预测的迭代顺序。该实现与HashMap的不同之处在于它维护了一个贯穿其所有条目的双向链表。该链表定义了迭代顺序，通常是键被插入到映射中的顺序(插入顺序)。注意，如果密钥被重新插入到映射中，插入顺序不会受到影响。当m . includekey ( k )在调用之前立即返回true时调用(如果m . put ( k , v ) ,则密钥k被重新插入到映射m中)。)
这种实现使其客户端免受HashMap (和Hashtable )提供的不特定的、通常是混沌的排序的影响，而不会增加与树图相关的成本。它可以用来制作与原图顺序相同的地图副本，而不管原图的实现方式如何：void foo(Map m) {
Map copy = new LinkedHashMap(m);
...
}这种技术特别有用，如果一个模块在输入上取一个映射，复制它，然后返回由复制的顺序决定的结果。(客户一般赞赏以相同的顺序返回的东西。)
提供了一个特殊的构造函数来创建一个链接哈希映射，其迭代的顺序是它的条目最后被访问的顺序，从最近访问到最近访问( access-order )。这种映射非常适合构建LRU缓存。调用put、putIfAbsent、get、getOrDefault、计算、计算IfAbsent、计算IfPresent或合并方法得到对应条目的访问(假设它在调用完成后存在)。替换方法仅在值被替换的情况下导致条目的访问。putAll方法为指定地图中的每个映射生成一个入口访问，顺序为键值映射由指定地图的入口集合迭代器提供。没有其他方法。可以重写 removeEldestEntry（Map.Entry） 方法，以强加在将新映射添加到映射时自动删除过时映射的策略。
此类提供所有可选的 Map 操作，并允许空元素。与 HashMap 一样，它为基本操作（添加、包含和删除）提供恒定时间性能，假设哈希函数在存储桶之间正确分散元素。由于维护链表的额外费用，性能可能略低于HashMap，但有一个例外：对LinkedHashMap的集合视图进行迭代需要与地图大小成正比的时间，无论其容量如何。在HashMap上进行迭代可能会更昂贵，需要与其容量成正比的时间。链接的哈希映射有两个影响其性能的参数：初始容量和负载系数。它们的定义与HashMap精确。但请注意，对于此类，为初始容量选择过高值的惩罚不如 HashMap 严重，因为此类的迭代时间不受容量的影响。
请注意，此实现不同步。如果多个线程同时访问链接的哈希映射，并且至少有一个线程在结构上修改了映射，则必须在外部同步该映射。这通常是通过在自然封装地图的某些对象上进行同步来实现的。如果不存在这样的对象，则应使用 Collections.syncdMap 方法“包装”映射。最好在创建时执行此操作，以防止意外不同步访问map：Map m = Collections.synchronizedMap(new LinkedHashMap(...));
结构修改是添加或删除一个或多个映射的任何操作，或者在访问顺序链接哈希映射的情况下，影响迭代顺序。在插入顺序链接哈希映射中，仅更改与映射中已包含的键关联的值不是结构修改。在访问顺序链接哈希映射中，仅使用 get 查询映射是一种结构修改。)
由迭代器方法返回的迭代器返回的所有此类集合视图方法返回的迭代器是快速失败的：如果在创建迭代器后的任何时间对映射进行结构修改，则除了通过迭代器自己的 remove 方法之外，迭代器将抛出 ConcurrentModificationException。因此，面对并发修改，迭代器会快速而干净地失败，而不是冒着在未来不确定的时间出现任意、非确定性行为的风险。请注意，无法保证迭代器的快速故障行为，因为一般来说，在存在不同步的并发修改的情况下，不可能做出任何硬保证。Fail-fast 迭代器会尽最大努力抛出 ConcurrentModificationException。因此，编写一个依赖于此异常的正确性的程序是错误的：迭代器的快速故障行为应仅用于检测错误。
由此类的所有集合视图方法返回的集合的拆分器方法返回的拆分器是后期绑定的、快速失败的，并且还报告 Spliterator.ORDERED。
此类是 Java 集合框架的成员。
LikedeHashMap是继承HashMap,这里只讲述，LikedeHashMap维护了一个Entry的双向链表，保证Entry的顺序，可以理解为有序的HashMap. LikedeHashMap存放不是存放在数组里面的了，是存放在一个双向链表，当发生哈希冲突就会直接放在最后一个位置这样做解决了无序的问题，完美的继承了双向链表的特性，查询速度变慢。