ThreadPoolTaskExecutor配置与CPU核心关联及高并发超时问题咨询

我开发了一个Spring Boot应用，暴露POST类型的REST API接口，接收输入数据后完成简单校验，再将数据存入关系型数据库及第三方文件存储系统S3。应用的线程池配置如下：

public TaskExecutor taskExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(6);
        executor.setMaxPoolSize(10);
        executor.setQueueCapacity(50);
        return executor;
    }

目前接口运行正常，但当外部通过循环调用该接口100000次时出现超时问题。服务器配置为i5四核（每核1线程，共4线程）、16GB内存。

我的疑问：

1. 这种场景下出现超时是否合理？
2. 硬件线程与应用TaskExecutor的线程池是如何关联的？是否是请求进入服务后，从线程池取线程执行任务，由CPU核心的线程处理，最多同时处理4个任务？若单任务耗时500ms，短时间内提交超过5个任务，第5个需等待？若提交任务数超过队列容量50，剩余任务会被拒绝吗？

注：该接口未使用异步方法或Future/CompletableFuture调用。

1. 超时是否合理？ #

完全合理，核心原因如下：

• 服务器仅提供4个硬件线程，即便应用线程池配置了6个核心线程、10个最大线程，CPU同一时刻最多只能真正执行4个用户态线程，剩余线程会处于等待CPU调度的状态，任务总执行耗时会被大幅拉长。
• 10万次调用远超当前系统的处理能力，且每个任务包含数据库写入、S3存储这两个IO密集型操作，本身就存在网络和服务端延迟，高并发下排队任务会持续累积，后续请求的等待时间会超过超时阈值。
• 另外Spring Boot默认使用Tomcat作为容器，其默认请求线程池最大容量约200，10万次请求瞬间涌入会直接占满Tomcat的请求队列，后续请求要么被直接拒绝，要么因等待过久而超时。

2. 硬件线程与应用线程池的关联及相关问题 #

关联逻辑 #

应用线程池中的线程是用户态线程，硬件线程是内核态线程，两者通过操作系统调度器绑定。操作系统会将用户态线程分配到可用的硬件线程上执行，但同一时刻一个硬件线程只能处理一个用户态线程。因此你的4个硬件线程，最多同时有4个用户态线程在CPU上真正执行，其余线程处于就绪等待调度的状态。

关于任务处理的细节 #

• 不是“最多同时处理4个任务”：如果任务包含大量IO操作（如数据库、S3交互），线程会进入阻塞状态，此时操作系统会把CPU时间片分配给其他就绪线程。这种情况下，实际“在处理”的任务数可能多于4个，但CPU真正在执行计算的线程始终不超过4个。
• 单任务耗时500ms，短时间提交超5个任务：若任务是CPU密集型，第5个任务确实需要等待某个硬件线程空闲才能执行；但如果是IO密集型，前面的线程在IO阻塞时会让出CPU，第5个任务可能无需等待即可被调度。
• 任务数超过队列容量50是否被拒绝：取决于线程池的拒绝策略。你当前的配置未显式设置，ThreadPoolTaskExecutor默认使用AbortPolicy——当任务总数超过maxPoolSize + queueCapacity（10+50=60）时，新提交的任务会直接抛出RejectedExecutionException，导致请求失败或超时。但需要注意：你提到接口未使用异步方法，这个自定义的TaskExecutor可能根本没被启用，接口同步处理请求时，实际使用的是Tomcat的请求线程池，而非这个自定义线程池，这点需要确认。

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