误用 run() 而非 start() 会导致任务串行执行：run() 是普通方法调用，不启动新线程；start() 才触发线程调度。三步检查法包括搜索 .run() 调用、区分 thread 子类与 runnable 实现、观察线程名与堆栈；jfr 和 visualvm 可验证线程行为；修复建议为优先使用 executorservice，必要时在 run() 中加断言，并在 ci 中引入静态检查。
确认是否误用了 run() 而非 start()
Java 中 Thread.run() 是普通方法调用，不会启动新线程；而 Thread.start() 才真正触发线程调度。如果审计逻辑本该并发执行，却写了 thread.run()，那所有任务会在当前线程里顺序执行——表面无报错，实则完全串行，审计耗时暴涨且失去并发意义。
快速定位可疑代码的三步检查法
在多线程审计模块中，重点扫描以下模式：
- 搜索
.run()调用，尤其出现在new Thread(...)后直接链式或单独调用的地方，例如：new AuditThread(data).run()或thread.run() - 检查是否混淆了
Runnable实现类与Thread子类：若类已继承Thread，仍手动调用run()就是典型误用；若只是实现了Runnable，又没传给Thread构造器而是直接调用run()，同样无效 - 观察线程名和堆栈：在关键审计入口加一句
System.out.println(Thread.currentThread().getName());，若所有输出都是main或同一个工作线程名（如pool-1-thread-1），基本可断定未真正并发
用 JFR 或 VisualVM 验证线程行为
静默串行很难靠日志发现，但线程活动会留下痕迹：
- 启用 JDK Flight Recorder（JFR）运行审计过程，导出事件后查看
jdk.ThreadStart和jdk.ThreadEnd事件数量——若只看到 0～1 次新建线程，说明start()几乎没被调用 - 用 VisualVM 连接进程，在「Threads」页观察实时线程数变化：正常并发审计应出现多个处于
RUNNABLE状态的审计专用线程；若始终只有 1～2 个活跃线程，且 CPU 利用率低、耗时线性增长，大概率是run()误用
修复与防御建议
改法简单，但需系统性规避再犯：
- 统一使用
ExecutorService替代裸Thread：把审计任务封装为Runnable或Callable，交由线程池submit()或execute()，天然杜绝run()误调 - 若必须用
Thread，在构造后立刻调用start()，并删除任何run()显式调用；可在基类run()方法开头加断言：if (Thread.currentThread() == this) throw new IllegalStateException("run() called directly, use start() instead"); - CI 阶段加入静态检查：用 SpotBugs 或自定义 Sonar 规则，检测
Thread实例后紧跟.run()的 AST 模式，提前拦截
