HashMap、Hashtable、ConcurrentHashMap、LinkedHashMap 数据结构及原理

最新推荐文章于 2025-04-18 09:04:27 发布

时光不负追梦人

最新推荐文章于 2025-04-18 09:04:27 发布

阅读量752

点赞数 1

文章标签： java 数据结构链表

本文链接：https://blog.youkuaiyun.com/qq1344691727/article/details/107934344

版权

本文深入探讨Java中Map接口的不同实现，包括HashMap、Hashtable、LinkedHashMap和TreeMap的特点和使用场景，详细分析了红黑树、哈希冲突解决、线程安全等问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Map

HashMap Hashtable treeMap区别

HashMap怎么put(key, value)?

HashMap怎么get(key)?

Hashmap扩容时机

HashMap扩容

HashMap初始容量为什么是2的n次幂及扩容为什么是2倍的形式

重新调整HashMap大小存在什么问题?

为什么String, Interger这样的wrapper(包装)类适合作为键

HashMap总结

ConcurrentHashMap

ConcurrentHashMap数据结构

ConcurrentHashMap的初始化

ConcurrentHashMap线程安全

ConcurrentHashMap的锁分段技术

定位Segment

ConcurrentHashMap的get操作

ConcurrentHashMap的Put操作

ConcurrentHashMap的size操作

Hashtable与ConcurrentHashMap

HashMap、HashTable和ConcurrentHashMap的区别与联系

Map

HashMap Hashtable treeMap区别

java为数据结构中的映射定义了一个接口java.util.Map;它有四个实现类,分别是HashMap Hashtable LinkedHashMap 和TreeMap.

Map主要用于存储健值对，根据键得到值，因此不允许键重复(重复了覆盖了),但允许值重复。

Hashmap 是一个最常用的Map,它根据键的HashCode值存储数据,根据键可以直接获取它的值，具有很快的访问速度，遍历时，取得数据的顺序是完全随机的。 HashMap最多只允许一条记录的键为Null;允许多条记录的值为 Null;HashMap不支持线程的同步，即任一时刻可以有多个线程同时写HashMap;可能会导致数据的不一致。如果需要同步，可以用 Collections的synchronizedMap方法使HashMap具有同步的能力，或者使用ConcurrentHashMap。

Hashtable与 HashMap类似,它继承自Dictionary类，不同的是:它不允许记录的键或者值为空;它支持线程的同步，即任一时刻只有一个线程能写Hashtable,因此也导致了 Hashtable在写入时会比较慢。

LinkedHashMap 是HashMap的一个子类，保存了记录的插入顺序，在用Iterator遍历LinkedHashMap时，先得到的记录肯定是先插入的.也可以在构造时用带参数，按照应用次数排序。在遍历的时候会比HashMap慢，不过有种情况例外，当HashMap容量很大，实际数据较少时，遍历起来可能会比 LinkedHashMap慢，因为LinkedHashMap的遍历速度只和实际数据有关，和容量无关，而HashMap的遍历速度和他的容量有关。

TreeMap实现SortMap接口，能够把它保存的记录根据键排序,默认是按键值的升序排序，也可以指定排序的比较器，当用Iterator 遍历TreeMap时，得到的记录是排过序的。

一般情况下，我们用的最多的是HashMap,在Map 中插入、删除和定位元素，HashMap 是最好的选择。但如果您要按自然顺序或自定义顺序遍历键，那么TreeMap会更好。如果需要输出的顺序和输入的相同,那么用LinkedHashMap 可以实现,它还可以按读取顺序来排列.

HashMap Hashtable treeMap的原理以及区别

1.这三个都对Map接口进行了实现

2.HashMap是不安全的线程，他允许Key值出现一次null Value值出现无数次的Null

3.Hashtable是安全的线程，他不仅实现了Map接口也实现了Dictionary接口，他的key值与Value值都不允许出现Null

4.treeMap是可以进行排序的，默认按照键的自然顺序进行升序排序，若要进行降序排序则需要在构造集合时候传递一个比较器

HashMap

Hashmap数据结构

HashMap底层是由数组+链表组成的。HashMap会有一个方法，先拿到要add进HashMap中的对象的hashCode，再将这个hashCode异或上对象自身hashCode右移16位（是不是感觉说的不是人话？这个步骤叫扰乱）

这样做的目的是为了让hashCode每一位都尽可能用到，hashCode经过上述步骤之后再&（数组长度-1），计算的结果就是这个对象在数组中的位置了

为什么红黑树的效率比较高

二叉搜索树

二叉搜索树要求：若它的左子树不空，则左子树上所有结点的值均小于它的根结点的值；若它的右子树不空，则右子树上所有结点的值均大于它的根结点的值；它的左、右子树也分别为二叉排序树。

