大规模文本分词与NLP异步处理属IO密集型+轻量计算混合任务，W/C比约为5～20，推荐线程数=CPU核心数×(1+W/C)，16核服务器建议核心线程40～60、最大100，并配以有界队列、CallerRunsPolicy拒绝策略及业务标识线程名。
大规模文本分词与NLP异步处理属于典型的IO密集型+轻量计算混合型任务：分词本身计算开销小，但频繁访问词典、加载模型、读写缓存或调用远程NLP服务（如NER、依存分析）会引入显著IO等待。因此线程数不能按纯CPU密集型设置，需兼顾等待时间占比。
先判断任务实际I/O占比
真实场景中，分词任务的W/C（等待时间/计算时间）往往在5～20之间——比如一次本地词典查表耗时0.2ms（计算），而一次远程语义角色标注API调用平均耗时5ms～40ms（等待）。可通过采样日志或Arthas trace验证：
- 记录单次分词全流程耗时（含模型加载、缓存命中、网络往返）
- 用JFR或Async-Profiler分离CPU执行时间与阻塞时间
- 若平均阻塞占比＞70%，可近似按W/C ≈ 10～15估算
推荐线程数公式与取值范围
采用《Java Concurrency in Practice》提出的通用公式：
Nthreads = CPU核心数 × (1 + W/C)
以当前主流服务器（16核）为例：
- 若W/C ≈ 8 → 理论值 ≈ 16 × 9 = 144
- 但需叠加资源约束：每个分词线程常驻加载10～50MB模型权重，内存成为瓶颈
- 实践中建议上限设为100～120，并配合堆内存监控（如-XX:MaxRAMPercentage=75）
- 核心线程数可设为40～60，确保常规流量不触发扩容；最大线程数设为100，防突发洪峰
必须搭配的关键配置
仅调线程数不够，以下三点缺一不可：
立即学习“Java免费学习笔记（深入）”；
- 队列必须有界：用ArrayBlockingQueue(200)，禁用LinkedBlockingQueue（无界→OOM）
- 拒绝策略选CallerRunsPolicy：当队列满+线程达上限时，由提交线程自己执行，自然限流且不丢任务
- 线程名带业务标识：如“nlp-seg-worker-%d”，便于通过jstack或arthas定位卡顿线程
动态验证比理论计算更可靠
上线后观察三类指标：
- ThreadPoolExecutor.getActiveCount()长期＞corePoolSize → 说明核心数偏低
- getQueue().size()持续＞queueCapacity × 0.7 → 队列积压，需调大core或加节点
- GC频率突增+老年代使用率＞80% → 内存不足，应降低maxPoolSize而非加机器
