首页/资讯中心/详情

C++并发编程调试实战：六步排查法解决数据竞争与死锁

C++并发编程调试实战：六步排查法解决数据竞争与死锁
📅 发布时间：2026/7/24 7:00:34

1. 项目概述：当并发遇上C++，一场无声的崩溃

如果你写过C++并发程序，并且经历过那种“程序在测试时跑得好好的，一到线上就间歇性崩溃，日志里除了一个Segmentation fault啥也没有”的绝望，那咱们就是同道中人了。C++并发编程，尤其是涉及到多线程共享数据、锁、条件变量这些玩意儿时，它带来的性能红利有多大，调试的噩梦就有多深。问题往往不是稳定复现的，它像幽灵一样，在特定的时序、特定的负载下才悄然现身，留下一地狼藉和一个抓狂的你。

这个项目，或者说这篇分享，就是聚焦于这个痛点。它不是教你std::thread、std::mutex的语法（这些是基础），而是当你已经用上了这些工具，程序却出现难以捉摸的崩溃、数据错乱、死锁时，你该怎么办。我将结合自己多年在后台服务、高频交易等对稳定性要求极高的场景中踩过的坑，总结出一套从“崩溃”到“可控”的六步实战排查法。这套方法的核心思想是系统性和可操作性，它不是零散的经验，而是一个从现象到根因的完整调查流程。

为什么是六步？因为调试并发错误就像破案，你不能一上来就盯着最复杂的锁交互看。你需要先划定范围，排除干扰，收集证据，然后才是深入核心的现场勘查。盲目行动只会让“犯罪现场”被破坏得更彻底。接下来，我们就一步步拆解这套方法，我会用大量真实的代码片段和场景来还原整个调试过程。

2. 核心思路：从混沌到有序的六步排查框架

面对一个并发导致的崩溃，新手容易犯两个错误：一是漫无目的地加日志，把程序输出搞得像瀑布一样，结果关键信息被淹没；二是一头扎进代码里，试图在脑海中模拟所有可能的线程交织，这在大规模代码中几乎是不可能的。我的六步法就是为了对抗这种低效和盲目。

第一步：稳定复现与最小化现场。这是所有调试的基石，对于并发问题尤其关键。你的目标不是让问题100%稳定出现（那有时很难），而是创造一个能让问题较高概率出现的“压力环境”。同时，要尽全力将问题复现的代码范围缩小。一个动辄数十万行的服务出了问题，你不可能全盘检查。

第二步：武器准备：升级你的调试工具链。工欲善其事，必先利其器。printf大法在并发调试中基本是无效的，因为输出本身会严重干扰线程时序。你需要依赖更强大的工具，比如线程消毒器（ThreadSanitizer）、地址消毒器（AddressSanitizer）以及调试器对多线程的深度支持。

第三步：内存与数据竞争：第一嫌疑犯。C++并发错误的大头，无非是两类：非法内存访问（空指针、野指针、越界）和数据竞争（Data Race）。这一步，我们要利用第二步准备好的工具，进行第一轮快速扫描和定位。

第四步：锁与死锁：梳理资源依赖图。如果初步排除了内存和数据竞争，那么问题很可能出在同步原语的使用上。死锁、锁顺序反转、锁粒度不当导致的性能瓶颈乃至逻辑错误，是下一步的调查重点。我们需要画出资源的持有和等待关系图。

第五步：原子操作与内存序：深入硬件视角。这是高级话题，但也是现代C++高性能并发无法回避的。错误地使用std::atomic或者选错了内存序，会导致一些违反直觉的、极难复现的问题。这一步，我们要审视所有自以为“无锁”的代码。

第六步：设计复盘与防御性编程。找到并修复了直接原因，工作只完成了一半。更重要的是复盘：为什么这样的代码会被写出来？如何从设计上避免？我们需要建立一些编码规范和防御性编程习惯，让并发Bug更难滋生。

这六步是一个递进的过程，也常常需要循环。你可能在第三步就解决了问题，也可能需要走完第六步才发现根源在第一步的复现环境没构造好。下面，我们进入每一步的实战细节。

3. 第一步：稳定复现与最小化现场

并发Bug最烦人的特性就是它的不确定性。它可能跑一万次才出现一次，也可能在开发者的机器上从不出现，只在生产环境的某个特定容器里发作。所以，我们的首要任务是提高它的“出镜率”。

