1. 多线程编程的“暗礁”与“浅滩”：从入门到放弃的常见陷阱

干了这么多年C++，从单线程的“岁月静好”到多线程的“刀光剑影”，我最大的感受就是：多线程编程，本质上是在和不确定性作斗争。你写的代码，在单线程环境下跑得飞快，逻辑清晰，一到多线程环境，就可能变成一场随机崩溃的“俄罗斯轮盘赌”。标题里的“常见问题”，说白了，就是那些我们踩过无数次、新人还会继续踩的坑。这些问题不解决，你的程序就永远是个“薛定谔的程序”——在崩溃与不崩溃之间叠加，直到你观察到它（用户运行它）的那一刻才坍缩。

为什么这些问题如此普遍？因为多线程打破了我们对程序执行的线性认知。我们习惯了“先A后B”的顺序逻辑，但多线程世界里，A和B可能同时发生，也可能交错发生，顺序完全由操作系统调度器这个“上帝”决定。C++11标准库<thread>的引入，让创建线程变得像std::thread t(func)一样简单，但这恰恰是最大的“甜蜜陷阱”。它降低了入门门槛，却把同步、数据竞争、死锁这些复杂问题赤裸裸地抛给了开发者。很多人以为会用std::thread就是会多线程了，其实那只是万里长征第一步。真正的挑战，在于如何让这些并发的“野马”在共享数据的“草原”上安全、有序地奔跑，而不互相践踏。

这篇文章，我就结合自己这些年调试多线程Bug到头皮发麻的经历，把这些常见问题掰开揉碎了讲。目标很明确：让你不仅能写出能跑的多线程代码，更能写出跑得稳、跑得对的多线程代码。我们会从最基础的数据竞争讲起，一路深入到死锁、条件变量的误用、生命周期管理这些深水区。每个问题我都会配上最典型的代码示例，并告诉你“为什么”会出错，以及“怎么”正确地解决。适合所有正在或即将踏入C++并发编程领域的开发者，无论你是正在面试准备“八股文”，还是在实战中遇到了灵异崩溃。

2. 数据竞争：看不见的“内存混战”

数据竞争是多线程问题里最经典、最普遍，也最隐蔽的一个。它的定义很简单：两个或更多线程在没有同步的情况下，同时访问同一块内存区域，并且至少有一个访问是写操作。听起来很简单，对吧？但它的表现形式千奇百怪，从程序偶尔计算出错，到直接段错误崩溃，都有可能。

2.1 一个典型的“计数器”陷阱

我们来看一个几乎所有教程都会写，但几乎都写错了的例子：多线程累加计数器。

#include <iostream> #include <vector> #include <thread> int counter = 0; // 共享数据 void increment() { for (int i = 0; i < 100000; ++i) { ++counter; // 隐患就在这一行！ } } int main() { std::thread t1(increment); std::thread t2(increment); t1.join(); t2.join(); std::cout << "Final counter value: " << counter << std::endl; return 0; }

你的预期输出是200000，对吧？但实际运行十次，可能会得到十种不同的结果，比如198752、199345、200000（运气好时）等等。为什么？

++counter这行代码，看起来是原子操作，但在CPU层面不是。它至少包含三个步骤：

1. 从内存加载counter的当前值到CPU寄存器。
2. 在寄存器中将值加1。
3. 将新值存回counter所在的内存。

现在假设两个线程几乎同时执行++counter：

• 时刻1：counter初始为0。
• 时刻2：线程A加载值0到寄存器A。线程B加载值0到寄存器B。
• 时刻3：线程A在寄存器A中计算得到1。
• 时刻4：线程B在寄存器B中计算得到1。
• 时刻5：线程A将1写回内存。counter变为1。
• 时刻6：线程B也将1写回内存。counter还是1。

看，两次自增操作，最终只增加了1。这就是数据竞争导致的更新丢失。

注意：不要被Debug模式下的“正常”运行所欺骗。Debug版本通常关闭了编译器优化，且执行速度慢，数据竞争出现的概率可能较低。但Release版本开启优化后，线程交错执行更频繁，问题极易暴露。这也是为什么多线程Bug经常在测试阶段发现不了，上线后才爆发的原因。

2.2 解决方案：互斥锁与原子操作

解决数据竞争，核心是为共享数据的访问建立“临界区”，保证同一时刻只有一个线程能执行临界区内的代码。

