# IO多路复用与并发编程发展史

Posted on 2025-09-30 00:37 吾以观复阅读(6) 评论(0) 收藏举报

关联知识库：# IO多路复用与并发编程发展史

IO多路复用与并发编程发展史

【思维路线图】

** 本文主旨：**
本笔记通过“时间演进”与“权责划分”两大核心视角，深度剖析操作系统并发编程的宏大图景。它旨在探究各种并发模型“是什么”，并追问其“为什么”会以特定形态出现，最终聚焦于IO多路复用技术，并落脚于最关键的技术选型实践，揭示其在现代高性能服务中的基石角色与应用智慧。

** 内容结构与核心看点：**

第一部分：并发思想的演进史诗 (时间线篇)
- 核心脉络： 以时间为线索，讲述一部为应对时代核心矛盾而不断演进的技术斗争史。
- 看点：
  - 多线程： 诞生于“利用CPU等待时间”的史前时代。
  - IO多路复用： 成为应对“C10K”网络风暴的银弹。
  - 协程与Actor： 作为“多核与分布式”时代的两大现代答案。
  - 异步I/O： 作为追逐“硬件性能极限”的未来之星。
第二部分：内核与应用的权力游戏 (权责视角篇)
- 核心脉络： 从“权力与责任”的哲学高度，审视不同模型中内核与应用层的角色定位与分工模式。
- 看点：
  - 应用层主导型 (多线程)： 因“信息不对称”而低效的权力游戏。
  - 内核代理型 (IO多路复用/AIO)： “专业分工”带来的效率革命。
  - 应用层优化型 (协程/Actor)： 外部协作优化到极致后，通过“内部革命”实现的飞跃。
第三部分：IO多路复用深度解析 (技术核心篇)
- 核心脉络： 聚焦于IO多路复用这一关键技术，从生态影响到内核实现，进行全方位解构。
- 看点：
  - 生态影响： Nginx、Redis、Node.js等视其为“幕后英雄”。
  - 核心三要素： 操作者(内核)、操作对象(Socket)与核心数据结构(红黑树+双向链表)的精巧设计。
  - 黄金触发链： 从“硬件中断”到“回调函数”的完整事件之旅。
  - 哲学回归： “硬件中断感知权”是内核拥有绝对优势的根本原因。
第四部分：技术选型篇 (实践智慧篇)
- 核心脉络： 回归实践，提供一个系统性的决策框架，指导如何在真实业务场景中选择最合适的并发模型。
- 看点：
  - 核心原则： “职责分离”是所有选型思考的基石。
  - 决策框架： 如何权衡应用类型、并发等级、资源约束三大关键因素。
  - 场景分析与最佳实践： 深入剖析纯I/O、纯CPU及最常见的混合型场景，并结合Nginx、Redis、Netty、Go等真实案例，讲解“单兵极致”、“多核并行”与“混合架构”的智慧。

⏰ 第一部分：时间线篇 —— 并发思想的演进史诗

引言： 技术并非凭空产生，而是时代需求的产物。并发编程的演进史，就是一部计算机科学家与工程师们，为了追赶硬件发展、应对爆炸式增长的网络需求而不断斗争、创新的历史。循着时间的足迹，我们能更深刻地理解每一种并发模型为何诞生，以及它解决了哪个时代的核心矛盾。

第一幕：史前时代 (1960s - 1990s) —— 多线程模型的诞生与确立

时代背景： 单核CPU时代，分时操作系统出现。计算机从一次只能做一件事，演进到需要在昂贵的CPU资源空闲时（如等待慢速的磁带或磁盘I/O）处理其他任务。
核心矛盾： 如何利用CPU的I/O等待时间？
技术突破： 多线程/多进程模型应运而生。其哲学非常直观：当一个执行单元（线程）因I/O而阻塞时，操作系统（内核）就快速切换到另一个可执行的线程，让CPU“永不空闲”。
历史定位： 在那个时代，多线程是解决“阻塞”问题的革命性方案。它让单个程序能“同时”处理多个任务，极大地提升了系统的吞吐率和响应性。它奠定了并发编程的基础，其简单直观的“一个任务一个线程”模型，至今仍在许多场景下被使用。

第二幕：C10K挑战时代 (2000s) —— I/O多路复用的封王