3.1 构造压力测试环境

单纯地重复运行程序是没用的。你需要主动制造“压力”和“竞争”。

  1. 增加线程数：如果业务逻辑允许，把线程池的大小调大，远大于CPU核心数。这会让操作系统的线程调度器更频繁地进行上下文切换，放大潜在的竞争窗口。
  2. 循环与睡眠交织：在怀疑有问题的代码段周围，让线程执行大量循环，并在循环中随机插入std::this_thread::sleep_for。注意，睡眠时间要短且随机，比如1-100微秒。这能模拟出线程执行速度的差异，让一些在“匀速”情况下隐藏的时序问题暴露出来。
    // 模拟不稳定的线程执行速度 std::random_device rd; std::mt19937 gen(rd()); std::uniform_int_distribution<> dis(1, 100); for (int i = 0; i < 10000; ++i) { // 你的核心业务逻辑 do_something_concurrent(); // 随机睡眠，打乱时序 std::this_thread::sleep_for(std::chrono::microseconds(dis(gen))); }
  3. 使用压力测试工具：对于网络服务，使用wrk,ab,jmeter等工具进行高并发请求轰炸。对于计算任务，可以尝试反复启停大量线程来执行同一段任务。

实操心得：不要只在Debug模式下测试。有些问题（特别是与优化相关的）只在Release（-O2或-O3）模式下出现。务必在开启编译器优化的情况下进行压力测试。

3.2 代码最小化：剥离无关部分

一旦问题能够以较高概率复现，下一步就是“剪枝”。创建一个新的、最小的测试程序。

  1. 复制粘贴嫌疑模块：将与崩溃最可能相关的类、函数复制到一个新的.cpp文件里。
  2. 剥离依赖：移除这个模块对外部网络、数据库、复杂配置文件等的依赖。用内存模拟数据，用简单的函数调用替代RPC。
  3. 编写驱动代码：编写一个最简单的main函数，创建少数几个线程，执行核心逻辑，并循环运行成千上万次。

这个最小化程序有巨大好处：编译运行飞快，方便你快速迭代测试假设；消除了无关干扰，让问题本质更清晰；也便于你分享给同事或社区求助。

踩坑记录：我曾经遇到一个死锁，发生在某个全局管理器的初始化阶段，但现象却是服务运行几小时后才卡死。最小化过程异常痛苦。最后发现，是另一个看似无关的模块在启动时以某种特定顺序调用了该管理器的某个方法，形成了隐藏的初始化依赖链。最小化迫使我把所有交互都摆到明面上，才最终定位。

4. 第二步：武器准备：不可或缺的现代化工具

准备好最小化复现场景后，别急着看代码。先用工具做一次全身扫描。

4.1 编译时插桩：Sanitizers 是你的第一道防线

GCC/Clang提供的Sanitizer系列工具是C/C++程序员的福音。它们通过在编译时插入检测代码来运行时发现问题。

  1. AddressSanitizer (ASan)：检测内存错误，如堆栈缓冲区溢出、使用释放后内存、双重释放等。很多诡异的崩溃都是内存问题。

    # 编译命令 g++ -fsanitize=address -fno-omit-frame-pointer -g your_program.cpp -o your_program # 运行 ./your_program

    如果程序因内存错误崩溃，ASan会打印出非常详细的报告，包括出错位置、内存分配和释放的堆栈。

  2. ThreadSanitizer (TSan)：检测数据竞争（Data Race）的利器。数据竞争是指多个线程在没有正确同步的情况下访问同一内存位置，并且至少有一个是写操作。它是并发Bug的主要来源之一，且未必导致立即崩溃，而是先造成数据腐蚀。

    # 编译命令 g++ -fsanitize=thread -fno-omit-frame-pointer -g your_program.cpp -o your_program # 运行 TSAN_OPTIONS="second_deadlock_stack=1" ./your_program

    TSan会在检测到数据竞争时报告，并给出发生竞争的两个线程的调用堆栈。

重要提示：ASan和TSan通常不能同时使用（-fsanitize=address,thread）。建议先单独用ASan查内存问题，再用TSan查数据竞争。另外，开启Sanitizers后程序运行会慢2-10倍，内存占用也会增加，但这在调试阶段是完全值得的。

