非受检异常不会触发jvm特殊行为，仅按正常机制中断执行流、沿调用栈查找catch块；未捕获时终止当前线程并打印堆栈，但不影响jvm其他线程调度、gc或内存分配策略，其本质差异在于编译期是否强制处理，而非运行时jvm对待方式不同。
非受检异常（如 IllegalStateException、NullPointerException）本身不会触发 JVM 特殊的底层行为，JVM 不会因为抛出非受检异常而暂停、重启或回收内存区域。它只是按正常异常机制处理：中断当前执行流，沿调用栈向上查找匹配的 catch 块；若未捕获，则终止当前线程，打印堆栈跟踪（默认输出到 stderr），该线程所持有的栈帧被销毁，但堆中对象是否回收，取决于是否还有其他引用——和普通线程结束无异。
非受检异常不改变JVM运行时结构
它不影响堆、方法区、元空间或直接内存的分配策略，也不会导致 GC 触发或内存区域扩容。JVM 仍照常调度其他线程、执行 JIT 编译、进行垃圾回收。哪怕大量抛出 IllegalArgumentException，只要没耗尽资源或引发连锁错误，JVM 进程本身稳定运行。
程序状态变化取决于代码逻辑，而非异常类型
真正影响程序状态的是异常发生时的上下文：
- 如果在 Servlet 的
doGet中抛出IllegalStateException（比如重复提交响应），容器可能标记请求失败，但 Web 容器线程池不受影响 - 若在单线程批处理循环中未捕获
ArrayIndexOutOfBoundsException，整个任务中断，后续数据不再处理 - 多线程环境下，一个工作线程因
ConcurrentModificationException终止，只要线程池配置了核心线程保活或允许新建，任务仍可继续调度
与受检异常的本质区别不在JVM层面
编译器是否强制检查，是语言规范层面的设计，JVM 对所有 Throwable 子类一视同仁：
- 都通过相同字节码指令（
athrow）抛出 - 都走相同的异常分发路径（查找 handler_table）
- 唯一实际差异：受检异常在编译期被 javac 拦截并要求显式处理；非受检异常跳过这步，仅靠开发者自觉
容易被误读的“状态污染”场景
看似是异常导致状态错乱，实则是缺乏防护的编程习惯：
-
IllegalStateException往往暴露了对象生命周期管理缺陷（如已关闭的流又被写入），问题根源在状态字段未同步或未校验 - 多个线程共享可变对象，又没加锁，即使没异常，状态也早就不一致了；异常只是第一个暴露症状的“探针”
- 未清理的资源（如未 close 的数据库连接）不是因为抛了异常才泄漏，而是本就缺少
try-with-resources或 finally 保障
