Java “并发容器框架（Fork/Join）”面试清单（含超通俗生活案例与深度理解）
记得评论区领专属红包🧧
一、Java并发容器相关
1. 请详细说明CopyOnWriteList的实现原理，结合实际场景分析它为什么适合“读多写少”的业务需求？
CopyOnWriteList的核心实现逻辑是“读写分离+写时复制”，它底层维护一个不可变的数组，所有读操作（比如get、contains）都直接访问这个原数组，且读操作全程无锁，不需要线程等待；而当执行写操作（比如add、remove、set）时，会先创建一个与原数组长度相同或+1的新数组，将原数组中的数据完整复制到新数组中，然后在新数组上执行具体的修改操作，修改完成后，再通过一个volatile修饰的引用，将容器底层的数组引用从原数组切换到新数组，同时写操作会通过加锁（ReentrantLock）保证多个写线程串行执行，避免并发修改新数组导致数据错乱。
从这个原理能看出，它的读操作几乎没有性能开销，而写操作需要承担“数组复制”和“加锁串行”的双重开销，这就决定了它只适合读操作远多于写操作的场景。比如系统中的配置项管理，通常系统启动后配置项只会偶尔更新（写），但所有业务线程都会频繁读取配置项（读）；再比如应用的日志展示功能，日志一旦生成就很少会被修改或删除（写），但用户会频繁刷新页面查看日志列表（读）。
用生活中的例子理解更直观：就像小区门口的快递存放架，居民取快递（读操作）时不用跟任何人打招呼，直接去架子上找自己的快递就行，速度很快；而快递员放快递（写操作）时，不会直接在原架子上塞快递，而是先搬一个和原架子一样大的空架子过来，把原架子上的所有快递都挪到新架子上，再把新快递放到新架子的空位里，最后把旧架子撤走，换成新架子，而且放快递时会挂一个“正在整理”的牌子（加锁），避免其他快递员同时过来整理导致混乱。居民取快递（读）永远不排队，但快递员放快递（写）会慢一些，所以如果小区每天只有10个快递要放（写少），但有500个居民取快递（读多），这个架子就很高效；但如果每天有1000个快递要放（写多），快递员频繁搬架子、挪快递，效率就会极低。
2. CopyOnWriteList的迭代器有什么特殊特性？这种特性会带来什么实际影响，适合什么样的使用场景？
CopyOnWriteList的迭代器是“弱一致性迭代器”，它在创建时会保存一份当前容器底层数组的快照，迭代过程中始终访问这份快照，即使后续容器执行了写操作（修改了底层数组引用），迭代器也不会感知到新数组的变化，不会抛出ConcurrentModificationException异常，也不会遍历到新数组中的数据。
这种特性的本质是“迭代器与容器底层数组解耦”，代价是迭代过程中可能读取到“过时数据”，但好处是迭代操作无需加锁，不会阻塞其他读或写操作，保证了读操作的流畅性。比如在电商平台的商品列表页，用户点击“查看全部商品”后，页面会迭代加载商品数据（迭代器工作），此时如果后台更新了某个商品的价格（写操作），用户当前页面加载的商品列表中，该商品的价格还是更新前的旧价格（迭代器访问快照），直到用户刷新页面（重新创建迭代器），才会看到新价格。这种场景下，用户对“实时性要求不高”，更在意页面加载不卡顿，CopyOnWriteList的迭代器就很合适；但如果是银行的账户流水查询，用户需要看到最新的交易记录（实时性要求高），这种迭代器就不适用，因为可能会漏掉刚发生的交易记录。
再举个生活例子：图书馆的图书目录册（迭代器），目录册印刷出来后（创建迭代器），即使图书馆后续新增了几本书（写操作），读者拿着这本目录册也找不到新增的书（迭代器访问快照），只能等到图书馆印刷新的目录册（重新创建迭代器），才能查到新增的图书。对于普通读者来说，只要能找到大部分图书，不需要实时知道最新新增的几本，这种方式没问题；但如果是图书馆管理员需要盘点所有图书（实时性要求高），就不能用旧的目录册，必须去书架上逐本核对（访问最新数据）。
3. 对比CopyOnWriteList、ArrayList和Vector，从线程安全性、性能、适用场景三个维度分析它们的核心差异？
从线程安全性来看：ArrayList完全线程不安全，多个线程同时读写时会出现数据错乱（比如元素丢失、数组越界），甚至抛出ConcurrentModificationException；Vector是线程安全的，它的所有读写方法都用synchronized修饰，保证同一时间只有一个线程能操作；CopyOnWriteList也是线程安全的，通过“读写分离+写时复制”实现，读无锁、写加锁串行。
从性能来看：读操作性能排序为CopyOnWriteList > ArrayList > Vector，因为CopyOnWriteList读无锁，ArrayList读也无锁但线程不安全，Vector读加锁会阻塞；写操作性能排序为ArrayList（线程不安全，无锁）> CopyOnWriteList（写加锁+数组复制）> Vector（写加锁且锁粒度大），ArrayList写无锁但不安全，CopyOnWriteList写需要复制数组，Vector写则是全表加锁，多个写线程只能串行。
从适用场景来看：ArrayList适合单线程环境，或多线程仅读的场景，比如本地工具类中的临时数据存储；Vector适合“读写都不频繁”且需要线程安全的场景，比如早期JDK中的集合使用，现在已很少推荐；CopyOnWriteList适合“读极多、写极少”且对数据实时性要求不高的场景，比如系统配置缓存、日志列表、商品分类列表等。
用生活场景类比：ArrayList就像一个没有管理员的共享笔记本，谁都能随便写（无锁），但多个人同时写会把内容写乱（不安全）；Vector像一个有管理员的笔记本，每次只能一个人写（加锁），其他人要等，但内容不会乱（安全），但所有人都要排队，效率低；CopyOnWriteList像一个“只读笔记本+备用修改本”，大家平时读都看只读笔记本（无锁快），要修改就拿备用本改（复制），改完再替换只读笔记本（加锁防混乱），读的人永远不排队，但改的人要多花时间抄笔记（复制开销）。
4. ConcurrentHashMap在JDK1.7和JDK1.8中的实现有哪些核心差异？这些差异如何影响它的性能？
JDK1.7的ConcurrentHashMap底层采用“Segment数组+HashEntry数组”的双层结构，Segment是一个继承自ReentrantLock的可重入锁，每个Segment对应一个HashEntry数组（即一个“分区”），当执行写操作（put、remove）时，会先通过哈希计算确定当前数据属于哪个Segment，然后只对该Segment加锁，其他Segment不受影响，实现“分段锁”；读操作则无需加锁，通过volatile修饰HashEntry的value保证可见性。但这种结构的锁粒度是“Segment级”，如果多个线程操作的数据恰好落在同一个Segment中，仍会发生锁竞争，且Segment数组的长度在初始化后不可变，无法动态扩容，灵活性较低。
JDK1.8则彻底抛弃了Segment结构，底层采用“Node数组+链表/红黑树”的单层结构，锁粒度缩小到“Node节点级”：写操作时，通过CAS（Compare and Swap）尝试修改节点，如果CAS失败（说明有并发冲突），再对当前Node节点用synchronized加锁，实现“按需加锁”；当链表长度超过8且数组长度大于64时，链表会转化为红黑树，提升查询效率；读操作同样无需加锁，通过volatile修饰Node的value和next指针，保证可见性和有序性。此外，JDK1.8支持动态扩容，扩容时会将原数组的每个Node拆分到新数组的两个位置，且扩容过程中仍能支持读写操作，可用性更高。
这些差异对性能的影响主要体现在锁竞争和查询效率上：JDK1.8的锁粒度更细，同一数组中不同Node节点的写操作可以并行执行，锁竞争概率远低于JDK1.7的Segment锁；红黑树的引入让查询时间复杂度从O(n)降到O(logn)，尤其是数据量较大时，查询速度提升明显；动态扩容也让ConcurrentHashMap能更好地适应数据量变化，避免固定分区导致的资源浪费或不足。
用生活中的超市结账场景类比：JDK1.7的ConcurrentHashMap像超市划分了5个结账区（Segment），每个结账区有10个收银台（HashEntry），顾客结账时只能去对应分区的收银台，且每个分区同一时间只能有一个收银台工作（加锁），其他收银台只能等，即使其他分区空闲，也不能跨区结账；JDK1.8则像超市取消了分区，所有收银台（Node）都能使用，顾客结账时直接找空闲的收银台，只有当某个收银台有人在用（并发冲突）时，才需要等这个人结完（加锁），而且超市会根据顾客数量动态增加收银台（动态扩容），人多的时候还会把排队太长的收银台（链表长度>8）换成快速通道（红黑树），结账效率大幅提升。
5. ConcurrentHashMap的get操作为什么不需要加锁？它是如何保证读取到的数据是最新的？
ConcurrentHashMap的get操作不需要加锁，核心依赖volatile关键字的内存可见性特性，以及底层数据结构的设计：在JDK1.7中，HashEntry类的value字段被volatile修饰，当某个线程修改了HashEntry的value后，volatile会保证这个修改立刻被写入主内存，其他线程读取value时会从主内存获取，而不是从线程本地缓存读取，从而看到最新值；同时，Segment数组的引用是final的，HashEntry数组的引用也是final的，保证了数组结构不会被并发修改，避免了读操作时数组结构变化导致的异常。
在JDK1.8中，Node类的value字段和next指针都被volatile修饰，除了保证value的可见性外，next指针的volatile还能防止指令重排序，确保线程读取链表或红黑树时，节点之间的关联关系是正确的（比如不会出现“某个节点的next指针指向未初始化的节点”的情况）。此外，JDK1.8的红黑树结构中，节点的颜色、父节点、左右子节点等字段虽未被volatile修饰，但红黑树的修改操作（如旋转、变色）都是在加锁的情况下执行的，且修改后会通过volatile的next指针传递可见性，确保读操作能看到完整的红黑树结构。
简单来说，get操作不需要加锁的原因是“读取的是不可变或被volatile修饰的字段”，底层结构的修改要么在加锁下执行，要么通过volatile保证可见性，不会出现“读操作看到半修改状态的数据”的情况。比如生活中，超市货架上的商品价签（value）用荧光笔标注（volatile），只要价签被修改（写操作），顾客（读操作）一眼就能看到最新价格，不需要等店员（锁）允许才能看；而且货架的结构（数组）不会随便变动，顾客找商品时不会因为货架突然移位而找不到。
6. ConcurrentHashMap为什么不允许存储null键和null值？这一点和HashMap、Hashtable有什么区别？
ConcurrentHashMap不允许存储null键和null值，核心原因是“避免null值带来的歧义”：在并发场景下，如果允许null值，当get方法返回null时，无法判断是“键不存在”还是“键存在但值为null”，这会给业务逻辑带来混乱。比如线程A调用put(null, "test")，线程B调用get(null)返回null，此时线程B无法确定是线程A的put操作还没执行（键不存在），还是线程A已经执行了put但值被其他线程改成了null（键存在但值为null），这种歧义在并发环境下难以解决，可能导致业务错误。此外，ConcurrentHashMap的设计目标是用于高并发的业务场景（如分布式缓存、服务间数据传递），这些场景对数据的准确性要求极高，不允许存在模糊的null值语义。
而HashMap允许存储null键和null值，因为它是单线程或低并发场景下的集合，get返回null时，虽然也有“键不存在”和“值为null”的歧义，但可以通过containsKey方法先判断键是否存在（如if (map.containsKey(key)) { ... } else { ... }），在单线程环境下这种判断是可靠的；Hashtable则不允许存储null键和null值，它的原因是早期设计时为了避免null值导致的空指针异常，比如Hashtable的put方法会直接检查key和value是否为null，若为null则抛出NullPointerException，和ConcurrentHashMap的“避免歧义”原因不同。
用生活例子理解：ConcurrentHashMap像银行的账户系统，每个账户（键）必须有明确的余额（值），不能出现“账户存在但余额为null”或“没有账户但显示余额为null”的情况，否则银行无法判断用户是否有钱；HashMap像个人的记账本，允许记录“某笔支出（键）还没确定金额（值为null）”，因为个人记账是单线程操作，后续可以手动确认金额；Hashtable则像早期的手写账本，记账人不允许写“无”（null），必须写具体数字，否则会被认为是记账错误。
7. 分析CopyOnWriteArraySet的实现原理，它和CopyOnWriteList有什么关联？为什么它的add操作效率比HashSet低？
CopyOnWriteArraySet的底层是通过“委托CopyOnWriteList实现的”，它内部维护一个CopyOnWriteList实例，所有核心操作（如add、remove、contains）都直接调用CopyOnWriteList的对应方法，比如add方法会调用CopyOnWriteList的addIfAbsent方法，确保集合中不会有重复元素（Set的核心特性）。也就是说，CopyOnWriteArraySet本质是“基于CopyOnWriteList实现的去重集合”，它的线程安全性、读写特性都和CopyOnWriteList一致，同样是“读多写少”场景的优化方案。
CopyOnWriteArraySet的add操作效率比HashSet低，核心原因是“去重逻辑的实现方式不同”：HashSet底层基于HashMap，判断元素是否存在时，通过哈希计算直接定位到元素所在的桶（时间复杂度O(1)），add操作只需先判断桶中是否有该元素，没有则直接插入，效率很高；而CopyOnWriteArraySet的add操作依赖CopyOnWriteList的addIfAbsent方法，该方法需要遍历整个数组（时间复杂度O(n)）来判断元素是否存在，只有遍历完所有元素确认不存在后，才会执行写操作（复制数组+插入元素）。当集合中元素数量较多时，遍历数组的开销会显著增加，导致add操作效率远低于HashSet。
比如生活中的两种收纳盒：HashSet像带标签的抽屉收纳盒，每个物品（元素）都有专属标签（哈希值），要放新物品时，根据标签直接找到对应的抽屉，打开看有没有相同物品（O(1)），没有就放进去；CopyOnWriteArraySet像一个无标签的大箱子，要放新物品时，必须把箱子里所有物品都倒出来逐个检查（O(n)），确认没有相同的才能放回去，物品越多，检查时间越长，效率越低。不过，CopyOnWriteArraySet的优势在于读操作无锁，适合读多写少且元素数量不多的场景，比如系统中的角色权限集合（权限数量少，频繁检查是否有某个权限，偶尔新增权限）。
二、Fork/Join框架相关
8. 什么是Fork/Join框架？它的核心组成部分有哪些？每个组成部分的作用是什么？
Fork/Join框架是Java7引入的一种用于并行执行“分治任务”的框架，它的核心思想是“将一个规模庞大、可拆分的大任务，按照预设的阈值拆分成多个独立的小任务，然后通过多线程并行执行这些小任务，最后汇总所有小任务的执行结果，得到大任务的最终结果”，本质是通过“分而治之”的策略充分利用CPU多核资源，提升任务执行效率。
Fork/Join框架的核心组成部分包括ForkJoinPool、ForkJoinTask、工作窃取算法，它们的作用分别如下：
第一，ForkJoinPool是框架的“线程池”，负责管理线程和任务队列，它内部维护一个由ForkJoinWorkerThread组成的线程集合，以及每个线程对应的双端任务队列（Deque）；ForkJoinPool的主要作用是接收用户提交的ForkJoinTask任务，将任务分配到线程的任务队列中，同时协调线程执行任务和进行工作窃取，确保线程资源被充分利用，避免空闲。
第二，ForkJoinTask是框架中的“任务抽象类”，所有需要通过Fork/Join框架执行的任务都必须继承这个类，它定义了任务的核心行为——fork()和join()方法；fork()方法用于“拆分任务”，即当一个任务规模超过阈值时，调用fork()创建子任务，并将子任务提交到当前线程的任务队列中；join()方法用于“汇总结果”，即等待子任务执行完成，并获取子任务的执行结果；根据任务是否需要返回结果，ForkJoinTask又分为两个子类：RecursiveTask（有返回值，用于需要汇总结果的任务）和RecursiveAction（无返回值，用于仅需执行操作、无需结果的任务）。
第三，工作窃取算法是框架的“线程调度策略”，用于解决“线程任务分配不均”的问题；当ForkJoinPool中的某个线程（ForkJoinWorkerThread）执行完自己任务队列中的所有任务后，它会成为“空闲线程”，此时它会主动去其他线程的任务队列尾部“窃取”一个任务来执行，而被窃取任务的线程则从自己队列的头部获取任务，这样既避免了空闲线程浪费CPU资源，又通过“头部取自己任务、尾部偷他人任务”的方式减少了线程间的竞争，提升了整体执行效率。
用生活中的“公司年会筹备”例子理解：Fork/Join框架就像年会筹备组，大任务是“完成年会的所有筹备工作”；ForkJoinPool是筹备组组长，负责分配人员（线程）和任务；ForkJoinTask是具体的筹备任务，比如“场地布置任务”“节目编排任务”；其中“节目编排任务”需要返回节目单（RecursiveTask），“场地布置任务”只需布置好场地无需返回结果（RecursiveAction）；工作窃取算法就像如果负责“采购零食”的员工提前完成了任务（空闲线程），就主动去帮负责“制作邀请函”的员工写邀请函（窃取任务），而负责“制作邀请函”的员工继续从自己的待办清单头部拿任务（写剩下的邀请函），这样所有员工都在忙碌，筹备效率更高。
9. 请详细解释Fork/Join框架中的“分而治之”思想，结合一个原创的实际场景说明如何通过分而治之拆分任务，以及拆分时需要注意什么？
Fork/Join框架中的“分而治之”思想，是将一个“规模大、难以单线程快速完成”的复杂任务，拆解成多个“规模小、逻辑独立、与原任务性质相同”的子任务，每个子任务可以单独执行，且子任务的执行结果汇总后能得到原任务的结果；拆解过程是递归的，即如果子任务的规模仍然超过预设的阈值，会继续将子任务拆分成更小的子任务，直到所有子任务的规模都小于等于阈值，再开始执行子任务并汇总结果。
比如实际场景中的“大型商场单日销售额统计”：假设商场有10个楼层，每个楼层有20家店铺，单日总销售额统计（大任务）如果让1个财务人员（单线程）统计，需要逐个楼层、逐个店铺核对销售数据，耗时8小时；用分而治之思想拆分的话，首先将大任务拆分成“10个楼层销售额统计子任务”（每个子任务对应1个楼层），如果预设阈值是“1个楼层”（即子任务规模≤1个楼层时不再拆分），就可以让10个财务助理（线程）分别统计1个楼层的销售额（每个助理统计自己负责楼层的20家店铺），每个助理耗时1小时；所有助理统计完成后，将10个楼层的销售额相加，得到商场单日总销售额（汇总结果），总耗时仅1小时（统计）+10分钟（汇总）=1小时10分钟，效率提升近7倍。
如果某个楼层的店铺数量特别多（比如30家），预设阈值是“15家店铺”，那么“该楼层销售额统计子任务”的规模（30家）超过阈值，需要继续拆分成“2个15家店铺的子任务”，让2个财务助理分别统计这15家店铺的销售额，再将两个子任务的结果相加，得到该楼层的销售额，这就是递归拆分。
拆分任务时需要注意三个核心点：第一，拆分后的子任务必须“相互独立”，即子任务的执行结果不会影响其他子任务，比如统计A楼层销售额和统计B楼层销售额互不干扰，这样才能并行执行；第二，要设置合理的“拆分阈值”，阈值太大可能导致子任务数量过少，无法充分利用CPU多核（比如阈值设为10个楼层，只拆分成1个任务，还是单线程执行），阈值太小则会导致任务拆分过细，拆分和汇总的开销超过并行收益（比如将10个楼层拆分成200个店铺子任务，财务助理们需要频繁汇报结果，汇总时间比统计时间还长）；第三，任务必须“可拆分”，即大任务的逻辑能均匀拆分成小任务，比如销售额统计可以按楼层、按店铺拆分，但像“处理客户投诉”这样的任务，每个投诉的处理逻辑不同，无法拆分成独立子任务，就不适合用分而治之。
10. Fork/Join框架中的工作窃取算法具体是如何执行的？它能解决什么问题？在什么情况下工作窃取算法的效率会降低？
Fork/Join框架中工作窃取算法的执行流程可以分为四个步骤：第一步，ForkJoinPool初始化时，会创建多个ForkJoinWorkerThread线程，每个线程都会初始化一个专属的双端任务队列（Deque），用于存放该线程需要执行的任务；第二步，当用户提交一个ForkJoinTask任务到ForkJoinPool后，Pool会将任务分配到某个线程的任务队列头部；第三步，线程在执行任务时，会从自己任务队列的头部弹出任务并执行，如果执行过程中通过fork()方法创建了子任务，会将子任务加入到当前线程的任务队列头部（保证子任务优先执行）；第四步，当某个线程的任务队列为空（任务执行完毕，成为空闲线程）时，它会随机选择一个其他线程的任务队列，从该队列的尾部弹出一个任务（窃取任务）并执行，直到所有任务队列都为空。
工作窃取算法主要解决“线程任务负载不均”的问题：在没有工作窃取的情况下，如果线程A的任务队列有10个任务，线程B的任务队列为空，线程B会一直空闲，而线程A需要长时间执行，导致CPU资源浪费；有了工作窃取后，线程B会主动窃取线程A的任务，两者并行执行，充分利用CPU多核资源，缩短整体任务执行时间。比如快递站点有3个快递员（线程），快递员A有20个快递要送（任务队列），快递员B和C都没有快递（空闲），没有工作窃取时，B和C只能等着，A要送2小时；有工作窃取时，B和C会各从A的快递列表尾部拿5个快递，3人各送10个、5个、5个快递，1小时就能送完，效率翻倍。
但在两种情况下，工作窃取算法的效率会降低：第一，任务拆分过细时，每个任务的执行时间很短，线程需要频繁窃取任务，而窃取任务时需要检查其他线程的任务队列，这个过程会产生额外开销，当开销超过并行执行的收益时，效率会下降；比如将20个快递拆分成200个“送1件快递的小任务”，快递员送完1个任务就要立刻去偷下一个，频繁偷任务的时间比送快递的时间还长，反而低效。第二，任务存在“依赖关系”时，比如子任务A需要等待子任务B执行完成才能执行，即使有空闲线程窃取了子任务A，也只能等着子任务B完成，无法真正执行，导致工作窃取失效；比如快递员B窃取了“送客户甲的快递”任务，但这个快递需要先等快递员A送完“客户甲的前置包裹”才能送，B只能等着A，无法执行任务，相当于白窃取了。
11. RecursiveTask和RecursiveAction有什么核心区别？分别适合什么样的任务场景？请结合原创例子说明如何使用这两个类实现任务。
RecursiveTask和RecursiveAction的核心区别在于“任务是否需要返回执行结果”：RecursiveTask是有返回值的任务类，它继承自ForkJoinTask，泛型参数指定返回值类型，需要重写compute()方法，该方法的返回值就是任务的执行结果，适合用于需要汇总子任务结果的场景；RecursiveAction是无返回值的任务类，同样继承自ForkJoinTask，不需要指定泛型，重写的compute()方法返回值为void，适合用于仅需执行具体操作、无需返回结果的场景。
比如场景一：“统计某学校所有学生的平均身高”（需要返回结果），适合用RecursiveTask。具体实现时，创建一个继承RecursiveTask的类（比如StudentHeightTask），泛型参数Double表示返回平均身高；compute()方法中，先判断当前任务的学生数量是否超过阈值（比如50人），如果不超过，直接计算这部分学生的身高总和和人数，返回总和/人数（平均身高）；如果超过阈值，将学生列表拆分成两部分，创建两个StudentHeightTask子任务，调用fork()方法提交子任务，再通过join()方法获取两个子任务的平均身高，最后计算两个子任务的平均身高的平均值（比如子任务A平均165cm，子任务B平均170cm，总平均167.5cm），作为当前任务的返回值。
场景二：“给某学校所有学生发放新学期通知书”（无需返回结果），适合用RecursiveAction。具体实现时，创建一个继承RecursiveAction的类（比如SendNoticeTask），重写compute()方法；方法中判断当前任务的学生数量是否超过阈值（比如50人），如果不超过，直接逐个给学生发放通知书（执行具体操作）；如果超过阈值，将学生列表拆分成两部分，创建两个SendNoticeTask子任务，调用fork()方法提交子任务，无需调用join()方法（因为无需汇总结果），子任务执行完成后，发放通知书的操作就完成了。
再用生活中的例子对比：RecursiveTask像“家庭聚餐前统计每个人想吃的菜”，需要每个人（子任务）反馈想吃的菜（返回结果），最后汇总成菜单（总结果）；RecursiveAction像“家庭聚餐后每个人收拾自己的碗筷”，每个人（子任务）只需完成收拾动作（无返回结果），不需要反馈，所有人收拾完任务就结束了。
12. 在实现Fork/Join任务时，compute()方法的核心逻辑是什么？如果任务拆分后，某个子任务执行过程中抛出异常，会导致什么后果？如何处理这种异常？
在实现Fork/Join任务时，compute()方法的核心逻辑是“判断+拆分+执行+汇总”，具体分为四个步骤：第一步，判断当前任务的规模是否小于等于预设的拆分阈值，如果是，说明任务足够小，可以直接执行，计算并返回结果（RecursiveTask）或执行操作（RecursiveAction）；第二步，如果任务规模超过阈值，将当前任务拆分成两个或多个子任务（子任务的类型与当前任务一致，比如RecursiveTask的子任务也是RecursiveTask），拆分时需要保证子任务的规模之和等于原任务规模，且子任务相互独立；第三步，调用子任务的fork()方法，将子任务提交到当前线程的任务队列中，由ForkJoinPool调度线程执行子任务；第四步，对于RecursiveTask，调用子任务的join()方法等待子任务执行完成，并获取子任务的返回结果，然后汇总所有子任务的结果，作为当前任务的返回结果；对于RecursiveAction，无需调用join()方法，子任务执行完成后当前任务即完成。
比如实现“计算1到1000的整数和”的RecursiveTask任务，compute()方法的逻辑就是：判断当前任务的起始值和结束值的差值（比如1到1000，差值999）是否超过阈值（比如100），超过则拆分成1到500和501到1000两个子任务，调用fork()提交子任务，再用join()获取两个子任务的和（比如1到500的和是125250，501到1000的和是375250），汇总得到125250+375250=500500，作为当前任务的返回值；如果差值不超过阈值（比如1到100，差值99），直接循环计算1到100的和（5050）并返回。
如果某个子任务执行过程中抛出异常，会导致该子任务的join()方法抛出ExecutionException异常（因为ForkJoinTask会将子任务的异常封装成ExecutionException），如果不处理这个异常，会导致当前任务的执行中断，进而影响整个大任务的执行，甚至导致最终无法得到汇总结果。比如统计学校学生平均身高时，某个子任务在计算身高时，遇到一个学生的身高数据是负数（非法数据），抛出IllegalArgumentException，该子任务的join()方法会抛出ExecutionException，如果当前任务不处理这个异常，就无法获取该子任务的平均身高，也就无法汇总总平均身高。
处理这种异常的方法有两种：第一，在compute()方法中，调用子任务的join()方法时，用try-catch块捕获ExecutionException，在catch块中处理异常，比如设置默认值（如果子任务统计失败，默认该部分学生的平均身高为全校平均身高的预估 value），或者记录异常日志后跳过该子任务（如果子任务数据不重要）；第二，在提交ForkJoinTask任务到ForkJoinPool后，通过Future的get()方法获取最终结果时，捕获ExecutionException，在外部统一处理异常，比如返回错误提示给用户，或者重新执行整个任务。
用生活例子理解：比如公司组织员工体检报告汇总，某个部门的体检报告统计（子任务）时，发现有一份报告数据损坏（抛出异常），如果不处理，整个公司的体检汇总报告就无法完成；处理方式可以是，统计该部门时，忽略损坏的报告，用该部门其他员工的平均数据代替（try-catch中设置默认值），或者记录下损坏的报告编号，汇总时注明“该部门有1份报告损坏，未统计”（记录日志），确保整个汇总任务能继续完成。
13. ForkJoinPool和普通的ThreadPoolExecutor（如Executors创建的线程池）有什么核心区别？在什么场景下选择Fork/Join框架而不是普通线程池？
ForkJoinPool和普通ThreadPoolExecutor的核心区别主要体现在任务处理方式、线程调度策略、适用任务类型三个方面：
从任务处理方式来看，ThreadPoolExecutor处理的是“独立任务”，即提交给线程池的每个任务都是独立的，线程池会将任务分配给空闲线程执行，任务之间没有关联，也不能拆分；而ForkJoinPool处理的是“可拆分的分治任务”，提交的大任务可以通过fork()方法拆分成多个子任务，子任务之间相互关联（汇总结果），线程池会协调子任务的执行和结果汇总。
从线程调度策略来看，ThreadPoolExecutor采用“任务队列+空闲线程”的调度方式，任务提交到公共队列，空闲线程从队列头部获取任务执行，当某个线程执行完任务后，继续从公共队列获取任务，若队列空则线程阻塞等待；而ForkJoinPool采用“线程私有双端队列+工作窃取”的调度方式，每个线程有自己的任务队列，线程优先执行自己队列的任务，空闲线程会窃取其他线程队列的任务，避免线程阻塞，资源利用率更高。
从适用任务类型来看，ThreadPoolExecutor适合处理“大量独立、小规模、执行时间较短”的任务，比如处理HTTP请求、发送消息等；而ForkJoinPool适合处理“单个规模大、可拆分、执行时间较长”的分治任务，比如大数据量计算（统计、排序）、文件批量处理（遍历文件夹）等。
在以下场景下选择Fork/Join框架而不是普通线程池：第一，任务规模庞大且可拆分成独立子任务，比如计算1亿个整数的总和，普通线程池只能单线程执行整个任务，而Fork/Join可以拆分成多个子任务并行执行；第二，任务执行时间较长且需要充分利用CPU多核资源，比如批量处理10万个文件，每个文件处理需要1分钟，普通线程池若线程数少则耗时久，Fork/Join通过工作窃取让所有CPU核心都忙碌，缩短总耗时；第三，任务需要汇总子任务结果，比如统计多个地区的用户活跃度，需要将每个地区的统计结果相加得到总活跃度，Fork/Join的join()方法能方便汇总结果，而普通线程池需要手动实现结果汇总逻辑（如用CountDownLatch+ConcurrentHashMap），代码更复杂。
比如生活中的“搬家”场景：普通ThreadPoolExecutor像找几个搬家工人（线程），每个工人负责搬一个独立的家具（独立任务），搬完自己的家具就等下一个家具，没有家具就等着；Fork/Join框架像找几个工人搬一个大衣柜（大任务），工人先把大衣柜拆成柜门、柜体、抽屉（子任务），每人搬一个部件（并行执行），到新家后再把部件组装成大衣柜（汇总结果），如果某个工人先搬完自己的部件，会去帮其他工人搬（工作窃取），效率更高。如果只是搬几个小家具（独立小任务），用普通线程池就行；如果搬大衣柜（大分治任务），用Fork/Join框架更合适。
14. 使用Fork/Join框架时，如何设置合理的拆分阈值？如果阈值设置过大或过小，分别会带来什么问题？请结合例子说明。
使用Fork/Join框架时，设置合理的拆分阈值需要考虑两个核心因素：“任务的执行时间”和“拆分与汇总的开销”，通常的原则是“让每个子任务的执行时间略大于拆分与汇总的开销”，确保并行执行的收益能覆盖拆分开销，一般通过测试不同阈值下的任务执行时间，选择总耗时最短的阈值；同时，阈值也不宜过小（避免拆分过细）或过大（避免并行不足），通常可以参考CPU核心数，比如将阈值设置为“总任务量/（CPU核心数*2）”，确保每个CPU核心能处理2个左右的子任务，充分利用资源。
如果阈值设置过大，会导致任务拆分次数过少，子任务数量不足，无法充分利用CPU多核资源，并行优势无法发挥，甚至退化为单线程执行。比如计算1到10000的整数和，CPU核心数为4，若阈值设置为5000，大任务会拆分成2个子任务（1到5000和5001到10000），此时只能用到2个CPU核心，另外2个核心空闲，总执行时间相当于2个核心并行执行的时间，而不是4个核心的时间，并行效率大打折扣；如果阈值设置为10000（比总任务量还大），则不会拆分任务，只有1个核心执行整个任务，完全没有并行优势，耗时和单线程一样。
如果阈值设置过小，会导致任务拆分过细，子任务数量过多，拆分和汇总的开销超过并行执行的收益，反而导致总执行时间增加。比如同样计算1到10000的整数和，若阈值设置为10，大任务会拆分成1000个子任务（每个子任务计算10个整数的和），此时虽然能用到4个核心，但每个子任务的执行时间极短（仅需几纳秒），而拆分1000个子任务、调用1000次fork()和join()方法的开销（如线程调度、结果传递）却很大，总耗时（拆分开销+执行时间+汇总开销）反而比阈值设置为500时更长；极端情况下，若阈值设置为1，会拆分成10000个子任务，拆分开销会远大于执行时间，总耗时甚至比单线程还长。
用生活中的“包饺子”例子理解：家里有4个人（CPU核心数4），要包100个饺子（大任务），拆分阈值是“每人每次包的饺子数”。如果阈值设置为50（过大），会拆分成2份（每份50个），只有2个人包饺子，另外2人闲着，1小时才能包完；如果阈值设置为2（过小），会拆分成50份（每份2个），4人频繁拿面团、擀皮、包饺子，每次包2个就要换一份面团，光换面团的时间（拆分开销）就占了半小时，1小时也只能包完80个；如果阈值设置为25（合理），拆分成4份（每份25个），4人各包25个，不用频繁换面团，40分钟就能包完100个，效率最高。
15. 请举一个Fork/Join框架的实际应用场景，并详细说明如何设计任务、拆分任务、执行任务和汇总结果，以及在这个过程中需要注意的问题。
Fork/Join框架的一个实际应用场景是“遍历某个目录下所有文件，统计指定后缀名（如.txt）的文件总大小”，该场景中，“统计目录下所有.txt文件总大小”是大任务，目录下的每个子目录或文件可以作为子任务，符合“可拆分、独立执行、可汇总”的分治任务特点。
具体实现步骤如下：
第一步，设计任务类：由于需要返回文件大小（结果），选择继承RecursiveTask，泛型Long表示返回文件大小（单位字节），任务类命名为FileSizeTask，构造方法接收一个File对象（当前要处理的目录或文件），重写compute()方法实现核心逻辑。
第二步，拆分任务的逻辑（compute()方法）：首先判断当前File对象是文件还是目录，如果是文件，且文件后缀名为.txt，直接返回文件的长度（该文件的大小）；如果是文件但后缀名不是.txt，返回0（不统计）；如果是目录，获取该目录下的所有子File对象（子目录或文件），判断子File对象的数量是否超过阈值（比如10个，即目录下子文件/子目录数量≤10时不拆分，直接处理）；如果不超过阈值，循环处理每个子File对象，累加所有.txt文件的大小，返回累加结果；如果超过阈值，创建多个FileSizeTask子任务（每个子任务对应一个子File对象），调用fork()方法提交所有子任务，然后循环调用每个子任务的join()方法获取子任务的文件大小，累加所有子任务的结果，返回累加总和（当前目录下所有.txt文件的总大小）。
第三步，执行任务：创建ForkJoinPool实例（可使用默认构造方法，自动根据CPU核心数设置线程数），创建根FileSizeTask任务（传入要遍历的根目录，如new File("D:/test")），调用ForkJoinPool的submit()方法提交根任务，得到Future对象。
第四步，汇总结果：调用Future的get()方法获取根任务的执行结果，该结果就是根目录下所有.txt文件的总大小，将结果转换为MB或GB（1MB=1024*1024字节），输出给用户。
在这个过程中需要注意三个问题：第一，处理目录时可能遇到“权限不足”的异常，比如某个子目录无法访问，会抛出SecurityException，需要在compute()方法中捕获异常，返回0并记录日志，避免整个任务中断；第二，阈值设置要合理，若目录下子文件数量少（如每个目录只有2-3个文件），阈值设置为10会导致很少拆分，若目录下子文件数量多（如每个目录有100个文件），阈值设置为10会拆分成10个子任务，充分利用并行；第三，避免重复处理文件，比如某个文件被多个子任务同时处理，这里由于每个子任务对应独立的子File对象，不会出现重复处理，无需额外处理。
比如生活中的“统计某栋楼所有家庭的用电量”场景：根任务是“统计1号楼所有家庭的用电量”，每个单元（子目录）是子任务，每个家庭（文件）是更小的子任务；如果1号楼有5个单元，每个单元有20户，阈值设置为10户，那么“统计1单元用电量”的子任务会拆分成2个“统计10户用电量”的子任务，每个子任务统计10户的用电量，汇总得到1单元总用电量，最后将5个单元的用电量相加，得到1号楼总用电量；过程中如果某户没人（权限不足），就统计为0并记录，确保整个统计任务能完成。