时代背景： 互联网浪潮爆发，Web 1.0/2.0兴起。服务器需要面对的不再是几百个，而是成千上万（C10K - Concurrent 10,000 connections）甚至更多的并发连接。
核心矛盾： 多线程模型在海量连接下面临崩溃。 线程的创建和上下文切换开销变得无法承受，系统资源被迅速耗尽。
技术突破： I/O多路复用模型（以Linux epoll为代表）登上历史舞台。它提出了一种颠覆性的思想：不要为每个连接都创建一个线程，而是用一个线程去管理所有连接。通过将"等待I/O事件"这一职责完全交给内核，应用层只在事件真正发生时才介入处理。
- The C10K Problem - Dan Kegel - C10K问题的经典论文，详细分析了高并发连接的技术挑战和解决方案
- Nginx Architecture Documentation - Nginx官方架构文档，展示基于epoll的高性能架构设计
历史定位： I/O多路复用是应对互联网高并发时代的“银弹”。Nginx、Redis、Node.js等技术的巨大成功，都建立在这块基石之上。它标志着高性能网络编程从“资源消耗型”向“事件驱动型”的根本转变。

第三幕：多核与分布式时代 (2010s) —— Actor与协程的崛起

时代背景： 摩尔定律趋缓，“核战争”打响，多核CPU成为标配。同时，单机性能达到瓶颈，分布式系统成为主流。
核心矛盾：
1. 如何充分利用多核CPU的计算能力？（I/O多路复用模型本身是单线程的）
2. 如何简化日益复杂的并发与分布式编程？（锁、共享内存、网络通信让人头疼）
技术突破（两条路线）：
1. Actor模型 (Erlang/Akka)： 诞生于电信领域的Actor模型，其“无共享状态，消息传递”的哲学，被发现在分布式和多核环境下能从根本上解决数据竞争和锁的问题。它为构建高容错、易扩展的系统提供了完美的架构范式。
2. 协程模型 (Go/Kotlin/Java Loom)： 协程提供了一种更务实的方案。它在用户态实现了比线程轻量得多的"微线程"，让开发者能以简单的同步代码风格，写出兼具I/O多路复用性能和多线程利用多核能力的程序。Go语言的成功，正是因为它将复杂的协程调度完美地封装在了语言运行时中。
  * Go Concurrency Patterns - Go语言官方博客，详细介绍协程并发模式和最佳实践
  - Go Concurrency Best Practices - Go语言官方博客，提供并发编程的最佳实践和设计模式
历史定位： Actor和协程是应对“多核”与“分布式”两大主题的现代答案。Actor在架构层面提供了并发安全的顶层设计，而协程则在编程语言层面极大地降低了高性能并发编程的门槛。

第四幕：未来已来 (2020s - ) —— 异步I/O的回归与统一

时代背景： 云原生、大数据、AI对I/O性能提出了极致要求。内核与应用层之间的交互开销（系统调用）本身也成了新的瓶颈。
核心矛盾： 如何将I/O性能压榨到硬件极限？
技术突破： 异步I/O模型（以Linux io_uring为代表）强势回归。它不仅让内核通知事件，还让内核代为完成I/O操作，并通过共享内存环形缓冲区等技术，将系统调用的开销降到最低。
- Linux io_uring: The Future of Async I/O - LWN.net深度技术分析，详细介绍io_uring的设计原理和性能优势
历史定位： io_uring被誉为“Linux I/O的未来”，它统一了多种I/O范式，提供了接近硬件极限的性能。它代表了并发模型演进的最新方向：将更多底层细节交给内核，让应用层以更高效、更声明式的方式与系统交互。

⚖️ 第二部分：权责视角篇 —— 内核与应用的权力游戏

引言： 并发模型的本质，是一场关于“权力”与“责任”的划分。拥有最高权限、掌控硬件的操作系统内核，与贴近业务、负责逻辑的应用程序，应该如何分工协作？不同的分工模式，决定了不同模型的基因与命运。

阵营一：应用层主导型 —— "我的地盘我做主"

代表模型： 多线程模型
权责划分：
- 应用层责任： 承担了主要的并发管理责任。负责创建线程、分配任务、处理线程同步（加锁）。
- 内核层责任： 扮演“基础设施提供者”的角色。提供线程这一基本单元，并负责在CPU上进行“不知情”的调度。
设计哲学： 这是一种"信任自己"的哲学。应用层试图在自己的地盘上解决所有并发问题。但由于缺乏对底层硬件状态的感知权（如I/O是否就绪），这种管理往往是低效和昂贵的。