红黑树

红黑树属于平衡二叉树（二叉搜索树）

1. 每一个结点要么是红色，要么是黑色。

2. 根结点是黑色的。

3. 所有叶子结点都是黑色的（实际上都是Null指针，下图用NIL表示）。叶子结点不包含任何关键字信息，所有查询关键字都在非终结点上。

4. 每个红色结点的两个子节点必须是黑色的。换句话说：从每个叶子到根的所有路径上不能有两个连续的红色结点

5. 从任一结点到其每个叶子的所有路径都包含相同数目的黑色结点

红黑树相关定理

1. 从根到叶子的最长的可能路径不多于最短的可能路径的两倍长。

2. 红黑树的树高(h)不大于两倍的红黑树的黑深度(bd)，即h<=2bd

3. 一棵拥有n个内部结点(不包括叶子结点)的红黑树的树高h<=2log(n+1)

从这里我们能够看出，红黑树的查找长度最多不超过2log(n+1)，因此其查找时间复杂度也是O(log N)级别的。

红黑树的操作

因为每一个红黑树也是一个特化的二叉查找树，因此红黑树上的查找操作与普通二叉查找树上的查找操作相同。

然而，在红黑树上进行插入操作和删除操作会导致不再符合红黑树的性质。恢复红黑树的属性需要少量(O(log n))的颜色变更(实际是非常快速的)和不超过三次树旋转(对于插入操作是两次)。

虽然插入和删除很复杂，但操作时间仍可以保持为 O(log n) 次。

红黑树的优势

红黑树能够以O(log2(N))的时间复杂度进行搜索、插入、删除操作。此外,任何不平衡都会在3次旋转之内解决。这一点是AVL所不具备的。

如何解决hash冲突

HashMap解决hash冲突使用的是链地址法（拉链法），将哈希表的每个单元作为链表的头结点，所有哈希地址为i的元素构成一个同义词链表。即发生冲突时就把该关键字链在以该单元为头结点的链表的尾部。

如果一个元素跟另一个元素发生了hash冲突，那么就会以链表的形式存储在数组中，每次获取元素的时候，就需要遍历链表（时间复杂度O(n)），所以链表过长会降低性能，所以当链表的长度大于阈值8的时候，

就会转换为红黑树（时间复杂度O(logn)），长度为6的时候又会从红黑树退化为链表。

HashMap怎么put(key, value)?

public V put(K key, V value) {

        // 对key为null的处理

        if (key == null)

            return putForNullKey(value);

        // 根据key算出hash值

        int hash = hash(key);

        // 根据hash值和HashMap容量算出在table中应该存储的下标i

        int i = indexFor(hash, table.length);

        for (Entry<K,V> e = table[i]; e != null; e = e.next) {

            Object k;

            // 先判断hash值是否一样，如果一样，再判断key是否一样

            if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {

                V oldValue = e.value;

                e.value = value;

                e.recordAccess(this);

                return oldValue;

            }

        }

        modCount++;

        addEntry(hash, key, value, i);

        return null;

    }

    static int indexFor(int h, int length) {

        return h & (length-1);

    }

HashMap中添加元素putVal()方法的部分源码，可以看出，向集合中添加元素时，会使用(n - 1) & hash的计算方法来得出该元素在集合中的位置

HashMap扩容时调用resize()方法中的部分源码，可以看出会新建一个tab，然后遍历旧的tab，将旧的元素进过e.hash & (newCap - 1)的计算添加进新的tab中，

也就是(n - 1) & hash的计算方法，其中n是集合的容量，hash是添加的元素进过hash函数计算出来的hash值。

当我们给put()方法传递键和值时，我们先对键调用hashCode()方法，根据int index=hashCode&length 找到index位置来储存Entry对象.

HashMap怎么get(key)?

当我们调用get()方法，HashMap会使用键对象的hashcode找到index位置，然后会调用key.equals()方法去找到链表中正确的节点，最终找到要找的值对象。

原理：HashMap::get返回一个数据节点, 如果不存在则返回空。

链表

    final Node<K,V> getNode(int hash, Object key) {
        Node<K,V>[] tab; Node<K,V> first, e; int n; K k;
        if ((tab = table) != null && (n = tab.length) > 0 &&
            (first = tab[(n - 1) & hash]) != null) {
            if (first.hash == hash && // always check first node
                ((k = first.key) == key || (key != null && key.equals(k))))
                return first;
            if ((e = first.next) != null) {
                if (first instanceof TreeNode)
                    return ((TreeNode<K,V>)first).getTreeNode(hash, key);
                do {
                    if (e.hash == hash &&
                        ((k = e.key) == key || (key != null && key.equals(k))))
                        return e;
                } while ((e = e.next) != null);
            }
        }
        return null;
    }

