1. 项目概述为什么C多线程编程是“带刺的玫瑰”如果你写过C多线程程序大概率经历过这种场景程序在测试环境跑得稳稳当当一到生产环境就间歇性崩溃或者结果时对时错用调试器一跟问题又神秘消失了。这感觉就像在调试一个“薛定谔的bug”——你不观察它的时候它肯定出问题你一旦想仔细看看它又表现得一切正常。这正是多线程编程的魅力与危险并存之处。它能让你的程序性能飞升充分利用多核处理器的算力处理海量数据或高并发请求但同时也引入了无数难以复现和调试的“幽灵”问题。C标准库从C11开始正式支持了原生的多线程thread这无疑是一大福音让我们摆脱了对平台特定API如Windows的CreateThread或POSIX的pthread的依赖。然而标准库提供的是一把锋利的“双刃剑”。它给了你构建并发系统的强大工具但并没有附赠一份“安全使用说明书”。竞态条件、死锁、数据竞争、虚假共享……这些概念从教科书走进你的代码带来的往往是深夜调试的煎熬。这篇文章我不想再重复教科书上关于std::thread、std::mutex用法的基本介绍。那些资料随处可见。我想聚焦于更实际的东西那些在真实项目开发中老手们用血泪教训换来的“注意事项”以及那些看似合理、实则暗藏杀机的“错误示例”。我们会把这些抽象的问题具象化看看它们是如何在代码中悄然滋生的更重要的是如何系统地预防和解决它们。无论你是正在学习多线程的初学者还是已经写过一些并发代码、但总被一些诡异问题困扰的中级开发者相信这些从实战中总结出的经验能帮你避开不少坑写出更健壮、更高效的C多线程程序。2. 核心陷阱解析多线程编程中的四大“致命伤”在深入代码之前我们必须从原理上理解多线程程序为什么会出错。错误往往源于对共享资源访问的失控。下面这四大问题是多线程编程中最核心的陷阱。2.1 竞态条件当“先读后写”不再可靠竞态条件可能是最普遍也最令人头疼的问题。它的本质是程序运行的结果依赖于多个线程执行操作的相对时序而这个时序是不确定的。想象一个简单的场景一个全局计数器int counter 0;两个线程同时执行counter操作。你的直觉可能是执行两次后counter应该等于2。但在底层counter通常不是原子操作它可能被编译成三条机器指令1. 从内存加载counter到寄存器2. 寄存器值加一3. 将寄存器值存回内存。如果两个线程几乎同时执行可能会发生如下交错线程A加载counter(值0)。线程B也加载counter(值0因为A还没存回去)。线程A将加1后的值(1)存回counter。线程B将其加1后的值(1)也存回counter。 最终counter的值是1而不是2。这就是一个典型的竞态条件。注意竞态条件不一定导致程序崩溃它更常导致的是数据错误即程序产生了逻辑上错误的结果但继续运行。这种错误非常隐蔽因为它在单线程测试或低并发下可能永远不会出现。2.2 数据竞争未同步的访问是万恶之源数据竞争是竞态条件的一种特定形式C标准对其有严格定义当两个或多个线程并发访问同一个内存位置其中至少有一个是写操作且这些操作没有使用同步机制来排序时就发生了数据竞争。发生数据竞争的程序其行为是未定义的。这意味着编译器、CPU甚至运行时环境都可以对这样的程序做任何事它可能产生错误结果可能崩溃也可能在某些架构和优化级别下“看似正常”地运行。这是最危险的情况因为你失去了对程序行为的所有保证。// 错误示例典型的数据竞争 #include thread #include iostream int shared_data 0; void increment() { for (int i 0; i 100000; i) { shared_data; // 未同步的写操作 } } int main() { std::thread t1(increment); std::thread t2(increment); t1.join(); t2.join(); std::cout Final value: shared_data std::endl; // 结果几乎肯定小于200000 return 0; }上面这段代码两个线程并发地对shared_data执行上万次自增最终结果几乎不可能是预期的200000而是一个小于它的随机数。这就是数据竞争导致的结果错误。2.3 死锁当线程们陷入永恒的等待死锁就像几个哲学家围坐在餐桌前每人左手边有一把叉子他们都需要两把叉子才能吃饭。如果每个人同时拿起自己左边的叉子那么所有人都会永远等待右边的人放下叉子最终全体饿死。在程序中死锁通常发生在两个或多个线程互相等待对方持有的锁时。一个经典的死锁场景需要四个必要条件同时满足互斥、持有并等待、不可剥夺、循环等待。最常见的错误模式就是锁的顺序不一致。// 错误示例锁顺序不一致导致的死锁 std::mutex mutex_a; std::mutex mutex_b; int data_a 0; int data_b 0; void thread1_work() { std::lock_guardstd::mutex lock_a(mutex_a); // 先锁A // 模拟一些处理 std::this_thread::sleep_for(std::chrono::milliseconds(10)); std::lock_guardstd::mutex lock_b(mutex_b); // 再尝试锁B data_a data_b 1; } void thread2_work() { std::lock_guardstd::mutex lock_b(mutex_b); // 先锁B std::this_thread::sleep_for(std::chrono::milliseconds(10)); std::lock_guardstd::mutex lock_a(mutex_a); // 再尝试锁A data_b data_a 1; }如果thread1锁住了mutex_a的同时thread2锁住了mutex_b那么它们就会陷入死锁彼此无限期地等待对方释放锁。在实际中死锁不一定立即发生它依赖于线程调度的“运气”这使得它成为一个间歇性的、难以在测试中发现的严重缺陷。2.4 虚假共享看不见的性能杀手前三个问题主要影响正确性而虚假共享则是一个纯粹的性能陷阱。现代CPU的每个核心都有自己的高速缓存L1、L2。为了保持缓存一致性当某个核心修改了其缓存中的一段数据时如果其他核心的缓存也持有该数据那么这些缓存行会被标记为无效迫使其他核心从更慢的内存或上级缓存中重新加载数据。这个过程代价很高。缓存行是缓存操作的基本单位通常是64字节。虚假共享发生在两个线程频繁修改位于同一个缓存行但不同内存位置的变量。尽管它们逻辑上不共享数据但由于物理上位于同一个缓存行一个线程的写操作会导致另一个线程的缓存行失效引发频繁的缓存同步从而严重拖慢程序速度。// 潜在的性能陷阱虚假共享 struct AlignedData { int data1; // 线程1频繁修改 // 假设int是4字节这里可能会有60字节的“填充”使得data2在下一个缓存行 // 但如果没有特意对齐data2很可能和data1在同一个缓存行 int data2; // 线程2频繁修改 }; void thread1_func(AlignedData d) { for(int i0; i1e9; i) d.data1; } void thread2_func(AlignedData d) { for(int i0; i1e9; i) d.data2; }如果data1和data2在同一个缓存行两个线程分别疯狂自增这两个变量其性能可能会比单线程还要差因为大量的CPU时间被浪费在了缓存一致性协议的开销上。3. 工具与同步原语的正确选用了解了核心陷阱我们来看看C标准库提供了哪些武器来应对。选用合适的工具并正确使用它们是写出稳健多线程代码的第一步。3.1 互斥量不仅仅是std::mutexstd::mutex是最基本的互斥量但直接使用它很容易出错比如忘记解锁导致死锁。因此C提供了管理类std::lock_guard和std::unique_lock。std::lock_guard在构造时加锁析构时自动解锁。适用于简单的临界区保护生命周期内不需要手动控制锁。std::mutex mtx; void safe_increment(int val) { std::lock_guardstd::mutex lock(mtx); // 构造即加锁 val; } // lock 析构自动解锁std::unique_lock比lock_guard更灵活。可以延迟加锁、手动加解锁、转移所有权并且能与条件变量配合使用。std::mutex mtx; std::unique_lockstd::mutex lock(mtx, std::defer_lock); // 延迟加锁 // ... 做一些不需要锁的操作 lock.lock(); // 手动加锁 // ... 操作共享数据 lock.unlock(); // 可以手动解锁 // ... 再做些非临界区操作 lock.lock(); // 再次加锁实操心得对于绝大多数简单的临界区保护优先使用std::lock_guard。它的意图更明确RAII资源获取即初始化代码更简洁不易出错。只有当你需要std::condition_variable的配合或者需要复杂的锁策略如尝试加锁、超时加锁时才使用std::unique_lock。3.2 原子操作轻量级的同步利器对于简单的标量类型如int,bool,指针使用互斥量可能显得“杀鸡用牛刀”开销过大。C11的atomic头文件提供了原子类型如std::atomicint。对原子类型的操作是原子的、不可分割的并且会建立必要的内存屏障防止指令重排。#include atomic #include thread std::atomicint atomic_counter(0); // 正确使用原子变量 void atomic_increment() { for (int i 0; i 100000; i) { atomic_counter.fetch_add(1, std::memory_order_relaxed); // 原子自增 // 或者直接用 atomic_counter; } } // 两个线程同时调用 atomic_increment最终结果一定是200000。原子操作有不同内存序memory_order选项如relaxed,acquire,release,acq_rel,seq_cst。std::memory_order_seq_cst顺序一致性是默认的也是最严格的保证所有线程看到的操作顺序一致但性能开销最大。在保证正确性的前提下可以根据场景选择更宽松的内存序来提升性能但这属于高级话题需要对内存模型有深刻理解。注意事项原子操作并非万能。它只能保证单个变量的操作是原子的。如果你需要对多个变量进行“要么全做要么全不做”的原子更新或者操作是复合的如“检查-然后-行动”原子变量 alone 是不够的仍然需要锁。例如实现一个线程安全的栈仅靠std::atomic管理栈顶指针是不够的因为pop操作涉及“读指针、取数据、更新指针”多个步骤。3.3 条件变量让线程学会等待与通知条件变量std::condition_variable用于让一个或多个线程等待某个条件成立。它总是与一个互斥量配合使用。常见的生产者-消费者模式就是其典型应用场景。#include queue #include thread #include mutex #include condition_variable std::queueint data_queue; std::mutex queue_mutex; std::condition_variable data_cond; void data_producer() { int data produce_data(); { std::lock_guardstd::mutex lock(queue_mutex); data_queue.push(data); } data_cond.notify_one(); // 通知一个等待的消费者 } void data_consumer() { while(true) { std::unique_lockstd::mutex lock(queue_mutex); // 等待条件成立。为了防止虚假唤醒条件检查必须放在while循环内。 data_cond.wait(lock, []{ return !data_queue.empty(); }); int data data_queue.front(); data_queue.pop(); lock.unlock(); // 尽早释放锁让其他消费者可以继续 process_data(data); } }这里的关键是wait函数。它会自动释放锁并将线程挂起。当其他线程调用notify_one()或notify_all()时等待的线程被唤醒但在从wait返回前它会重新获取锁并再次检查lambda表达式给出的条件。这个“检查-等待”的循环是必须的因为存在“虚假唤醒”线程在没有被通知的情况下也可能从等待中返回。3.4 锁策略与死锁预防预防死锁的核心原则是保证所有线程以相同的全局顺序获取锁。单次锁定如果可能尽量一次只持有一个锁。如果必须持有多个锁则设计一个固定的锁获取顺序例如总是先锁A再锁B。使用std::lockC标准库提供了std::lock函数它可以一次性锁定两个或多个互斥量且不会产生死锁内部通常使用某种死锁避免算法如try-and-backoff。std::mutex mutex1, mutex2; void safe_operation() { // 使用std::lock一次性锁定多个互斥量避免死锁 std::lock(mutex1, mutex2); // 接着使用lock_guard接管已锁定的互斥量adopt_lock策略表示mutex已锁 std::lock_guardstd::mutex lock1(mutex1, std::adopt_lock); std::lock_guardstd::mutex lock2(mutex2, std::adopt_lock); // ... 安全地操作受mutex1和mutex2保护的资源 } // lock1, lock2析构时自动解锁避免在持有锁时调用用户代码你不知道用户代码会不会再去获取别的锁从而破坏你的锁顺序引发死锁。这是一个重要的设计准则。4. 实战错误示例剖析与修正理论说再多不如看几个活生生的“反面教材”。下面我们剖析几个常见的错误模式并给出正确的写法。4.1 错误示例一返回局部静态变量的引用这是一个单例模式或工厂函数中常见的错误。// 错误示例非线程安全的“懒汉”单例 class Singleton { public: static Singleton getInstance() { static Singleton instance; // C11保证局部静态变量初始化是线程安全的吗是但... return instance; } void doSomething() { /* ... */ } private: Singleton() default; ~Singleton() default; Singleton(const Singleton) delete; Singleton operator(const Singleton) delete; };问题分析在C11及以后的标准中局部静态变量的初始化是线程安全的。编译器会生成额外的代码来保证instance只被初始化一次。但是这仅仅保证了构造函数的调用是安全的。如果doSomething()方法内部修改了对象的成员变量并且多个线程同时调用getInstance().doSomething()那么对成员变量的访问仍然可能存在数据竞争除非doSomething()本身是线程安全的。修正方案需要根据实际情况决定。如果单例是无状态的或不可变的那么上述写法在C11后是安全的。如果单例有状态且需要修改必须在doSomething()内部或调用处进行同步。class StatefulSingleton { public: static StatefulSingleton getInstance() { static StatefulSingleton instance; return instance; } void doSomething() { std::lock_guardstd::mutex lock(mutex_); // 内部同步 // ... 修改成员数据 } private: StatefulSingleton() default; std::mutex mutex_; // ... 其他成员数据 };4.2 错误示例二错误地使用std::asyncstd::async是启动异步任务的便捷方式但它的启动策略和返回值处理有坑。// 错误示例忽略std::async的返回值导致潜在阻塞 void fire_and_forget_bad() { std::async(std::launch::async, []{ std::this_thread::sleep_for(std::chrono::seconds(5)); std::cout Task done.\n; }); // 函数立即返回 std::cout Function returned.\n; } // 问题std::async返回的std::future析构函数会阻塞等待任务完成。 // 因此实际上在fire_and_forget_bad()函数退出时会等待5秒。问题分析std::async返回一个std::future对象。这个future的析构函数会等待关联的异步任务完成对于以std::launch::async策略启动的任务。在上面的代码中返回的future是个临时对象在语句结束时立即析构导致调用线程阻塞等待任务完成失去了“发射后不管”的意义。修正方案如果确实需要“发射后不管”可以将future存储到一个持久化的地方如全局容器、类成员或者使用std::thread并 detach需谨慎detach的线程生命周期难以管理。void fire_and_forget_better() { auto fut std::async(std::launch::async, []{ std::this_thread::sleep_for(std::chrono::seconds(5)); std::cout Task done.\n; }); // 将future转移给一个长期存在的对象管理避免在此阻塞 // 例如global_future_container.push_back(std::move(fut)); std::cout Function returned.\n; } // 注意如果fut在此析构且任务未完成仍然会阻塞明确等待或获取结果如果任务有结果或你需要知道它何时完成就应该保存future并适时调用get()或wait()。void process_with_result() { std::futureint fut std::async(std::launch::async, []{ std::this_thread::sleep_for(std::chrono::seconds(1)); return 42; }); // ... 主线程可以做其他事情 int result fut.get(); // 必要时获取结果会阻塞直到任务完成 std::cout Result: result std::endl; }4.3 错误示例三在构造/析构函数中传递this指针这是一个生命周期管理的经典陷阱。// 错误示例在构造函数中将this传递给另一个线程 class DangerousClass { public: DangerousClass() { // 启动一个后台线程并将this指针传给它 worker_thread std::thread(DangerousClass::backgroundWork, this); } ~DangerousClass() { stop_flag true; if (worker_thread.joinable()) { worker_thread.join(); } } void backgroundWork() { while (!stop_flag) { // 访问成员变量... std::this_thread::sleep_for(std::chrono::milliseconds(100)); } } private: std::thread worker_thread; std::atomicbool stop_flag{false}; };问题分析这里存在两个严重问题对象构造未完成在DangerousClass的构造函数中对象还没有完全构造完成worker_thread成员可能尚未初始化完成取决于成员声明顺序就将this指针传递给新创建的线程。新线程可能立即开始执行backgroundWork访问尚未初始化完成的成员导致未定义行为。析构函数竞态条件在析构函数中我们设置stop_flag然后等待线程结束。但是如果backgroundWork函数正在执行而析构函数已经销毁了一些成员比如在stop_flag之后声明的成员那么backgroundWork访问这些已被销毁的成员就会导致内存错误。修正方案绝对不要在构造函数中启动一个会访问对象成员的线程。正确的做法是提供一个单独的start()方法。class SafeClass { public: SafeClass() : stop_flag(false) { // 仅初始化不启动线程 } ~SafeClass() { stop(); } void start() { // 显式启动 if (!worker_thread.joinable()) { stop_flag false; worker_thread std::thread(SafeClass::backgroundWork, this); } } void stop() { stop_flag true; if (worker_thread.joinable()) { worker_thread.join(); } } private: void backgroundWork() { while (!stop_flag.load()) { // 访问成员变量... std::this_thread::sleep_for(std::chrono::milliseconds(100)); } } std::thread worker_thread; std::atomicbool stop_flag; };更进一步为了更安全地管理线程生命周期可以考虑使用“可停止线程”的模式或者使用更高级的框架如 Intel TBB Microsoft PPL。5. 高级议题与性能考量当你掌握了基础同步原语并能避免常见错误后可以开始关注一些更高级的话题以提升程序的性能和可维护性。5.1 读写锁std::shared_mutex(C17)互斥量std::mutex是排他锁任何时候只允许一个线程进入临界区。但在“读多写少”的场景下这会造成不必要的性能瓶颈。多个读操作同时进行是不会破坏数据一致性的。C17引入了std::shared_mutex读写锁来解决这个问题。共享锁读锁多个线程可以同时持有共享锁用于读操作。独占锁写锁同一时间只能有一个线程持有独占锁用于写操作。当有线程持有独占锁时其他线程无法获取共享锁或独占锁。#include shared_mutex #include map class ThreadSafeLookupTable { private: std::mapint, std::string data; mutable std::shared_mutex mutex_; // mutable允许在const成员函数中加锁 public: std::string lookup(int key) const { std::shared_lockstd::shared_mutex lock(mutex_); // 共享锁读锁 auto it data.find(key); return (it data.end()) ? : it-second; } void update(int key, const std::string value) { std::unique_lockstd::shared_mutex lock(mutex_); // 独占锁写锁 data[key] value; } void erase(int key) { std::unique_lockstd::shared_mutex lock(mutex_); data.erase(key); } };使用std::shared_lock获取共享锁std::unique_lock获取独占锁。这样多个线程可以并发地执行lookup操作大大提升了读密集型应用的性能。5.2 线程局部存储thread_local有些数据本质上就是线程私有的比如随机数生成器、数据库连接、或者一些中间计算结果。使用全局变量加锁来访问它们效率低下。C11引入了thread_local关键字用于声明线程局部存储期变量。每个线程都有该变量的独立实例。#include iostream #include thread thread_local int thread_specific_value 0; // 每个线程都有自己的副本 void print_and_increment() { std::cout Thread std::this_thread::get_id() : value thread_specific_value std::endl; thread_specific_value; // 修改只影响当前线程的副本 } int main() { std::thread t1(print_and_increment); std::thread t2(print_and_increment); print_and_increment(); // 主线程 t1.join(); t2.join(); print_and_increment(); // 主线程再次打印 return 0; } // 输出可能是 // Thread [主线程ID]: value 0 // Thread [t1 ID]: value 0 // Thread [t2 ID]: value 0 // Thread [主线程ID]: value 1thread_local变量在第一次被线程访问时初始化。它非常适合用于将一些非线程安全的库函数如C语言的strtok或rand包装成线程安全的版本或者用于实现每线程缓存。5.3 避免虚假共享的实践技巧解决虚假共享的核心思路是让被不同线程频繁访问的变量在物理内存上相隔足够远确保它们不在同一个缓存行内。手动填充这是最直接的方法。在结构体中插入无用的填充字节。struct PaddedCounter { alignas(64) long long counter1; // C11 alignas指定对齐要求 char padding[64 - sizeof(long long)]; // 手动填充到缓存行大小假设64字节 alignas(64) long long counter2; };alignas(64)确保每个counter都从缓存行的起始位置开始。这样counter1和counter2肯定位于不同的缓存行。使用编译器属性或语言特性GCC/Clang可以使用__attribute__((aligned(64)))。C17提供了std::hardware_destructive_interference_size和std::hardware_constructive_interference_size来查询缓存行大小使代码更具可移植性。#include new // for std::hardware_destructive_interference_size struct alignas(std::hardware_destructive_interference_size) CacheLineAlignedCounter { long long counter; // 编译器会自动填充以达到指定的对齐要求 };数组分离如果每个线程访问一个大数组的不同部分确保每个线程访问的区间跨度大于缓存行大小或者让每个线程访问独立的数组。性能测试建议在优化虚假共享前后务必进行基准测试。可以使用perf工具Linux或 VTuneIntel来分析缓存未命中率cache-misses以验证优化是否有效。有时过度的填充会浪费内存反而降低缓存利用率需要权衡。6. 调试、测试与问题排查实录多线程bug之所以难在于它的不确定性和不可复现性。下面分享一些在实际项目中积累的调试和测试经验。6.1 利用工具进行动态分析Thread Sanitizer (TSan)这是排查数据竞争问题的神器。它是Clang/LLVM和GCC编译器工具链的一部分。在编译和链接时添加-fsanitizethread标志程序运行时TSan会监控所有内存访问并报告潜在的数据竞争。# 使用Clang编译并启用ThreadSanitizer clang -stdc17 -fsanitizethread -g -O1 my_program.cpp -o my_program_tsan ./my_program_tsan如果程序存在数据竞争TSan会输出非常详细的报告包括冲突的堆栈轨迹、内存地址、涉及线程等。注意TSan会显著降低程序运行速度通常5-10倍并增加内存消耗仅用于调试。Helgrind 和 DRD这是Valgrind工具套件中的两个工具用于检测多线程错误如锁顺序问题、数据竞争、误用POSIX线程API等。它们不需要重新编译程序但运行时开销极大可能慢20倍以上。静态分析工具如Clang Static Analyzer、Cppcheck等可以在编译阶段发现一些潜在的多线程问题例如未初始化的变量在锁外使用等。6.2 设计可测试的多线程代码写出易于测试的并发代码本身就能减少bug。依赖注入与控制反转将同步原语如mutex、condition_variable作为接口参数或通过构造函数注入而不是在类内部硬编码创建。这样在单元测试中你可以传入“模拟”的锁控制其行为或者检查加锁顺序。class DataProcessor { public: // 接收一个锁类型便于测试时替换 using LockType std::mutex; DataProcessor(std::shared_ptrLockType mtx std::make_sharedLockType()) : mutex_(mtx) {} void process() { std::lock_guardLockType lock(*mutex_); // ... 处理数据 } private: std::shared_ptrLockType mutex_; };提高可复现性在测试代码中可以插入一些可控的“调度点”比如使用条件变量或std::this_thread::yield()来有意制造特定的线程交错增加发现竞态条件的机会。虽然不能保证100%复现但能大大提高概率。压力测试与模糊测试让多线程程序在高负载下长时间运行或者使用随机延迟、随机操作顺序进行模糊测试有助于暴露那些在特定时序下才会出现的深层bug。6.3 常见问题速查与排查思路当程序出现诡异的多线程问题时可以按照以下思路排查现象可能原因排查思路与工具程序结果随机错误但单线程正确数据竞争、竞态条件1. 使用ThreadSanitizer (TSan) 运行程序。2. 检查所有共享数据的访问是否都有适当的同步锁或原子操作。3. 特别注意对STL容器的并发修改如std::vector的push_back。程序偶尔卡死无响应死锁、活锁、线程阻塞1. 使用调试器gdb中断程序查看所有线程的堆栈看它们卡在哪个锁上。2. 检查锁的获取顺序是否全局一致。3. 检查是否有线程在等待一个永远不会成立的条件条件变量使用错误。多线程性能反而比单线程差锁竞争激烈、虚假共享、过度同步1. 使用性能分析工具如perf, VTune查看热点和缓存未命中率。2. 考虑使用读写锁(shared_mutex)替代互斥锁。3. 检查频繁修改的变量是否位于同一缓存行结构体填充。4. 评估是否可以通过减少临界区范围细粒度锁或无锁数据结构来优化。程序崩溃错误指向STL或系统库在析构后访问对象、迭代器失效1. 检查对象的生命周期。线程是否可能访问一个已被销毁的堆对象或临时对象2. 检查STL容器在迭代时是否被其他线程修改。条件变量唤醒丢失或虚假唤醒wait调用不正确1. 确保wait调用在一个while循环中检查条件而不是if语句。2. 确保在修改条件变量关联的状态和调用notify之间持有相同的锁。一个关键的排查习惯当多线程bug难以复现时尝试在怀疑的代码区域前后增加日志输出带时间戳和线程ID。虽然日志本身可能影响时序海森堡bug但有时能提供宝贵的线索。确保日志输出函数本身是线程安全的。多线程编程是一场与不确定性的战斗。没有银弹可以解决所有问题但通过理解核心概念、善用同步工具、遵循最佳实践、并借助强大的调试工具我们可以极大地降低其复杂度写出既正确又高效的并发程序。最重要的经验是保持简单。能用原子变量就不用锁能用单个锁就不用多个锁能明确线程职责就不要过度共享数据。复杂性是并发bug最好的温床。