Python 的"换心"手术：Rust 化浪潮与生态重构

摘要：2026 年春，Pandas 3.0 宣布核心循环全面采用 Rust 重写，处理速度飙升 300%。这并非一次孤立的性能优化，而是一场生态级的"换心手术"。从 Ruff 到 Pydantic V2，从 Polars 的异军突起到 orjson 的隐秘角落，Python 正在经历从"纯解释型脚本"向"Rust 引擎驱动"的范式转移。本文深度拆解这一浪潮的技术底座（PyO3/Arrow）、历史演进（C Extension → Cython → Rust）、生态博弈（GIL 突围/零拷贝）与工程隐忧，揭示 Python 如何在 AI 与大数据时代，通过"胶水语言"的终极形态，延续其不可替代的生命力，并探讨这场重构对开发者、企业与整个数字文明的深远影响。

一、引子：当"胶水语言"长出"钢铁骨骼"

2026 年 4 月，Python 数据科学领域投下了一枚深水炸弹。

Pandas 官方在 GitHub 上发布了 3.0 版本的路线图，其中最引人注目的声明只有一句话："核心数据处理循环已全面采用 Rust 重写。"

没有铺垫，没有妥协。这是一次底层引擎的彻底置换。

基准测试的数据令人震惊：在千万级行数据的 groupby、merge 和 rolling 操作中，Pandas 3.0 的速度提升了惊人的 300%，内存峰值占用下降了近 40%。曾经让无数数据工程师在深夜崩溃的 MemoryError 和 PerformanceWarning，终于有了系统性的解法。

如果把时间轴拉长，你会发现 Pandas 3.0 只是冰山一角。

过去三年，Python 生态正在经历一场静悄悄却波澜壮阔的"换心手术"：

Ruff：这个用 Rust 重写的 Python Linter，以比 Flake8 快 10-100 倍的恐怖速度，瞬间统一了代码规范工具的半壁江山，成为现代 Python 项目的标配。
Pydantic V2：底层核心 pydantic-core 全面 Rust 化，数据验证性能提升 5-50 倍，直接撑起了 FastAPI 等现代异步框架在高并发场景下的性能底座。
Polars：这个原生 Rust 编写的 DataFrame 库，像一条凶猛的鲶鱼，凭借多线程并行和 Arrow 零拷贝架构，直接把 Pandas 按在性能摩擦地上，迫使老牌霸主不得不"壮士断腕"。
orjson / tiktoken：在 JSON 序列化与大模型 Token 化这两个看似不起眼的角落，Rust 扩展同样以数量级的优势碾压了纯 Python 实现。

Python，这个以"优雅、简单、慢"著称的解释型语言，正在疯狂地给自己安装"钢铁骨骼"。

这不是性能焦虑的被迫反击，而是生态进化的必然选择。当 AI 大模型训练的数据集突破 TB 级别，当云原生应用的并发请求达到百万级，当实时数据分析成为业务标配，纯 Python 的"大力出奇迹"已经走到了尽头。

Python 没有死，它只是换了一种活法。

在这场"换心手术"中，我们看到的不仅仅是代码的重写，更是架构范式的转移、开发哲学的重塑，以及一个古老语言在 AI 狂飙时代的自我救赎。

二、第一章：Python 的"性能焦虑"与生态危机

要理解 Pandas 为什么要"壮士断腕"，必须先回到 Python 的基因里，看看它究竟被什么束缚了手脚。

2.1 摩尔定律的失效与算力通胀

过去二十年，Python 之所以能够容忍"慢"，很大程度上是因为摩尔定律在背后兜底。

硬件性能每年翻倍，掩盖了软件效率的低下。当 CPU 主频不断提升、核心数不断增加、内存容量不断膨胀时，开发者可以肆无忌惮地编写"优雅但低效"的代码。反正，下一代的硬件会解决这一代的问题。

但 2020 年代之后，摩尔定律的脚步明显放缓。单核性能的提升遭遇物理瓶颈，内存带宽的增长也远不及数据量的爆炸。与此同时，AI 大模型的崛起带来了前所未有的算力需求。训练一个千亿参数模型，需要处理 PB 级别的文本数据；推理一个实时推荐系统，需要在毫秒级完成千万级向量的检索。

当硬件红利消失，软件效率的债务开始集中爆发。

