join() 本质是让当前线程等待目标线程终止，不控制并行度；并行度由线程创建数量决定，join仅协调执行顺序，用于结果依赖场景，真正限流应使用线程池等机制。
join 不是用来控制并行度的
Java 中的 join() 方法本身不控制并行度，它只负责「等待」——让调用它的线程暂停执行，直到目标线程终止。并行度（比如同时跑几个线程）由你创建和启动线程的数量决定，不是 join 控制的。很多人误以为调用 join 就能让多线程变“串行”，从而“降低并行度”，其实只是表象：线程依然并行启动了，只是主线程被阻塞住，无法继续推进后续逻辑。
它真正起作用的场景是结果依赖与执行顺序协调
当主线程需要子线程的计算结果、或必须确保某些操作在所有子任务完成后才执行时，join 才体现价值。例如：
- 启动 5 个线程分别下载图片，主线程需等全部完成再生成相册缩略图
- 多个子线程预处理数据块，主线程要汇总结果后写入数据库
- 测试中验证“所有后台任务结束前，服务不可标记为就绪”
这些都不是在限制 CPU 或线程数量，而是在保障逻辑正确性——没结果就不往下走。
想真正控制并行度？该用线程池 + 等待策略
若你实际想限制并发线程数（比如最多同时运行 3 个下载任务），应使用 ExecutorService + CountDownLatch / CompletableFuture，而不是靠 join 拼凑：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 用
Executors.newFixedThreadPool(3)直接限定最大并发数 - 提交任务后，用
CountDownLatch等待全部完成，比逐个调用 join 更清晰、可扩展 -
CompletableFuture.allOf(...).join()是现代写法，语义更明确，且支持异常传播和超时
手动 new Thread + join 容易失控：启动 10 个线程再逐个 join，系统瞬间承受 10 个线程压力，并行度早已拉满，join 只是让主线程卡在最后而已。
join 的典型误用与风险
以下做法看似“控制并行”，实则低效甚至危险：
- 在循环里 start + join 一个接一个：变成彻底串行，完全失去多线程意义
- 对未 start 的线程调用 join：无效，isAlive() 返回 false，直接跳过，逻辑断裂
- 忽略 InterruptedException：导致无法响应中断，线程难以优雅关闭
- 用 join(long) 做“软限流”：超时后继续执行，但子线程仍在后台跑，资源未释放，可能引发重复提交或状态不一致