阵营二：内核代理型 —— "专业的事交给专业的人"

代表模型： I/O多路复用、异步I/O
权责划分：
- 内核层责任： 权力被大大加强。内核利用其硬件感知特权，接管了“I/O事件管理”的核心职责。在异步I/O中，内核甚至代为完成了“数据拷贝”。内核从被动调度者，变成了主动的“事件代理”和“任务执行者”。
- 应用层责任： 责任被聚焦。应用层下放了“等待”和“探查”的职责，只需告诉内核“我要什么”，并在内核完成任务后处理结果。
设计哲学： 这是“权责分离”与“专业分工”的哲学。内核做它唯一能做且最擅长的事（与硬件交互），应用层则专注于业务逻辑。这是构建高性能I/O系统的基石。

阵营三：应用层优化型 —— "在自己的世界里精耕细作"

代表模型： 协程模型、Actor模型
权责划分：
- 这是一个在应用层内部进行的“自我革命”和“架构重塑”。
- 协程模型： 应用层（通过语言运行时）在内核线程之上，建立了一套用户态的、更轻量、更聪明的调度系统。它在不改变与内核协作模式的前提下，通过“内部挖潜”，将单个内核线程的利用率压榨到极致。
- Actor模型： 应用层通过架构设计，将自身划分为无数个“责任独立、状态隔离”的单元（Actor）。它在应用层强制推行了一套“无共享、消息传递”的通信法则，从根本上解决了并发安全问题。
设计哲学： 这是“向上抽象”和“内部优化”的哲学。当与内核的协作模式优化到一定程度后，将目光转向应用层自身，通过更聪明的调度算法或更优秀的架构模式，来解决更上层的复杂性问题。

第三部分：IO多路复用深度解析 —— 内核的"事件调度"艺术

引言： 在前两章，我们明确了IO多路复用在并发历史长河中的坐标，以及它在"内核与应用权责划分"中的"内核代理"定位。现在，是时候拉开帷幕，走进这位"金牌代理人"的内部，探究它究竟是如何凭借一己之力，调度成千上万的网络连接的。

3.1 生态与影响：无处不在的基石

在深入技术细节之前，我们必须先认识到IO多路复用技术在现代软件生态中的统治级地位。它并非一个孤立的内核特性，而是支撑了无数流行框架和语言的幕后英雄。

Java NIO & Netty： Java从JDK 1.4开始引入的NIO（New I/O）库，其核心Selector机制，在Linux平台上就是对epoll的直接封装。而像Netty、Mina这样的高性能网络框架，更是将epoll的威力发挥到了极致，成为了Spring WebFlux、Dubbo、RocketMQ等众多分布式组件的底层网络引擎。
- Java NIO Package - Oracle官方Java NIO API文档
- Netty Framework Wiki - Netty官方架构文档和最佳实践指南
Node.js： Node.js能以单线程处理高并发的秘密，就在于其底层的libuv库。libuv为上层JavaScript提供了统一的异步接口，而在Linux环境下，它正是依赖epoll来实现高效的事件循环。
- libuv Implementation - Node.js底层事件循环库的源码和文档
Python asyncio & uvloop： Python的asyncio库为Python带来了原生的异步编程能力，其默认的事件循环在Linux上也是使用epoll。为了追求极致性能，社区还开发了uvloop——一个用Cython编写的、直接封装libuv的事件循环，性能远超原生实现。
- Python asyncio PEP 3156 - Python异步I/O的官方设计文档
Nginx & Redis： 这两位高性能领域的王者，其核心竞争力都源于对IO多路复用模型的精湛运用。
- Redis Network Architecture - Redis官方技术博客，详细介绍网络架构和性能优化

结论： 理解IO多路复用，尤其是epoll，就等于拿到了理解现代高性能网络编程的“万能钥匙”。

3.2 核心三要素：解构`epoll`的工作台

epoll的高效，源于其精巧的设计。我们可以从三个核心要素来解构它的工作台：