这就是所谓的"算力通胀"：同样的任务，现在需要消耗更多的算力资源。而在云原生时代，算力直接等同于金钱。Python 的"慢"，不再只是开发者的体验问题，而是企业的真金白银。

2.2 GIL 的诅咒：单行道上的八核法拉利

Python 性能瓶颈的第一大元凶，是 GIL（Global Interpreter Lock，全局解释器锁）。

CPython 是 Python 的官方实现，也是使用最广泛的版本。为了保证内存管理的线程安全，CPython 引入了 GIL。它就像一把唯一的钥匙，同一时刻只能有一个线程持有这把钥匙并执行 Python 字节码。

这意味着什么？

意味着即使你拥有 64 核的服务器，运行纯 Python 代码时，也只有一个核心在真正干活，其余 63 个核心在围观。这就像让一辆八核法拉利在单行道上跑，引擎再强也发挥不出来。

在 I/O 密集型任务（如网络请求、文件读写）中，GIL 的影响较小，因为线程在等待 I/O 时会释放锁。但在 CPU 密集型任务（如数值计算、图像处理、数据清洗）中，GIL 就是致命的性能杀手。

多年来，Python 社区尝试过各种方案来绕过 GIL：

多进程（multiprocessing）：通过进程间通信（IPC）实现并行，但进程创建和通信的开销巨大，且无法共享内存。
C 扩展：在 C 代码中手动释放 GIL，但开发门槛极高，且容易引发内存泄漏和段错误。
JIT 编译器（如 PyPy）：通过即时编译提升性能，但与 C 扩展的兼容性差，生态割裂。

这些方案都未能从根本上解决问题。直到 Rust 的出现，才提供了一条"曲线救国"的优雅路径。

2.3 内存碎片化与解释器开销

除了 GIL，Python 的内存模型也是性能的重灾区。

Python 是动态类型语言，所有变量都是 PyObject 的指针。每次创建变量、调用函数、访问属性，都需要进行动态类型检查、引用计数更新和内存分配。在紧密循环（Tight Loop）中，这些开销被无限放大。

更严重的是内存碎片化。Python 的对象分配器（pymalloc）虽然对小对象进行了优化，但在处理大规模数据时，频繁的分配和释放会导致内存碎片化，降低缓存命中率，最终引发 MemoryError。

相比之下，Rust 提供了零成本抽象和编译期内存安全。Rust 代码在编译期就能确定内存布局，避免运行时的动态检查；其所有权模型杜绝了数据竞争和内存泄漏；其迭代器（Iterator）机制支持惰性求值和 SIMD 向量化，极大地提升了缓存利用率和计算吞吐量。

2.4 Polars 的"鲶鱼效应"：降维打击与护城河撕裂

当 Python 的痛点日益凸显时，Polars 的横空出世，成为了压垮骆驼的最后一根稻草。

Polars 从第一天起就是为并行计算而生的。它不依赖 NumPy，而是直接基于 Apache Arrow 构建内存模型。Arrow 是一种列式内存格式，它允许不同的数据处理库之间实现**零拷贝（Zero-Copy）**数据交换。

Polars 的成功，证明了 Python 用户的痛点不是"不会写代码"，而是"工具太慢"。它用 Rust 的多线程引擎和 Arrow 的列式存储，直接撕开了 Pandas 的护城河。

面对 Polars 的攻城略地，Pandas 只有两条路：要么固守纯 Python/Cython 的旧阵地，眼睁睁看着用户流失；要么拥抱 Rust，完成底层引擎的彻底置换。

Pandas 3.0 选择了后者。这是一场背水一战，也是 Python 生态进化的必然。

三、第二章：Rust 化浪潮的核心案例拆解

Rust 化不是简单的"翻译代码"，而是架构级的重构。我们来看四个最具代表性的案例，看看 Rust 是如何在不同领域"接管"Python 的。

3.1 数据处理：Pandas 3.0 的"芯"脏移植与 Arrow 统一

Pandas 3.0 的 Rust 化，核心在于计算后端的置换与内存格式的统一。

Before：Pandas 的核心逻辑（如 groupby, merge, rolling）由 Python 和 Cython 混合编写。Cython 虽然比纯 Python 快，但开发效率低，类型系统弱，且难以利用现代 CPU 的 SIMD（单指令多数据）指令集。此外，Pandas 内部使用 NumPy 数组存储数据，不同库之间的数据交换需要序列化和反序列化，产生大量拷贝开销。

