并发是任务调度器快速切换执行权实现“看似同时”，并行是多核物理“真正同时”；前者重I/O等待与调度，后者重CPU计算与隔离，二者常嵌套但瓶颈类型不同。
并发不是并行，高并发系统里搞混这两者，轻则压测结果看不懂，重则上线后线程池爆满却查不出原因。
并发（concurrency）是“看起来同时做多件事”
它本质是任务调度器在单核或多核上快速切换执行权，让多个任务交替推进。比如 Python 的 asyncio、Go 的 goroutine（默认绑定到少量 OS 线程）、Java 的 CompletableFuture 都是典型并发模型。
- 常见错误现象：
top显示 CPU 使用率很低，但请求延迟飙升、超时大量出现——说明不是算力瓶颈，而是 I/O 等待堆积或协程/线程调度阻塞 - 关键判断点：是否依赖
await、yield、回调或事件循环来让出控制权？如果是，就是并发 - 性能影响：并发本身不消耗额外 CPU，但上下文切换、队列排队、锁竞争会拖慢整体吞吐；过度拆分任务反而增加调度开销
并行（parallelism）是“真正在多个 CPU 核心上同时跑代码”
它要求任务能真正物理隔离执行，比如 Java 的 ForkJoinPool、Python 的 multiprocessing、Rust 的 rayon::par_iter()。没有共享内存竞争或全局解释器锁（GIL）干扰时，并行才有效。
- 常见错误现象：
threading在Python里 CPU 密集型任务几乎不提速——因为GIL阻止了真正的并行 - 使用场景：图像批量处理、矩阵计算、日志归档等可切分且无强状态依赖的计算任务
- 参数差异：
multiprocessing.Pool(processes=4)中的processes应该接近 CPU 核心数，设成 100 反而引发进程创建和 IPC 开销
高并发系统里，两者经常嵌套使用
比如一个 Web 服务用 epoll（并发）接收数千连接，每个连接里的数据库查询又通过连接池 + 异步驱动（并发），而某个报表导出接口内部调用 rayon（并行）加速数据聚合——三层混合很常见，但每一层的瓶颈类型完全不同。
- 容易踩的坑：
async函数里直接调用同步阻塞函数（如time.sleep(5)或未加await的requests.get()），会让整个事件循环卡住 - 调试线索：看
strace -p PID是否频繁出现epoll_wait（并发等待）还是clone/wait4（并行进程活动） - 兼容性注意：
asyncio和threading混用需小心loop.run_in_executor()的线程安全边界；goroutine调用 C 代码可能触发M级别阻塞，影响其他 goroutine 调度
真正难的是在监控指标里分辨清楚：延迟毛刺来自并发调度延迟，还是并行资源争抢。比如 go tool pprof 看到大量 runtime.mcall 时间，说明协程调度压力大；而 perf record -e cycles:u 显示用户态周期集中在某几个函数，则更可能是并行计算热点。这些信号不结合原理去读，很容易误判优化方向。
