Java多线程处理方案设计

场景分析

• 业务需求概述
  • 接收用户标题/大纲/参考链接，拆分为段落（8~16 并行度），每段并行生成草稿。
  • 检索增强（RAG）拼接成终稿；执行相似段去重、敏感词校验、多版本存储。
  • 支持取消、超时、重试、租户级限额；生成完成后 2s 内 Webhook 回调。
  • 峰值 5k QPS，单用户并发≤5，租户隔离；外部 LLM 受令牌速率限制需令牌桶节流。
  • I/O 与 CPU 分离线程池；有界队列与背压；批量提示并行、请求级超时取消。
• 并发特性评估
  • 端到端为“多阶段流水线 + 段落内并行 + I/O 重、CPU 混合”的场景。
  • I/O 重：RAG 检索（向量库/搜索）、LLM 生成、Webhook 回调；适合虚拟线程。
  • CPU 重：分段、提示组装、相似度计算（MinHash/SimHash/嵌入）、敏感词校验、拼接与格式化。
  • 强一致性不要求逐段强耦合（失败不影响同批其他段），可阶段解耦。
• 关键挑战识别
  • 峰值 5k QPS 下内部段落任务可能爆发至 40k~80k 并发，需严格限流与背压。
  • LLM 的令牌速率限制与请求级 SLA（P50 1.8s / P95 4s）之间的矛盾，需要按令牌计费的节流与并发窗口控制。
  • 资源上限（CPU≤70%，Heap≤8GB，无明显 FGC），需要虚拟线程 + 有界平台线程 + 有界队列策略。
  • 租户隔离、单用户并发≤5、可取消/超时传播、部分失败不影响整体。

线程模型设计

• 线程池配置建议（Java 21+, 虚拟线程 + 平台线程分离）
  • 接入层（HTTP Server，虚拟线程-per-request）
    • 使用虚拟线程处理请求编排与大部分阻塞 I/O（HttpClient、JDBC、Redis 等）。
  • I/O 执行器（虚拟线程）
    • ioVtExecutor = Executors.newThreadPerTaskExecutor(Thread.ofVirtual().name("io-vt-", 0).factory())。
    • 不直接用于限流；所有外部 I/O（LLM、检索、存储、Webhook）前需通过限流/并发闸门（Semaphore/令牌桶）。
  • CPU 执行器（平台线程）
    • cpuExecutor = new ThreadPoolExecutor(core=CPU核数, max=CPU核数, queue=有界, 拒绝策略=CallerRunsPolicy)。
    • 建议 core=max=cores，避免上下文切换；队列大小≈ cores * 200（根据压测调整），任务平均<5ms 时可增至 cores * 500。
    • 用途：文本拆分、相似度计算、敏感词扫描、格式拼接等。
  • LLM 并发闸门（平台资源门限，不是线程池）
    • 全局与租户级 Semaphore（并发上限由令牌速率与平均延迟动态计算），配合令牌桶（按 tokens 获取）。
• 任务分配策略
  • 请求编排在虚拟线程中串联阶段：拆分 ->（并行）RAG+生成 -> 去重/敏感词 -> 拼接 -> 存储 -> 回调。
  • 段落级并行：每请求限制并行度 P = min(N段落, 配置上限[8..16], LLM并发剩余窗口)。
    • 并发度控制优先保证系统与租户上限，其次满足请求目标 SLA。
  • 批量提示：若 LLM 支持 batch（一次请求多 prompt），将段落按 batchSize（如 4~8）聚合以降低往返延迟和连接开销；batch 内部按 tokens 合计走令牌桶。
• 线程生命周期管理
  • 进程级单例：ioVtExecutor、cpuExecutor、令牌桶管理器、并发闸门、租户路由器。
  • 每请求创建一个 RequestContext（deadline、取消句柄、租户信息、观测ID）；所有子任务在该上下文下创建，取消/超时向下游传播。
  • 通过 try-with-resources/Finally 保证句柄释放（计时器、流、HTTP body、DB游标）。

同步机制方案

• 数据同步方法
  • 同一请求内的段落中间结果放入 ConcurrentHashMap<Integer, ParagraphDraft>。
  • 去重阶段对段落集合进行只读扫描，生成保留/淘汰集合；避免跨段粒度的写锁。
  • 版本存储采用 append-only（例如版本号自增）；多线程写入用乐观重试，主键包含 requestId/version，确保幂等。
• 线程协作方式
  • 并行段落使用 CompletableFuture.supplyAsync(..., ioVtExecutor) 启动，封装 cancel 支持。
  • 合并：CompletableFuture.allOf(futures...) 或收集已完成的子集；失败的段落记录错误并继续其他段处理。
  • 去重/敏感词阶段提交到 cpuExecutor；对每段独立执行，最后汇总。
• 锁策略选择
  • 避免粗粒度锁；段落独立处理几乎无共享写入。
  • 去重用无锁/低锁方案：
    • 先全量并行生成，再在 CPU 池执行一次集中去重（推荐）。
    • 或采用并发结构 + 原子集合（ConcurrentHashMap<MinHash, ParagraphId>）做“首胜”策略，但易误伤边界；推荐集中去重保证质量。
  • 令牌桶与并发闸门使用原子与无锁快路径（LongAdder/VarHandle）+ 极短临界区。