After：Pandas 引入了基于 Rust 的计算引擎。Rust 代码通过 PyO3 编译为 Python 扩展模块。在运行时，Python 层负责 API 交互和元数据管理，而繁重的数值计算全部下沉到 Rust 层执行。

关键收益：

SIMD 向量化：Rust 编译器能自动利用 AVX2/AVX-512 指令集，一次处理多个数据点。例如，在浮点数加法中，SIMD 可以一次性处理 8 个 double 类型数据，吞吐量提升数倍。
多线程并行：Rust 模块可以释放 GIL，真正利用多核 CPU。Pandas 3.0 的 groupby 操作现在可以自动将数据分片，分配到多个线程并行计算，最后合并结果。
Arrow 统一：Pandas 3.0 全面拥抱 Apache Arrow 作为内部内存格式。这意味着 Pandas 与 Polars、DuckDB、PyArrow 之间可以实现零拷贝数据交换，极大地降低了内存占用和 CPU 开销。
内存安全：Rust 的所有权机制在编译期杜绝了数据竞争和内存泄漏，这在处理 TB 级数据时至关重要。

3.2 代码规范：Ruff 的闪电战与 AST 高效遍历

如果说 Pandas 是"老树发新芽"，那 Ruff 就是"新物种碾压"。

Ruff 用 Rust 重写了 Flake8、pycodestyle、pyflakes、isort、Black 等十几个工具的功能。它的核心逻辑是AST（抽象语法树）的高效遍历。

架构优势：

零成本抽象：Rust 的零成本抽象让 Ruff 在解析百万行代码时，内存占用极低。它不需要像 Python 工具那样为每个节点创建对象，而是直接在内存中操作 AST 结构。
缓存机制：Ruff 内置了智能缓存，只重新检查变更的文件。结合 Rust 的高效哈希算法，缓存命中和更新的开销微乎其微。
规则统一：Ruff 不仅快，而且统一了碎片化的工具链。它内置了 700+ 条规则，覆盖了 Flake8 及其主流插件的功能。开发者不再需要配置十几个工具，一个 ruff.toml 文件即可搞定。

结果：曾经需要几分钟的 Lint 检查，现在只需几十毫秒。Ruff 不仅快，而且成为了 Python 工程化的新标准。GitHub 上无数项目已将 Ruff 集成到 CI/CD 流水线，代码审查效率呈指数级提升。

3.3 数据验证：Pydantic V2 的基石与 FastAPI 的并发突围

Pydantic 是 FastAPI 的核心依赖，负责请求数据的解析和验证。

在 V1 时代，Pydantic 是纯 Python 实现。随着 FastAPI 的爆发，Pydantic 成为了高并发服务的性能瓶颈。特别是在处理复杂嵌套模型和大量数据时，验证延迟高达数百毫秒，严重拖累了 API 的吞吐量。

V2 版本中，作者 Samuel Colvin 做出了一个艰难的决定：用 Rust 重写核心验证引擎 pydantic-core。

性能飞跃：

验证速度：基准测试显示，V2 的验证速度是 V1 的 5-50 倍。对于简单的模型，验证时间从微秒级降至纳秒级；对于复杂的嵌套模型，速度提升更为显著。
内存占用：Rust 核心避免了 Python 对象的频繁创建和销毁，内存占用大幅下降。
无缝升级：对于开发者来说，API 几乎完全兼容。只需 pip install pydantic==2.0，就能免费获得性能提升。

Pydantic V2 的成功证明了一个道理：底层的优化，对上层应用应该是透明的。 FastAPI 开发者无需修改任何代码，就能享受到 Rust 带来的性能红利。这也是 Rust 化浪潮能够迅速普及的关键原因。

3.4 序列化与 Token 化：orjson 与 tiktoken 的隐秘角落

在数据序列化和大模型 Token 化这两个看似不起眼的角落，Rust 同样以数量级的优势碾压了纯 Python 实现。

orjson：

