在银行的后端服务中，如何设计线程池来处理高并发请求？请说明线程池的核心参数（如corePoolSize、maximumPoolSize、keepAliveTime）的设置依据，以及如何处理线程池的饱和策略。
交通银行后端开发工程师难度：中等
答案
1) 【一句话结论】
银行后端处理高并发请求时，线程池设计需针对I/O密集型任务（如转账），核心线程数匹配数据库连接数或网络I/O并发数（如核心线程数=数据库连接池大小×0.8），最大线程数为核心线程数的1.5-2倍，空闲线程存活时间设为30秒左右，队列采用有界阻塞队列（容量根据系统内存计算），饱和策略根据任务关键性选择AbortPolicy（关键交易）或CallerRunsPolicy（非关键任务），确保资源高效利用且任务不丢失。
2) 【原理/概念讲解】
线程池的核心是复用线程，减少线程创建与销毁的开销。对于银行转账这类I/O密集型任务（线程主要等待数据库或网络I/O，而非CPU计算），核心参数设置需结合I/O资源：
- 核心线程数（corePoolSize）：用于处理常量I/O负载，应与数据库连接池大小或网络并发数匹配。例如，数据库连接池设为100，核心线程数可设为80（即连接池的80%），避免线程数超过连接数导致连接耗尽，同时保持余量应对突发请求。
- 最大线程数（maximumPoolSize）：当任务数超过核心线程时，多余的放入队列或执行饱和策略。通常设为核心线程数的1.5-2倍（如80×1.5=120），应对突发流量。
- 空闲线程存活时间（keepAliveTime）：空闲线程超过该时间未执行任务则回收，避免资源浪费。I/O密集型任务等待时间长，通常设为30秒左右。
- 队列类型：有界阻塞队列（如ArrayBlockingQueue），容量需根据系统内存计算（公式：队列容量=(系统可用内存 - JVM占用)/（任务内存占用 + 线程栈大小），测试调整），防止队列过大导致内存溢出。
- 饱和策略（RejectedExecutionHandler）：当队列满且线程数达到最大时，如何处理任务。不同策略有不同风险，需结合业务场景选择。
3) 【对比与适用场景】
| 策略名称 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| AbortPolicy | 直接抛RejectedExecutionException | 强制拒绝任务，抛异常 | 不可容忍任务丢失（如关键转账、支付） | 会中断调用方，需捕获异常处理 |
| CallerRunsPolicy | 调用执行器线程运行任务 | 任务延迟执行，不丢失 | 任务可延迟（如非关键日志、通知） | 可能阻塞调用方线程，影响响应 |
| DiscardPolicy | 直接丢弃任务 | 任务丢失，不抛异常 | 任务可丢失（如非关键统计、日志） | 风险高，可能导致业务数据丢失 |
| DiscardOldestPolicy | 丢弃队列最老任务，执行新任务 | 保持队列有序，任务不丢失 | 任务有时间顺序要求（如订单处理、交易记录） | 可能丢弃重要历史任务，需谨慎 |
4) 【示例】
伪代码展示银行转账任务处理：
public class BankTransferService {
// 假设数据库连接池大小为100
private static final int CORE_POOL_SIZE = 80; // 数据库连接池的80%
private static final int MAX_POOL_SIZE = 120; // 核心线程数的1.5倍
private static final long KEEP_ALIVE_TIME = 30; // 秒
private static final int QUEUE_CAPACITY = 500; // 根据内存计算
private static final BlockingQueue<Runnable> queue = new ArrayBlockingQueue<>(QUEUE_CAPACITY);
private static final ThreadFactory factory = new NamedThreadFactory("bank-transfer-pool");
private static final RejectedExecutionHandler handler = new AbortPolicy(); // 关键交易用AbortPolicy
private static final ExecutorService executor = new ThreadPoolExecutor(
CORE_POOL_SIZE, MAX_POOL_SIZE, KEEP_ALIVE_TIME, TimeUnit.SECONDS,
queue, factory, handler
);
public void processTransfer(TransferRequest request) {
executor.execute(() -> {
try {
validateRequest(request);
debit(request.getFromAccount());
credit(request.getToAccount());
logTransfer(request);
} catch (Exception e) {
logError(e, request);
}
});
}
}
5) 【面试口播版答案】
在银行后端处理高并发请求时，线程池设计需针对I/O密集型任务（如转账），核心参数设置要匹配系统资源。比如核心线程数设为数据库连接池大小的80%（假设连接池100，核心线程80），最大线程数是核心线程的1.5倍（120），空闲线程存活30秒。队列用有界阻塞队列，容量根据内存计算（比如500），防止内存溢出。饱和策略上，关键转账用AbortPolicy，直接抛异常让调用方处理；非关键任务用CallerRunsPolicy，延迟执行不丢失。这样既利用资源，又控制资源，确保系统在高并发下稳定运行，任务不丢失。
6) 【追问清单】
- 问：为什么核心线程数设为数据库连接数的80%？
答：因为转账需要数据库连接，线程数超过连接数会导致连接耗尽，所以核心线程数设为连接数的80%左右，既保证处理能力，又避免资源浪费。 - 问：队列容量如何确定？
答：根据系统可用内存和任务内存占用计算，比如公式（系统内存 - JVM占用）/（任务内存 + 线程栈大小），测试调整，防止队列过大导致内存溢出。 - 问：处理异常时线程池如何处理？
答：饱和策略的AbortPolicy会抛异常，需在调用方捕获，或自定义处理（如记录日志后重试），避免任务丢失。 - 问：突发大流量时如何调整？
答：可动态调整最大线程数或队列容量，或结合熔断降级，防止系统过载。 - 问：线程池与业务逻辑的解耦是否重要？
答：重要，线程池线程只负责调度，业务逻辑由业务线程处理，避免线程池线程被阻塞影响其他任务。
7) 【常见坑/雷区】
- 核心线程数设为CPU核数：银行转账是I/O密集型，CPU核数与I/O资源不匹配，会导致线程数超过数据库连接数，连接耗尽。
- 队列设为无界：导致内存溢出，系统崩溃。
- 饱和策略选错：如DiscardPolicy，任务丢失导致业务错误，如转账失败。
- 忽略线程池监控：无法及时发现资源问题，影响系统稳定性。
- 线程池与业务逻辑耦合：线程池线程直接处理业务逻辑，导致线程池线程被阻塞，影响其他任务。