方案一：使用互斥锁（std::mutex）

这是最直观的解决方案。

#include <iostream> #include <vector> #include <thread> #include <mutex> int counter = 0; std::mutex counter_mtx; // 专门保护counter的互斥锁 void increment() { for (int i = 0; i < 100000; ++i) { std::lock_guard<std::mutex> lock(counter_mtx); // 进入临界区自动加锁 ++counter; // lock_guard析构时自动解锁 } } int main() { std::thread t1(increment); std::thread t2(increment); t1.join(); t2.join(); std::cout << "Final counter value (with mutex): " << counter << std::endl; // 稳定输出200000 return 0; }

这里用了std::lock_guard，它是一种RAII（资源获取即初始化）风格的锁管理器。构造时锁定互斥量，析构时自动解锁。这避免了手动调用lock()和unlock()时，因异常或提前返回而忘记解锁导致的死锁。这是你必须养成的习惯：永远使用lock_guard或unique_lock，而不是直接操作mutex。

方案二：使用原子操作（std::atomic）

对于简单的计数器，使用互斥锁有点“杀鸡用牛刀”，因为锁的获取和释放是有开销的。更高效的方式是使用原子类型。

#include <iostream> #include <vector> #include <thread> #include <atomic> std::atomic<int> counter(0); // 声明为原子整数 void increment() { for (int i = 0; i < 100000; ++i) { ++counter; // 现在这个操作是原子的！ // 等价于 counter.fetch_add(1, std::memory_order_relaxed); } } int main() { std::thread t1(increment); std::thread t2(increment); t1.join(); t2.join(); std::cout << "Final counter value (with atomic): " << counter << std::endl; // 稳定输出200000 return 0; }

std::atomic模板通过特殊的CPU指令保证该类型上的操作（如读、写、自增、交换）是不可分割的。它的性能通常远高于互斥锁，尤其是在竞争不激烈的情况下。对于简单的标志位、计数器，应优先考虑std::atomic。

实操心得：选择锁还是原子？我有个简单的判断原则：如果共享状态只是一个简单的整数或布尔值，且操作简单（赋值、自增），用atomic。如果共享状态是一个复杂结构（如std::vector、std::map），需要多个操作组合成一个逻辑上不可分割的动作（例如先检查map中是否存在，再插入），那么必须用锁。因为原子操作只能保证单个操作的原子性，无法保证多个操作组合的原子性。

3. 死锁：线程间的“深情对望”与集体僵局

如果说数据竞争是“乱战”，那死锁就是“冷战”——所有相关线程都卡住，等待对方，程序完全停滞。死锁通常发生在两个或多个线程互相持有对方所需的资源（通常是锁），并循环等待时。

3.1 经典的“双锁死锁”场景

最经典的死锁例子就是两个线程以不同的顺序请求两把锁。

#include <iostream> #include <thread> #include <mutex> std::mutex mtx1; std::mutex mtx2; void thread_a() { std::lock_guard<std::mutex> lock1(mtx1); // 先锁mtx1 std::this_thread::sleep_for(std::chrono::milliseconds(10)); // 模拟一些操作，增加死锁概率 std::lock_guard<std::mutex> lock2(mtx2); // 再尝试锁mtx2 std::cout << "Thread A acquired both locks\n"; } void thread_b() { std::lock_guard<std::mutex> lock2(mtx2); // 先锁mtx2 std::this_thread::sleep_for(std::chrono::milliseconds(10)); std::lock_guard<std::mutex> lock1(mtx1); // 再尝试锁mtx1 std::cout << "Thread B acquired both locks\n"; } int main() { std::thread t1(thread_a); std::thread t2(thread_b); t1.join(); t2.join(); // 程序很可能卡在这里，因为t1和t2死锁了 std::cout << "Main thread finished.\n"; return 0; }

运行这个程序，很可能看不到任何输出，或者只看到一个线程的输出，然后程序就挂起了。我们用时间线来分析：

1. t1锁定了mtx1。
2. t2锁定了mtx2。
3. t1尝试锁定mtx2，但mtx2被t2持有，所以t1阻塞，等待mtx2。
4. t2尝试锁定mtx1，但mtx1被t1持有，所以t2阻塞，等待mtx1。
5. 双方都在等待对方释放锁，陷入永久等待。这就是死锁。