背景：Python 标准库 json 模块在解析和序列化大型 JSON 时性能较差，特别是处理嵌套对象和特殊类型（如 datetime、UUID）时。
Rust 化：orjson 用 Rust 重写了 JSON 解析器，支持 SIMD 加速和零拷贝序列化。其速度比标准库快 2-10 倍，且支持更丰富的类型。
影响：orjson 已成为 FastAPI、Starlette 等现代框架的推荐 JSON 引擎，极大地提升了 API 的响应速度。

tiktoken：

背景：大语言模型（LLM）的输入和输出都需要经过 Token 化。Python 的 tiktoken 库负责将文本转换为 Token ID 序列。
Rust 化：tiktoken 的核心逻辑用 Rust 编写，通过高效的哈希表和字节码匹配算法，实现了极快的 Token 化速度。
影响：在构建 RAG（检索增强生成）系统或处理长上下文时，tiktoken 的性能直接决定了数据预处理的效率。Rust 的引入，让 Token 化不再是瓶颈。

四、第三章：底层逻辑与技术底座

Python 的 Rust 化浪潮，离不开一个幕后英雄：PyO3。它是连接两个世界的桥梁，也是这场"换心手术"的手术刀。

4.1 PyO3：连接两个世界的桥梁与生命周期管理

PyO3 是 Rust 的 Python 绑定库。它允许 Rust 代码像原生 Python 模块一样被导入和调用。

use pyo3::prelude::*;  
  
#[pyfunction]  
fn sum_as_string(a: usize, b: usize) -> PyResult<String> {  
    Ok((a + b).to_string())  
}  
  
#[pymodule]  
fn my_rust_module(m: &Bound<'_, PyModule>) -> PyResult<()> {  
    m.add_function(wrap_pyfunction!(sum_as_string, m)?)?;  
    Ok(())  
}

通过 PyO3，Rust 函数可以：

接收 Python 对象：自动将 PyObject 转换为 Rust 类型（如 &str, i64, Vec<f64>）。
抛出 Python 异常：使用 PyResult<T> 返回结果，错误会自动转换为 Python 异常。
释放 GIL：在 Rust 代码中显式释放 GIL，执行多线程计算。

生命周期管理是 PyO3 的核心难点。Python 使用引用计数（Reference Counting）管理内存，而 Rust 使用所有权（Ownership）和生命周期（Lifetime）。PyO3 通过 GILGuard 和 Py<T> 智能指针，桥接了两种内存模型。

当 Rust 代码持有 Python 对象时，PyO3 会自动增加引用计数；当 Rust 变量超出作用域时，引用计数自动减少。这种机制既保证了内存安全，又避免了手动管理引用计数的繁琐。

4.2 架构范式转移：Python 做"启动器"，Rust 做"引擎"

Python 的生态正在形成一种新的架构范式：

Python 层（胶水）：负责业务逻辑、API 设计、元编程、动态类型检查。Python 的优势在于开发效率和生态丰富度。
Rust 层（骨骼）：负责数值计算、内存管理、并发控制、I/O 密集型操作。Rust 的优势在于运行效率和内存安全。

这种分工，完美契合了"二八定律"：20% 的核心代码消耗 80% 的运行时间。将这部分代码用 Rust 重写，就能获得 80% 的性能收益，同时保留 Python 的开发体验。

开发者可以用 Python 快速原型设计，验证业务逻辑；当性能成为瓶颈时，再将热点函数下沉到 Rust 层。这种"渐进式优化"策略，既保证了开发速度，又兼顾了运行效率。

4.3 GIL 的突围：`allow_threads` 与多线程并行

Python 3.13 引入了实验性的 Free-threading（无 GIL 模式），但这需要漫长的生态适配。而 Rust 模块提供了一种"曲线救国"的方案：

在 Rust 代码中，可以显式释放 GIL（Python::allow_threads），从而在 Rust 线程池中并行执行任务。 这意味着，即使 Python 解释器有 GIL，Rust 扩展依然可以实现真正的多线程并行。

这种机制在 Pandas 3.0 和 Polars 中被广泛应用。当执行大规模数据计算时，Rust 代码会暂时"交出"GIL，让 Python 主线程继续处理其他任务（如 UI 响应或网络请求），而 Rust 线程池则在后台全速运转。计算完成后，再重新获取 GIL 并返回结果。

这是一种优雅的妥协：既不破坏 Python 的兼容性，又实现了多核并行。

五、第四章：历史演进——从 C Extension 到 Rust 的长征