HashMap::getNode的流程是:
.1 通过 hash & (table.length - 1)获取该key对应的数据节点的hash槽;
.2 判断首节点是否为空, 为空则直接返回空;
.3 再判断首节点.key 是否和目标值相同, 相同则直接返回(首节点不用区分链表还是红黑树);
.4 首节点.next为空, 则直接返回空;
.5 首节点是树形节点, 则进入红黑树数的取值流程, 并返回结果;
.6 进入链表的取值流程, 并返回结果;

红黑树

    final TreeNode<K,V> getTreeNode(int h, Object k) {
			return ((parent != null) ? root() : this).find(h, k, null);
		}

HashMap.TreeNode::getTreeNode返回的是key对应的红黑树节点, 看代码可知他是从根节点开始遍历寻找key相对应的节点, 我们接着来看获取红黑树节点的核心方法: HashMap.TreedNode::find:

    final TreeNode<K,V> find(int h, Object k, Class<?> kc) {
            TreeNode<K,V> p = this;
            do {
                int ph, dir; K pk;
                TreeNode<K,V> pl = p.left, pr = p.right, q;
                if ((ph = p.hash) > h)
                    p = pl;
                else if (ph < h)
                    p = pr;
                else if ((pk = p.key) == k || (k != null && k.equals(pk)))
                    return p;
                else if (pl == null)
                    p = pr;
                else if (pr == null)
                    p = pl;
                else if ((kc != null ||
                          (kc = comparableClassFor(k)) != null) &&
                         (dir = compareComparables(kc, k, pk)) != 0)
                    p = (dir < 0) ? pl : pr;
                else if ((q = pr.find(h, k, kc)) != null)
                    return q;
                else
                    p = pl;
            } while (p != null);
            return null;
        }

HashMap::getTreeNode的流程是:

.1 获取当前节点, 第一次进入是根节点;
.2 通过一个循环去遍历节点, 当下一个遍历节点为空时退出, 返回null;
.3 先比较每个节点的hash值, 目标节点的hash小于当前节点时, 位于当前节点的左子树, 将当前节点的左子节点赋值给p, 进行下一次循环;
.4 目标节点的hash大于当前节点时, 位于当前节点的右子树, 将当前节点的右子节点赋值给p, 进行下一次循环;
.5 如果目标节点的hash等于当前节点的hash值, 再比较key是否相同, 如果相同则返回节点;
.6 左节点为空时, 将右节点赋值给p, 进行下一轮循环;
.7 右节点为空时, 将左节点赋值给p, 进行下一轮循环;
.8 如果key不相等, 再次判断能否通过key::compareTo(key是否实现Comparable接口)比出大小, 如果小, 则将左子节点赋值给p, 如果大则将右子节点赋值给p, 进行下一轮循环;
.9 如果无法通过key::compareTo比较出大小, 右子节点递归调用find, 如果结果不为空, 则返回结果(第8步已经保证pr不为空了);
.10 如果右子节点的递归无法得出结果, 只能将左子节点赋值给p, 进行下一轮循环;
经过上面的分析, 我们可以发现红黑树获取节点与链表获取节点有个很大的不同:
.1 红黑树需要通过hash与key的比较来判断节点的位置, 这是为什么呢?
.2 因为红黑树的特性要求了每个节点必须是有序的, 也就是左子树的父节点必定小于任一子节点的, 那么当hash相同时, 就必须借助于key来实现大小有序了(右子树同理), 所以在查找时, 我们就需要先通过hash来判断, 如果hash相同时, 就需要借助key来判断大小了;

Hashmap扩容时机

默认链表长度达到8就将链表树形化（变为红黑树）。

发生hash碰撞，那形成长链表是肯定的，这个时候树形化其实是治标不治本，因为引起链表过长的根本原因是数组过短，所以在JDK1.8源码中，执行树形化之前，会先检查数组长度，

如果长度小于64，则对数组进行扩容，而不是进行树形化。

所以发生扩容的时候有两种情况，一种是元素达到阀值了，一种是HashMap准备树形化但又发现数组太短，这两种情况均可能发生扩容。

HashMap扩容

HashMap的扩容条件就是当HashMap中的元素个数（size）超过临界值（threshold）时就会自动扩容。

在HashMap中，threshold = loadFactor * capacity。

loadFactor 负载因子默认为0.75，默认情况下HashMap元素个数达到12的时候，就会扩容了，扩容之后的大小为之前的2倍。既然容量变了，那么寻址时的元素的下标也会随之改变，

