关于多线程，我给出13点建议
时间：2021-08-07 11:16:23
手机看文章
扫描二维码
随时随地手机看文章
[导读]平时开发过程中大家可能都接触过多线程开发，其实多线程还是有很多门道的，这里贴出我的一点点看法，抛砖引玉一波。1使用标准库中的并行算法：C标准库中有大量算法，在C17后，有60多个算法支持并行执行，可设置ExecutionPolicy策略。尽量使用这些并行算法，没必要自己写个多线程...
平时开发过程中大家可能都接触过多线程开发，其实多线程还是有很多门道的，这里贴出我的一点点看法，抛砖引玉一波。
1 使用标准库中的并行算法：C 标准库中有大量算法，在C 17后，有60多个算法支持并行执行，可设置ExecutionPolicy策略。尽量使用这些并行算法，没必要自己写个多线程相关算法。
2 可更多使用C 11的std::thread，而不是pthread，推荐std::thread没啥别的性能方面的原因，只是因为使用起来很方便。
● std::thread配合lambda表达式创建个线程运行，很方便！
● thread对象直接join或者detach，很方便！
●使用thread再配合mutex的std::unique_lock和std::lock_guard使用，很方便！
● 使用thread再配合条件变量使用，很方便！
● 使用std::this_thread::sleep_for(xxx)休眠某段时间，很方便！
3 在使用std::thread时，确保在生命周期结束前，std::thread对象不是可结合的，即确保对象调用了join()或者detach()。否者程序会crash，为什么会这样？源码之下，了无秘密，这是std::thread的析构函数，一看便知：
~thread(){ if (joinable()) std::terminate();}
C 20的std::jthread就解决了这个问题，jthread在析构函数中会自动join()。其实不使用C 20，我们也可以自己封装一个std::thread的wrapper，来解决这种问题。4 使用sleep(xxx)永远解决不了任何时序相关的bug，一定要使用条件变量来保证时序。
5 不要迷信多线程，我们要明确知道，为什么要使用多线程，是为了更高的性能？还是为了不阻塞当前线程？还是有其他考虑？想清楚利弊，最好能综合做出评估后再决定。
6 最好的同步就是没有同步：尽可能使用更合理的方式设计线程，让所有的线程在使用共享数据时只读不写，或者只写入其他线程不会读取的部分，或者确保数据的所有权是单线程模式，同一时刻只会有一个线程在访问这块数据，那么多线程编码就会简单很多，不会有任何数据竞争，也不会出现死锁等问题。
7 先考虑原子类型再考虑锁：通过原子类型或原子操作更方便编写没有数据竞争和死锁的代码，因为他们能自动处理同步问题。如果不能使用原子类型或原子操作，那再考虑使用互斥锁来保护临界区。（看到过有大佬不推荐原子操作的，但是没说为啥，这是有什么顾虑吗？大家可以留言聊一聊。）
8 先确保解决了同步问题，再考虑优化：典型的就是普通互斥锁和读写锁的问题，很多人上来就使用读写锁，追求更高的性能，除非读操作比写操作频繁的多，否则读写锁并不会提高多少性能，我看见过很多使用读写锁导致出现同步问题的案例。所以，开始写代码时还是消停的使用普通锁吧，真正需要优化时再考虑使用其他手段。
9 使用RAII锁对象：使用lock_guard、unique_lock、shared_lock或scoped_lock等RAII类来管理锁，这样可以确保一定会释放锁。降低出现死锁的风险，但我们也要了解，如果真的出现了死锁，我们要如何定位？再出个思考题：我们都知道加锁的顺序不一致可能会导致死锁，如果释放锁的顺序不一致会导致死锁吗？
10 尽快释放锁：当需要通过锁保护共享数据时，务必尽快释放锁，尽可能缩小锁控制的粒度，明确哪些数据需要加锁，哪些根本就不需要，不要无脑加锁。因为当一个线程持有一个锁时，会使得其他线程阻塞等待这个锁，这可能会降低程序的性能。
11 使用线程池：动态频繁的创建和销毁大量的线程会导致性能下降。这种情况下，最好使用线程池来重用已有的线程，我之前写过如何撸一个线程池的文章，大家可以去看看。
12 如果真的需要共享数据，尽量使用通信方式，而非共享内存方式。可使用队列，通信队列如果需要可考虑使用阻塞队列，而不是while(!queue.empty()) { xxx }。
13 做好日志记录：使用多线程程序很容易出现各种问题，而且问题还不稳定复现，复现的时机多数时候还不一样，一定要做好日志记录，确保出现问题时有据可查，可快速分析出问题所在。
下载文档