4.2 调试器的多线程视角

GDB（或LLDB）不仅是设断点、看变量的工具。用好它的多线程命令，能让你看清瞬间的状态。

  1. 查看所有线程：info threads列出所有线程及其当前状态（运行、断点、信号等）。
  2. 切换线程上下文：thread <线程ID>切换到指定线程，然后你可以用bt查看该线程的堆栈，用print查看该线程上下文中的变量。
  3. 给所有线程下命令：thread apply all bt可以一次性打印所有线程的堆栈。这在分析死锁时极其有用，你能一眼看到哪些线程在等哪些锁。
  4. 条件断点：对于只在特定线程或特定条件下才触发的问题，可以设置条件断点。
    # 只在thread_id为2的线程命中此断点时停止 break my_function if $_thread == 2 # 当全局变量counter大于100时停止 break my_function if counter > 100

4.3 可视化与日志增强

虽然强调不要乱加日志，但结构化、线程标识明确的日志在后期分析中至关重要。确保你的每一条日志都包含线程ID（如std::this_thread::get_id()）和时间戳。这能帮你事后重建事件发生的时序。

对于复杂的锁依赖，可以尝试画图。简单的文本图也行，例如：

线程A: 持有锁L1 -> 申请锁L2 线程B: 持有锁L2 -> 申请锁L1

这就是一个典型的死锁。在代码审查时，对锁的获取顺序进行约定，是避免这类问题的有效方法。

5. 第三步：内存与数据竞争：首要排查对象

有了工具和复现场景，我们可以开始正式“破案”了。首先从最常见的两类问题入手。

5.1 使用ASan排查内存错误

运行用ASan编译的程序，如果崩溃，仔细阅读输出。ASan的报告通常包含：

  • 错误类型：比如heap-use-after-free,stack-buffer-overflow。
  • 出错地址和堆栈：错误发生时的调用堆栈。
  • 分配和释放堆栈：如果是use-after-free，它还会告诉你这块内存是在哪里分配，又是在哪里释放的。这几乎直接指明了问题所在。

案例分析：一个经典的“悬空指针”问题。

std::vector<int>* vec_ptr = new std::vector<int>(); // 线程A std::thread t1([&]{ vec_ptr->push_back(1); // 可能崩溃点 }); // 线程B std::thread t2([&]{ delete vec_ptr; // 可能删除点 vec_ptr = nullptr; }); t1.join(); t2.join();

ASan会清晰地报告，在push_back的地址发生了heap-use-after-free，并指出内存是在t2的lambda函数中被delete的。解决方案是确保对象的生命周期管理是线程安全的，例如使用std::shared_ptr配合合适的同步，或者让对象不被并发析构。

5.2 使用TSan排查数据竞争

运行用TSan编译的程序。TSan会在检测到数据竞争时打印报告，即使程序没有崩溃。报告会包含：

  • 竞争涉及的两个（或多个）线程的堆栈。
  • 发生竞争的内存地址和大小。
  • 读/写操作的信息。

案例分析：一个未同步的计数器。

