一、CountDownLatch,Semaphore相关问题
1.1 CountDownLatch是什么,有什么作用,底层实现
CountDownLatch本质其实就是一个计数器。
在多线程并形处理业务时,需要等待其他线程处理完,再做后续的合并等操作,再响应用户时,可以使用CountDownLatch做计数,等到其他线程出现完之后,主线程就会被唤醒。
CountDownLatch本身就是基于AQS实现的。
new CountDownLatch时,直接指定好具体的数值。这个数值会复制给state属性。
当子线程处理完任务后,执行countDown方法,内部就是直接给state - 1而已。
当state减为0之后,执行await挂起的线程,就会被唤醒。
CountDownLatch不能重复使用,用完就凉凉。
1.2 Semaphore是什么,有什么作用,底层实现
信号量,就是一个可以用于做限流功能的工具类。
比如Hystrix中涉及到了信号量隔离,要求并发的线程数有限制,就可以使用信号量实现。
比如要求当前服务最多10个线程同时干活,将信号量设置为10。没一个任务提交都需要获取一个信号量,就去干活,干完了,归还信号量。
信号量也是基于AQS实现的。
构建信号量时,指定信号量资源数,获取时,指定获取几个信号量,也是CAS保证原子性,归还也是类似的。
1.3 main线程结束,程序会停止吗
如果main线程结束,但是还有用户线程在执行,不会结束!
如果main线程结束,剩下的都是守护线程,结束!
二、CopyOnWriteArrayList相关问题
2.1 CopyOnWriteArrayList是如何保证线程安全的
CopyOnWriteArrayList写数据时,是基于ReentrantLock保证原子性的。
其次,写数据时,会复制一个副本写入,写入成功后,才会写入到CopyOnWriteArrayList中的数组。
保证读数据时,不要出现数据不一致的问题。
如果数据量比较大时,每次写入数据,都需要复制一个副本,对空间的占用太大了。如果数据量比较大,不推荐使用CopyOnWriteArrayList。
写操作要求保证原子性,读操作保证并发,并且数据量不大 ~
三、ConcurrentHashMap(JDK1.8)相关问题
3.1 HashMap为什么线程不安全
问题1:JDK1.7里有环(扩容时)。
问题2:数据会覆盖,数据可能丢失。
问题3:其次计数器,也是传统的++,在记录元素个数和HashMap写的次数时,记录不准确。
问题4:数据迁移,扩容,也可能会丢失数据。
3.2 ConcurrentHashMap如何保证线程安全的
回答1:尾插,其次扩容有CAS保证线程安全
回答2:写入数组时,基于CAS保证安全,挂入链表或插入红黑树时,基于synchronized保证安全。
回答3:这里ConcurrentHashMap是采用LongAdder实现的技术,底层还是CAS。(AtomicLong)
回答4:ConcurrentHashMap扩容时,一点基于CAS保证数据迁移不出现并发问题, 其次ConcurrentHashMap还提供了并发扩容的操作。举个例子,数组长度64扩容为128,两个线程同时扩容的话,
线程A领取64-48索引的数据迁移任务,线程B领取47-32的索引数据迁移任务。关键是领取任务时,是基于CAS保证线程安全的。
3.3 ConcurrentHashMap构建好,数组就创建出来了吗?如果不是,如何保证初始化数组的线程安全
ConcurrentHashMap是懒加载的机制,而且大多数的框架组件都是懒加载的~
基于CAS来保证初始化线程安全的,这里不但涉及到了CAS去修改sizeCtl的变量去控制线程初始化数据的原子性,同时还使用了DCL,外层判断数组未初始化,中间基于CAS修改sizeCtl,内层再做数组未初始化判断。
3.4 为什么负载因子是0.75,为什么链表长度到8转为红黑树
而且ConcurrentHashMap的负载因子不允许修改!
负载因子是0.75从两个方面去解释。
为啥不是0.5,为啥不是1?
0.5:如果负载因子是0.5,数据添加一半就开始扩容了
- 优点:hash碰撞少,查询效率高。
- 缺点:扩容太频繁,而且空间利用率低。
1:如果负载因子是1,数据添加到数组长度才开始扩容
- 优点:扩容不频繁,空间利用率可以的。
- 缺点:hash冲突会特别频繁,数据挂到链表上,影响查询效率,甚至链表过长生成红黑树,导致写入的效率也收到影响。
0.75就可以说是一个居中的选择,两个方面都兼顾了。
再聊就是泊松分布,在负载因子是0.75时,根据泊松分布得出,链表长度达到8的概率是非常低的,源码中的标识是0.00000006,生成红黑树的概率特别低。
虽然ConcurrentHashMap引入了红黑树,但是红黑树对于写入的维护成本更高,能不用就不用,HashMap源码的注释也描述了,要尽可能规避红黑树。
至于6退化为链表,是因为满树是7个值,7不退化是为了防止频繁的链表和红黑树转换,这里6退化留下了一个中间值,避免频繁的转换。
put操作太频繁的场景,会造成扩容时期put的阻塞 ?
一般情况下不会造成阻塞。
因为如果在put操作时,发现当前索引位置并没有数据时,正常把数据落到老数组上。
如果put操作时,发现当前位置数据已经被迁移到了新数组,这时无法正常插入,去帮助扩容,快速结束扩容操作,并且重新选择索引位置查询
3.5 ConcurrentHashMap何时扩容,扩容的流程是什么
- ConcurrentHashMap中的元素个数,达到了负载因子计算的阈值,那么直接扩容
- 当调用putAll方法,查询大量数据时,也可能会造成直接扩容的操作,大量数据是如果插入的数据大于下次扩容的阈值,直接扩容,然后再插入
- 数组长度小于64,并且链表长度大于等于8时,会触发扩容
扩容的流程:(sizeCtl是一个int类型变量,用于控制初始化和扩容)
- 每个扩容的线程都需要基于oldTable的长度计算一个扩容标识戳(避免出现两个扩容线程的数组长度不一致。其次保证扩容标识戳的16位是1,这样左移16位会得到一个负数)
- 第一个扩容的线程,会对sizeCtl + 2,代表当前有1个线程来扩容
- 除去第一个扩容的线程,其他线程会对sizeCtl + 1,代表现在又来了一个线程帮助扩容
- 第一个线程会初始化新数组。
- 每个线程会领取迁移数据的任务,将oldTable中的数据迁移到newTable。默认情况下,每个线程每次领取长度为16的迁移数据任务
- 当数据迁移完毕时,每个线程再去领取任务时,发现没任务可领了,退出扩容,对sizeCtl - 1。
- 最后一个退出扩容的线程,发现-1之后,还剩1,最后一个退出扩容的线程会从头到尾再检查一次,有没有遗留的数据没有迁移走(这种情况基本不发生),检查完之后,再-1,这样sizeCtl扣除完,扩容结束。
3.6 ConcurrentHashMap得计数器如何实现的
这里是基于LongAdder的机制实现,但是并没有直接用LongAdder的引用,而是根据LongAdder的原理写了一个相似度在80%以上的代码,直接使用。
LongAdder使用CAS添加,保证原子性,其次基于分段锁,保证并发性。
3.7 ConcurrentHashMap的读操作会阻塞吗
无论查哪,都不阻塞。
查询数组? :第一块就是查看元素是否在数组,在就直接返回。
查询链表?:第二块,如果没特殊情况,就在链表next,next查询即可。
扩容时?:第三块,如果当前索引位置是-1,代表当前位置数据全部都迁移到了新数组,直接去新数组查询,不管有没有扩容完。
查询红黑树?:如果有一个线程正在写入红黑树,此时读线程还能去红黑树查询吗?因为红黑树为了保证平衡可能会旋转,旋转会换指针,可能会出现问题。所以在转换红黑树时,不但有一个红黑树,还会保留一个双向链表,此时会查询双向链表,不让读线程阻塞。至于如何判断是否有线程在写,和等待写或者是读红黑树,根据TreeBin的lockState来判断,如果是1,代表有线程正在写,如果为2,代表有写线程等待写,如果是4n,代表有多个线程在做读操作。