性能优化建议

• 资源利用率优化
  • I/O 使用虚拟线程，避免为阻塞 I/O 占用平台线程；CPU 密集任务固定平台线程数量，避免过度上下文切换。
  • 有界队列与背压：入站网关采用令牌/队列双限流；当全局或租户队列满时立即返回 429，并带 Retry-After。
  • 字符串处理：启用 G1 + String Dedup；prompt 组装使用 StringBuilder/Formatter，避免多次拼接产生短命大对象。
• 吞吐量提升策略
  • LLM 调用使用批量提示（若可用），同时使用连接池与 HTTP/2 多路复用（java.net.http.HttpClient 默认支持）。
  • 自适应并发窗口：并发上限 c ≈ (有效令牌速率 Rt / 平均tokens L) * 平均RTT t，基于滑动窗口实时估算，AIMD 调整，避免 429。
  • RAG 检索并发控制：对同请求并发 N 限制在 4~8，减少下游存储抖动。
• 响应时间优化
  • 请求级截止时间：deadline = 4s（P95）- 安全裕度（如 300ms 持久化+回调+排队），段落生成阶段硬性 3.5s 截止；超时即刻取消未发出的 LLM 调用。
  • 早停合并：当段落完成率达到阈值（如 90%）且距离 deadline < X ms 时，跳过剩余段生成或降级（缩短目标长度）。
  • 优先生成头段（引言/摘要）提升主观响应质量；可先回传“预览”再补全（如产品允许）。

异常处理策略

• 异常捕获机制
  • 每段落的 Future 独立 try-catch，分类记录：客户端取消、超时、429/5xx、网络错误、敏感词失败等。
  • 对于 LLM/网络异常：重试策略（指数退避+抖动，最大 2~3 次；尊重 Retry-After），在请求 deadline 内执行；失败不阻塞其他段。
• 故障恢复方案
  • 入站幂等：requestId + 幂等等号，重复提交直接返回已有结果或继续未完成段。
  • 存储幂等：版本写入用唯一键（requestId, version, segmentId），重试不产生重复副本。
  • Webhook 回调至少一次投递：回调队列与重试（指数退避，最长 1 分钟），前端幂等键为 requestId/version；强制要求首次回调≤2s。
• 资源清理保障
  • 取消/超时：Future.cancel(true) 触发虚拟线程中断；HttpClient 请求使用 java.net.http.HttpRequest + BodyHandlers 且支持 abort，确保底层连接复用不泄漏。
  • 令牌桶：仅在发起请求前申请 tokens；取消不“退还”已消耗的 tokens，避免复杂度；若采用预留策略则在发送失败时归还。
  • 使用 try-with-resources 关闭流/响应体；finally 中释放 Semaphore 许可；所有定时器与计量器注册关闭钩子。

—— 以下为关键子系统的可操作设计细节 ——

1. 入站限流与租户隔离

• 全局限流：峰值 5k QPS，采用漏桶/滑动窗口限流（基于高性能计数器 LongAdder），过载直接返回 429。
• 租户隔离：每租户独立队列（ArrayBlockingQueue，容量按租户权重配置），单租户并发闸门（Semaphore permits = 租户并发上限），单用户并发≤5 可在租户内再细分 userId -> Semaphore(5)。
• 背压：当租户队列满 -> 429；系统进入保护模式时下调每租户并发窗口。

2. 令牌桶节流（按 LLM tokens）

• 维度：全局 + 租户级双层桶；支持 burst（桶容量 B = 1~3 秒配额）。
• acquire(tokens, timeout): 非阻塞快速失败或限时等待；失败则重试/降级。
• tokens 估算：promptTokens + targetTokens；基于历史回传的实际 tokens 做在线校准（P50/P95 维护两个估算值，优先使用 P50，临近 deadline 改用更保守的 P95）。

3. 段落编排与取消/超时

• 每请求创建 Deadline（Instant now + 4s）与 CancellationToken。
• 拆分段落（cpuExecutor），得到 N 段与优先级（大纲顺序/摘要优先）。
• 选择并行度 P ∈ [8, 16]，但不得突破租户并发闸门与 LLM 并发窗口。
• 对每段落启动 Future：
  • RAG 检索（ioVtExecutor；若有缓存则先查缓存）。
  • 组装提示词，估 tokens，令牌桶 acquire(t)；失败立即重试或降级（缩短目标长度）。
  • LLM 调用（HttpClient，per-call timeout = min(Deadline-现在, LLM上限)）。
  • 草稿持久化（append-only，异步失败重试队列）。
• allOf 合并后进入集中去重（cpuExecutor），随后敏感词审查（可并行每段），最后拼接成终稿与版本存储。

4. 相似段去重

• 方案：集中去重（质量优先）
  • 对每段生成 MinHash/SimHash 指纹（cpuExecutor 并行）。
  • 两两候选通过倒排桶/LSH 降维查近邻，Jaccard/汉明距离阈值，如 Jaccard>0.85 视为重复，保留质量分更高者（质量分可由 LLM logprobs/长度/覆盖参考文献等估算）。
  • 输出保留索引集合，重新编号段落。
