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