所以扩容时，需要先创建一个新的数组，容量是之前的两倍，然后再Rehash把之前的元素都重新进行hash计算，放入新的数组中。

这里有一个问题，就是扩容时，JDK1.7时使用的是头插法，同一位置上新元素总会被放在链表的头部位置，所以在多线程的情况下有可能会产生环形链表。JDK1.8之后使用尾插法，

在扩容时会保持链表元素原本的顺序，就不会出现环形链表的问题。

HashMap.resize()

在看HashMap源码是看到了resize()的源代码，当时发现在将old链表中引用数据复制到新的链表中时，发现复制过程中时，源码是进行了反序，此时是允许反序存储的，同时这样设计的效率要高，不用采用尾部插入，每次都要遍历到尾部。

下面对该原理进行总结：

JDK1.7的HashMap在实现resize()时，新table[]的列表采用LIFO方式，即队头插入。这样做的目的是：避免尾部遍历。尾部遍历是为了避免在新列表插入数据时，遍历队尾的位置。因为，直接插入的效率更高。

直接采用队头插入，会使得链表数据倒序

例如原来顺序是：

10 20 30 40

插入顺序如下

20 10

30 20 10

40 30 20 10

存在的问题:采用队头插入的方式，导致了HashMap在“多线程环境下”的死循环问题

从前我们的Java代码因为一些原因使用了HashMap这个东西，但是当时的程序是单线程的，一切都没有问题。后来，我们的程序性能有问题，所以需要变成多线程的，

于是，变成多线程后到了线上，发现程序经常占了100%的CPU，查看堆栈，你会发现程序都Hang在了HashMap.get()这个方法上了，重启程序后问题消失。但是过段时间又会来。而且，这个问题在测试环境里可能很难重现。

我们简单的看一下我们自己的代码，我们就知道HashMap被多个线程操作。而Java的文档说HashMap是非线程安全的，应该用ConcurrentHashMap。

HashMap初始容量为什么是2的n次幂及扩容为什么是2倍的形式

HashMap的容量为什么是2的n次幂，和这个(n - 1) & hash的计算方法有着千丝万缕的关系，符号&是按位与的计算，这是位运算，计算机能直接运算，特别高效，按位与&的计算方法是，只有当对应位置的数据都为1时，运算结果也为1，当HashMap的容量是2的n次幂时，(n-1)的2进制也就是1111111***111这样形式的，这样与添加元素的hash值进行位运算时，能够充分的散列，使得添加的元素均匀分布在HashMap的每个位置上，减少hash碰撞。

终上所述，HashMap计算添加元素的位置时，使用的位运算，这是特别高效的运算；另外，HashMap的初始容量是2的n次幂，扩容也是2倍的形式进行扩容，是因为容量是2的n次幂，

可以使得添加的元素均匀分布在HashMap中的数组上，减少hash碰撞，避免形成链表的结构，使得查询效率降低！

为什么h&(lenght-1) ？这其实就是mod取余的一种替换方式，相当于h%(lenght)，其中h为hash值，length为HashMap的当前长度。而&是位运算，效率要高于%。至于为什么是跟length-1进行&的位运算位运算(&)效率要比代替取模运算(%)高很多，主要原因是位运算直接对内存数据进行操作，不需要转成十进制，因此处理速度非常快。

那么，为什么可以使用位运算(&)来实现取模运算(%)呢？这实现的原理如下：

X % 2^n = X & (2^n - 1)

length为2的幂次方，即一定是偶数，偶数减1，即是奇数，这样保证了（length-1）在二进制中最低位是1，而&运算结果的最低位是1还是0完全取决于hash值二进制的最低位。

如果length为奇数，则length-1则为偶数，则length-1二进制的最低位横为0，则&位运算的结果最低位横为0，即横为偶数。这样table数组就只可能在偶数下标的位置存储了数据，

浪费了所有奇数下标的位置，这样也更容易产生hash冲突。这也是HashMap的容量为什么总是2的平方数的原因

重新调整HashMap大小存在什么问题?

多线程的情况下，可能产生条件竞争.

当重新调整HashMap大小的时候，确实存在条件竞争，因为如果两个线程都发现HashMap需要重新调整大小了，它们会同时试着调整大小。在调整大小的过程中，存储在链表中的元素的次序会反过来，

因为移动到新的位置的时候，HashMap并不会将元素放在链表的尾部，而是放在头部，这是为了避免尾部遍历(tail traversing)。如果条件竞争发生了，那么就死循环了。

多线程不要使用HashMap

为什么String, Interger这样的wrapper(包装)类适合作为键