操作者：内核程序
- 这是最关键的一点。执行epoll调度的主体，不是应用程序，而是拥有最高权限的操作系统内核。只有它，才能直接与硬件对话，才能在全局视角下管理所有socket资源。
操作对象：Socket连接
- epoll管理的是一个个的socket连接。在内核看来，每个socket都是一个内核层面的资源对象，它有自己的状态（可读、可写、已关闭等）和自己的数据缓冲区。
核心数据结构：红黑树 + 双向链表
- 这是epoll性能优越的秘诀所在。
  - 红黑树： 用于存储所有被监听的socket。当你需要添加或移除一个监听时，红黑树能提供O(log n)级别的快速查找和操作，轻松管理数十万连接。
  - Red-Black Tree in Linux Kernel - Linux内核红黑树实现的官方文档
  - 双向链表（就绪队列）： 用于存放那些已经就绪（即有事件发生）的socket。这个设计是点睛之笔，它使得应用程序获取就绪事件时，只需从这个链表中拿数据即可，时间复杂度是O(1)，无论总连接数有多少。

⚡ 3.3 黄金触发链：一次完整的事件之旅

为了彻底理解epoll的运行机制，让我们以一个客户端请求为例，追踪一次完整的事件触发流程。这个流程的核心，就是由硬件中断驱动的回调函数机制。

【客户端】发送数据： 客户端（例如，执行redis-cli set key value）通过网络向服务器发送数据。
【服务器网卡】接收数据 & 触发硬件中断：
- 数据包到达服务器的网卡。网卡在将数据写入自己的缓冲区后，会立刻向CPU发送一个硬件中断信号。
- 【权限关键点】：这是整个流程的起点，也是只有内核才拥有的特权。应用程序无法直接感知硬件中断。
【内核】中断处理 & 数据拷贝：
- CPU收到中断信号后，会暂停当前正在执行的任务，跳转到内核预设好的中断服务例程（ISR）。
- ISR程序会读取网卡缓冲区的数据，并根据数据包的目标端口号，找到对应的socket，然后将数据拷贝到该socket的内核缓冲区中。
【内核】状态变化 & 触发回调：
- 数据进入socket缓冲区后，该socket的状态发生了根本性变化：从“不可读”变为了“可读”。
- 【核心机制】：在之前通过epoll_ctl添加这个socket监听时，内核就已经给这个socket注册了一个回调函数。此时，socket状态的变化会自动触发这个回调函数的执行。
【内核】执行回调 & 加入就绪队列：
- 这个被触发的回调函数，其核心工作非常简单：将当前这个就绪的socket，添加到epoll实例的“就绪队列”（双向链表）的末尾。
【应用层】获取就绪事件：
- 应用程序的事件循环线程，此时可能正阻塞在epoll_wait()调用上。当就绪队列不再为空时，epoll_wait()会立即返回，并将就绪队列中的socket列表拷贝给应用程序。应用程序拿到这个列表，就知道该处理哪些连接了。

3.4 技术优势总结与哲学回归

通过上述分析，我们可以总结出IO多路复用技术的两大本质优势：

基于硬件中断的被动通知： 它彻底抛弃了应用层低效的“主动轮询”。应用程序不再需要空转CPU去问“谁好了？”，而是进入休眠，等待内核这位“管家”在真正有事时“被动地”叫醒。这是从“忙等”到“静候”的革命。
精巧数据结构带来的极致效率： 通过“红黑树管理全集，链表管理就绪集”的分离设计，使得无论总连接数多庞大，获取就绪事件的成本始终是恒定的O(1)，从算法层面保证了其卓越的扩展性。

最后，我们再次回归到权责划分的哲学层面。IO多路复用之所以必须且只能在内核中实现，根本原因在于内核独占了对硬件中断的感知权。这决定了它必然是最高效的I/O事件发现者。而应用程序的最佳策略，就是信任内核，将专业的事交给专业的人，自己则专注于更高层次的业务逻辑。这不仅是技术的选择，更是架构的智慧。

第四部分：技术选型篇 —— 并发编程的实践智慧

引言： 理论的最终目的是指导实践。在掌握了并发模型的演进历史、设计哲学和技术内核之后，我们来到了最关键的一环：在纷繁复杂的现实世界中，如何为我们的应用选择最合适的并发模型？这不仅是技术的抉择，更是对业务场景、资源成本和团队能力的综合考量。

4.1 核心原则：职责分离的架构智慧

