在性能调优、系统设计和并发编程中，我们常将任务或程序区分为 CPU 密集型 和 I/O
密集型。理解这两种类型的根本区别，对于合理分配计算资源、选择合适的编程模型和优化系统性能至关重要。

CPU 密集型（CPU-Bound）
核心特征：任务的执行速度主要受限于中央处理器（CPU）的运算能力。任务需要大量的计算和逻辑处理，CPU 处于高负荷运转状态。

系统表现：运行此类任务时，CPU 使用率通常会接近 100%（或某个核心的100%），而磁盘 I/O 和网络 I/O 的等待时间很短，因为计算是主要瓶颈。

通俗比喻：就像一个数学家在草稿纸上飞速演算一道复杂的微积分题。草稿纸（I/O）提供和记录数据很快，但解题思考（CPU计算）过程占据了绝大部分时间。

典型例子：

复杂的科学计算（如圆周率计算、物理模拟、密码哈希计算）。

视频编码/解码、图像渲染。

大数据分析中的复杂聚合与转换运算。

对编程的启示：

语言选择：应优先选择执行效率高、接近硬件的编译型语言，如 C、C++、Rust。像 Python 这类解释型语言，由于运行效率较低，不适合核心的
CPU 密集型计算（可通过调用 C 扩展库弥补）。

并发策略：并非线程/进程越多越好。对于纯 CPU 密集型任务，理想的最大并行数应约等于 CPU
的核心数（或逻辑处理器数）。如果创建过多的线程，大量的时间会浪费在上下文切换上，反而降低整体吞吐量。线程池的核心线程数应设置为
CPU 核数。

I/O 密集型（I/O-Bound 或 I/O Intensive）
核心特征：任务的执行速度主要受限于输入/输出操作的速度。这些 I/O 操作包括磁盘读写、网络请求、数据库查询等。任务大部分时间在等待这些慢速操作完成，CPU
经常处于空闲或低负载状态。

系统表现：运行此类任务时，CPU 使用率通常较低（可能只有百分之几或几十），系统瓶颈在于磁盘的吞吐量、网络的延迟或数据库的响应速度。

通俗比喻：就像一个图书管理员根据索书单去巨大的书库里找书。思考索书单（CPU计算）很快，但大部分时间花在穿梭于书架之间和取书（I/O
等待）上。

典型例子：

Web 服务器处理 HTTP 请求（大部分时间在等待网络传输和数据库响应）。

文件读写、日志处理。

调用外部 API 或 RPC 服务。

对编程的启示：

语言选择：更看重开发效率和生态。高级脚本语言如 Python、JavaScript (Node.js)、Java 是绝佳选择。因为 CPU 不是瓶颈，用 C
语言重写带来的微秒级 CPU 时间提升，相比数百毫秒的 I/O 等待时间可以忽略不计。

并发策略：非常适合高并发模型。当一个任务因等待 I/O 而阻塞时，CPU 可以立刻切换到另一个任务去执行。因此，可以创建远多于 CPU
核心数的线程或协程（如成千上万个），以充分利用 CPU 在 I/O 等待期间的闲置能力。异步非阻塞编程模型（如
Node.js、NIO、协程）在此类场景下优势极大，可以用极少的线程服务大量并发连接。

对比总结与混合类型
特性 CPU 密集型 I/O 密集型
主要瓶颈 CPU 计算速度 磁盘/网络/数据库 I/O 速度
CPU 使用率 高（接近饱和） 低（大量时间在等待）
优化方向 优化算法，提升单核性能，并行计算 减少 I/O 次数，使用缓存，异步非阻塞，提高并发度
理想线程数 ≈ CPU 核心数 >> CPU 核心数
语言偏好 C, C++, Rust, Go Python, Java, JavaScript, Go
现实中的任务：很多任务都是混合型的，例如一个 Web 请求，既包含从数据库取数据（I/O），也包含对数据进行业务逻辑处理和 JSON
序列化（CPU）。分析时需要识别瓶颈主要出现在哪个环节。

结论：先明确任务类型，才能做出正确的技术决策：是用 Go 的 goroutine 处理海量网络连接，还是用 C++
编写高性能的游戏物理引擎。这是架构师和高级开发者必备的系统性思维。