虚拟线程异常不触发默认uncaughtexceptionhandler，因异常发生在carrier线程；需显式设置或用structuredtaskscope聚合异常；interruptedexception不再抛出，应改用scope.cancel()和isinterrupted()轮询；outofmemoryerror实为调度器元数据耗尽，须用作用域管理生命周期。
虚拟线程抛出异常时，uncaughtExceptionHandler 不生效？
Java 21 虚拟线程默认不走传统线程的未捕获异常处理器——这是最常被踩的坑。因为虚拟线程由 CarrierThread 托管，异常实际发生在 carrier 上，但 Thread.setDefaultUncaughtExceptionHandler() 只对平台线程注册有效。
实操建议：
- 必须为每个虚拟线程显式设置处理器：
Thread.ofVirtual().uncaughtExceptionHandler((t, e) -> {...}).start(...) - 若用
Executors.newVirtualThreadPerTaskExecutor()，需配合ForkJoinPool.setDefaultUncaughtExceptionHandler()（仅限 carrier 线程崩溃时兜底） - 不要依赖
Thread.currentThread().setUncaughtExceptionHandler()—— 虚拟线程调用该方法无效
StructuredTaskScope 中子任务异常如何传播？
它不是简单“抛出第一个异常”，而是按结构化语义聚合：所有子任务结束后，只抛出一个 ExecutionException，其 getCause() 是首个非取消异常；若全是取消，则抛 CancellationException。
常见错误现象：日志里只看到 ExecutionException，找不到原始堆栈。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 务必用
ex.getCause()解包，而不是直接打印ex - 若需收集全部异常，用
scope.exceptions()（返回List<throwable></throwable>），但注意它只包含非取消异常 - 在
join()后立即处理，不要等 scope 关闭后再查——关闭后exceptions()返回空列表
虚拟线程中 try-catch 捕获不到 InterruptedException？
没错。Java 21 的虚拟线程已废弃中断机制语义，Thread.interrupt() 对虚拟线程无效果，InterruptedException 几乎不会抛出（除非你手动 throw）。
这意味着：老代码里靠捕获 InterruptedException 来响应取消的逻辑，在虚拟线程里会静默失效。
实操建议：
- 改用
Thread.currentCarrierThread().isInterrupted()检查 carrier 中断状态（仅限调试/兼容场景） - 真正推荐路径是使用
StructuredTaskScope+scope.cancel()，然后在子任务中定期轮询Thread.currentThread().isInterrupted()（此时返回的是 scope 的取消信号） - 别再给虚拟线程调用
thread.interrupt()—— 它什么也不会发生
日志里看到 java.lang.VirtualMachineError: OutOfMemoryError？
这不是堆内存溢出，而是虚拟线程调度器耗尽了内部元数据空间（比如太多活跃虚拟线程未被及时回收）。典型诱因是：大量短生命周期虚拟线程 + 频繁 GC + 缺少作用域约束。
性能影响明显：一旦触发，后续虚拟线程创建会变慢甚至阻塞数秒。
实操建议：
- 避免裸写
Thread.startVirtualThread()，优先用StructuredTaskScope或ExecutorService管理生命周期 - 检查是否遗漏
scope.close()或executor.shutdown()—— 虚拟线程不自动释放关联资源 - 监控
jdk.ThreadStart和jdk.ThreadEndJVM 事件，确认线程创建/销毁是否成对
协程级异常处理的关键不在“怎么捕获”，而在于接受虚拟线程不是线程的复制品——它的异常流转、取消机制、资源边界都重构了。最容易被忽略的是：你以为在处理线程异常，其实是在和结构化并发模型对话。
