java异常本身不阻塞线程，未捕获异常会终止线程而非阻塞；真正导致阻塞的是异常处理中同步操作、阻塞i/o或显式等待等行为。
Java异常本身不会直接阻塞线程，但异常的处理方式和所处上下文可能间接导致线程阻塞。
未捕获异常会终止线程，而非阻塞
当一个线程中抛出未捕获的异常（即没有被 try-catch 捕获，也未通过 Thread.setDefaultUncaughtExceptionHandler 设置处理器），该线程会立即停止运行，进入 TERMINATED 状态。这不是阻塞（Blocked/Waiting），而是直接结束。
- 主线程抛出未捕获 RuntimeException，JVM 退出
- 子线程抛出未捕获异常，仅该线程死亡，不影响其他线程
- 线程池中的工作线程若因未捕获异常退出，ThreadPoolExecutor 默认会创建新线程补上（取决于 allowCoreThreadTimeOut 和 keepAliveTime）
阻塞常发生在异常处理过程中的同步操作
真正造成阻塞的，往往不是异常本身，而是开发者在异常路径中写的同步代码，比如：
- 在 catch 块里调用 synchronized 方法或代码块，而锁正被其他线程持有
- 在异常处理逻辑中执行了 阻塞 I/O（如 socket.read()、fileInputStream.read()）
- 调用 Thread.sleep()、Object.wait() 或 CountDownLatch.await() 等显式阻塞方法
- 使用 Future.get() 等待异步结果，且未设超时——一旦依赖任务卡住，当前线程就挂起
异步与非阻塞异常处理可避免阻塞
现代 Java 推荐将异常处理与业务主流程解耦，尤其在高并发场景：
立即学习“Java免费学习笔记（深入）”；
- 用 CompletionHandler.failed() 处理 AsynchronousFileChannel / AsynchronousSocketChannel 的 I/O 异常，不阻塞事件线程
- 用 CompletableFuture.exceptionally() 或 handle() 声明式处理异步异常，后续链式操作仍可并行执行
- 在 Web 层（如 Spring WebFlux）用 Mono.onErrorResume 统一兜底，保持响应式流不中断
- 日志记录、告警通知等副作用操作应异步化（如提交到独立线程池），避免拖慢主请求线程
常见误解澄清
有人以为 “throw new Exception()” 会让线程卡住，其实不会。耗时的是栈展开（stack unwinding）和异常对象构造，对绝大多数应用可忽略。真正要注意的是：
- 不要在 finally 里写阻塞代码（如 close() 调用底层阻塞流）
- 避免在 synchronized 块内抛异常后又在 catch 里再次尝试加同一把锁
- 慎用 Thread.stop()、suspend() 等已废弃的强制中断方法——它们已被移除，且本身也不解决阻塞问题
基本上就这些。异常是信号，不是锁；阻塞是行为，不是结果。关键看你怎么响应它。
