并发编程核心概念：别再搞混这些基础了
各位同学，咱们先聊点最基础的。别看这些概念听起来简单，我在生产环境里见过太多因为概念不清而翻车的情况了。今天就好好掰扯清楚。
进程与线程：到底谁是谁的容器？
先说进程。它就像一家独立的饭店——有自己的厨房、服务员、收银台、甚至自己的煤气表和电表。操作系统给每个进程分配了独立的内存空间、文件句柄和系统资源。
线程就不一样了。它是在饭店里打工的厨师。所有线程共享进程的厨房用具、食材、收银台。说白了，线程就是进程里的一个执行路径。
我接触HSM SDK时发现一个现象：有些开发者把所有任务都丢到新进程里，觉得这样最安全。结果呢？进程间通信开销直接把性能拉爆了。我建议你搞清楚场景：需要强隔离就开进程，需要高效协作就用线程。
| 对比维度 | 进程 | 线程 |
|---|---|---|
| 资源开销 | 大（独立内存空间，反复创建会卡顿） | 小（共享进程资源，创建销毁都快） |
| 隔离性 | 强（一个崩了不影响其他） | 弱（一个崩了整个进程都得完） |
| 切换开销 | 高（需要切换整个上下文） | 低（只需切换栈和寄存器） |
| 通信方式 | IPC机制（管道、共享内存、套接字） | 直接读写共享内存（但要加锁） |
| HSM适用场景 | 隔离不同安全级别的操作 | 同一安全域内高频调用的分解 |
并发与并行：听名字像一回事，本质差很多
我经常遇到有人把这两个混着用。请你记住：并发是逻辑概念，并行是物理概念。
单核CPU也能做并发——通过时间分片，让多个任务轮流执行。就像你一边泡面一边写代码：泡面等待的时候敲几行，面好了吃两口再继续写。同时只有一件事在做，但看起来像多线同时进行。
并行就不同了。它需要多个CPU核心同时工作。每个核心真正同时执行不同任务。你想想看，单核CPU再怎么折腾也做不到真正并行。这就是为什么多核优化这么复杂。
以HSM的签名操作为例：100个签名请求，单核CPU靠时间分片并发处理；8核CPU可以每个核处理12-13个请求，真正并行运行。
• 4线程（并行度=核心数）: 吞吐量 5200 ops/s
• 32线程（过度并行）: 吞吐量 2800 ops/s
从此我再也不迷信“多线程一定快”了。
同步与异步：别让调用方傻等
同步调用就像你在柜台前等着取餐，什么都干不了，只能干看着。异步调用就像你拿了号，找个位子坐着刷手机，听到叫号再过去拿。
在HSM应用中这个区别特别重要。很多安全操作耗时较长，比如密钥生成可能花费几十毫秒到几百毫秒。如果用同步方式，调用线程就一直阻塞着。
我建议在网络I/O和远程HSM调用场景下优先考虑异步。你把任务放到一个队列里，注册一个回调或等待一个Future，主线程可以继续处理其他工作。
// 同步模式 — 调用方傻等
signature = hsm_sync_sign(hsm_ctx, key_id, data);
process_result(signature); // 等sign返回了才能执行
// 异步模式 — 调用方不阻塞
future = hsm_async_sign(hsm_ctx, key_id, data);
do_other_work(); // 不用等，继续干别的
signature = future_wait(future); // 需要结果时才wait
process_result(signature);
| 对比维度 | 同步 | 异步 |
|---|---|---|
| 执行方式 | 发出请求后等待完成 | 发出请求后立即返回 |
| 阻塞情况 | 调用线程全程阻塞 | 调用线程不阻塞，可做其他事 |
| 编程复杂度 | 简单直接，像读小说 | 需要回调/协程/Future，容易写出回调地狱 |
| CPU利用率 | 低（阻塞时CPU空转） | 高（阻塞时间被其他任务利用） |
| HSM适用场景 | 短耗时操作（毫秒级签名） | 长耗时操作（密钥生成、证书签发） |
并发性能指标：别只盯着一个数看
做性能优化，你得知道怎么衡量。我一般盯三样东西：吞吐量、延迟、CPU利用率。这三个指标相互影响，不能只看一个。
吞吐量就是单位时间内能处理多少请求。我习惯用每秒签名次数（ops/s）来衡量HSM的性能。提升吞吐量，核心思路是减少每个请求的处理时间，或者同时处理更多请求。
延迟是从发起到完成的时间间隔。这个指标特别受关注。用户端感知的“卡顿”其实就是延迟高。吞吐量高了不一定是好事——如果延迟也跟着涨，用户就骂娘了。
CPU利用率也不简单。CPU跑满100%不一定就是好事，可能是在做无谓的上下文切换。我见过最极端的情况：一个HSM SDK进程占了400%的CPU（4核），但吞吐量还不如另一个只占150%的版本。
| 指标 | 含义 | 优化要点 | 常见陷阱 |
|---|---|---|---|
| 吞吐量 | 单位时间处理请求数 | 减少单次耗时、增加并发度 | 一味堆线程反而降低 |
| 延迟 | 请求发起到完成的时间 | 减少阻塞、避免频繁切换 | 吞吐量提升时延迟可能暴涨 |
| CPU利用率 | CPU繁忙程度百分比 | 区分有效计算和调度开销 | 高利用率≠高吞吐（可能全浪费在切换上） |