📚 课程目录第3章国密SDK并发模型

国密SDK并发模型：线程池、异步回调、事件驱动对比

并发模型的选择，说白了就是在「资源利用率」「开发复杂度」「响应时延」之间做取舍。我在不同项目中试过这三种模型踩过的坑加起来能写满一个笔记本。今天就逐一拆开聊，顺便把核心差异理清楚。

线程池模型

这是最直观的做法：来一个请求，从线程池里拎一个线程去干活。我早期做国密签名服务时就用的这个模型，简单粗暴。

资源管控：核心线程数、最大线程数、队列容量写死在配置里，超出就拒绝。
阻塞点：线程在执行 SM2_do_sign() 时是同步阻塞的，如果密码卡耗时波动大，线程池很容易被占满。
适用场景：CPU 密集型或短耗时的同步操作。

避坑指南：我曾经把核心线程数设成跟 CPU 核数一样，结果某个接口调用了内部 HTTP 服务，线程全堵在 IO 上，后面任务全排队超时。后来我改成根据 IO 等待时间动态调参，才稳住。

小技巧：用 ThreadPoolExecutor 的 setRejectedExecutionHandler 配个降级策略，别直接抛异常。

异步回调模型

线程池模型搞不定长耗时操作，异步回调就出来了。调用方发起请求后立即返回一个 Future，拿到结果后再走回调。

典型实现：CompletableFuture、Guava 的 ListenableFuture。
优势：调用线程不被阻塞，吞吐量提得很明显。
痛点：回调嵌套深了代码就变成“箭头形”地狱，调试时根本看不清调用栈。

我记得在给某银行做国密网关时，用了异步回调处理签名验证链。一开始回调里套回调，出了个异常根本定位不到是哪一层抛的。后来硬着头皮改成链式编排 + 统一异常处理，才算可维护。

// 异步回调示例（CompletableFuture）
CompletableFuture.supplyAsync(() -> sm2Service.doSign(data))
    .thenApply(signResult -> verifyService.checkSign(signResult))
    .exceptionally(ex -> {
        log.error("签名验证链路异常", ex);
        return ErrorResponse.of(500);
    });

注意：回调中的线程切换容易丢失上下文（比如 TraceId、国密 Key 索引），务必用 Executor 包装一下或者手动传递上下文。

事件驱动模型

事件驱动，说白了就是“等事件来了再干活”。典型代表是 Netty 的 Reactor 模型，或者 Vert.x 里的 Event Loop。

核心思想：用少量 Event Loop 线程处理所有 IO 事件，业务逻辑拆成 Handler 链。
优势：无锁、线程数极少、上下文切换成本低。
劣势：Handler 里绝不能做阻塞操作，否则整个 Event Loop 完蛋。

我建议在做国密代理网关、商密隧道这类对并发要求极高的场景时，优先考虑事件驱动。我自己在自研国密 SDK 底层就用了 epoll + 事件驱动架构，把 SM4 加解密流水线化，单机吞吐比线程池模型高了 3 倍以上。

关键实践：把国密运算（如 SM3 哈希、SM4 加解密）拆成无状态阶段，每个阶段一个 Handler，用 Event Loop 串联。

维度	线程池模型	异步回调模型	事件驱动模型
线程管理	池化管理，可预配	回调线程池 + 调用方线程	少量 Event Loop，固定
阻塞方式	同步阻塞	非阻塞，回调唤醒	非阻塞，事件通知
开发复杂度	低，直观	中，需处理回调地狱	高，需理解事件流转
适用场景	短耗、CPU 密集型	IO 密集型、可拆分阶段	高吞吐、长连接、低时延