必须通过自定义checkstyle检查器强制校验线程池中lambda的try-catch配对，结合@musttry注解标记、ast扫描线程池方法调用、白名单抑制及ci阻断构建实现强约束。

在大型团队中，强制要求所有在线程池中执行的 Lambda 表达式必须包裹在 try-catch 块中（即“配对 Try”），不能靠人工 Review 或文档约定来保障——必须通过静态检查实现强约束。Checkstyle 本身不直接识别“是否运行在线程池中”，但可以通过规则组合 + 自定义逻辑 + 上下文标记实现可落地的强校验。

核心思路：用注解标记 + 自定义 Checkstyle 检查器

Java 运行时无法静态判定某段 Lambda 是否被提交到线程池，但开发人员可在调用点显式标注意图。我们采用“契约先行”策略：

• 定义一个轻量注解 @MustTry，用于标记明确需异常兜底的异步执行场景（如 executor.submit(() -> {...})）
• 要求所有线程池提交方法（submit、execute、schedule 等）的 Lambda 参数必须被 @MustTry 注解修饰
• 编写自定义 Checkstyle 检查器 RequiredTryInThreadPoolLambdaCheck，扫描 AST 中满足以下条件的 Lambda：
  • 作为参数传入已知线程池类（Executor、ExecutorService、ScheduledExecutorService 及其子类）的方法调用
  • 且该 Lambda 表达式体未被 try 包裹（即非 () -> { try { ... } catch (...) { ... } } 形式）
  • 且未被 @MustTry 显式豁免（避免误报）

配置 Checkstyle 规则并集成到工程

在 checkstyle.xml 中启用自定义检查器（需提前将编译好的 jar 放入 IDEA 或 Maven classpath）：

<module name="RequiredTryInThreadPoolLambdaCheck"><property name="threadPoolClasses" value="java.util.concurrent.Executor,java.util.concurrent.ExecutorService"></property><property name="exemptAnnotation" value="com.yourcompany.annotation.MustTry"></property></module>

同时，在团队规范中同步要求：

• 禁止直接使用裸 new Thread(...).start()，统一走封装后的 AsyncExecutor 工具类
• 所有自研线程池工具方法签名必须声明 @MustTry 在 Lambda 参数上（利用 IDE 提示倒逼开发者补 try）
• CI 流水线中设置 failsOnError=true，违反即阻断构建

规避误报与历史代码兼容

为避免对测试代码、Mock 场景或已知安全路径误报，支持白名单机制：

• 在 suppressions.xml 中按文件/包/方法名排除低风险上下文：<suppress checks="RequiredTryInThreadPoolLambdaCheck" files=".*Test\.java|.*Mock.*\.java"></suppress>
• 允许在 Lambda 内部用 // CHECKSTYLE:OFF RequiredTryInThreadPoolLambdaCheck 临时关闭（需带理由注释，并在 PR 评审中重点核查）
• 对存量项目，初期设为 warning 级别，生成报告并分配负责人分批修复，两周后升级为 error

为什么不用 PMD 或 SpotBugs 替代？

这类需求本质是“语义+上下文敏感”的检查：

• PMD 的 EmptyCatchBlock 只管空 catch，不管是否漏写 try；SpotBugs 的 REC_CATCH_EXCEPTION 关注异常类型宽泛性，不解决“根本没 try”问题
• 只有 Checkstyle 支持深度 AST 遍历 + 自定义节点匹配（如识别 MethodCallExpr → MemberSelectExpr → 类型是否为 Executor 子类）
• Checkstyle 可无缝嵌入 IDEA 实时提示、Git Hook 预提交、Maven validate 阶段，形成全链路拦截