int global_counter = 0; void increment() { for (int i = 0; i < 100000; ++i) { ++global_counter; // 数据竞争！ } } int main() { std::thread t1(increment); std::thread t2(increment); t1.join(); t2.join(); std::cout << global_counter << std::endl; // 结果不确定，且小于200000 }

TSan会明确报告在global_counter上存在数据竞争。修复方法是使用std::atomic<int>或者用std::mutex保护。

深度解析：为什么++global_counter不是原子的？即使在x86上，这条语句也可能被编译成LOAD、ADD、STORE三条指令。线程A可能在LOAD之后被切换，线程B完成了完整的LOAD-ADD-STORE，然后线程A恢复，它的ADD是基于旧的寄存器值，STORE会覆盖线程B的写入，导致一次增加丢失。

5.3 锁的误用与数据竞争

有时，你明明加了锁，TSan还是报告竞争。这通常是因为锁的范围不对。

std::vector<int> shared_vec; std::mutex vec_mutex; void unsafe_add(int val) { // 错误：锁只保护了find，没保护整个“检查-插入”操作 std::lock_guard<std::mutex> lock(vec_mutex); auto it = std::find(shared_vec.begin(), shared_vec.end(), val); // 锁在这里已经释放了（lock_guard离开作用域） if (it == shared_vec.end()) { // 这里没有锁！另一个线程可能同时执行插入，导致重复插入或迭代器失效。 shared_vec.push_back(val); } }

正确的做法是将整个“检查-插入”逻辑用同一个锁保护起来，或者使用支持并发访问的容器（如Intel TBB的concurrent_vector，但要注意其语义与std::vector不同）。

6. 第四步：锁与死锁：梳理依赖关系

如果内存和数据竞争都排除了，那么同步逻辑本身可能就是问题所在。

6.1 死锁检测与预防

死锁的四个必要条件：互斥、持有并等待、不可剥夺、循环等待。预防死锁主要从破坏后三个条件入手。

  1. 锁顺序一致性：这是最实用、最有效的预防策略。为系统中所有的锁定义一个全局的获取顺序（例如，按内存地址排序，或按逻辑层级排序），并强制所有线程都按这个顺序获取锁。

    // 假设有锁 L1, L2, L3 // 定义顺序：必须先锁L1，才能锁L2；必须先锁L2，才能锁L3。 std::mutex L1, L2, L3; void thread_func_A() { std::lock_guard<std::mutex> lock1(L1); std::lock_guard<std::mutex> lock2(L2); // 顺序正确 // ... } void thread_func_B() { std::lock_guard<std::mutex> lock2(L2); // 错误！在持有L2的情况下试图锁L1，违反了顺序。可能引发死锁。 std::lock_guard<std::mutex> lock1(L1); // ... }

    可以使用std::lock或std::scoped_lock（C++17）来一次性锁定多个互斥量，它会使用死锁避免算法（如Dijkstra算法）来安全地获取锁，但这也要求你在同一作用域需要所有锁。

    std::mutex L1, L2; void safe_func() { std::scoped_lock lock(L1, L2); // 一次性按未指定顺序安全获取L1和L2 // ... }

  2. 使用层次锁（Hierarchical Mutex）：这是一种将锁顺序编码到类型中的设计模式。每个锁有一个“层级值”，线程在持有某个层级的锁时，只能获取层级更低的锁。这能在编译期或运行期检查锁顺序。

  3. 避免嵌套锁：如果设计上允许，尽量缩短锁的持有时间，并避免在一个锁的保护区内去调用另一个可能申请锁的函数。这需要仔细设计接口和模块边界。

6.2 锁粒度问题

锁的粒度太粗（一个锁保护大量数据）会严重限制并发度，导致性能瓶颈。粒度太细（大量细粒度锁）则增加了死锁风险和锁开销。

案例分析：细粒度锁的竞争。你为了高性能，为哈希表的每个桶都配了一把锁。但在高并发下，如果大量操作恰好都落在少数几个桶里，这些锁的竞争会非常激烈，性能可能反而不如一把大锁。这时可能需要结合“锁分段”和“无锁编程”等技术。

调试时，可以使用性能剖析工具（如perf,Intel VTune）查看锁的争用情况（contention）。如果某个锁的等待时间占总时间的比例很高，它就是热点，需要优化。

6.3 条件变量的陷阱

std::condition_variable使用不当会导致丢失唤醒（lost wakeup）或虚假唤醒（spurious wakeup）。

经典的正确模式：

std::mutex mtx; std::condition_variable cv; bool data_ready = false; void producer() { { std::lock_guard<std::mutex> lock(mtx); // 生产数据 data_ready = true; } cv.notify_one(); // 通知时最好不持有锁，以减少上下文切换开销 } void consumer() { std::unique_lock<std::mutex> lock(mtx); // 必须使用循环，防止虚假唤醒 while (!data_ready) { cv.wait(lock); // wait会原子地释放锁并进入等待，被唤醒后重新获取锁 } // 消费数据 data_ready = false; }

关键点：

  • 条件判断（data_ready）必须受互斥量保护。
  • 判断条件必须使用while循环，不能是if。
  • notify调用时，不持有锁通常性能更好（但并非绝对，需根据场景判断）。

7. 第五步：原子操作与内存序：理解硬件行为

当你使用了std::atomic，程序依然行为诡异时，很可能问题出在内存序上。

7.1 原子操作不是万能的

std::atomic保证了针对该变量的单个读、写或读-修改-写操作是原子的、无数据竞争的。但它不保证操作之间的顺序与其他线程看到的顺序一致。

std::atomic<bool> x{false}, y{false}; int data = 0; void thread1() { data = 42; // 操作A x.store(true, std::memory_order_relaxed); // 操作B } void thread2() { while (!y.load(std::memory_order_relaxed)) { // 操作C std::this_thread::yield(); } if (x.load(std::memory_order_relaxed)) { // 操作D assert(data == 42); // 这个断言可能会失败！ } } void thread3() { y.store(true, std::memory_order_relaxed); // 操作E }

即使线程2看到了y为真（操作E），并且随后看到了x为真（操作B），它也不能推断出data已经被写入了42（操作A）。因为std::memory_order_relaxed只保证原子变量本身操作的原子性，不提供任何顺序保证。这就是内存序的问题。

7.2 理解六种内存序

C++提供了六种内存序，从弱到强：

  • memory_order_relaxed：只保证原子性，无顺序约束。用于计数器等场景。
  • memory_order_consume：依赖携带顺序。较复杂且编译器支持不理想，通常不推荐使用。
  • memory_order_acquire：获取操作。保证该操作之后的所有读/写操作（在当前线程内）不会被重排到该操作之前。
  • memory_order_release：释放操作。保证该操作之前的所有读/写操作（在当前线程内）不会被重排到该操作之后。
  • memory_order_acq_rel：获取-释放操作，兼具两者特性，用于读-修改-写操作（如fetch_add）。
  • memory_order_seq_cst：顺序一致性。默认选项，最强保证。保证所有线程看到的原子操作顺序是一致的，且所有非原子操作和原子操作的顺序也得到保证。性能开销最大。

如何选择？

  • 默认用seq_cst：除非你证明这里有性能瓶颈，并且你完全理解其他内存序的语义。seq_cst最安全，最符合直觉。
  • 锁同步：实现锁或保护临界区时，acquire（读锁）和release（写锁）配对使用。
  • 生产者-消费者：这是release-acquire的典型场景。
    // 生产者 data = ...; // 非原子数据 atomic_flag.store(true, std::memory_order_release); // 发布 // 消费者 while (!atomic_flag.load(std::memory_order_acquire)) { // 获取 // wait } // 这里一定能看到生产者release之前的所有写入 use_data(data);
  • 计数器：用relaxed即可。

7.3 调试内存序问题

这类问题极难调试，因为可能只在某些弱内存模型架构（如ARM、PowerPC）上出现，在x86上由于TSO（总存储序）内存模型较强，可能被隐藏。

  1. 代码审查：仔细审查所有atomic操作的内存序参数。问自己：这里需要怎样的“可见性”保证？
  2. 使用模型检查工具：如CDSChecker、TLA+等，可以对并发算法进行形式化验证，但学习曲线较陡。
  3. 压力测试与交叉编译：在ARM服务器或利用QEMU等工具模拟弱内存模型环境进行长时间压力测试。

个人体会：在我处理过的一个无锁队列Bug中，问题就出在一个本该用memory_order_acq_rel的地方误用了memory_order_relaxed。在x86服务器上测试了上亿次操作都没问题，但移植到ARM架构的嵌入式设备上，运行几小时就出现数据丢失。最终是靠代码审查结合ARM架构的内存模型文档才定位的。教训是：对于无锁数据结构，不要轻易使用relaxed序，除非你有绝对的把握。

8. 第六步：设计复盘与防御性编程

找到并修复了Bug，工作只算完成了一半。更重要的是防止同类问题再次发生。

8.1 并发设计原则

  1. 尽可能避免共享数据：这是最根本的原则。使用线程本地存储（thread_local）、为每个线程分配独立的工作队列和数据块、用消息传递（如Actor模型）替代共享状态。
  2. 用高级抽象替代原始锁：优先使用std::async,std::future, 并行算法库（<algorithm>中的并行版本），或者像Intel TBB,HPX这样的并行任务库。它们封装了底层的线程和同步细节。
  3. 缩小临界区：锁只保护真正需要共享的数据，且持有时间尽可能短。计算、I/O等操作尽量移到锁外。
  4. 优先使用只读或不变数据：如果数据初始化后就不再修改，那么它可以被所有线程安全地读取，无需任何同步。

8.2 编码规范与静态检查

  1. 明确所有权与生命周期：使用智能指针（std::unique_ptr,std::shared_ptr）管理动态内存的生命周期。对于shared_ptr，注意其引用计数的增减是原子操作，但指向对象的读写不是。
  2. 使用const和constexpr：尽可能将变量声明为const，从编译器层面防止意外修改。
  3. 静态分析工具：在CI/CD流水线中集成静态分析工具，如Clang-Tidy。它可以检查出许多潜在的并发问题模式，例如：
    • -Wthread-safety（Clang）可以注解代码，进行锁的静态检查。
    • clang-tidy的-checks=concurrency-*系列检查项。
  4. 代码审查清单：在代码审查时，对涉及并发的代码，强制检查以下问题：
    • 是否有共享的可变数据？
    • 共享数据的访问是否都有适当的同步（锁或原子操作）？
    • 锁的获取顺序是否一致，是否可能死锁？
    • 是否有条件变量，使用模式是否正确（while循环）？
    • 原子操作的内存序是否恰当？

8.3 测试策略

  1. 单元测试并行化：对线程安全的类，编写多线程单元测试，让多个测试线程同时调用其方法。
  2. 压力测试常态化：将高并发压力测试作为发布前的必经环节。
  3. 使用Helgrind和DRD：这是Valgrind工具套件中的线程错误检测工具，可以作为TSan的补充，尤其在无法使用TSan的环境（如某些嵌入式平台）下。
  4. 模糊测试（Fuzzing）：对于输入接口，使用随机或半随机的输入进行高并发测试，可以暴露一些边界条件下的问题。

9. 实战案例：一个真实死锁的排查全记录

最后，我们用一个简化的真实案例，串联一下整个六步法。

问题现象：一个数据处理服务，在夜间批量处理高峰期，偶尔会完全卡死，所有线程无响应，CPU占用率为0。

第一步：稳定复现。通过增加并发任务数量，并模拟网络I/O延迟，成功在测试环境将卡死概率从“几天一次”提高到“几分钟一次”。

第二步：工具准备。由于是卡死而非崩溃，ASan/TSan可能无法直接触发。我们首先使用GDB附加到卡死的进程。

第三步：初步分析。在GDB中执行thread apply all bt，发现大量线程阻塞在pthread_cond_wait或__lll_lock_wait（锁等待）上。排除了明显的非法内存访问竞争。

第四步：锁依赖分析。从堆栈中提取出每个线程持有的锁和等待的锁。手动梳理后发现：

  • 线程A持有锁L1，正在申请锁L2。
  • 线程B持有锁L2，正在申请锁L3。
  • 线程C持有锁L3，正在申请锁L1。 形成了一个清晰的循环等待链，即死锁。

第五步：深入代码。检查L1,L2,L3对应的具体互斥量。发现它们分别保护三个不同的全局管理器：ConfigMgr,ConnectionPoolMgr,CacheMgr。问题出在它们的初始化函数里：

  • ConfigMgr::init()会调用ConnectionPoolMgr::getInstance()（获取L2）。
  • ConnectionPoolMgr::init()会调用CacheMgr::getInstance()（获取L3）。
  • CacheMgr::init()会读取配置，调用ConfigMgr::getValue()（获取L1）。 这三个init函数在服务启动时被三个不同的线程并发调用，导致了死锁。

第六步：解决方案与复盘。

  1. 紧急修复：将初始化改为单线程顺序执行，或者使用std::call_once确保每个管理器只初始化一次，且避免在初始化函数中调用其他可能未初始化的管理器。
  2. 设计复盘：根本原因是模块间存在隐藏的循环初始化依赖。违反了“单向依赖”或“层次化初始化”的原则。
  3. 防御性措施：
    • 在代码规范中明确禁止在全局/静态对象的构造函数、初始化函数中，调用其他可能未初始化的全局对象的方法。
    • 使用依赖注入模式，显式地传递依赖，而不是隐式地通过全局单例获取。
    • 引入启动阶段检查，确保初始化顺序是确定且无环的。

这个案例展示了从现象收集、工具辅助、逻辑推理到根因修复和设计改进的完整闭环。并发调试固然挑战重重，但通过系统性的方法和严谨的态度，总能将失控的代码重新纳入掌控。记住，最重要的不是记住所有技巧，而是培养一种对共享状态和同步操作保持高度警惕的思维方式。