Java多线程下使用哈希表

本文探讨了Java中多线程环境下使用哈希表的问题。HashMap在多线程环境下不安全,而HashTable虽然通过加锁确保线程安全,但效率较低。相比之下,ConcurrentHashMap通过锁分段和CAS操作提高了并发性能,同时其在扩容时采用化整为零的策略,避免了一次性搬运所有元素导致的卡顿问题。

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

HashMap本身线程不安全

1.HashTable(不推荐)

通过给关键方法加锁保证线程安全,针对this来加锁,当有多个线程访问HashTable的时候,无论是啥样的操作和数据都会出现锁竞争,因此导致所竞争的概率非常大,效率比较低。

public synchronized V put(K key, V value){
    
}
public synchronized V get(Object key){
    
}

2.ConcurrentHashMap(推荐)

减少了锁冲突,让锁加到每个链表的头节点上(锁痛)。即操作元素的时候是针对这个元素所在的链表的头结点来加锁的,如果你两个线程操作是针对两个不同的链表的元素,没有线程安全问题其实不必加锁。由于Hash表中链表数目非常多,每个链表长度相对短就可以保证锁冲突的概率非常小了。

只是针对写操作加锁了,读操作没加锁 更广泛地使用CAS,进一步提高效率 针对扩容进行了巧妙地化整为零:

对于HashTable只要put触发扩容就会一次性搬运完,会导致这次的put非常卡顿
而ConcurrentHashMap每次操作只搬运一点,通过多次搬运完成整个搬运过程,同时维护一个新的HashMap和一个旧的,查找的时候既需要查旧的也需要查新的,插入时候只需要插入新的直到搬运完毕再销毁旧的。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值