String, Interger这样的wrapper类作为HashMap的键是再适合不过了，而且String最为常用。因为String是不可变的，也是final的，而且已经重写了equals()和hashCode()方法了。

其他的wrapper类也有这个特点。不可变性是必要的，因为为了要计算hashCode()，就要防止键值改变，如果键值在放入时和获取时返回不同的hashcode的话，那么就不能从HashMap中找到你想要的对象。

如果两个不相等的对象返回不同的hashcode的话，那么碰撞的几率就会小些，这样就能提高HashMap的性能。

HashMap总结

HashMap是基于哈希表实现的，用Entry[]来存储数据，而Entry中封装了key、value、hash以及Entry类型的next

HashMap存储数据是无序的

hash冲突是通过拉链法解决的

HashMap的容量永远为2的幂次方，有利于哈希表的散列

HashMap不支持存储多个相同的key，且只保存一个key为null的值，多个会覆盖

put过程，是先通过key算出hash，然后用hash算出应该存储在table中的index，然后遍历table[index]，看是否有相同的key存在，存在，则更新value；不存在则插入到table[index]单向链表的表头，时间复杂度为O(n)

get过程，通过key算出hash，然后用hash算出应该存储在table中的index，然后遍历table[index]，然后比对key，找到相同的key，则取出其value，时间复杂度为O(n)

HashMap是线程不安全的，如果有线程安全需求，推荐使用ConcurrentHashMap。

ConcurrentHashMap

Java5中引入了java.util.concurrent.ConcurrentHashMap作为高吞吐量的线程安全HashMap实现，它采用了锁分离的技术允许多个修改操作并发进行

最顶部标数字的部分是一个Entry数组，而Entry又是一个链表。当向Hashtable中插入数据的时候，首先通过键的hashCode和Entry数组的长度来计算这个值应该存放在数组中的位置index。

如果index对应的位置没有存放值，则直接存放到数组的index位置即可，当index有冲突的时候，则采用“拉链法”来解决冲突

Hashtable是通过“拉链法”（链地址法）实现的散列表，因此，它使用数组+链表的方式来存储实际的元素。

public class Hashtable<K,V>

extends Dictionary<K,V>

implements Map<K,V>, Cloneable, java.io.Serializable

Entry{

-next

-hash

-key

-value}

ConcurrentHashMap数据结构

ConcurrentHashMap是由Segment数组结构和HashEntry数组结构组成。Segment是一种可重入锁ReentrantLock，在ConcurrentHashMap里扮演锁的角色，HashEntry则用于存储键值对数据。一个ConcurrentHashMap里包含一个Segment数组，Segment的结构和HashMap类似，是一种数组和链表结构，一个Segment里包含一个HashEntry数组，每个HashEntry是一个链表结构的元素，每个Segment守护者一个HashEntry数组里的元素,当对HashEntry数组的数据进行修改时，必须首先获得它对应的Segment锁

ConcurrentHashMap的初始化

ConcurrentHashMap初始化方法是通过initialCapacity，loadFactor, concurrencyLevel几个参数来初始化segments数组，段偏移量segmentShift，段掩码segmentMask和每个segment里的HashEntry数组。

segments数组的长度ssize通过concurrencyLevel计算得出。为了能通过按位与的哈希算法来定位segments数组的索引，必须保证segments数组的长度是2的N次方（power-of-two size），所以必须计算出一个是大于或等于concurrencyLevel的最小的2的N次方值来作为segments数组的长度。假如concurrencyLevel等于14，15或16，ssize都会等于16，即容器里锁的个数也是16。注意concurrencyLevel的最大大小是65535，意味着segments数组的长度最大为65536，对应的二进制是16位。

初始化segmentShift和segmentMask。这两个全局变量在定位segment时的哈希算法里需要使用，sshift等于ssize从1向左移位的次数，在默认情况下concurrencyLevel等于16，1需要向左移位移动4次，所以sshift等于4。segmentShift用于定位参与hash运算的位数，segmentShift等于32减sshift，所以等于28，这里之所以用32是因为ConcurrentHashMap里的hash()方法输出的最大数是32位的，后面的测试中我们可以看到这点。segmentMask是哈希运算的掩码，等于ssize减1，即15，掩码的二进制各个位的值都是1。因为ssize的最大长度是65536，所以segmentShift最大值是16，segmentMask最大值是65535，对应的二进制是16位，每个位都是1。

初始化每个Segment。输入参数initialCapacity是ConcurrentHashMap的初始化容量，loadfactor是每个segment的负载因子，在构造方法里需要通过这两个参数来初始化数组中的每个segment。

ConcurrentHashMap线程安全

