任务不返回结果是因为用了execute()而非submit()，或任务未正确返回值；future.get()阻塞或抛executionexception需检查异常原因并统一收集后调用。
主从模式用 ExecutorService + Future 实现时，为什么任务不返回结果？
主从模式的核心是“主节点分发、从节点执行、主节点汇总”，Java 里最常用的是提交任务到线程池，再用 Future 拿结果。但很多人写完发现 future.get() 一直阻塞，或返回 null —— 通常是因为任务本身没正确返回值，或者用了 execute() 而非 submit()。
实操建议：
立即学习“Java免费学习笔记（深入）”；
-
ExecutorService.execute(Runnable)不返回Future，必须用submit(Callable<t>)</t>或submit(Runnable, result)才能取结果 - 如果从节点逻辑抛了未捕获异常，
future.get()会直接抛ExecutionException，不是返回null；要 catch 并检查e.getCause() - 别在循环里对每个
Future立即调get()，否则变成串行；应先 collect 所有Future，再统一 get（或用invokeAll()） - 示例关键片段：
List<Future<Integer>> futures = service.invokeAll(tasks);<br>for (Future<Integer> f : futures) {<br> result.add(f.get()); // 这里才真正阻塞并取值<br>}
分治模式用 ForkJoinPool 时，compute() 方法卡死或栈溢出
ForkJoinPool 依赖任务拆分和合并，但 compute() 写错就容易无限递归或无法收敛。典型现象是 CPU 占满、线程无响应，或者抛 StackOverflowError。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 必须设置合理的阈值（threshold），在数据量小到一定程度时直接计算，而不是继续 fork；比如处理数组时，
if (end - start -
fork()和join()要配对：先fork()子任务，再join()获取结果；不能反过来，也不能只fork()不join() - 避免在
compute()中做阻塞操作（如 IO、锁等待），ForkJoinPool的工作线程不是为阻塞设计的，会导致吞吐骤降甚至死锁 - 默认使用
ForkJoinPool.commonPool()，但若任务可能长时间阻塞，应显式创建带足够并行度的独立池：new ForkJoinPool(4)
主从 vs 分治：选错模式导致线程数失控或资源耗尽
两者都并发，但调度逻辑完全不同：主从是“固定角色 + 显式协调”，分治是“无状态任务 + 隐式工作窃取”。选错会立刻暴露在线程模型上。
eSiteGroup站群管理系统是基于eFramework低代码开发平台构建，是一款高度灵活、可扩展的智能化站群管理解决方案，全面支持SQL Server、SQLite、MySQL、Oracle等主流数据库，适配企业级高并发、轻量级本地化、云端分布式等多种部署场景。通过可视化建模与模块化设计，系统可实现多站点的快速搭建、跨平台协同管理及数据智能分析，满足政府、企业、教育机构等组织对多站点统一管控的
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 主从适合有明确阶段划分的场景，比如“读配置 → 启动 N 个采集器 → 汇总上报”，此时用
ExecutorService配合CountDownLatch或CyclicBarrier更自然；硬套ForkJoinPool反而难控制生命周期 - 分治适合可均匀切分、无共享状态的计算密集型任务，比如归并排序、树遍历、大规模数值计算；若任务之间要频繁通信或共享变量，
ForkJoinTask的不可变性会让你不断绕弯子 - 主从模式下线程池大小通常设为业务从节点数（如 5 个采集器就用
newFixedThreadPool(5)）；分治则依赖parallelism参数，一般设为 CPU 核心数，设太大反而因上下文切换拖慢速度 - 监控时注意：
ExecutorService的队列积压（getQueue().size()）和ForkJoinPool的偷窃失败率（getStealCount()）是两类不同瓶颈信号
混合使用 CompletableFuture 和 ForkJoinPool 的陷阱
有人想“用 CompletableFuture 做主从编排，内部用 ForkJoinPool 加速子计算”，结果发现异步链莫名中断、异常丢失，或线程池被意外关闭。
实操建议：
立即学习“Java免费学习笔记（深入）”；
-
CompletableFuture.supplyAsync(..., pool)的pool参数必须传自定义的ForkJoinPool实例，不能传ForkJoinPool.commonPool()—— 因为后者会被 JVM 全局共享，其他库（如 Stream.parallel()）也可能用它，干扰你的任务调度 - 不要在
thenApply等回调里直接调join()，这会阻塞当前线程；应继续用thenCompose链式转异步，或用thenApplyAsync指定线程池 -
CompletableFuture默认异常会静默吞掉（除非显式exceptionally或whenComplete），而ForkJoinTask的异常会传播到join()；混用时务必统一错误处理路径 - 一个易忽略点：如果
ForkJoinPool是手动shutdown()的，而CompletableFuture还在用它提交任务，会直接抛RejectedExecutionException，且不会重试
事情说清了就结束。主从和分治不是性能高低问题，而是“谁该知道谁的存在”这个责任边界问题；边界画错，再多的 parallelism 参数和线程池配置都救不回来。
