操作系统——多线程使用哈希表

硌手的小虫子@

已于 2023-09-16 11:10:57 修改

阅读量1k

点赞数 1

分类专栏：操作系统文章标签：操作系统多线程哈希表

于 2023-04-09 19:27:26 首次发布

本文链接：https://blog.csdn.net/xh1605004242/article/details/130043182

版权

操作系统专栏收录该内容

16 篇文章 0 订阅

订阅专栏

（1）、加锁粒度不同——触发锁冲突的频率不同

（2）、充分利用CAS机制——无锁编程

（3）、优化扩容策略

一、HashMap

1、定义

HashMap是通过哈希表实现的，相比于1.7由数组+链表组成的版本，1.8的版本是由是数组+链表+红黑树组成的。HashMap的每一个元素都是一个key-value键值对，其内部通过单链表解决冲突问题，容量不足时会自动增长。

HashMap中key和value都允许为null，键值对以key为头结点放在链表中。

注：HashMap是非线程安全的。

二、HashTable

1、定义：

HashTable是线程安全的，其只是简单的把关键方法加上synchronized关键字，相当于直接针对 HashTable对象本身加锁。

多线程访问同一个HashTable时会直接造成锁冲突。
size属性是通过synchronized来控制同步，每次都会花费内存，时间较长效率较低。
触发扩容时，由该线程完成整个扩容过程。这个过程会涉及到大量的元素拷贝，效率非常低。

一个HashTable只有一把锁，两个线程访问HashTable中的任意数据都会出现锁竞争。有两个线程要操作这两个元素时，由于是同一把锁所以会产生锁竞争。但是这两操作在不同的哈希桶上，不牵扯修改同一个变量，因此就不会发生线程安全，所以上面的锁竞争是没有必要的。但如果两个修改落到同一个哈希桶上，有线程安全风险。

2、区别：

HashTable与HashMap在原理上基本上相同，它们之间的区别在于HashTable的大部分方法是被synchronized所修饰的，并且键值都不能为null。
相比于HashMap的线程不安全，HashTable是线程安全的。由于HashTable大部分方法被synchronized修饰，因此是其是线程安全的。HashMap则是非线程安全的，大量的线程存取可能会出现异常。
HashMap效率相比HashTable较高，因为synchronized修饰方法，获取锁会耗费时间，导致效率相对较低。

三、ConcurrentHashMap

1、定义：

ConcurrentHashMap底层是基于数组+链表实现的，JDK1.7版本中的数据结构采用分段式设计，通过segment数组+HashEntry数组+链表来实现，哈希冲突采用拉链法处理。而在JDK1.8的版本中，HashMap的设计思想采用数组+链表+红黑树的数据结构，并且由原来的分段式锁换成了CAS+Synchronized锁。

ConcurrentHashMap相比于 HashTable 做出了一系列的改进和优化。以 Java1.8 为例读操作没有加锁（但是使用了 volatile 保证从内存读取结果），只对写操作进行加锁。

加锁的方式仍然是用synchronized，但不是锁整个对象，而是“锁桶”(用每个链表的头结点作为锁对象)，大大降低了锁冲突的概率。充分利用 CAS 特性，比如size属性通过 CAS 来更新，避免出现重量级锁的情况。

优化扩容方式：化整为零。发现需要扩容的线程时，只需要创建一个新的数组，同时只搬几个元素过去。扩容期间，新老数组同时存在。后续每个操作ConcurrentHashMap的线程，都会参与搬家的过程，每个操作负责搬运一小部分元素。搬完最后一个元素再把老数组删掉，这个期间插入只往新数组加，而查找需要同时查新数组和老数组。

2、优化

（1）、加锁粒度不同——触发锁冲突的频率不同

HashTable是针对整个哈希表加锁，任何增删查改的操作都会触发加锁，也就都可能有锁竞争。

如果是两个线程同时插入元素：线程1在下标为1的链表上插入元素，线程2在下标为2的链表上插入元素。

两个线程修改不同变量时不存在线程安全问题，但是由于synchronized是加到this上的，仍然会针对同一个对象产生锁竞争，产生阻塞等待。

相比于HashTable，ConcurrentHashMap是将每个链表（头节点）作为一把锁，每次进行操作都是针对对应链表的锁进行加锁。操作不同链表就是针对不同的锁加锁，不会有锁冲突。

（2）、充分利用CAS机制——无锁编程

有的操作，比如获取/跟新元素个数，就可以直接使用CAS完成，不必加锁。

CAS也能保证线程安全，往往比锁更高效，但是不经常使用，适用范围不像锁那么广泛。

（3）、优化扩容策略

对于HashTable如果元素太多会涉及到扩容——负载因子。

扩容需要重新申请内存空间，搬运空间（把元素从旧的哈希表上删掉，插入到新的哈希表上）。

如果本身元素非常多，搬运一次成本很高会导致这一次的操作非常卡顿。ConcurrentHashMap将其化整为零，并不会试图一次性的把所有元素都搬运过去，而是每次操作过程中只搬运一小部分，此时相当于同时存在两份哈希表。当插入元素时直接往新表插入元素，删除元素时元素在哪个表上删除哪个表，查找元素时新表旧表都查询。