Python 的"换心"并非一蹴而就。回顾历史，从 C Extension 到 Cython，再到如今的 Rust，这是一场跨越三十年的性能长征。

5.1 C Extension 时代：蛮荒与危险

Python 诞生之初，就提供了 C API，允许开发者用 C 语言编写扩展模块。这是 Python 性能优化的第一把钥匙。

优势：极致性能，直接调用底层系统 API。
劣势：开发门槛极高，需要精通 C 语言和 Python 内部机制；内存管理全靠手动，极易引发段错误（Segmentation Fault）和内存泄漏。

NumPy、SciPy 等早期科学计算库都是 C Extension 的产物。它们奠定了 Python 在数据科学领域的地位，但也留下了难以维护的历史包袱。

5.2 Cython 时代：妥协与过渡

为了降低 C Extension 的开发门槛，Cython 应运而生。它允许开发者编写类似 Python 的代码，然后将其编译为 C 扩展。

优势：语法接近 Python，学习曲线平缓；支持静态类型声明，显著提升性能。
劣势：类型系统依然薄弱，难以处理复杂的泛型和并发；编译速度慢，且生成的 C 代码难以阅读和调试。

Pandas 的旧版本大量使用了 Cython。虽然比纯 Python 快，但在面对现代多核 CPU 和 SIMD 指令集时，Cython 显得力不从心。

5.3 Rust 时代：现代与优雅

Rust 的出现，为 Python 扩展开发带来了革命性的变化。

优势：
- 内存安全：编译期杜绝数据竞争和空指针。
- 零成本抽象：高级语言特性（如迭代器、闭包）在编译后等同于手写汇编。
- 现代工具链：Cargo 包管理器、Clippy 静态分析、Rustfmt 代码格式化，极大地提升了开发体验。
Maturin 的崛起：Maturin 是一个专门用于构建和发布 Rust-Python 扩展的工具。它简化了编译流程，支持自动构建跨平台 Wheel，让开发者只需关注 Rust 代码本身。

从 C 到 Cython 再到 Rust，是一条从"蛮荒"走向"现代"，从"危险"走向"安全"，从"妥协"走向"优雅"的进化之路。

六、第五章：工程隐忧与反证——Rust 化是万能药吗？

尽管 Rust 化带来了显著的性能提升，但它并非银弹。我们必须清醒地看到其中的隐忧。

6.1 编译复杂度与构建系统

引入 Rust 意味着项目需要同时管理 pip 和 Cargo。

构建依赖：用户安装包时，可能需要 Rust 编译器（rustc）和 Cargo。虽然有 maturin 这样的工具可以预编译 Wheel，但跨平台分发（如 ARM64, musl libc）依然充满挑战。
CI/CD 负担：项目需要配置 Rust 的 CI 流程，增加了维护成本。

6.2 跨平台与分发体积

Wheel 体积：Rust 编译出的二进制文件通常比纯 Python 代码大得多。一个包含 Rust 扩展的 Wheel 可能达到几十 MB，而纯 Python 包可能只有几百 KB。
交叉编译：为不同平台（Windows/macOS/Linux, x86/ARM）预编译 Wheel 需要复杂的 CI 配置。

6.3 人才门槛

既精通 Python 又熟悉 Rust 的开发者依然稀缺。

学习曲线：Rust 的所有权模型和生命周期概念对 Python 开发者来说是巨大的挑战。
调试难度：当 Bug 发生在 Rust 层时，Python 开发者可能缺乏调试工具和经验。

6.4 过度优化陷阱

并非所有场景都需要 Rust。
对于简单的脚本、一次性数据分析或小型 Web 服务，纯 Python 完全够用。引入 Rust 可能会带来"杀鸡用牛刀"的复杂度，反而降低开发效率。

工程的核心是权衡（Trade-off），而不是盲目追求性能。

七、第六章：行业影响与未来展望

Rust 化浪潮正在重塑 Python 生态的利益格局，并对整个数字基础设施产生深远影响。

7.1 受益者：开发者、企业与 AI 团队

数据科学家/工程师：处理更大规模的数据集，不再受限于单机内存和单核性能。Pandas 3.0 和 Polars 让"单机大数据"成为可能。
后端开发者：Ruff 和 Pydantic V2 大幅缩短了开发循环时间。CI/CD 流水线从分钟级降到秒级，提升了交付效率。
AI/机器学习团队：大模型训练前的数据清洗（ETL）效率倍增。更快的工具链意味着更快的实验迭代。
企业：算力成本下降。同样的云实例，现在能处理更多请求。

