1. 简介
JSF 业务线程池使用 JDK 的线程池技术，缺省情况下采用 Cached 模式（核心线程数 20，最大线程数 200）。此外，还提供了 Fixed 固定线程大小的模式，两种模式均可设置请求队列大小。
本文旨在通过一个简化场景（“单服务应用”）下的负载测试，为 “JSF 业务线程池大小配置” 提供基准测试结果，并形成一些普遍适用的结论。
本文的目标读者包括需要合理配置 JSF 线程大小的压测工程师、开发部署运维工程师以及架构师。
本文不涉及 JSF 服务端的其他配置项，也不针对 “复合服务应用” 的合理配置进行探讨。你可以利用本文提供的结论，作为设计压测用例或评估业务线程池大小的基本方法的参考，以便在实践中合理配置 JSF 业务线程池大小。需要注意的是，JSF 业务线程池大小的合理配置应该基于高保真的负载测试结果。
“单服务应用” 指应用仅包含一个提供接口，且接口中仅有一个方法。 “复合服务应用” 则指应用包含多个提供接口或一个接口中含有多个方法。
2. 测试用例说明
本次基准测试选取了 USF3.0 权限系统，将其定制化为一个单一的服务提供者，仅对该提供者的一个方法进行了测试，因此可以看作是一个 “单服务应用”。
测试中将 CPU 作为基准测试的核心资源，并考虑到 JVM 垃圾收集器的影响，采用了简单的测试数据以保证服务每次调用的一致性，并确保 YGC 具有规律性（即固定调用量会导致一次 30+ms 的 YGC），无 FGC 的影响。
测试用例的设计中，所有依赖的服务资源都无限制，以确保测试过程中服务的可用率达到 100%。我们的关键性能指标是 TP99，即服务响应时长的 99% 必须小于 10ms。
为了测试不同线程池模式下的性能表现，我们使用了 JSF 线程池的 Cached 和 Fixed 两种模式，并针对每种模式进行了多组测试，以得出在满足 TP99<10ms 的前提下，系统最大的负载情况。
测试应用：USF3.0 权限系统 (定制化处理) 测试服务：com.jd.susf.service.api.SusfPermissionService#findUserInfo，根据用户信息从 Redis 中查询一条数据返回的服务。
硬件配置：单台 4C 8G 测试方法：在 Forcebot 系统采用了阶梯发压的方式对 JSF 业务线程池在 Cached 和 Fixed 模式下进行了系统负载测试 拟定 SLA 要求：服务响应时长的 TP99<10ms
注：我们对 USF3.0 权限系统进行了定制，调整了服务提供方的配置数据，仅保留了 com.jd.susf.service.api.SusfPermissionService。
3. 测试结果及分析
3.1.cached 线程池的系统负载
图：JSF 默认线程池 (cached, threads=200) 在不同并发用户数 (1-200) 下的系统负载图
| 并发用户数 | TP99 | 吞吐量 TPS | CPU 利用率 (%) |
|---|---|---|---|
| 1~23 | <8ms | 线性增长 | 线性增长 |
| 24 | 8ms | 6553 | 99.62 |
| 25 | 11ms | 6607 | 99.83 |
| 26～79 | 迅速增长 | 缓慢增长 | 99+ |
| 80 | 74ms | 6928 | 99.82 |
| 81~199 | 缓慢增加 | 缓慢下降 | 99.82 |
| 200 | 99ms | 6230 | 99.94 |
小结：默认的 JSF 线程池配置存在很大的风险。系统最大可支持 24 个并发，超过 24 个并发 SLA 就无法满足。
3.2 fixed 线程池 (队列) 的系统负载
图：JSF 固定线程池 (fixed + 队列) 在不同并发用户数 (1-50) 下的系统负载图
| JSF 业务线程数 | 可支持的最大并发用户数 | TP 值 (50/90/99/999) | 吞吐量 (TPS) | CPU 最大利用率（%） |
|---|---|---|---|---|
| 4 | 11 | 7/8/10/18 | 1531 | 27.67 |
| 8 | 25 | 8/8/10/18 | 3113 | 46.45 |
| 16 | 50 | 8/8/10/21 | 6228 | 87.97 |
| 20 | 23 | 3/4/10/15 | 6409 | 99.92 |
| 24 | 22 | 3/4/7/15 | 6178 | 99.86 |
| 25 | 22 | 3/4/6/15 | 6182 | 98.83 |
表：JSF 固定业务线程池 (fixed + 队列) 在满足 TP99<10ms 的系统最大负载（最大并发用户数）
小结： ① 在 fixed 线程模式下，CPU 的利用率存在使用上限。
② 队列的使用可以有效增加系统对并发量的支持，同时也会带来吞吐量的提升。然而，由于任务在队列中等待，服务的响应时间会出现 “水涨船高” 的现象，存在一定风险。
3.3 fixed 线程池的系统负载
图：JSF 固定线程池 (fixed) 模式下，系统最大并发用户数时的系统负载
| JSF 业务线程数 | 并发用户数 | TP99 | 吞吐量 (TPS) | CPU 最大利用率（%） |
|---|---|---|---|---|
| 4 | 4 | 5 | 1063 | 20.26 |
| 8 | 8 | 5 | 2216 | 36.62 |
| 16 | 16 | 6 | 4262 | 68.56 |
| 20 | 20 | 5 | 5550 | 86.22 |
| 24 | 24 | 8 | 6711 | 99.62 |
| 25 | 25 | 16 | 6644 | 98.77 |
| 26 | 26 | 19 | 6744 | 99.93 |
小结：综合固定线程池 (fixed) 的性能表现，需要设置一个合理的线程数大小来平衡 CPU 资源的充分利用和满足 SLA 的需求，线程数过小会导致 CPU 资源浪费，线程数过大则无法满足 SLA
4. 结论
根据测试结果和数据分析，我们得出以下结论：
JSF 线程池的默认配置在并发量高的场景下存在风险：所有线上生产环境中的 JSF 服务所在的服务器，很少有能够在 200 个线程的情况下还能够满足 SLA 的。最大 200 个线程的线程池配置，将服务器置于 “并发量高的场景下被压垮” 的风险中。线程池大小的合理配置应该来自高保真的负载测试。
足量的线程数才能保证资源 (CPU) 的利用率：业务型的服务通常都存在一定的 IO 操作（网络，磁盘等），线程执行过程中会发生等待，CPU 利用率不高，需要增加并发的线程数量，让更多的线程参与 CPU 的分配，才能提高 CPU 的利用率。服务中 IO 操作越多，等待时长越长，需要的并发线程就越多。对于有 IO 操作的业务型服务，负载测试的线程数可以从 2N（N 是服务器的 CPU 核数）开始。
过多的线程数只会降低系统的 SLA：当线程数已能 100% 利用 CPU 后，增加线程数，线程就无法获取足够的 CPU 分配，这样服务的响应时间就会增大。
在一定范围内，TP99 还可能满足 SLA 的要求，系统的吞吐量也会有少量的增加。再持续增加线程数，TP99 就无法满足系统的要求，系统的吞吐量也会开始下降。
固定的线程数可以保护系统需要承担的负载能力：固定线程数可以保证系统对 CPU 的利用率限定在一定的负载范围内，保护系统稳定运行，保证响应时间 TP99，但也限定了系统的并发能力。
合理设置队列大小可以增加系统的并发度，也不会影响系统 TP99，但会整体拉高服务的响应时间，出现不稳定性的变化，存在风险。
让 CPU100% 的高负载运行：通常服务对外的 SLA 承诺通常高于服务真实的性能，这是因为我们考虑了基础设施及依赖服务的不稳定性。
因此，即使 CPU 已经达到了 100%，我们仍然可以增加一定数量的线程数，而不会影响对外的响应时间 TP99 的承诺。这样可以提高系统的并发能力。虽然系统可以在高负载下运行，但我们需要进一步进行稳定性测试，以提高系统的可靠性。
综上所述，线程池大小的合理配置需要结合业务需求和系统资源情况进行评估和测试，并预留合理的 buffer 空间，以保证系统稳定运行和满足用户的 SLA。
5. 附录
附录一：统计指标及术语说明
并发用户数：同时发起请求的用户数。
TP 值 (50/90/99/999)：客户端的 TP 值，单位 ms，数据来源于 Forcebot。
吞吐量 TPS：数据来源于 Forcebot。
CPU 利用率 (%)：数据来源于 PFinder。
JSF 业务线程数：JSF 业务线程池的线程数，如：
fixed/cached：JSF 业务线程池的线程池类型，如：
审核编辑：刘清