所有技术选型的出发点，都应回归到一个深刻的架构哲学：让系统的每个部分都做自己最擅长的事。

操作系统的独特优势（内核层）：
1. 硬件中断感知能力： 唯一能直接、高效地响应网卡、磁盘等硬件事件。
2. 底层资源管理： 对socket连接、内存缓冲区、进程/线程拥有绝对控制权。
3. 高效的全局调度： 能够从系统全局视角进行任务调度。
应用程序的专注领域（应用层）：
1. 业务逻辑处理： 解析协议、执行业务规则、生成响应。
2. 数据转换与计算： 将原始数据流转换为有意义的业务对象。
3. 状态管理与持久化： 维护应用会话状态，与数据库等外部系统交互。

一个优秀的并发架构，就是让内核高效地处理I/O事件和任务调度，而让应用程序能心无旁骛地专注于实现复杂的业务逻辑。

⚖️ 4.2 决策框架：权衡三大关键因素

在进行技术选型时，我们需要在一个决策框架内，权衡以下三个关键因素：

应用类型 (I/O密集型 vs. CPU密集型 vs. 混合型)
- I/O密集型 (I/O-Bound)： 应用大部分时间都在等待网络或磁盘I/O。例如API网关、消息队列、静态文件服务器。这是I/O多路复用和协程的主战场。
- CPU密集型 (CPU-Bound)： 应用大部分时间都在进行科学计算、视频编码、图像处理等。这是多线程模型发挥多核优势的最佳场景。
- 混合型： 大多数Web应用都属于此类，既有大量的I/O操作（查询数据库、调用外部服务），又有不可忽视的业务逻辑计算。这是混合架构大显身手的地方。
并发连接数 (Concurrency Level)
- 低并发 (< 1000)： 连接数较少，性能压力不大。多线程模型因其开发简单，通常是首选。
- 高并发 (> 5000-10000)： 需要处理数万甚至更多的连接。I/O多路复用或协程模型是必然选择，因为它们在资源占用上具有压倒性优势。
资源与团队约束 (Resource & Team Constraints)
- 内存受限： I/O多路复用/协程模型内存占用极少，是内存敏感型应用的首选。
- CPU受限： 需要充分利用多核CPU时，应选择多线程或支持多线程调度的协程模型。
- 团队熟悉度与开发效率： 如果团队更熟悉传统的多线程同步编程，且项目上线时间紧迫，选择多线程模型或Java虚拟线程（用同步方式写异步代码）可能是更务实的选择。

4.3 场景分析与最佳实践

场景一：纯粹的高并发I/O —— “单兵极致”

场景描述： 应用的核心任务是处理海量的网络连接，每个连接上的业务逻辑非常简单，甚至是纯粹的数据转发。
技术选型： 纯粹的I/O多路复用模型。
架构模式： 单线程或“Master + 多Worker进程”模式，每个Worker进程内部是一个单线程的事件循环。
案例分析：
- Nginx： 作为Web服务器和反向代理，其主要工作就是高效地处理HTTP请求和响应的I/O。Nginx的Master-Worker架构，每个Worker进程就是一个高效的epoll事件循环，使其成为处理静态资源和代理请求的性能之王。
  - Nginx Performance Tuning - Nginx官方博客，提供性能调优和最佳实践指南
- Redis (6.0前)： Redis是内存数据库，所有操作极快，性能瓶颈几乎完全在网络I/O上。其经典的单线程Reactor模型，利用epoll处理所有客户端连接，既保证了极高的吞吐量，又完美地避免了多线程操作共享数据带来的锁开销和复杂性。
  - Redis Performance Optimization - Redis官方技术博客，提供性能优化和架构设计指南

场景二：CPU密集型计算 —— “多核并行”

场景描述： 应用需要进行大量的数值计算、数据分析、图像渲染等，I/O操作相对较少。
技术选型： 经典的多线程模型。
架构模式： 创建一个与CPU核心数相当的线程池，将计算任务分解后分发给各个线程，实现真正的并行计算。
案例分析：
- 视频转码服务： 一个视频文件可以被切分成多个片段，每个线程负责处理一个片段的编码，最后再将结果合并。这能最大限度地利用所有CPU核心，大大缩短处理时间。
- 科学计算与数据分析： 在Python中，像NumPy、SciPy这样的库，其底层许多计算密集型操作都是通过C语言实现并释放了GIL（全局解释器锁），能够充分利用多线程并行计算。

