类名须体现执行域与生命周期，如syncordersubmithandler；join()必须带超时且限于同线程池内；执行通道需用命名线程池隔离，禁止跨域复用。
大厂代码评审中，类名不规范、join() 使用不当，确实可能“误伤”兄弟模块——不是语法报错，而是引发线程阻塞、超时传染、资源争用等隐蔽故障。关键不在 join() 本身，而在它所嵌入的执行上下文是否被清晰隔离、可追溯、可管控。
类名必须携带执行域与生命周期语义
类名是模块边界的第一个信号。如果叫 UserProcessor，评审时大概率被打回：它属于同步编排？异步回调？还是定时重试链？没人能一眼判断。
- 推荐命名格式：动词+业务实体+执行特征，例如
SyncOrderSubmitHandler、AsyncInventoryDeductWorker、RetryablePaymentNotifyTask - 禁止模糊泛称：
Manager、Helper、Service单独出现；若必须用，须加前缀限定作用域，如InventoryLockService（而非LockService） - 含
join()的类，建议在类名中显式体现阻塞意图，如BlockingOrderStatusWaiter，让评审者立刻意识到该类需配套超时、中断、线程池隔离策略
join() 调用必须绑定明确的执行链上下文
join() 不是独立动作，它是某条执行链的收尾环节。脱离链路谈 join()，就像没看红绿灯就踩刹车——危险且不可控。
- 每次调用前，必须确认：被
join()的线程是否归属本执行链？例如，不能在订单主流程中join()一个由风控模块启动的异步校验线程 - 强制要求：所有
join()必须配套 超时参数（thread.join(3000)），禁用无参join()；超时值需与当前链路 SLA 对齐（如支付链路 ≤ 800ms） - 若需等待多个子任务，优先用
CountDownLatch或CompletableFuture.allOf()替代逐个join()，避免阻塞扩散
执行通道隔离：用线程池 + 命名前缀划清责任边界
兄弟模块执行通道被“误伤”，本质是共享了线程资源。规范做法是：每个逻辑执行链独占命名线程池，且线程名带链路标识。
- 定义线程池时强制命名前缀：
new ThreadPoolExecutor(..., new ThreadFactoryBuilder().setNameFormat("order-submit-%d").build()) - 在日志、监控、链路追踪中，所有该池中线程产生的操作（含
join()等待行为）自动打上order-submit标签，便于故障时快速归因 - 禁止跨域复用线程池：支付链路的线程池不能用于用户中心的异步通知，哪怕“看起来空闲”
评审时必查的三项硬指标
自动化工具可拦截基础问题，但以下三点必须人工确认：
-
类名是否能反向推导出其在线程模型中的角色？例如看到
AsyncSmsSendWorker，应能立即判断它属于异步发送链，不应出现在主流程同步调用栈中 -
所有
join()是否处于同一命名线程池内？若主线程在order-main池中，却join()了user-sync池里的线程，即为违规 -
是否存在未声明的隐式依赖？比如 A 模块的
join()实际等待 B 模块启动的线程，但 A 并未在依赖配置或文档中标明对 B 的强耦合
