ConcurrentHashMap 1.7与1.8的区别

1.锁结构不同
在JDK1.7中,ConcurrentHashMap基于Segment+HashEntry数组实现的。Segment是Reentrant的子类,而其内部也维护了一个Entry数组,这个Entry数组和HashMap中的Entry数组是一样的。所以说Segment其实是一个锁,可以锁住一段哈希表结构,而ConcurrentHashMap中维护了一个Segment数组,所以是基于分段锁实现的。 而JDK1.8中,ConcurrentHashMap摒弃了Segment,而是采用synchronized+CAS+红黑树来实现的。锁的粒度也从段锁缩小为结点锁.

2.put()的执行流程有所不同
JDK1.7中,ConcurrentHashMap要进行两次定位,先对Segment进行定位,再对其内部的数组下标进行定位。定位之后会采用自旋锁+锁膨胀的机制进行加锁,也就是自旋获取锁,当自旋次数超过64时,会发生膨胀,直接陷入阻塞状态,等待唤醒。并且在整个put操作期间都持有锁。

而在JDK1.8中只需要一次定位,并且采用CAS+synchronized的机制。如果对应下标处没有结点,说明没有发生哈希冲突,此时直接通过CAS进行插入,若成功,直接返回。若失败,则使用synchronized进行加锁插入。

3.计算size的方法不一样
1.7:采用类似于乐观锁的机制,先是不加锁直接进行统计,最多执行三次,如果前后两次计算的结果一样,则直接返回。若超过了三次,则对每一个Segment进行加锁后再统计。

1.8:会维护一个baseCount属性用来记录结点数量,每次进行put操作之后都会CAS自增baseCount

4.引入了红黑树
这点和HashMap相同,引入了红黑树结构用降低哈希冲突严重的场景的时间复杂度。

