线程池任务抛出未捕获异常本身不直接影响GC，但可能因资源泄漏、引用未清理或ThreadLocal未remove等导致对象延迟回收。
线程池中任务抛出未捕获异常（UncaughtException）本身不会直接影响垃圾回收（GC）行为，但可能间接干扰对象生命周期和内存释放，尤其在异常导致资源泄漏、引用未清理或线程状态异常时。
线程池默认不捕获任务异常，异常会“消失”
使用 execute(Runnable) 提交任务时，若任务抛出未捕获异常，该异常会被 Thread.defaultUncaughtExceptionHandler 处理（通常仅打印堆栈），然后线程继续运行（对复用线程而言）。异常本身不阻止 GC，但若异常发生在关键清理逻辑（如 finally 或 close()）之前，可能导致：
- 文件句柄、数据库连接等系统资源未释放，间接拖慢 GC（因底层资源耗尽可能触发 Full GC）
- 局部变量持有的大对象（如缓存、缓冲区）未能及时置为
null，延长其可达性，延迟回收 - 异常中断了正常执行流，跳过显式清除弱引用/软引用的代码
submit(Callable) 的异常被包装为 ExecutionException
与 execute 不同，submit 返回 Future，异常被封装进 ExecutionException 并推迟到 get() 时抛出。此时异常对象本身是短命的——只要 Future 被回收且无强引用持有异常，它就能被 GC。但要注意：
-
Future若长期未调用get()或未主动取消，其内部可能持有异常引用和任务结果，阻碍相关对象回收 - 若异常对象持有了任务闭包中的大对象（例如捕获了某个 Service 实例），会造成意外的强引用链
自定义 UncaughtExceptionHandler 可能引入内存泄漏
若重写 Thread.UncaughtExceptionHandler 并在其中保存异常、上下文或堆栈信息（比如写入日志队列、上报监控），需警惕：
立即学习“Java免费学习笔记（深入）”；
- 将异常对象或其
getStackTrace()结果放入静态集合或长生命周期队列，会导致异常及所引用的对象无法回收 - 异常的
cause链可能形成环状引用（罕见但可能），影响可达性分析 - Handler 中匿名类隐式持有外部类引用，若 Handler 是非静态内部类，可能意外延长宿主对象生命周期
线程复用机制下，异常不影响线程对象回收，但影响任务对象
线程池中的工作线程（Worker）是长期存活的，异常不会导致线程对象被 GC；真正影响 GC 的是任务对象（Runnable/Callable）及其闭包：
- 任务执行完后，若没有其他强引用，任务对象可立即被 GC —— 无论是否抛异常
- 但如果任务是 lambda 或匿名类，且捕获了外部大对象（如
byte[]、Map），异常提前退出可能跳过清空操作，使这些被捕获对象继续被持有 - 使用
ThreadLocal的任务，若未手动remove()，异常发生时更易遗漏清理，造成内存泄漏（尤其在线程复用场景）
finally 块中、避免在 Handler 中长期持有异常、及时清理 ThreadLocal 和闭包引用，才是保障及时回收的关键。 