ConcurrentHashMap采用了更细粒度的锁来提高在并发情况下的效率。ConcurrentHashMap将Hash表默认分为16个桶（每一个桶可以被看作是一个Hashtable），大部分操作都没有用到锁，

而对应的put、remove等操作也只需要锁住当前线程需要用到的桶，而不需要锁住整个数据。采用这种设计方式以后，在大并发的情况下，同时可以有16个线程来访问数据。显然，大大提高了并发性。

只有个别方法（例如size()方法和containsValue()方法）可能需要锁定整个表而不是某个桶，在实现的时候，需要按照顺序锁定所有桶，操作完毕后，又“按顺序”释放所有桶，“按顺序”的好处是能防止死锁的发生。

假设一个线程在读取数据的时候，另外一个线程在Hash链的中间添加或删除元素或者修改某一个结点的值，此时必定会读取到不一致的数据。

那么如何才能实现在读取的时候不加锁而又不会读取到不一致的数据呢？ConcurrentHashMap使用不变量的方式来实现，它通过把Hash链中的结点HashEntry设计成几乎不可变的方式来实现，HashEntry的定义如下：

static final class HashEntry<K, V> {

final K key;

final int hash;

volatile V value;

final HashEntry<K, V> next;

}

除了变量value以外，其他的变量都被定义为final类型。因此，增加结点（put方法）的操作只能在Hash链的头部增加。对于删除操作，则无法直接从Hash链的中间删除结点，因为next也被定义为不可变量。

因此，remove操作的实现方式如下：把需要删除的结点前面所有的结点都复制一遍，然后把复制后的Hash链的最后一个结点指向待删除结点的后继结点，由此可以看出，ConcurrentHashMap删除操作是比较耗时的。

此外，使用volatile修饰value的方式使这个值被修改后对所有线程都可见（编译器不会进行优化），采用这种方式的好处如下：一方面，避免了加锁；另一方面，如果把value也设计为不可变量（用final修饰），

那么每次修改value的操作都必须删除已有结点，然后插入新的结点，显然，此时的效率会非常低下。

由于volatile只能保证变量所有的写操作都能立即反映到其他线程中，也就是说，volatile变量在各个线程中是一致的，但是由于volatile不能保证操作的原子性，因此它不是线程安全的

因此在访问ConcurrentHashMap中value的时候，为了保证多线程安全，最好使用一些原子操作。如果要使用类似map.put（1，map.get(1)+1）;的非原子操作，则需要通过加锁来实现多线程安全

Synchronized容器和Concurrent容器有什么区别？

在Java语言中，多线程安全的容器主要分为两种：Synchronized和Concurrent，虽然它们都是线程安全的，但是它们在性能方面差距比较大。

Synchronized容器（同步容器）主要通过synchronized关键字来实现线程安全，在使用的时候会对所有的数据加锁。需要注意的是，由于同步容器将所有对容器状态的访问都串行化了，

这样虽然保证了线程的安全性，但是这种方法的代价就是严重降低了并发性，当多个线程竞争容器时，吞吐量会严重降低。于是引入了Concurrent容器（并发容器），

Concurrent容器采用了更加智能的方案，该方案不是对整个数据加锁，而是采取了更加细粒度的锁机制，因此，在大并发量的情况下，拥有更高的效率。

ConcurrentHashMap的锁分段技术

HashTable容器在竞争激烈的并发环境下表现出效率低下的原因，是因为所有访问HashTable的线程都必须竞争同一把锁，那假如容器里有多把锁，每一把锁用于锁容器其中一部分数据，那么当多线程访问容器里不同数据段的数据时，线程间就不会存在锁竞争，从而可以有效的提高并发访问效率，这就是ConcurrentHashMap所使用的锁分段技术，首先将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问。

定位Segment

既然ConcurrentHashMap使用分段锁Segment来保护不同段的数据，那么在插入和获取元素的时候，必须先通过哈希算法定位到Segment。可以看到ConcurrentHashMap会首先使用Wang/Jenkins hash的变种算法对元素的hashCode进行一次再哈希。

再哈希，其目的是为了减少哈希冲突，使元素能够均匀的分布在不同的Segment上，从而提高容器的存取效率。假如哈希的质量差到极点，那么所有的元素都在一个Segment中，不仅存取元素缓慢，分段锁也会失去意义

ConcurrentHashMap的get操作

Segment的get操作实现非常简单和高效。先经过一次再哈希，然后使用这个哈希值通过哈希运算定位到segment，再通过哈希算法定位到元素