public class ConcurrentHashMap<K,V> extends AbstractMap<K,V> implements ConcurrentMap<K,V>,
		Serializable {

    /* --------- 常量及成员变量的设计 几乎与HashMap相差无几 -------- */

    /**
     * 最大容量
     */
    private static final int MAXIMUM_CAPACITY = 1 << 30;

    /**
     * 默认初始容量
     */
    private static final int DEFAULT_CAPACITY = 16;

    /**
     * 单个数组最大容量
     */
    static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8;

    /**
     * 默认并发等级,也就分成多少个单独上锁的区域
     */
    private static final int DEFAULT_CONCURRENCY_LEVEL = 16;

    /**
     * 扩容因子
     */
    private static final float LOAD_FACTOR = 0.75f;

    /**
     *
     */
    transient volatile Node<K,V>[] table;

    /**
     *
     */
    private transient volatile Node<K,V>[] nextTable;

    /* --------- 系列构造方法,依然推荐在初始化时根据实际情况设置好初始容量 -------- */
    public ConcurrentHashMap() {
    }

    public ConcurrentHashMap(int initialCapacity) {
        if (initialCapacity < 0)
            throw new IllegalArgumentException();
        int cap = ((initialCapacity >= (MAXIMUM_CAPACITY >>> 1)) ?
                   MAXIMUM_CAPACITY :
                   tableSizeFor(initialCapacity + (initialCapacity >>> 1) + 1));
        this.sizeCtl = cap;
    }

    public ConcurrentHashMap(Map<? extends K, ? extends V> m) {
        this.sizeCtl = DEFAULT_CAPACITY;
        putAll(m);
    }

    public ConcurrentHashMap(int initialCapacity, float loadFactor) {
        this(initialCapacity, loadFactor, 1);
    }

    public ConcurrentHashMap(int initialCapacity,
                             float loadFactor, int concurrencyLevel) {
        if (!(loadFactor > 0.0f) || initialCapacity < 0 || concurrencyLevel <= 0)
            throw new IllegalArgumentException();
        if (initialCapacity < concurrencyLevel)   // Use at least as many bins
            initialCapacity = concurrencyLevel;   // as estimated threads
        long size = (long)(1.0 + (long)initialCapacity / loadFactor);
        int cap = (size >= (long)MAXIMUM_CAPACITY) ?
            MAXIMUM_CAPACITY : tableSizeFor((int)size);
        this.sizeCtl = cap;
    }

    /**
     * ConcurrentHashMap 的核心就在于其put元素时 利用synchronized局部锁 和
     * CAS乐观锁机制 大大提升了本集合的并发能力,比JDK7的分段锁性能更强
     */
    public V put(K key, V value) {
        return putVal(key, value, false);
    }

	/**
	 * 当前指定数组位置无元素时,使用CAS操作 将 Node键值对 放入对应的数组下标。
	 * 出现hash冲突,则用synchronized局部锁锁住,若当前hash对应的节点是链表的头节点,遍历链表,
	 * 若找到对应的node节点,则修改node节点的val,否则在链表末尾添加node节点;倘若当前节点是
	 * 红黑树的根节点,在树结构上遍历元素,更新或增加节点
	 */
    final V putVal(K key, V value, boolean onlyIfAbsent) {
        if (key == null || value == null) throw new NullPointerException();
        int hash = spread(key.hashCode());
        int binCount = 0;
        for (Node<K,V>[] tab = table;;) {
            Node<K,V> f; int n, i, fh;
            if (tab == null || (n = tab.length) == 0)
                tab = initTable();
            else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {
            	// 注意!这是一个CAS的方法,将新节点放入指定位置,不用加锁阻塞线程
            	// 也能保证并发安全
                if (casTabAt(tab, i, null, new Node<K,V>(hash, key, value, null)))
                    break;                   // no lock when adding to empty bin
            }
            // 当前Map在扩容,先协助扩容,在更新值
            else if ((fh = f.hash) == MOVED)
                tab = helpTransfer(tab, f);
            else { // hash冲突
                V oldVal = null;
                // 局部锁,有效减少锁竞争的发生
                synchronized (f) { // f 是 链表头节点/红黑树根节点
                    if (tabAt(tab, i) == f) {
                        if (fh >= 0) {
                            binCount = 1;
                            for (Node<K,V> e = f;; ++binCount) {
                                K ek;
                                // 若节点已经存在,修改该节点的值
                                if (e.hash == hash && ((ek = e.key) == key ||
                                    	 (ek != null && key.equals(ek)))) {
                                    oldVal = e.val;
                                    if (!onlyIfAbsent)
                                        e.val = value;
                                    break;
                                }
                                Node<K,V> pred = e;
                                // 节点不存在,添加到链表末尾
                                if ((e = e.next) == null) {
                                    pred.next = new Node<K,V>(hash, key,
                                                              value, null);
                                    break;
                                }
                            }
                        }
                        // 如果该节点是 红黑树节点
                        else if (f instanceof TreeBin) {
                            Node<K,V> p;
                            binCount = 2;
                            if ((p = ((TreeBin<K,V>)f).putTreeVal(hash, key,
                                                           value)) != null) {
                                oldVal = p.val;
                                if (!onlyIfAbsent)
                                    p.val = value;
                            }
                        }
                    }
                }
                // 链表节点超过了8,链表转为红黑树
                if (binCount != 0) {
                    if (binCount >= TREEIFY_THRESHOLD)
                        treeifyBin(tab, i);
                    if (oldVal != null)
                        return oldVal;
                    break;
                }
            }
        }
        // 统计节点个数,检查是否需要resize
        addCount(1L, binCount);
        return null;
    }
}

参考:https://blog.youkuaiyun.com/SCUTJAY/article/details/104359923