场景三：最常见的混合型应用 —— “混合架构的智慧”

场景描述： 大多数现代Web应用和后端服务，既要应对高并发的I/O请求，又要处理其中涉及的复杂业务逻辑（CPU计算）。
技术选型： 混合使用I/O多路复用与多线程/协程。
架构模式一：Reactor + 线程池 (IO线程 + 工作线程池)
- 工作原理： 使用少量I/O线程（通常与CPU核心数相等）通过epoll等机制专门负责网络I/O。当接收到请求并完成数据读取后，将解析出的业务任务封装成一个Task，扔到后端的业务逻辑线程池中去处理。业务线程池中的线程可以执行耗时的、甚至阻塞的操作（如访问数据库、复杂计算），而不会影响到前台I/O线程的响应能力。
- 案例分析：
  - Java Netty框架： 这是该模式最经典的实现。Netty的EventLoopGroup可以被看作是I/O线程池，开发者可以在ChannelHandler中将耗时任务提交给一个单独的业务ExecutorGroup（工作线程池）。
    - Netty Architecture Best Practices - Netty官方架构文档和最佳实践指南
  - Redis 6.0+ 的多线程： Redis 6.0引入的多线程，并非用多线程处理命令执行（核心数据结构操作依然是单线程），而是在网络I/O处理上使用了多线程。即一个主线程负责接收连接，然后将socket的读写任务分发给多个I/O线程去处理，处理完的数据再交由主线程去执行命令。这正是用多线程来分担主线程的I/O压力，是混合架构思想的体现。
架构模式二：现代协程模型 (内置混合调度)
- 工作原理： 语言的运行时（Runtime）内置了对混合场景的智能调度。当一个协程发起I/O操作时，运行时会将其挂起，并让底层的I/O线程（通常是基于epoll）去处理。当协程需要进行CPU密集型计算时，运行时会将其调度到专门的计算线程上。这一切对开发者几乎是透明的。
- 案例分析：
  - Go语言： Go的GMP调度模型是混合架构的典范。开发者只需用go关键字创建goroutine，无论是执行I/O还是CPU计算，Go的运行时会自动在网络轮询器（netpoller，基于epoll）和系统工作线程之间进行最优的调度。
  - Java虚拟线程 (Project Loom)： 当一个虚拟线程执行阻塞I/O操作时，JVM会将其从平台线程上卸载，直到I/O完成。这使得开发者可以用简单的阻塞式代码，达到非阻塞的性能，其底层正是JVM帮助我们完成了I/O线程与工作线程的调度切换。

结论：
没有放之四海而皆准的"银弹"。成功的技术选型，源于对业务本质的深刻洞察和对不同并发模型权责边界的清晰认知。从纯粹的I/O多路复用，到经典的多线程并行，再到优雅的混合架构，掌握这些模式的适用场景与实践智慧，是每一位高级工程师的必备技能。

参考资料

本文在撰写过程中参考了大量权威的技术文档、学术论文和最佳实践指南，为读者提供深入学习的方向：

The C10K Problem - Dan Kegel - C10K问题的经典论文，详细分析了高并发连接的技术挑战
Linux io_uring: The Future of Async I/O - LWN.net深度技术分析，详细介绍io_uring的设计原理
Java NIO Package - Oracle官方Java NIO API文档
Python asyncio PEP 3156 - Python异步I/O的官方设计文档
Red-Black Tree in Linux Kernel - Linux内核红黑树实现的官方文档
Netty Framework Wiki - Netty官方架构文档和最佳实践指南
Nginx Architecture Documentation - Nginx官方架构文档
Go Concurrency Patterns - Go语言官方博客，详细介绍协程并发模式
Nginx Performance Tuning - Nginx官方博客，提供性能调优指南
Redis Performance Optimization - Redis官方技术博客，提供性能优化指南
Go Concurrency Best Practices - Go语言官方博客，提供并发编程最佳实践
libuv Implementation - Node.js底层事件循环库的源码和文档
Linux Kernel Source - Linux内核源码，包含epoll等核心实现

这些参考资料为本文的技术论述提供了坚实的理论基础和实践支撑，读者可以根据需要深入阅读相关文档，进一步提升对并发编程技术的理解和应用能力。

刷新页面返回顶部

以观复