get操作的高效之处在于整个get过程不需要加锁，除非读到的值是空的才会加锁重读，我们知道HashTable容器的get方法是需要加锁的，那么ConcurrentHashMap的get操作是如何做到不加锁的呢？原因是它的get方法里将要使用的共享变量都定义成volatile，如用于统计当前Segement大小的count字段和用于存储值的HashEntry的value。定义成volatile的变量，能够在线程之间保持可见性，能够被多线程同时读，并且保证不会读到过期的值，但是只能被单线程写（有一种情况可以被多线程写，就是写入的值不依赖于原值），在get操作里只需要读不需要写共享变量count和value，所以可以不用加锁。之所以不会读到过期的值，是根据java内存模型的happen before原则，对volatile字段的写入操作先于读操作，即使两个线程同时修改和获取volatile变量，get操作也能拿到最新的值，这是用volatile替换锁的经典应用场景。

在定位元素的代码里我们可以发现定位HashEntry和定位Segment的哈希算法虽然一样，都与数组的长度减去一相与，但是相与的值不一样，定位Segment使用的是元素的hashcode通过再哈希后得到的值的高位，而定位HashEntry直接使用的是再哈希后的值。其目的是避免两次哈希后的值一样，导致元素虽然在Segment里散列开了，但是却没有在HashEntry里散列开。

ConcurrentHashMap的Put操作

由于put方法里需要对共享变量进行写入操作，所以为了线程安全，在操作共享变量时必须得加锁。Put方法首先定位到Segment，然后在Segment里进行插入操作。插入操作需要经历两个步骤，第一步判断是否需要对Segment里的HashEntry数组进行扩容，第二步定位添加元素的位置然后放在HashEntry数组里。

是否需要扩容。在插入元素前会先判断Segment里的HashEntry数组是否超过容量（threshold），如果超过阀值，数组进行扩容。值得一提的是，Segment的扩容判断比HashMap更恰当，因为HashMap是在插入元素后判断元素是否已经到达容量的，如果到达了就进行扩容，但是很有可能扩容之后没有新元素插入，这时HashMap就进行了一次无效的扩容。

如何扩容。扩容的时候首先会创建一个两倍于原容量的数组，然后将原数组里的元素进行再hash后插入到新的数组里。为了高效ConcurrentHashMap不会对整个容器进行扩容，而只对某个segment进行扩容。

ConcurrentHashMap的size操作

如果我们要统计整个ConcurrentHashMap里元素的大小，就必须统计所有Segment里元素的大小后求和。Segment里的全局变量count是一个volatile变量，那么在多线程场景下，我们是不是直接把所有Segment的count相加就可以得到整个ConcurrentHashMap大小了呢？不是的，虽然相加时可以获取每个Segment的count的最新值，但是拿到之后可能累加前使用的count发生了变化，那么统计结果就不准了。所以最安全的做法，是在统计size的时候把所有Segment的put，remove和clean方法全部锁住，但是这种做法显然非常低效。

因为在累加count操作过程中，之前累加过的count发生变化的几率非常小，所以ConcurrentHashMap的做法是先尝试2次通过不锁住Segment的方式来统计各个Segment大小，如果统计的过程中，容器的count发生了变化，则再采用加锁的方式来统计所有Segment的大小。

那么ConcurrentHashMap是如何判断在统计的时候容器是否发生了变化呢？使用modCount变量，在put , remove和clean方法里操作元素前都会将变量modCount进行加1，那么在统计size前后比较modCount是否发生变化，从而得知容器的大小是否发生变化。

LinkedHashMap

LinkedHashMap继承于HashMap

HashMap是无序的，当我们希望有顺序地去存储key-value时，就需要使用LinkedHashMap了。

LinkedHashMap是有序的，且是通过双向链表来保证顺序的。

public LinkedHashMap() {

        // 调用HashMap的构造方法，其实就是初始化Entry[] table

        super();

        // 这里是指是否基于访问排序，默认为false

        accessOrder = false;

    }

首先使用super调用了父类HashMap的构造方法，其实就是根据初始容量、负载因子去初始化Entry[] table

LinkedHashMap是继承于HashMap，是基于HashMap和双向链表来实现的。

HashMap无序；LinkedHashMap有序，可分为插入顺序和访问顺序两种。如果是访问顺序，那put和get操作已存在的Entry时，都会把Entry移动到双向链表的表尾(其实是先删除再插入)。

LinkedHashMap存取数据，还是跟HashMap一样使用的Entry[]的方式，双向链表只是为了保证顺序。

LinkedHashMap是线程不安全的。

初始化

在HashMap的构造函数中，调用了init方法，而在HashMap中init方法是空实现，但LinkedHashMap重写了该方法，所以在LinkedHashMap的构造方法里，调用了自身的init方法，init的重写实现如下：