• 注意：失败段不参与去重；不因单段失败阻塞全局。

5. 敏感词校验

• Aho-Corasick/Trie DFA（预编译词表），并行分段检测（cpuExecutor）。
• 对违规段落按策略处理：打码/替换/丢弃并标注。

6. 多版本存储与幂等

• 版本键：(tenantId, requestId, version, segmentId)。
• 草稿与终稿分层保存：drafts_vN、final_vN；写失败进入重试队列（落库与对象存储分离，元数据先落地）。
• 幂等读写：先查是否存在相同键；存在则跳过写入。

7. 回调（Webhook）

• 生成完成后将回调消息投入“回调队列”（ArrayBlockingQueue，容量有界），由回调发送器（ioVtExecutor + 并发闸门）在 2s 内发送。
• 回调至少一次；接收端需使用 requestId/version 幂等；失败重试退避，最长 1 分钟；回调和主处理解耦，不影响主路径 SLA。

8. 监控与可观测性（“单请求成本可观测”）

• 指标（Micrometer/Prometheus）：QPS、入站拒绝数、队列长度、段落并发、LLM 请求计数、令牌消耗（prompt/complete）、P50/P95 时延、超时/取消率、重试次数、去重率、敏感词命中率、CPU/内存、GC、回调延迟。
• 分布式追踪（OpenTelemetry）：traceId= requestId；span 覆盖拆分、RAG、LLM、去重、敏感词、存储、回调；为每段落与每个 LLM 调用埋点。
• 成本：记录每请求 tokens 消耗（预估与实际），计算单请求成本并上报。

9. 关键参数与初始值（需压测调优）

• 每请求并行度：初始 12（在 8~16 内自适应，基于 deadline 和剩余段数调节）。
• LLM 并发窗口：c0 = floor((Rt/L50)*t50)，Rt 为有效令牌速率；最小下限 64；遭遇 429 则乘 0.7；稳定期逐步 +1。
• 队列大小：租户入站队列 1000~5000（按权重），CPU 队列 cores*200 起步，回调队列 10k。
• 超时：请求 4s 硬截止；LLM 单次 1.52.5s（随 deadline 缩短）；RAG 300600ms。
• 重试：LLM 429/5xx/网络异常最多 2 次，Jitter 100~400ms；尊重 Retry-After。

10. JVM 与 GC

• JDK 21，G1GC，建议参数：
  • -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+UseStringDeduplication
  • -XX:+AlwaysPreTouch（大内存机器） -XX:G1NewSizePercent=20 -XX:G1MaxNewSizePercent=60
• 避免巨型对象：对参考材料与生成内容分块处理；禁用不必要的对象复制；启用 HTTP/2 压缩与分块读取。
• 定期 heap dump/alloc profiling（JFR）定位短命热点对象。

—— 安全与正确性要点 ——

• 不使用已过时/不安全 API；优先 java.util.concurrent、java.net.http、虚拟线程。
• 所有外部交互（LLM/RAG/存储/回调）均有超时、重试与限流；防雪崩的隔离舱（并发闸门）与快速失败保护。
• 全链路取消与中断响应：Future.cancel(true) + HttpClient.abort 支持，避免资源泄漏。
• 设计避免死锁：不在持锁范围内执行阻塞 I/O；只在短临界区更新共享状态。

—— 简要伪代码骨架（关键流程） ——

• 注意：以下为设计伪代码，展示编排方式与取消/限流要点，具体实现需根据项目基础设施完善，确保单元/压测验证后上线。

• 请求处理

  • validate quota(tenant,user)
  • with DeadlineScope(4s):
    • segments = cpuExecutor.submit(split)
    • futures = for segment in prioritized(segments).limit(P):
      • supplyAsync(() -> generateOne(segment, ctx), ioVtExecutor)
    • drafts = await all futures (collect successes, record failures)
    • kept = cpuExecutor.submit(deduplicate(drafts))
    • checked = parallel sensitiveCheck(kept)
    • finalDoc = cpuExecutor.submit(assemble(checked))
    • persist versions (drafts + final)
    • enqueue webhook(final)

• generateOne(segment, ctx):

  • rag = withTimeout(ragFetch(segment.refs))
  • prompt = buildPrompt(segment, rag)
  • tokens = estimateTokens(prompt)
  • if !tokenBucket.tryAcquire(tokens, ctx.remainingTime()):
    • maybe retry/shorten prompt or mark degraded
  • withTimeout(llmCall(prompt)):
    • return draft
  • persist draft (async, best effort)
  • return draft

该方案在不牺牲安全与可维护性的前提下，最大化利用 Java 21 的虚拟线程处理 I/O，使用平台线程承载 CPU 任务，配合令牌桶与并发闸门精确控制 LLM 的吞吐与成本；通过有界队列、背压、隔离舱与全链路超时/取消保证在 5k QPS 峰值下仍可达成 P50/P95 的延迟目标与 99.5% 成功率，同时控制 CPU/内存使用并满足 99.9% 可用性与回调时限。