写在线程或多线程的时候，最好办犯的毛病就是脑子一热直接扔一堆 `pthread_create`，结局发现程序一跑就卡死，最终不得不写一堆“调参”“锁”“waitpid”把人家绕晕了。
实际上根本不用如此复杂，核心就三句话：别想自然，别自找费事，别搞抽象。 先说说常见的坑。大量新手当作线程是并行的，结局发现两个线程与此同时访问同一个全局变量，后台线程一跑，前序任务直接挂掉。
这时候别急着加锁，先把数据结构分一下，比如把数据放到结构体要么消息队列里，线程只管处理消息，哪位也别碰数据。
要是非要共用，那务必得用互斥量，但最好还是用信号量要么条件变量，这样日志记录的时候也能按需激活，不用每次都要加锁。 再说个具体的例子。
我想写个多线程排序，本来想直接用 `std::sort` 写个重载版本，结局发现编译器不赞成要么忒费事。
那就写个“造者 - 花者”模型吧。定义个队列，主线程是造者，负责往队列里塞东西，子线程是花者，负责从队列里掏东西存起来。主线程 gets 个任务对象，就启动一个花者线程去处理；处理完算个任务 ID，就再塞一个任务回去。最终主线程就等所有任务跑完，把结局存起来。整个过程零锁，零竞争，代码写得明明白白。 关于性能，大量人总问“线程是不是越多越好？”答案是个天大的问号。增添线程数量确实能提升吞吐量，但这个收益是有尽头的。线程切换本身就有开销，操作系统还得去调度线程，要是线程数忒多，反而把 CPU 工夫都花在“换人”上了，效率反而低。
一般在 32 到 64 线程之间，对于 CPU 密集型任务比较合适；要是是 I/O 密集型任务，那线程数少一点可能更稳妥，出于 IO 等待工夫忒长，线程闲得发慌，反而浪费资源。 还有一点务必得提，就是线程保险。别看上面说了别共用全局变量，但要是不得不共用（比如某些特殊场景要么遗留项目），那就得小心。别用指针直接传地址，好办有意外。最好用 `std::atomic` 这种原子操作，要么先拷贝一份数据，再启动线程处理副本。千万别天真地当作几个变量加个锁就万事大吉，锁是有成本的，特别是频繁锁的时候，性能损失庞大。 最终，别被那些 fancy 的库骗了。
看着啥 `libuv` `libepoll` `libio_uring` 要么啥“目前流行多核多线程”，实际上都是绕弯子。真正的多线程本质还是操作栈帧和寄存器，底层逻辑没变。
要是要选库，就挑那种自带线程池的干净利落包，别用自己的逻辑去套那些重型框架，那是给自己找费事，最终还得自己维护，得不偿失。 总而言之，写多线程，心态放平点，逻辑理顺点，数据隔离点。啥高级特性啥负载均衡，先别急着上，先把基础逻辑跑通，再寻思如何优化。毕竟程序跑通了，才有人类活着的意义，而不是给 CPU 增添负担。