Java 线程池隔离：核心链路不要和 AI 任务共用执行资源

大模型应用接入到传统 Java 后端时，一个常见隐患是线程池混用。核心交易接口、后台任务、AI 摘要、通知发送，都丢到同一个 executor。平时没问题，AI 任务一慢，核心链路也开始排队。

线程池隔离不是过度设计，而是高可用系统的基本边界。慢任务不能拖死快链路。

一、先按任务类型拆池

flowchart TD A[Request] --> B[Core Executor] A --> C[AI Executor] A --> D[IO Executor] C --> E[Model Gateway]

核心链路、AI 调用、文件 IO、通知任务，最好有不同执行资源。每类任务的耗时模型不同，混在一起很难调。

二、线程池要设置队列边界

ThreadPoolExecutor aiExecutor = new ThreadPoolExecutor( 8, 16, 60, TimeUnit.SECONDS, new ArrayBlockingQueue<>(200), new ThreadPoolExecutor.AbortPolicy() );

无界队列是事故温床。请求堆在内存里，看起来没拒绝，实际上延迟已经不可控。

三、拒绝策略要配合降级

AI 任务线程池满了，不一定要拖垮接口。可以返回排队提示、降级结果或稍后重试。

reject_policy: interactive_ai: return_busy_message batch_ai: retry_later core_order: never_share_pool

拒绝不是失败，毫无边界地等待才危险。

四、监控要按线程池维度

executor_metrics: active_threads: true queue_size: true reject_count: true task_latency_p95: true

如果只看应用整体 CPU，很难发现某个线程池已经排队。线程池是后端容量单元，必须可观测。

线程池参数也不要只靠经验。可以通过压测观察不同队列长度和线程数下的延迟曲线。线程数过大，可能增加上下文切换；队列过长，会让用户等到没有意义。

executor_tuning: measure_queue_wait measure_task_runtime reject_before_timeout separate_core_and_ai

调线程池不是把数字调大，而是让等待时间和资源使用处在可控范围。

五、总结

Java 后端接入 AI 任务时，要按任务类型做线程池隔离，设置有界队列、明确拒绝策略，并按线程池维度监控。

核心链路不要和 AI 慢任务共用执行资源。资源边界清楚，系统才不会被一个慢功能拖住全局。

一旦线程池隔离做好，故障半径也会变小。AI 任务慢，最多影响 AI 功能，不应该影响登录、支付或核心查询。

还要避免在核心请求线程里等待 AI 任务完成。如果 AI 结果不是同步必需，可以改成异步任务或事件通知。核心接口快速返回，AI 后续补齐结果。

sync_or_async: user_must_wait: synchronous_with_timeout can_notify_later: async_job batch_processing: queue_worker

同步边界选错了，再多线程池也救不回来。架构上先判断用户是否真的需要等待。