并发编程之J.U.C的第二篇
该类自JDK8加入,是为了进一步优化读性能,它的特点是使用读锁、写锁时都必须配合【戳】使用
加解读锁
加锁写锁
乐观锁,StampedLock 支持 tryOptimisticRead()方法(乐观读),读取完毕后需要做一次戳校验,如果校验通过,表示这期间确实没有写操作,数据可以安全使用,如果校验没通过,需要重新获取读锁,保证数据安全。
信号量,用来限制能同时访问共享资源的线程上限。
- 加锁解锁流程
Semaphore 有点像一个停车场,permits 就好像停车位数量,当线程获得了 permits就像是获得了停车位,然后停车场显示空余车位减一
刚开始,permits(state)为3,这时5个线程来获取资源
假设其中 Thread - 1,Thread - 2,Thread -4 cas 竞争成功,而Thread - 0和Thread - 3 竞争失败,进入AQS队列park阻塞
这时 Thread - 4 释放了 permits,状态如下
接下来Thread - 0 竞争成功,permits再次设置为0,设置自己为head节点,断开原来的head节点,unpark接下来的Thread - 3 节点,但由于 permits是0,因此Thread - 3 在尝试不成功后再次进入 park状态
用来进行线程同步协作,等待所有线程完成倒计时。
其中构造参数用来初始化等待计数值,await()用来等待计数归零,countDown()用来让计数减一
循环栅栏,用来进行线程协作,等待线程满足某个计数。构造时设置【计数个数】,每个线程执行到某个需要“同步”的时刻调用await()方法进行等待,当等待的线程数满足【计数个数】时,继续执行
线程安全集合类可以分为三大类 :
- 遗留的线程安全集合如 Hashtable、Vector
- 使用Collections装饰的线程安全集合,如 :
- Collections.synchronizedCollection
- Collections.synchronizedList
- Collections.synchronizedMap
- Collections.synchronizedSet
- Collections.synchronizedNavigableMap
- Collections.synchronizedNavigableSet
- Collections.synchronizedMap
- Collections.synchronizedSet
- java.util.concurrent.*
重点介绍java.util.concurrent.*下的线程安全集合类,里面包含三类关键词 :Blocking、CopyOnWrite、Concurrent - Blocking大部分实现基于锁,并提供用来阻塞的方法
- CopyOnWrite 之类容器修改稍相对较重
- Concurrent类型的容器
- 内部很多操作使用cas优化,一般可以提供高吞吐量
- 弱一致性
- 遍历时弱一致性,例如,当利用迭代器遍历时,如果容器发生修改,迭代器任然可以进行进行遍历,这时内存是旧的
- 求大小弱一致性,size操作未必是100%准确
- 读取弱一致性
- 遍历时如果发生了修改,对于非安全容器来讲,使用fail-fast机制也就是让遍历立刻失败,抛出ConcurrentModificationExecption,不再继续遍历
单词计数问题 :
重要属性和内部类
构造器分析
可以看到实现了懒惰初始化,在构造方法中仅仅计算了table的大小,以后在第一次使用时才会真正的创建
get流程分析
put流程
以下数组简称(table),链表简称(bin)
size计算流程
size计算实际发生在put、remove改变集合元素的操作之中
- 没有竞争发生,向baseCount累加计数
- 有竞争发生,新建counterCells,向其中的一个cell累加计数
- counterCells初始有两个cell
- 如果计数竞争比较激烈,会创建新的cell来累加计数
它维护了一个segment数组,每个segment对应一把锁
- 优点 : 如果多个线程访问不同的segment,实际是没有冲突的,这与jdk8中是类似的
- 缺点 :Segments数组默认大小为16,这个容量初始化指定后就不能改变了,并且不是懒得初始化
构造器分析
可以看到ConcurrentHashMap 没有实现懒惰初始化,空间占用不友好
其中 this.segmentShift 和 this.segmentMask的作用是决定将key的hash结果匹配到那个 segment
例如 :根据某一hash值求segment位置,先将高位向低位移动 this.segmentShift位
结果再与this.segmentMask 做位于运算,最终得到1010即下标为10的segment
put流程
segment继承了可重入锁(ReentrantLock),它的put方法为
get流程
get时并未加锁,用了UNSAFE方法保证了可见性,扩容过程中,get先发生就从旧表取内容,get后发生就从新表取内容
size计算流程 - 计算元素个数前,先不加锁计算两次,如果前后两次结果如一样,认为个数正确返回
- 如果不一样,进行重试,重试次数超过3,将所有segment锁住,重新计算个数返回
LinkedBlockingQueue 原理
- 基本的入队出队
初始化链表 last = head = new Node(null);Dummy节点用来占位,item为null
当一个节点入队 last = last.next = node;
再来一个节点入队 last = last.next = node
出队
h = head
first = h.next
h.next = h
head = first
E x = first.item;
first.item = null;
return x; - 加锁分析
高明之处在于用了两把锁和dummy节点
- 用一把锁,同一时刻,最多只允许有一个线程(生产者或消费者,二选一)执行
- 用两把锁,同一时刻,可以允许两个线程同时(一个生产者与一个消费者)执行
- 消费者与消费者线程任然串行
- 生产者与生产者线程任然串行
线程安全分析
- 当节点总数大于2时(包括dummy节点),putLock保证的是last节点的线程安全,takeLock保证的是head节点的线程安全。两把锁保证了入队和出队没有竞争
- 当节点总数等于2时(即一个dummy节点,一个正常节点)这时候,仍然是两把锁锁两个对象,不会竞争
- 当节点总数等于1时(就一个dummy节点)这时take线程会被notEmpty条件阻塞,有竞争,会阻塞
put操作
take操作
主要列举 LinkedBlockingQueue与ArrayBlockingQueue的性能比较
- Linked支持有界,Array强制有界
- Linked实现是链表,Array实现是数组
- Linked是懒惰的,而Array需要提前初始化Node数组
- Linked每次入队会生成新Node,而Array的Node是提前创建好的
- Linked两把锁,Array一把锁
ConcurrentLinkedQueue的设计与LinkedBlockingQueue 非常像,也是
- 两把【锁】,同一时刻,可以允许两个线程同时(一个生产者与一个消费者)执行
- dummy节点的引入让两把【锁】将来锁住的是不同对象,避免竞争
- 只是这【锁】使用了cas来实现
事实上,ConcurrentLinkedQueue应用还是非常广泛的
例如之前讲的Tomcat的Connector结构时,Acceptor作为生产者向Poller消费者传递事件信息时,正是采用了ConcurrentLinkedQueue将SocketChannel给Poller使用
CopyOnWriteArraySet 是它的马甲
底层实现采用了写入时拷贝的思想,增删改操作会将底层数组拷贝一份,更改操作在新数组上执行,这时不影响其他线程的并发读、读写分离。
这里的源码版本是Java11,在Java1.8中使用的是可重入锁而不是synchronized,其它读操作并未加锁,例如 :
适合【读多写少】的应用场景
get弱一致性
迭代器弱一致性
不要觉得弱一致性就不好
- 数据库的MVCC都是弱一致性的表现
- 并发高和一致性是矛盾的,需要权衡