文章目录 一、AQS高频问题1.1 AQS是什么？1.2 唤醒线程时，AQS为什么从后往前遍历？1.3 AQS为什么用双向链表，（为啥不用单向链表）？1.4 AQS为什么要有一个虚拟的head节点1.5 ReentrantLock的
AQS是JUC下大量工具的基础类，很多工具都基于AQS实现的，比如lock锁，CountDownLatch，Semaphore，线程池等等都用到了AQS。
AQS中有一个核心属性state，还有一个双向链表以及一个单向链表。其中state是基于volatile修饰，再基于CAS修改，可以保证原子，可见，有序三大特性。单向链表是内部类ConditionObject对标synchronized中的等待池，当lock在线程持有锁时，执行await方法，会将线程封装为node对象，扔到Condition单向链表中，等待唤醒。如果线程唤醒了，就将Condition中的Node扔到AQS的双向链表等待获取锁。
当持有资源的线程执行完成后，需要在AQS的双向链表拿出来一个，如果head的next节点取消了
如果在唤醒线程时，head节点的next是第一个要被唤醒的，如果head的next节点取消了，会出现节点丢失问题。
如下图，当一个新的Node添加到链表时有3个步骤，当第三个步骤还未完成时，如果从head开始就找不到需要被唤醒的节点了。
因为AQS中，存在取消节点的操作，如果使用双向链表只需要两步
但是如果是单向链表，需要遍历整个单向链表才能完成的上述的操作。比较浪费资源。
每个Node都会有一些状态，这个状态不单单针对自己，还针对后续节点
但是一个节点无法同时保存当前节点状态和后继节点状态，有一个哨兵节点，更方便操作。
ReentrantLock是基于AQS实现的。
公平锁和非公平中的lock方法和tryAcquire方法的实现有点不同，其他都一样
如果都没拿到锁，公平锁和非公平锁的后续逻辑是一样的，加入到AQS双向链表中排队。
如果一个操作写少读多，还用互斥锁的话，性能太低，因为读读不存在并发问题。读写锁可以解决该问题。
ReentrantReadWriteLock也是基于AQS实现的一个读写锁，但是锁资源用state标识。如何基于一个int来标识两个锁信息，有写锁，有读锁，怎么做的？
一个int，占了32个bit位。在写锁获取锁时，基于CAS修改state的低16位的值。在读锁获取锁时，基于CAS修改state的高16位的值。
写锁的重入，基于state低16直接标识，因为写锁是互斥的。读锁的重入，无法基于state的高16位去标识，因为读锁是共享的，可以多个线程同时持有。所以读锁的重入用的是ThreadLocal来表示，同时也会对state的高16为进行追加。
ArrayBlockingQueue：底层基于数组实现，记得new的时候设置好边界。
LinkedBlockingQueue：底层基于链表实现的，可以认为是无界队列，但是可以设置长度。
PriorityBlockingQueue：底层是基于数组实现的二叉堆，可以认为是无界队列，因为数组会扩容。
ArrayBlockingQueue，LinkedBlockingQueue是ThreadPoolExecutor线程池最常用的两个阻塞队列。
虚假唤醒在阻塞队列的源码中就有体现。
比如消费者1在消费数据时，会先判断队列是否有元素，如果元素个数为0，消费者1会await挂起。此处判断元素为0的位置，如果用if循环会导致出现一个问题。
解决方案，将判断元素个数的位置，设置为while判断。
核心线程数，最大线程数，最大空闲时间，时间单位，阻塞队列，线程工厂，拒绝策略
线程池有5个状态：RUNINING、SHUTDOWN、STOP、TIDYING、TERMINATED
线程池的状态是在ctl属性中记录的。本质就是int类型
AbortPolicy：丢弃任务并抛异常（默认） 
CallerRunsPolicy：当前线程执行
DiscardPolicy：丢弃任务直接不要
DiscardOldestPolicy：丢弃等待队列中最旧的任务，并执行当前任务
一般情况下，线程池自带的无法满足业务时，自定义一个线程池的拒绝策略，实现下面的接口即可。
核心线程不是new完就构建的，是懒加载的机制，添加任务才会构建核心线程
避免线程池出现队列有任务，但是没有工作线程处理。
当核心线程数是0个，任务进来后会到阻塞队列，但是没有工作线程，此时空任务的非核心线程就可以处理该任务。
##3.6 在没任务时，线程池中的工作线程在干嘛？
如果是核心线程，默认情况下，会在阻塞队列的位置执行take方法，直到拿到任务为止。
如果是非核心线程，默认情况下，会在阻塞队列的位置执行poll方法，等待最大空闲时间，如果没任务，删除线程，如果有活，那就正常干。
首先出现异常的工作线程不会影响到其他的工作线程。
工作线程的本质，就是Worker对象。继承AQS跟shutdown和shutdownNow有关系。
如果是shutdown，会中断空闲的工作线程，基于Worker实现的AQS中的state的值来判断能否中断工作线程。如果工作线程的state是0，代表空闲，可以中断，如果是1，代表正在干活。
如果是shutdownNow，直接强制中断所有工作线程
线程池的目的是为了减少线程频繁创建/销毁带来的资源消耗，充分发挥CPU的资源，提升整个系统的性能。不同业务的线程池参考的方式也不一样。
所以线程池的参数设置需要通过压测以及多次调整才能得出具体的。
CountDownLatch本质其实就是一个计数器。在多线程并行处理业务时，需要等待其他线程处理完再做后续的合并等操作时，可以使用CountDownLatch做计数，等到其他线程出现完之后，主线程就会被唤醒。实现过程如下：
import java.util.concurrent.CountDownLatch;public class CountDownLatchTest { public static void main(String[] args) throws InterruptedException { CountDownLatch count = new CountDownLatch(3); for (int i = 0; i < 3; i++) { int finalI = i; new Thread(() -> { try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("线程" + finalI + "执行中"); count.countDown(); }).start(); } count.await(); System.out.println("所有线程都执行完成了"); }}信号量，就是一个可以用于做限流功能的工具类。比如要求当前服务最多3个线程同时干活，将信号量设置为3。每个任务提交前都需要获取一个信号量，获取到就去干活，干完了，归还信号量。实现过程如下：
import java.util.concurrent.Semaphore;public class SemaphoreTest { public static void main(String[] args) { Semaphore semaphore = new Semaphore(3); for (int i = 0; i < 3; i++) { int finalI = i; new Thread(() -> { try { semaphore.acquire(); System.out.println("线程" + finalI + "执行中"); Thread.sleep(5000); } catch (InterruptedException e) { e.printStackTrace(); } finally { semaphore.release(); } }).start(); } new Thread(() -> { try { long begin = System.currentTimeMillis(); semaphore.acquire(); long end = System.currentTimeMillis(); System.out.println("限流了" + (end - begin) + "ms"); } catch (InterruptedException e) { e.printStackTrace(); } finally { semaphore.release(); } }).start(); }}CopyOnWriteArrayList写数据时，是基于ReentrantLock保证原子性的。写数据时，会复制一个副本写入，写入成功后，才会写入到CopyOnWriteArrayList中的数组，保证读数据时，不要出现数据不一致的问题。
缺点就是：如果数据量比较大时，每次写入数据，都需要复制一个副本，对空间的占用太大了。如果数据量比较大，不推荐使用CopyOnWriteArrayList。
适合写操作要求保证原子性，读操作保证并发，并且数据量不大的场景。
JDK1.7里有环（扩容时）。
并发添加数据时会覆盖，数据可能丢失。
在记录元素个数和HashMap写的次数时，记录不准确。
数据迁移，扩容，也可能会丢失数据。
ConcurrentHashMap是懒加载的机制，而且大多数的框架组件都是懒加载的~
基于CAS来保证初始化线程安全的，这里不但涉及到了CAS去修改sizeCtl的变量去控制线程初始化数据的原子性，同时还使用了DCL，外层判断数组未初始化，中间基于CAS修改sizeCtl，内层再做数组未初始化判断。
负载因子是0.75从两个方面去解释。为啥不是0.5，为啥不是1？
0.5：如果负载因子是0.5，数据添加一半就开始扩容了
如果负载因子是1，数据添加到数组长度才开始扩容
0.75就可以说是一个居中的选择，两个方面都兼顾了。
再就是泊松分布，在负载因子是0.75时，根据泊松分布得出，链表长度达到8的概率是非常低的，源码中的标识是0.00000006，生成红黑树的概率特别低。虽然ConcurrentHashMap引入了红黑树，但是红黑树对于写入的维护成本更高，能不用就不用，HashMap源码的注释也描述了，要尽可能规避红黑树。
一般情况下不会造成阻塞。
如果在put操作时，发现当前索引位置并没有数据时，正常把数据落到老数组上。
如果put操作时，发现当前位置数据已经被迁移到了新数组，这时无法正常插入，去帮助扩容，快速结束扩容操作，并且重新选择索引位置查询
这里是基于LongAdder的机制实现，但是并没有直接用LongAdder的引用，而是根据LongAdder的原理写了一个相似度在80%以上的代码，直接使用。
LongAdder使用CAS添加，保证原子性，其次基于分段锁，保证并发性。
无论查哪，都不阻塞。
来源地址：https://blog.csdn.net/qq_28314431/article/details/129067372
--结束END--
本文标题: Java并发编程面试题——JUC专题
本文链接: https://www.lsjlt.com/news/373642.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
下载Word文档到电脑，方便收藏和打印～
2024-04-03
2024-04-03
2024-04-01
2024-01-21
2024-01-21
2024-01-21
2024-01-21
2023-12-23
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
官方手机版
微信公众号
商务合作
0