Web应用多线程：线程执行机制与Tomcat线程数配置咨询

问题1：2核CPU环境下，是否存在机制保证单线程执行单个任务时不会中途切换到其他任务，实现任务跑完前线程不被调度释放？ #

默认的通用操作系统调度逻辑下，不存在这种保证。

• 现在主流操作系统（Windows、Linux、macOS）用的都是抢占式线程调度机制：只要触发调度条件——比如线程分配的时间片耗尽、有更高优先级的线程进入就绪队列、当前线程主动调用阻塞操作（等IO、sleep等），CPU会立刻收回当前线程的执行权，切给其他线程运行，和CPU核心数多少没有关系。哪怕是单核CPU跑多线程，也是靠毫秒级的快速切换实现伪并行，根本不会等单个任务跑完才调度。如果真的等一个任务跑完才切，那本质就是串行执行，根本算不上伪并行。
• 确实有特殊手段可以实现“线程不跑完不被切”的效果，比如把线程和指定CPU核心做亲和绑定、给线程设置最高的实时调度优先级、甚至定制内核调度策略，但这些手段都会破坏系统调度的公平性，很容易导致其他进程/线程饿死、系统整体响应卡顿，普通Web业务场景完全不会这么用。

问题2：网传“CPU核数*2为最优线程数”，为什么Tomcat默认工作线程数是200？二者核心差异是什么？只配4个线程能不能支撑1000以上用户的场景？ #

首先要纠正一个很多人记混适用边界的规则：核数*2的最优线程数结论，只适用于纯CPU密集型任务——也就是任务全程几乎都在做逻辑计算、没有任何阻塞等待（比如大数据计算、视频转码、压缩解压这类场景）。这种场景下线程不会主动让出CPU，线程数超过核数*2只会带来额外的上下文切换开销，反而拉低整体执行效率。

Tomcat的工作线程配置逻辑和这个规则的核心差异，来自二者面对的任务类型完全不同：

• Tomcat处理的绝大多数Web请求都属于IO密集型任务：一个请求的完整处理流程里，线程真正占用CPU做计算的时间占比非常低，大部分时间都在阻塞等待——等数据库返回查询结果、等下游服务接口响应、等磁盘读写完成、等网络数据传输。线程进入阻塞状态的时候，操作系统会直接把CPU执行权切给其他就绪的线程，根本不会浪费CPU资源。举个很常见的例子：一个接口平均响应时间100ms，其中只有10ms在消耗CPU做逻辑处理，剩下90ms都在等数据库返回，那单核心理论上就能顺畅支撑10个左右的这类请求，2核扣掉系统本身的资源开销，支撑上百个工作线程完全不会出现CPU调度瓶颈。Tomcat默认设200个工作线程，就是给普通IO密集型Web业务留的通用默认值，避免线程数不足导致请求无谓排队。

关于“只配4个线程能不能支撑1000以上用户场景”的问题，结论非常明确：

• 如果你的服务是纯CPU密集型场景，比如没有任何外部IO依赖的实时计算服务，那4个线程确实接近最优配置，但这种场景下别说1000个并发用户，就算是10个并发请求，剩下的6个都得排队等待，响应时间会直线上升。
• 如果是普通的JavaWeb业务（绝大多数线上服务都属于这类），只配4个工作线程完全达不到最优效果：哪怕CPU还有大量空闲资源，请求也会因为没有可用工作线程被阻塞排队，1000用户场景下会出现大量请求超时、排队等待时间过长的问题，属于典型的配置错误。
• 实际生产环境里Tomcat的线程数从来不会按核数*2来配置，都是根据业务的IO等待占比调整：IO等待占比越高，可配置的线程数就越大，常规业务场景配置200-500工作线程都是非常普遍的，不会带来不可接受的上下文切换开销。

内容的提问来源于stack exchange，提问作者Mary