高性能服务系列【十二】终篇：等待的代价

上一篇《主题匹配》入选CSDN的区块链领域内容榜，最早我看到的时候是排行榜34名，写这篇文章的时候已经落到了46名。虽然我没有觉得和区域链有什么关系，估计入选的原因是那篇文章涉及到几个算法吧。

在整个高性能服务系列中，我很少提及算法，倒不是说和算法没有关系，确切地说，性能本身是很难脱离算法的。一个原因是算法涉及的内容过于庞杂，见《算法导论》和高纳德的《计算机程序设计艺术》；另外一个原因，性能涉及到的算法并不会太多，反而是追求简单，加上系统级别的加成。

我们在总结高性能服务系列的核心关键是减少等待时间，而尽可能让CPU有效的跑满，重点提示，是有效的CPU时间。排除显而易见的网络IO、磁盘IO或者其他慢速服务，以及代码BUG导致死锁等。

我们假设一切都是正常的，没有低级错误，那么影响性能的几个因素，在之前几个篇章都提到过，这里做下总结。

一、锁互斥

这个不需要太多解释，锁互斥对性能的影响有两个：1、临界区资源只能被一个线程访问，其他线程等待导致的性能损失；2、等待线程被系统调度，切换出执行区间，再次进入可执行状态，需要重新加载内存。

为了降低锁互斥导致的等待时间，就要缩小临界区，使得进出临界区的执行时间尽可能的小。然后，再加上自旋锁，使得等待线程不需要被切换让出CPU执行时间。

或者更干脆地采用无锁数据结构，避免锁互斥，标本兼治。但无锁数据结构极为复杂，要编写一个正确的无锁数据结构，殊为不易，性价比太低。

如果从架构设计上，去减少需要被互斥共享的临界区，也是个不错的解决方案，从理论上讲是可行的。

二、系统调用

系统调用并不像锁那样容易理解，因为调用系统API简单而自然。一般不会注意到一个简单的系统调用，需要从用户空间切换到系统空间，要经过多个调用链。

我们之前提到过linux的futex调用，就是尽量将锁停留在用户空间，除非迫不得已，才会进行系统调用。windows下也有类似的API。

三，等待唤醒

有了等待，也同样有唤醒，比如条件变量，windows和Linux下都有。使用条件变量，就会涉及到互斥锁，见第一节。条件变量和信号量唤醒机制，都会出现虚假唤醒和唤醒丢失。虚假唤醒，比如惊群效应，最多损失性能，而唤醒丢失就比较严重了，不单是损失性能，甚至导致程序错误。唤醒丢失在条件变量时，还特别容易出现，需要警惕。windows下的事件，Event算是一种特殊的信号量，不单独论述。

四、内存分配

内存分配所需要的时间，也很容易被忽视。考察那些高性能软件源码，大部分都会自己定制一个内存分配器，或者引入第三方tcmalloc和jemalloc。传统的ptmalloc分配小块内存的代价比较大，远不如tcmalloc和jemalloc效果好，ptmalloc2已经做了不少优化。

内存分配之所以代价比较大，有这么几个方面。1、内存和地址空间是全局，因此在分配时，存在互斥的。2、小内存分配和释放是基本操作，调用频繁，所以对性能的影响很明显。

要自己定制一个内存分配器，代价比较大，还不如tcmalloc和jemalloc，但在一些特殊场景下，比如类似流水线的场景，就容易实现，也值得去定制一个内存分配器。

五、内存刷新

内存一致性协议导致的等待，因为是纳秒级别的，基本被忽视。只有用到原子操作，追求高性能的时候，才会被重视。题外话，用到原子操作时，必须特别注意到内存屏障。c++11引入了原子，std::memory_order集成了内存屏障，因此，需要理解每个memory_order的含义。