直接调用run()方法极其危险，因为它不创建新线程、无独立栈、无法中断、异常直抛调用方；必须用start()启动线程，并在run()内加try-catch捕获Throwable，或使用封装好的安全Runnable包装器。
直接调用线程的 run() 方法，本质上是把业务逻辑当作普通方法执行，完全绕过了线程调度机制。此时没有独立栈、不启动新线程、无法被中断、异常也不会由线程的未捕获异常处理器处理——所有异常都会原样抛给调用方，极易导致主线程崩溃或状态错乱。
为什么 run() 直接调用很危险
run() 是 Runnable 接口定义的普通方法，不是线程启动入口。调用它等价于执行一个 void 方法：
- 不会创建新线程，仍在当前线程上下文中执行
-
interrupt()对它完全无效（无中断标志参与） - 未捕获的
RuntimeException会穿透到调用栈上层，可能中断关键流程 - 无法统一做超时控制、资源清理、日志埋点等线程级保障
用 Thread.start() 替代直接 run() 调用
真正启用线程必须走 start() ——这是 JVM 保证线程生命周期和中断协作的基础：
- 调用
start()后，JVM 创建新执行栈，线程进入RUNNABLE状态 - 此时
interrupt()才能设置中断标志，isInterrupted()才有意义 - 未捕获异常会触发
Thread.UncaughtExceptionHandler，可集中兜底
错误写法：new Thread(() -> doWork()).run();
正确写法：new Thread(() -> doWork()).start();
在 run() 内部做最小化异常隔离
即使使用 start()，业务代码仍可能抛出未预期异常。应在 run() 最外层包裹统一 try-catch：
- 捕获
Throwable（不只是Exception），防止OutOfMemoryError等致命错误穿透 - 记录完整堆栈，避免静默失败
- 执行必要清理（如关闭流、释放锁），但避免在 catch 中重新 throw
- 不建议在 catch 里调用
System.exit()或阻塞等待，会拖垮整个线程池
示例：
public void run() {try {
// 你的业务逻辑
} catch (Throwable t) {
log.error("Uncaught error in thread {}", Thread.currentThread().getName(), t);
cleanup(); // 可选：释放资源
}
}
用包装类统一管控线程行为
避免每个地方都手写 try-catch 和中断检查，可封装一个安全的 Runnable 包装器：
- 自动捕获所有异常并委托给自定义处理器
- 支持传入超时阈值，在 run() 内定期检查中断或耗时
- 内置 finally 清理钩子，确保资源释放
- 与线程命名、上下文传递（如 MDC）集成，便于追踪
这样业务代码只需关注核心逻辑，异常、中断、清理全部下沉到框架层。
