为什么ConcurrentHashMap比HashTable更高效?
本文最后更新于60 天前,其中的信息可能已经过时,如有错误请发送邮件到big_fw@foxmail.com

底层数据结构:HashTable采用的是数组+链表,ConcurrentHashMap采用的是数组+链表/红黑树

实现线程安全的方式

  • HashTable的主要方法都使用了Synchronized锁,包括读、写,且每个操作都会锁整个HashTable,直接导致在并发情况下阻塞,效率低下
  • ConcurrentHashMap在JDK1.8后并发使用Synchronized锁和CAS,其中,在对空桶put操作时,会通过CAS进行,当出现哈希冲突时,会使用synchronized锁目标桶,而不锁其他桶,粒度更细。

 

  • CAS:组要含三个操作数:V(更新的内存位置的通过值)、E(预期的原值)、N(更新的目标值),在修改时,会先判断V是否等于E,也就是判断操作过程中,该位置的值是否被其他线程修改(类似乐观锁),如果相等,就直接修改,若否则放弃之前所有操作,重新尝试修改。不断重复以上过程。
  • CAS是一种自旋锁,不会阻塞,而synchronized锁会导致线程阻塞
文末附加内容
暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