应优先选用ForkJoinPool处理可递归拆分的CPU密集型计算任务（如归并排序、树遍历），但须满足无阻塞、无共享状态、子任务粒度适中（>100μs）等条件；否则应选ThreadPoolExecutor。
什么时候该用 ForkJoinPool 而不是 ThreadPoolExecutor
当你处理的是可递归拆分的计算型任务（比如归并排序、树遍历、大数组求和），且子任务之间无共享状态、无 I/O 等阻塞操作时，ForkJoinPool 才有优势。它靠工作窃取（work-stealing）缓解线程空闲，但代价是调度开销更大、调试更难。
- 别用在数据库查询、HTTP 调用、文件读写这类阻塞任务上——
ForkJoinPool的线程默认是daemon且不支持配置为可阻塞，容易卡死或提前退出 - 子任务粒度不能太小：拆成百万个
ForkJoinTask比直接 for 循环还慢；一般建议单个子任务耗时 > 100μs - 如果任务间要频繁同步（如共享
ConcurrentHashMap计数），性能反而不如普通线程池——ForkJoinPool不解决竞争，只优化 CPU 密集型分治
RecursiveTask 和 RecursiveAction 怎么选
看任务要不要返回结果：RecursiveTask<t></t> 用于有返回值的场景（如求和、找最大值），RecursiveAction 用于纯执行（如对数组每个元素做变换、DFS 遍历打日志）。
-
RecursiveTask必须重写compute()并返回T；漏掉return或返回null（而泛型非Object）会导致NullPointerException或类型擦除后运行时异常 - 两者都**不能**在
compute()里直接调用fork()后就 return——必须显式调用join()获取结果（RecursiveAction用invoke()或配对fork()/join()） - 错误写法示例：
protected Long compute() { if (end - start <= THRESHOLD) return sumRange(start, end); int mid = (start + end) / 2; RecursiveTask<Long> left = new SumTask(arr, start, mid); left.fork(); // ❌ 忘了 join，这里直接 return 会丢结果 return left.compute(); // ❌ 这行实际没触发 fork，退化成单线程 }
怎么设置合适的阈值（THRESHOLD）避免过度拆分
阈值决定“多大时停止 fork，改用串行计算”。设得太小，任务调度开销压倒计算收益；设太大，又无法充分利用多核。没有银弹，得结合数据规模和单次计算成本实测。
sc-java-to-ts-interface
下载
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
- 常见误区：把阈值固定写成
100或1000——实际应基于「单次串行计算耗时」评估。例如对 long 数组求和，每轮加法约 1ns，那么处理 1000 个元素才 ~1μs，远低于线程调度开销（通常 10–100μs），此时阈值至少设到10_000起步 - 可以用 JVM 参数
-Djava.util.concurrent.ForkJoinPool.common.parallelism=4控制并行度，但别指望靠调这个解决阈值问题——它只影响线程数，不影响任务拆分逻辑 - 调试时加一行日志：
System.out.println("task [" + start + "," + end + ") split? " + (end - start > THRESHOLD));，观察实际拆分深度是否合理
为什么用了 ForkJoinPool 还是单线程跑
最常见原因是任务没真正提交到池中执行，或者池被误用。不是 new 了 ForkJoinPool 就自动并行。
立即学习“Java免费学习笔记（深入）”；
- 忘了调
pool.invoke(task)或task.invoke()，而是直接调task.compute()—— 这等于手动递归，完全绕过 Fork/Join 调度 - 用了公共池（
ForkJoinPool.commonPool()），但 JVM 启动参数设置了-Djava.util.concurrent.ForkJoinPool.common.parallelism=1，或运行环境本身只有 1 个可用 CPU - 任务抛了未捕获异常（如
ArrayIndexOutOfBoundsException），导致join()阻塞等待一个永远不会完成的任务——建议在compute()外层包 try-catch，并记录getRawResult()或getException()
分治不是万能加速器，关键在拆得合理、合得及时、边界清晰。最容易被忽略的，是把“能递归”当成“该并行”——先确认单机 CPU 密集瓶颈是否存在，再动 Fork/Join。
