高并发场景下的线程、异步与数据库优化实践

引言

在电商秒杀、实时风控等高并发场景下，线程管理、异步任务和数据库交互往往是性能瓶颈的“重灾区”。近期我们在一个10万QPS的支付系统中，发现线程池耗尽导致交易失败的问题。本文将结合真实案例，探讨线程优化、异步编排、数据库访问模式，并介绍如何通过实时监控提前发现风险。

1. 线程池配置不当引发的血案

1.1 问题现象

我们的支付系统在大促期间频繁出现**“RejectedExecutionException”**，即线程池任务被拒绝。初步排查发现：

• 核心线程数（corePoolSize） 设置过低（默认10）
• 队列（workQueue） 使用无界队列（LinkedBlockingQueue），导致OOM风险
• 最大线程数（maxPoolSize） 未根据CPU核心数调整

1.2 优化方案

我们采用动态线程池（Dynamic ThreadPool），并结合监控告警：

关键代码调整：

ThreadPoolExecutor executor = new ThreadPoolExecutor(
    8,  // corePoolSize
    16, // maxPoolSize
    60, // keepAliveTime (秒)
    TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(500),  // 有界队列
    new ThreadPoolExecutor.CallerRunsPolicy()  // 降级策略
);

2. 异步任务编排优化

2.1 同步 vs. 异步的抉择

在高并发场景下，同步阻塞操作（如DB查询、RPC调用）会导致线程长时间占用。我们对比了不同方案的性能（测试环境：100并发请求）：

结论：

• CompletableFuture 适用于简单异步编排
• Reactor（响应式编程） 在超高并发下表现更优

2.2 异步任务的“坑”

• 数据库连接泄漏：异步任务未正确关闭连接
• 上下文丢失：MDC/ThreadLocal 在异步线程中失效
• 任务堆积：未限制异步队列大小

解决方案：

// 使用 MDC + 线程池装饰器
ExecutorService asyncExecutor = MDC.wrap(
    Executors.newFixedThreadPool(8)
);

3. 数据库访问优化

3.1 连接池调优

HikariCP 推荐配置：

spring:
  datasource:
    hikari:
      maximum-pool-size: 20
      connection-timeout: 2000
      leak-detection-threshold: 5000  # 连接泄漏检测（ms）

3.2 避免N+1查询

我们曾因ORM框架的懒加载导致1次API调用触发100+SQL查询。解决方案：

• 使用JOIN FETCH（JPA）
• MyBatis 开启二级缓存

4. 实时监控：提前发现性能瓶颈

4.1 关键监控指标

4.2 实战案例：线程泄漏排查

某次线上故障，线程数从200暴涨至2000，最终定位到：

1. 异步HTTP客户端未复用（每次请求新建线程）
2. 数据库连接未释放（因事务未提交）
3. 监控未覆盖线程创建速率

改进：

// 使用全局HTTP客户端（如OkHttp）
private static final OkHttpClient httpClient = new OkHttpClient();

总结

1. 线程池：避免无界队列，动态调整核心参数
2. 异步任务：选择合适框架（CompletableFuture/Reactor）
3. 数据库：优化连接池，避免N+1查询
4. 监控：覆盖线程、DB、异步任务关键指标

你的系统是否也有类似问题？欢迎在评论区交流！