@Override

    void init() {

        // 创建了一个hash=-1，key、value、next都为null的Entry

        header = new Entry<>(-1, null, null, null);

        // 让创建的Entry的before和after都指向自身，注意after不是之前提到的next

        // 其实就是创建了一个只有头部节点的双向链表

        header.before = header.after = header;

    }

LinkedHashMap put方法

当put元素时，不但要把它加入到HashMap中去，还要加入到双向链表中，所以可以看出LinkedHashMap就是HashMap+双向链表。

双向链表的重排序

主要是当前LinkedHashMap中不存在当前key时，新增Entry的情况。当key如果已经存在时，则进行更新Entry的value

主要看e.recordAccess(this)，这个方法跟访问顺序有关，而HashMap是无序的，所以在HashMap.Entry的recordAccess方法是空实现，但是LinkedHashMap是有序的,LinkedHashMap.Entry对recordAccess方法进行了重写。

在LinkedHashMap中，只有accessOrder为true，即是访问顺序模式，才会put时对更新的Entry进行重新排序，而如果是插入顺序模式时，不会重新排序，这里的排序跟在HashMap中存储没有关系，只是指在双向链表中的顺序。

举个栗子：开始时，HashMap中有Entry1、Entry2、Entry3，并设置LinkedHashMap为访问顺序，则更新Entry1时，会先把Entry1从双向链表中删除，然后再把Entry1加入到双向链表的表尾，

而Entry1在HashMap结构中的存储位置没有变化

LinkedHashMap get方法

先是调用了getEntry方法，通过key得到Entry，而LinkedHashMap并没有重写getEntry方法，所以调用的是HashMap的getEntry方法，在上一篇文章中我们分析过HashMap的getEntry方法：首先通过key算出hash值，

然后根据hash值算出在table中存储的index，然后遍历table[index]的单向链表去对比key，如果找到了就返回Entry。后面调用了LinkedHashMap.Entry的recordAccess方法，

上面分析过put过程中这个方法，其实就是在访问顺序的LinkedHashMap进行了get操作以后，重新排序，把get的Entry移动到双向链表的表尾。

遍历

nextEntry表示下一个应该返回的Entry，默认值是header.after，即双向链表表头的下一个元素。而上面介绍到，LinkedHashMap在初始化时，会调用init方法去初始化一个before和after都指向自身的Entry，

但是put过程会把新增加的Entry加入到双向链表的表尾，所以只要LinkedHashMap中有元素，第一次调用hasNext肯定不会为false。

基于LinkedHashMap的get特性，redis、mybatis实现LRU缓存处理

LinkedHashMap 2种有序

LinkedHashMap存储数据是有序的，而且分为两种：插入顺序和访问顺序。

访问顺序 recordAccess

存储顺序 accessOrder

LinkedHashMap 如何保证有序

LinkedHashMap是有序的，且是通过双向链表来保证顺序的。Entry类保留了HashMap的数据结构，同时通过before，after实现了双向链表结构（HashMap中Node类只有next属性，并不具备双向链表结构）

static class Entry<K,V> extends HashMap.Node<K,V> {
    Entry<K,V> before, after;
    Entry(int hash, K key, V value, Node<K,V> next) {
        super(hash, key, value, next);
    }
}

before与after的关系

TreeMap

可以实现元素的自动排序

TreeMap存储K-V键值对，通过红黑树（R-B tree）实现；

TreeMap继承了NavigableMap接口，NavigableMap接口继承了SortedMap接口，可支持一系列的导航定位以及导航操作的方法，当然只是提供了接口，需要TreeMap自己去实现；

TreeMap实现了Cloneable接口，可被克隆，实现了Serializable接口，可序列化；

TreeMap因为是通过红黑树实现，红黑树结构天然支持排序，默认情况下通过Key值的自然顺序进行排序；

TreeMap实现一定顺序是通过Comparable接口的，而他实现元素不重复也是完全通过compareTo，而不是hashCode和equals

红黑树规则特点：

节点分为红色或者黑色；
根节点必为黑色；
叶子节点都为黑色，且为null；
连接红色节点的两个子节点都为黑色（红黑树不会出现相邻的红色节点）；
从任意节点出发，到其每个叶子节点的路径中包含相同数量的黑色节点；
新加入到红黑树的节点为红色节点；

源码

static final class Entry<K,V> implements Map.Entry<K,V> {
    //key,val是存储的原始数据
    K key;
    V value;
    //定义了节点的左孩子
    Entry<K,V> left;
    //定义了节点的右孩子
    Entry<K,V> right;
    //通过该节点可以反过来往上找到自己的父亲
    Entry<K,V> parent;
    //默认情况下为黑色节点，可调整
    boolean color = BLACK;