宝安做网站wordpress媒体库 不显示

宝安做网站,wordpress媒体库 不显示,上海app研发,wordpress hermit在第 6 篇中我们已经看到一个非常反直觉的现象#xff1a;pool.submit(() - {throw new RuntimeException(submit error); });代码里明明 throw 了异常#xff0c;但日志里却什么都没有。这不是 JVM 的 Bug#xff0c;也不是线程池“不可靠”#xff0c; 而…在第 6 篇中我们已经看到一个非常反直觉的现象pool.submit(() - { throw new RuntimeException(submit error); });代码里明明 throw 了异常但日志里却什么都没有。这不是 JVM 的 Bug也不是线程池“不可靠”而是你没搞清楚线程池里异常的完整传递链路。本篇就专门把这件事讲清楚并给出生产级解决方案。一、先给结论非常重要线程池里的异常只有在“逃出线程执行边界”时才会被 JVM 当作未捕获异常处理。submit() 提交的任务异常会被 Future 捕获不会自动打印。所以你看到的现象是设计行为不是异常丢失。二、execute vs submit异常路径完全不同1️⃣ execute异常会“逃出线程”executor.execute(() - { throw new RuntimeException(execute boom); });执行路径是Runnable.run() ↓ 抛异常 ↓ 异常逃出 worker 线程 ↓ UncaughtExceptionHandler ↓ 打印异常栈所以execute 的异常通常你能看到。2️⃣ submit异常被 FutureTask 吃掉Future? f executor.submit(() - { throw new RuntimeException(submit boom); });submit 内部流程简化FutureTask.run() { try { callable.call(); } catch (Throwable e) { setException(e); // 存起来 } }关键点在这里❗异常没有逃出线程❗UncaughtExceptionHandler 不会被触发❗只有 f.get() 才会把异常抛出来如果你不get()异常就像“从没发生过”。三、最小 Demo你可以亲手验证ExecutorService pool Executors.newFixedThreadPool(1); // execute一定能看到异常栈 pool.execute(() - { throw new RuntimeException(execute error); }); // submit默认看不到异常栈 Future? f pool.submit(() - { throw new RuntimeException(submit error); }); Thread.sleep(500); // 注释掉这行submit 的异常通常不会打印 // f.get(); pool.shutdown();运行后你会发现execute error几乎一定会打印submit error不 get 就“消失”四、这在生产中为什么是“大坑”因为现实代码是这样的pool.submit(() - { // 更新缓存 // 调用下游 // 写数据库 });然后某一天某个逻辑 NPE 了你线上没看到任何异常业务却悄悄不执行了这不是小问题而是典型的“静默失败”五、生产级解决方案一任务包装最推荐✅ 思路不要相信调用方一定会 get Future异常必须在任务内部兜住。✅ SafeRunnable推荐public class SafeRunnable implements Runnable { private final Runnable delegate; private final String taskName; public SafeRunnable(Runnable delegate, String taskName) { this.delegate delegate; this.taskName taskName; } Override public void run() { try { delegate.run(); } catch (Throwable e) { System.err.println([TASK-EXCEPTION] taskName , thread Thread.currentThread().getName()); e.printStackTrace(); } } }使用pool.execute(new SafeRunnable(() - { throw new RuntimeException(boom); }, cache-refresh));✔ 不管 execute / submit✔ 不依赖 Future.get✔ 异常一定有日志这是最稳妥、最简单、最通用的方案。六、生产级解决方案二重写 afterExecute框架级如果你想从线程池层面统一兜底可以继承ThreadPoolExecutor。1️⃣ 原理ThreadPoolExecutor.afterExecute()在每个任务执行后都会被调用protected void afterExecute(Runnable r, Throwable t)texecute 抛出的异常对于 submit异常藏在Future里需要手动 get2️⃣ 标准模板非常经典public class MonitorThreadPoolExecutor extends ThreadPoolExecutor { public MonitorThreadPoolExecutor(...) { super(...); } Override protected void afterExecute(Runnable r, Throwable t) { super.afterExecute(r, t); Throwable ex t; // submit 的异常需要从 Future 里捞 if (ex null r instanceof Future?) { try { Future? f (Future?) r; if (f.isDone()) { f.get(); // 触发异常 } } catch (CancellationException ce) { ex ce; } catch (ExecutionException ee) { ex ee.getCause(); } catch (InterruptedException ie) { Thread.currentThread().interrupt(); } } if (ex ! null) { System.err.println([POOL-EXCEPTION] thread Thread.currentThread().getName()); ex.printStackTrace(); } } }✔ 一次兜住所有 submit / execute✔ 适合做成公共基础组件❌ 代码复杂度略高七、生产级解决方案三Future 必须 get有限场景Future? f pool.submit(task); try { f.get(3, TimeUnit.SECONDS); } catch (ExecutionException e) { log.error(任务异常, e.getCause()); }适用场景必须拿结果有超时控制同步业务流程❌ 不适合 fire-and-forget 任务❌ 不适合大量异步任务八、三种方案怎么选直接给你结论场景推荐方案fire-and-forget 异步任务SafeRunnable 包装框架 / 基础组件afterExecute 兜底必须拿结果submit get(timeout)一句工程经验异常必须在“离任务最近的地方”被处理。不要指望调用方一定会 get。九、本篇总结execute 抛异常 → 线程层面处理 → 通常能看到日志submit 抛异常 → Future 捕获 → 不 get 就“静默失败”生产中必须统一异常兜底推荐方案任务包装 or afterExecute不要把“异常可见性”交给调用方