7.2 掉队者：纯 Python 库与 Cython 遗老

纯 Python 实现的老旧库：如果拒绝引入 Rust 扩展，性能差距将导致用户流失。
依赖 Cython 的项目：Cython 的开发体验远不如 Rust（缺乏包管理、类型系统弱）。长期来看，Rust 将取代 Cython 成为 Python 扩展的首选语言。
不愿升级的开发者：Rust 化带来了构建复杂性的提升。如果团队缺乏 Rust 知识，维护成本将上升。

7.3 未来展望：Python + Rust 成为标准配置

Python + Rust，正在成为未来十年数据与 AI 基础设施的标准配置。

在 AI 狂飙的时代，底层工具的极致优化，是我们对抗"算力通胀"的最后防线。

对于开发者而言：拥抱 Rust 化不是放弃 Python，而是让 Python 变得更强。
对于企业而言：投资 Rust 化不是增加成本，而是构建长期的技术护城河。
对于生态而言：Python 将作为"胶水"和"启动器"，连接起 Rust、C++、CUDA 等各种高性能引擎，形成一个异构计算的超级生态。

八、结语：Python 的"第二曲线"

回顾 Python 的发展史，它曾多次面临"被取代"的危机。

2010 年代，人们说它太慢，会被 Go 取代。
2020 年代，人们说它类型不安全，会被 TypeScript 取代。
今天，人们说它并发差，会被 Rust 取代。

但 Python 依然屹立不倒，甚至更加繁荣。为什么？

因为 Python 找到了自己的"第二曲线"：成为 Rust 的"启动器"和"胶水"。

Rust 不是来取代 Python 的，而是来拯救 Python 的。
它补足了 Python 在性能和并发上的短板，让 Python 能够继续胜任 AI、大数据、云原生等前沿领域的"第一语言"。

在这场"换心手术"中，我们看到的不仅是技术的更迭，更是生态的韧性。
Python 用它的包容性，接纳了 Rust 的锋利；Rust 用它的严谨，守护了 Python 的优雅。

这，就是数字文明的进化之道。

雨轩于听雨轩 · 2026-04-15 18:45 完稿 🌧️🏠

Python 的"换心"手术：Rust 化浪潮与生态重构

Python 的"换心"手术：Rust 化浪潮与生态重构

一、引子：当"胶水语言"长出"钢铁骨骼"

二、第一章：Python 的"性能焦虑"与生态危机

2.1 摩尔定律的失效与算力通胀

2.2 GIL 的诅咒：单行道上的八核法拉利

2.3 内存碎片化与解释器开销

2.4 Polars 的"鲶鱼效应"：降维打击与护城河撕裂

三、第二章：Rust 化浪潮的核心案例拆解

3.1 数据处理：Pandas 3.0 的"芯"脏移植与 Arrow 统一

3.2 代码规范：Ruff 的闪电战与 AST 高效遍历

3.3 数据验证：Pydantic V2 的基石与 FastAPI 的并发突围

3.4 序列化与 Token 化：orjson 与 tiktoken 的隐秘角落

四、第三章：底层逻辑与技术底座

4.1 PyO3：连接两个世界的桥梁与生命周期管理

4.2 架构范式转移：Python 做"启动器"，Rust 做"引擎"

4.3 GIL 的突围：allow_threads 与多线程并行

五、第四章：历史演进——从 C Extension 到 Rust 的长征

5.1 C Extension 时代：蛮荒与危险

5.2 Cython 时代：妥协与过渡

5.3 Rust 时代：现代与优雅

六、第五章：工程隐忧与反证——Rust 化是万能药吗？

6.1 编译复杂度与构建系统

6.2 跨平台与分发体积

6.3 人才门槛

6.4 过度优化陷阱

七、第六章：行业影响与未来展望

7.1 受益者：开发者、企业与 AI 团队

7.2 掉队者：纯 Python 库与 Cython 遗老

7.3 未来展望：Python + Rust 成为标准配置

八、结语：Python 的"第二曲线"

4.3 GIL 的突围：`allow_threads` 与多线程并行