3.2 死锁的预防与解决策略

策略一：固定锁的顺序（最重要、最实用）这是避免死锁最有效的方法。为所有需要用到的锁定义一个全局的获取顺序，所有线程都必须按照这个顺序来申请锁。

void thread_a_safe() { std::lock_guard<std::mutex> lock1(mtx1); // 先锁顺序在前的锁 std::this_thread::sleep_for(std::chrono::milliseconds(10)); std::lock_guard<std::mutex> lock2(mtx2); // 再锁顺序在后的锁 std::cout << "Thread A acquired both locks safely\n"; } void thread_b_safe() { std::lock_guard<std::mutex> lock1(mtx1); // 同样，先锁mtx1 std::this_thread::sleep_for(std::chrono::milliseconds(10)); std::lock_guard<std::mutex> lock2(mtx2); // 再锁mtx2 std::cout << "Thread B acquired both locks safely\n"; }

现在两个线程都先申请mtx1，再申请mtx2。即使t1拿到了mtx1，t2在尝试拿mtx1时也会被阻塞，直到t1用完并释放两把锁后，t2才能依次获取。顺序保证了不会出现循环等待。

策略二：使用std::lock一次性锁定多个互斥量C++标准库提供了std::lock函数，它可以一次性锁定两个或更多的互斥量，且保证不会因为锁的顺序问题导致死锁。它内部使用了一种死锁避免算法（如Dijkstra的算法）。

void thread_a_deadlock_free() { // std::lock会尝试同时锁定mtx1和mtx2，避免死锁 std::lock(mtx1, mtx2); // 锁定后，需要用lock_guard接管所有权，并采用std::adopt_lock策略表示锁已持有 std::lock_guard<std::mutex> lock1(mtx1, std::adopt_lock); std::lock_guard<std::mutex> lock2(mtx2, std::adopt_lock); std::cout << "Thread A acquired both locks deadlock-free\n"; }

std::lock(mtx1, mtx2)要么同时成功锁定两个锁，要么一个都不锁（如果中途失败，它会释放已锁定的锁）。这从根本上避免了持有并等待的条件。

策略三：使用std::scoped_lock（C++17）std::scoped_lock是std::lock_guard的增强版，可以接收多个互斥量，并在构造时自动调用std::lock来一次性获取它们，更简洁安全。

// C++17 及以上 void thread_a_modern() { std::scoped_lock lock(mtx1, mtx2); // 一行搞定，自动避免死锁 std::cout << "Thread A acquired both locks with scoped_lock\n"; }

这是现代C++多线程编程的首选方式，只要你的项目支持C++17或更高标准。

策略四：避免嵌套锁与缩短锁的持有时间尽量让锁的粒度更细，只锁住真正需要保护的共享数据区域。并且，尽量避免在一个锁的保护区内去调用另一个未知的函数，因为那个函数内部可能也会获取锁，从而形成复杂的锁依赖，增加死锁风险。如果实在需要嵌套，必须严格遵守固定的锁顺序。

排查技巧：当程序疑似死锁挂起时，在Linux下可以用gdbattach到进程，然后thread apply all bt查看所有线程的调用栈。通常你会看到两个或多个线程的栈顶都停在pthread_mutex_lock或类似的锁等待函数上。这就是死锁的典型特征。

4. 条件变量的“虚假唤醒”与等待逻辑

条件变量std::condition_variable是线程间同步的强大工具，用于让一个线程等待某个条件成立。但它有两个非常著名的陷阱：“虚假唤醒”和使用不当导致的死锁。

4.1 虚假唤醒：为什么wait要用循环

“虚假唤醒”指的是，一个等待在条件变量上的线程，即使没有其他线程调用notify_one()或notify_all()，也可能被唤醒。这是POSIX标准和C++标准明确允许的行为，通常是为了兼容性和性能。

错误的写法：

std::mutex mtx; std::condition_variable cv; bool data_ready = false; int shared_data; void consumer() { std::unique_lock<std::mutex> lock(mtx); if (!data_ready) { cv.wait(lock); // 错误！可能被虚假唤醒，此时data_ready可能还是false。 } // 消费shared_data std::cout << "Consumed: " << shared_data << std::endl; }

如果cv.wait(lock)因为虚假唤醒而返回，但data_ready仍然是false，消费者线程就会错误地认为数据准备好了，从而访问未初始化的shared_data，导致未定义行为。

正确的写法：总是将wait放在一个检查条件的循环中。

void correct_consumer() { std::unique_lock<std::mutex> lock(mtx); while (!data_ready) { // 使用while循环，而不是if cv.wait(lock); } // 当循环退出时，我们确信data_ready == true std::cout << "Consumed: " << shared_data << std::endl; }

condition_variable::wait的第二种重载形式直接支持这种模式，它接受一个谓词（返回bool的可调用对象）。

void elegant_consumer() { std::unique_lock<std::mutex> lock(mtx); cv.wait(lock, []{ return data_ready; }); // 等价于上面的while循环 std::cout << "Consumed: " << shared_data << std::endl; }

这是必须牢记的规则：调用wait时，必须提供一个条件检查，并且这个检查必须放在循环中，或者使用带谓词的wait重载。

4.2 生产者-消费者模型中的丢失通知与竞态条件

另一个常见问题是通知的丢失。看下面这个有缺陷的生产者-消费者实现：

// 生产者 void flawed_producer() { std::this_thread::sleep_for(std::chrono::milliseconds(100)); // 模拟耗时计算 { std::lock_guard<std::mutex> lock(mtx); shared_data = 42; data_ready = true; } cv.notify_one(); // 通知消费者 } // 消费者 void flawed_consumer() { std::unique_lock<std::mutex> lock(mtx); cv.wait(lock, []{ return data_ready; }); std::cout << "Consumed: " << shared_data << std::endl; data_ready = false; // 重置标志 }

这个模型在大多数情况下能工作，但存在一个竞态条件：

1. 消费者先运行，检查data_ready为false，然后调用wait释放锁并进入等待。
2. 生产者随后运行，获取锁，设置数据和标志，释放锁，然后调用notify_one()。
3. 消费者被唤醒，重新获取锁，检查条件（此时为真），消费数据。

问题出在步骤1和步骤2之间。如果调度顺序反过来：

1. 生产者先运行，设置数据和标志，发出通知。但此时消费者还没有开始等待！
2. 消费者随后运行，调用wait。由于通知已经发出，这次wait调用将永远阻塞，因为条件变量不保存通知事件。这就是“丢失通知”。

解决方案是确保“设置标志”和“发送通知”在同一个锁的保护下，并且消费者的等待逻辑正确。上面的flawed_producer和flawed_consumer实际上已经做到了这一点（因为修改data_ready和notify都在锁外，但data_ready的修改在锁内，这保证了消费者在检查条件时能看到最新的值）。更隐蔽的问题是，如果存在多个消费者，使用notify_one()可能只唤醒一个，而其他消费者可能永远等下去。这时你需要仔细设计逻辑，是使用notify_all()，还是使用多个条件变量。

实操心得：对于简单的“一次性事件”通知（比如任务完成、数据就绪），使用“原子布尔标志 + 条件变量”是经典模式。但务必记住：修改标志必须上锁，wait必须用循环或谓词。对于更复杂的通信，比如消息队列，通常需要维护一个队列，条件变量等待的条件是“队列非空”。

5. 线程生命周期管理与资源释放

线程对象本身和线程执行的函数是两个概念。std::thread对象是C++对象，遵循RAII原则。但线程的执行体是一个独立的控制流。错误管理它们的生命周期会导致资源泄露或程序崩溃。

5.1join与detach：你必须二选一

这是C++多线程最严格的规则之一：在std::thread对象销毁之前，你必须决定它的归宿——要么join()，要么detach()。如果都没做，std::thread的析构函数会调用std::terminate()终止整个程序。

• join()：阻塞当前线程（通常是主线程），直到被join的线程执行完毕。这确保了子线程的所有资源（栈内存、局部变量等）都被正确清理。join后，thread对象不再代表任何执行线程（其joinable()为false），可以安全销毁。
• detach()：将线程与thread对象分离。分离后的线程在后台独立运行，其资源在线程结束时由系统自动回收。分离后，你失去了对这个线程的控制权，无法再对它进行join。通常用于执行一些不关心结果的后台任务（如日志写入、监控心跳）。

错误示例：

void risky_function() { std::thread t([](){ std::this_thread::sleep_for(std::chrono::seconds(2)); std::cout << "Background task done.\n"; }); // 忘记调用 t.join() 或 t.detach() } // t 离开作用域，析构函数被调用，程序调用 std::terminate() 崩溃！

正确做法：

// 方案1：使用join，等待线程结束 void safe_function_with_join() { std::thread t([](){ /* ... */ }); // ... 可能发生异常 t.join(); // 确保即使发生异常也能join } // 方案2：使用RAII包装器，确保异常安全 class ThreadGuard { std::thread& t; public: explicit ThreadGuard(std::thread& t_) : t(t_) {} ~ThreadGuard() { if (t.joinable()) { t.join(); // 或 t.detach()，根据设计决定 } } ThreadGuard(const ThreadGuard&) = delete; ThreadGuard& operator=(const ThreadGuard&) = delete; }; void safe_function_with_guard() { std::thread t([](){ /* ... */ }); ThreadGuard g(t); // ... 即使这里抛出异常，g的析构函数也会调用t.join() } // 方案3：C++20的 std::jthread // std::jthread 在析构时会自动 join，是更安全的选择。

5.2 捕获局部变量与悬空引用

当线程函数通过Lambda表达式捕获局部变量时，要格外小心变量的生命周期。

void dangerous_lambda_capture() { int local_var = 100; std::thread t([&local_var]() { // 按引用捕获！ std::this_thread::sleep_for(std::chrono::seconds(1)); std::cout << local_var << std::endl; // 危险！local_var可能已销毁 }); t.detach(); // 分离线程，主线程继续执行 } // 函数结束，local_var被销毁。但分离的线程还在运行，并试图访问已销毁的内存！

分离的线程(t)可能还在睡眠，而dangerous_lambda_capture函数已经返回，局部变量local_var的内存被释放。一秒钟后，线程醒来访问这块内存，结果是未定义的（通常是段错误或读取到垃圾值）。

解决方案：

1. 按值捕获：如果数据不大，且需要独立副本。

   std::thread t([local_var]() { /* 安全，拥有自己的副本 */ });

2. 确保线程在局部变量失效前结束：即使用join()，而不是detach()。
3. 传递堆上数据的智能指针：对于复杂数据。

   auto shared_data = std::make_shared<int>(100); std::thread t([shared_data]() { /* 安全，shared_ptr保证数据存活 */ }); t.detach();

5.3 线程与this指针的陷阱

在类的成员函数中启动线程，并让线程访问类的成员变量，这是一个高频踩坑点。

class MyClass { std::thread worker_thread; int member_data = 10; void do_work() { // 长时间运行的任务，访问 member_data std::cout << member_data << std::endl; } public: void start_work() { worker_thread = std::thread(&MyClass::do_work, this); // 传递this指针 } ~MyClass() { if (worker_thread.joinable()) { worker_thread.join(); } } };

这段代码看起来没问题，但它隐藏着一个对象生命周期的问题。如果MyClass对象在do_work线程结束前就被销毁了怎么办？

{ MyClass obj; obj.start_work(); } // obj离开作用域，析构函数被调用，会join等待worker_thread结束。 // 这是安全的，因为析构函数中join了。

但如果worker_thread被detach了，或者MyClass对象是通过new创建并在线程结束前被delete了，那么do_work线程中的this指针就变成了悬空指针，访问member_data会导致未定义行为。

更安全的做法：考虑将线程需要的数据与对象生命周期解耦。或者，使用std::shared_from_this和std::shared_ptr来管理对象的生命周期，确保只要线程还在运行，对象就不会被销毁。但这引入了更复杂的生命周期管理。一个更简单的准则是：确保启动线程的对象的生命周期覆盖线程的执行周期，通常意味着在对象的析构函数中join所有它启动的线程。

6. 性能陷阱与std::atomic的内存序

多线程编程不仅要正确，还要高效。滥用锁会导致性能急剧下降，而错误使用std::atomic的内存序则可能导致逻辑错误。

6.1 锁粒度太粗：把整条街都封了

std::mutex big_lock; std::vector<int> shared_vec; void inefficient_function() { std::lock_guard<std::mutex> lock(big_lock); // 锁住整个函数 // 步骤A：一些不涉及shared_vec的本地计算 int local_result = heavy_computation(); // 耗时操作！ // 步骤B：修改shared_vec shared_vec.push_back(local_result); }

big_lock保护了shared_vec，这没错。但问题在于，锁的持有时间覆盖了耗时的heavy_computation()。在这段时间里，其他所有需要访问shared_vec的线程都被阻塞，即使它们与当前线程的本地计算完全无关。这严重降低了并发度。

优化：缩小临界区

void efficient_function() { // 步骤A：在锁外执行 int local_result = heavy_computation(); // 步骤B：仅锁住访问共享资源的最小代码段 { std::lock_guard<std::mutex> lock(big_lock); shared_vec.push_back(local_result); } // lock_guard在此析构，锁被立即释放 }

原则：锁的粒度应尽可能细，只保护真正共享的数据，持有锁的时间应尽可能短。

6.2std::atomic与内存序：不仅仅是原子性

很多人认为std::atomic就等同于“线程安全”，这其实是个误解。std::atomic保证了单个操作的原子性，但它默认的内存序（std::memory_order_seq_cst，顺序一致性）保证了更多：它保证了所有线程看到的原子变量修改顺序是一致的，并且会建立“同步”关系，影响其周围非原子变量的可见性。

但对于性能有极致要求的场景（如无锁数据结构），你可能需要放宽内存序。std::atomic的操作可以指定内存序，例如memory_order_relaxed、memory_order_acquire、memory_order_release等。

std::atomic<bool> data_ready{false}; int shared_value = 0; // 线程A（生产者） void producer() { shared_value = 42; // 1. 写入非原子变量 data_ready.store(true, std::memory_order_release); // 2. 原子存储，release语义 } // 线程B（消费者） void consumer() { while (!data_ready.load(std::memory_order_acquire)) { // 3. 原子加载，acquire语义 // 忙等待或让出CPU } std::cout << shared_value << std::endl; // 4. 读取非原子变量 }

这里使用了release-acquire配对。store操作（release）保证：在它之前的所有内存写操作（包括shared_value = 42），对执行了load（acquire）操作的线程是可见的。这建立了一个“同步点”，确保了shared_value的写入对消费者线程是可见的。如果只用memory_order_relaxed，则只保证原子操作本身的原子性，不提供这种同步保证，消费者线程可能看到data_ready为true，却看不到shared_value被更新为42（由于CPU缓存和指令重排）。

给新手的建议：除非你在进行极低层的无锁编程，并且完全理解内存模型，否则请坚持使用std::atomic的默认内存序（memory_order_seq_cst）。它虽然可能慢一点，但保证了最直观、最安全的行为。在绝大多数应用场景下，这点性能损失是值得的。

7. 调试与排查实战：当多线程程序出错时

多线程Bug难以复现，是调试的噩梦。以下是一些实战技巧和工具。

7.1 常见的错误现象与可能原因速查表

7.2 工具推荐与使用心得

1. ThreadSanitizer (TSan)：这是排查数据竞争的利器。在GCC或Clang编译时加上-fsanitize=thread -g选项，运行程序，TSan会在检测到数据竞争时给出详细的报告，包括冲突的堆栈信息。在开发阶段强烈建议定期使用TSan进行测试。
2. GDB / LLDB：当程序死锁或挂起时，用调试器attach上去。
   • info threads：查看所有线程。
   • thread apply all bt：打印所有线程的调用栈。死锁时，你会看到多个线程卡在__lll_lock_wait或类似的锁函数上。
   • thread [编号]：切换到特定线程进行详细检查。
3. Valgrind (Helgrind / DRD)：另一套强大的动态分析工具，Helgrind和DRD专门用于检测多线程错误，如数据竞争、锁顺序问题、误用POSIX线程API等。比TSan慢，但有时能发现更深层的问题。
4. 打印日志：在关键位置（如加锁、解锁、进入等待、收到通知时）添加带时间戳和线程ID的日志。分析日志的时间顺序可以帮助理解线程间的交互和发现问题。可以使用std::this_thread::get_id()获取线程ID。

最后的心得：多线程编程是对程序员心智的极大考验。最好的策略是“防御性编程”：优先使用高级的并发抽象（如任务队列、线程池），尽量减少手动操作裸线程和锁；如果必须用，则让同步逻辑尽可能简单、清晰；并且，充分测试，利用好TSan等工具，将并发Bug扼杀在开发阶段。记住，没有在并发环境下充分测试过的代码，就是不可靠的代码。