### 回答1ConcurrentHashMap 1.7 1.8区别主要在于性能功能上的改进。具体来说,ConcurrentHashMap 1.8 在以下方面有所改进: 1. 内存占用:ConcurrentHashMap 1.8 的内存占用比 1.7 更小,因为它使用了更少的对象更少的指针。 2. 并发性能:ConcurrentHashMap 1.8 在并发性能方面有所提升,因为它使用了更高效的算法数据结构。 3. 扩容机制:ConcurrentHashMap 1.8 的扩容机制更加智能化,可以更好地避免冲突竞争。 4. 锁粒度:ConcurrentHashMap 1.8 的锁粒度更细,可以更好地支持高并发环境。 总的来说,ConcurrentHashMap 1.8 是一个更加高效、更加智能化的并发哈希表,可以更好地满足多线程环境下的需求。 ### 回答2: ConcurrentHashMap是一个线程安全的Map实现,它可以支持高并发的读操作一定程度的写操作并发。在Java8之前,ConcurrentHashMap的实现功能都比较简单,但是在Java8中对其进行了很大的改进。 首先,Java8中的ConcurrentHashMap增加了一些新的方法,如forEachKey、forEachValue、forEachEntry、reduce等,这些方法都是为了更方便地对ConcurrentHashMap进行遍历操作。 其次,Java8中的ConcurrentHashMap在实现上采用了一种新的方式——分段锁(Segment Locking)。在Java7及之前,ConcurrentHashMap中只有一个全局锁,所有的读写操作都要竞争这个锁,这样会影响并发性能。而在Java8中,ConcurrentHashMap被划分成多个独立的段(Segment),每个段内部拥有一把锁。这样,当不同的线程对不同的段进行读写操作时,可以并行地进行,大大提高了ConcurrentHashMap的并发性能。 此外,Java8中的ConcurrentHashMap内部也采用了一些新的技术来优化其性能,如CAS、红黑树等,在处理高并发读写时性能更为出色。 综上所述,Java8中的ConcurrentHashMap相比Java7及之前的版本,在功能性能方面都有了大幅度的提升,更加适合于高并发场景下的使用。 ### 回答3: ConcurrentHashMapJava集合框架中的一个线程安全的哈希表,它可以在多线程环境下使用而不需要显式地进行同步控制。在Java 1.71.8版本中,ConcurrentHashMap都有一些区别1. 同步方式 Java 1.7中的ConcurrentHashMap使用分段锁来进行同步控制,即一个ConcurrentHashMap被分成多个段(Segment),每个段都有一个独立的锁来控制访问。不同的线程可以往不同的段中插入元素,从而避免了线程间的竞争。 而Java 1.8中的ConcurrentHashMap使用了CAS(Compare and Swap)算法进行同步控制。这种算法比分段锁更为轻量级,因为它不需要线程之间的协调,而是每个线程都可以自己完成同步操作。此外,Java 1.8中的ConcurrentHashMap使用了一种基于链表的算法来处理哈希冲突,可以大大减少哈希冲突带来的开销。 2. 空值检查 在Java 1.7中,当对一个不存在的键进行获取或删除操作时,需要先检查相应的值是否为null,因为ConcurrentHashMap不能存储null值,如果值为null说明该键不存在。但是,在多线程环境下,这种检查需要进行同步操作,会影响程序的性能。 而在Java 1.8中,ConcurrentHashMap增加了一种isNull()方法,用于判断键是否存在以及值是否为null。这种方式不需要进行同步操作,因此可以提高程序的性能。 3. 并发度的改进 在Java 1.7中,ConcurrentHashMap在创建时需要指定相应的并发度(concurrencyLevel),以确定分段锁的数量。如果并发度设置得不够大,会导致多个线程竞争同一个锁,从而影响程序的性能;而如果并发度设置得过大,会造成锁的浪费。 Java 1.8中的ConcurrentHashMap移除了并发度这一参数,转而使用更为动态的方式来确定分段锁的数量。这种方式可以根据实际线程并发数来自动计算分段锁的数量,从而提高程序的性能。 综上所述,Java 1.8中的ConcurrentHashMap相比Java 1.7中的版本在同步方式、空值检查以及并发度方面都有所改进,可以提供更为高效的多线程操作能力。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值