应通过自研Checkstyle规则在AST层级精准拦截硬编码线程创建行为，覆盖new Thread/Timer、Executors工厂方法、匿名线程类及非受控ThreadPoolExecutor调用，并集成至构建流程强制失败，配套提供统一工具类与IDE实时提示。
要通过自研 Checkstyle 规则强约束禁止硬编码线程（如 new Thread()、Executors.newFixedThreadPool() 等），核心思路是：**不依赖通用规则，而是定制 AST 层级的语义检查，精准识别线程创建行为，并在编译前拦截**。
定义明确的“硬编码线程”识别范围
先统一标准，避免规则漏判或误伤。以下行为应被识别为违规：
- 直接调用
new Thread(...)或new Timer()构造器 - 调用
java.util.concurrent.Executors工厂方法（如newCachedThreadPool、newSingleThreadExecutor） - 显式使用
java.lang.Thread子类的匿名内部类或 Lambda 实例化（如new Thread(() -> {...})） - 调用非受控的线程池构造器（如
new ThreadPoolExecutor(...)且未走统一配置入口）
编写自定义 Checkstyle 检查器（基于 TreeWalker）
继承 AbstractCheck，重写 visitToken 方法，在 AST 的 EXPR 或 METHOD_CALL 节点中匹配目标模式：
- 对
new表达式：检查CLASS_DEF名是否为Thread、Timer，或是否属于java.lang/java.util.concurrent下的线程相关类 - 对方法调用：检查全限定名是否匹配
java.util.concurrent.Executors.*，或简单名匹配new.*ThreadPool等关键词 - 支持白名单包路径（如
com.example.infra.threadsafe.*），允许基础设施层少量可控创建
集成到项目并设为构建失败项
在 checkstyle.xml 中注册该检查器，并确保其不可绕过：
- 将自定义检查器 JAR 放入 Maven
plugin的dependencies，避免 classpath 冲突 - 配置
<failsOnError>true</failsOnError>，CI 流水线中任何匹配即中断构建 - 配合 suppression 规则时，仅允许极少数已评审的例外，且必须带
@SuppressWarnings("hardcoded-thread")+ 注释说明原因和有效期
配套机制增强实效性
单靠静态检查不够，需与工程实践绑定：
- 提供公司级线程管理工具类（如
ThreadPools），封装预设命名、监控、拒绝策略的线程池实例，所有业务代码只许调用该类的静态方法 - 在 IDE 插件中同步加载该 Checkstyle 规则，实现编码时实时高亮+快速修复建议（如自动替换为
ThreadPools.ioPool()） - 将常见误用写成单元测试用例（如扫描 test 目录下故意写的违规代码），验证规则覆盖无遗漏
