在线支付业务中，经常会遇到掉单问题：用户已完成支付，但订单状态仍显示"待付款"。通常，用户支付完成后，第三方支付平台会通过梯度通知机制向商户同步支付结果。然而，若支付平台因网络波动、系统故障等原因导致通知失败，就需要引入补偿机制——比如：通过定时任务每隔一段时间主动查询特定时段内的待支付订单，批量发送至第三方支付平台查询支付结果，并同步更新系统订单状态，通知下游服务。为了高效处理这类订单，通常会借助线程池实现并发处理。

分析业务特征

Q：定时任务多久查一次？
A：假设用户通常在5分钟内完成支付，那么定时任务每隔5分钟查询一次。

Q：每次查询的时间跨度是多少？
A：查一天前到5分钟前待支付的订单。

Q：每次查询出的待支付订单期望多久时间处理完？
A：每批订单期望1分钟内处理完。

Q：平时和大促期间，单位时间内大约发生多少次掉单情况？
A：平时每5分钟大约掉单1200次，大促期间每5分钟大约5000次。

在 Java 服务端开发中，线程池几乎无处不在。

异步任务、接口聚合、批量处理、消息消费、第三方 RPC...只要一个任务不希望直接占用当前线程太久，我们往往都会想到线程池。

而线程池最让人头疼的问题之一，就是：

corePoolSize 到底应该设置多少？

maximumPoolSize 设置多少合适？

queueCapacity 到底应该设置 10、50，还是 1000？

M/M/c 是排队论（Queuing Theory）中最经典的多服务台模型：

M / M / c / ∞ / ∞

到达过程 / 服务时间 / 服务台数 / 队列容量 / 顾客总数

三个字母的含义