上一篇文章講了高性能編程的工具，這一篇我們基于前面的一些知識(shí)點(diǎn)和工具來(lái)聊一下Linux下的性能優(yōu)化(本知識(shí)點(diǎn)分為兩篇，當(dāng)前主要介紹CPU和內(nèi)存性能優(yōu)化)。

第一部分：CPU和內(nèi)存性能度量

系統(tǒng)調(diào)用

這張圖闡述一個(gè)應(yīng)用程序需要經(jīng)過(guò)這些模塊調(diào)用，對(duì)于性能每一部分都可能會(huì)有影響，那么我們先需要了解每個(gè)模塊需要怎么度量?

1、CPU度量

(1)CPU使用率

CPU使用率是最直觀描述當(dāng)前服務(wù)狀態(tài)的情況，如果CPU使用率過(guò)高，則表示當(dāng)前遇到了性能瓶頸，其中過(guò)高的這個(gè)具體值在線上一般是70%-90%之間，要么擴(kuò)容服務(wù)，要么就排查性能問題。

查看性能工具有很多，最常用的是通過(guò)top -p <進(jìn)程ID>或者通過(guò)查看線程top -H -p <進(jìn)程ID>觀察，另外可以使用上一篇的工具：mpstat -P ALL 1 2。

(2)用戶進(jìn)程消耗CPU

用戶進(jìn)程消耗CPU是常見的情況，往往和業(yè)務(wù)代碼或者使用的庫(kù)相關(guān)，比如大量的循環(huán)，JSON解析大包等，在用戶代碼層有很多耗CPU的操作，都會(huì)表現(xiàn)CPU使用率異常，定位其問題可以通過(guò)以下方式：

• 先通過(guò)ps或者top查詢具體進(jìn)程或者線程CPU消耗過(guò)高，然后查詢pidstat -p <進(jìn)程ID>判斷%usr %system %guest占比情況，判斷是否為用戶態(tài)消耗
• 由于用戶態(tài)涉及用戶代碼，可以通過(guò)perf top查看具體調(diào)用函數(shù)或者查看查看日志分析;

(3)內(nèi)核消耗CPU

消耗CPU不止用戶進(jìn)程，還包括內(nèi)核進(jìn)程，系統(tǒng)調(diào)用等內(nèi)核消耗CPU，可能的原因有大量的內(nèi)存拷貝，鎖，大量的上下文切換等等，具體分析和上面類似：

• 先通過(guò)ps或者top查詢具體進(jìn)程或者線程CPU消耗過(guò)高，然后查詢pidstat -p <進(jìn)程ID>判斷%usr %system %guest占比情況，判斷是否為內(nèi)核態(tài)消耗;
• 然后可以通過(guò)perf top或者strace查看系統(tǒng)調(diào)用情況，或者通過(guò)mpstat分析，總結(jié)中斷或者上下文切換頻率來(lái)判斷;

(4)CPU等待

CPU花費(fèi)在等待上的時(shí)間，主要是看是否大量的IO導(dǎo)致，也可以通過(guò)top定位具體進(jìn)程，然后跟蹤和分析該進(jìn)程或者線程的網(wǎng)絡(luò)調(diào)用情況。

(5)Nice消耗CPU

描述的是花費(fèi)的re-nicing進(jìn)程上時(shí)間占比，主要是更改了進(jìn)程的執(zhí)行順序或者優(yōu)先級(jí)。

(6)平均負(fù)載

平均負(fù)載是一個(gè)判斷系統(tǒng)快慢的重要原因，可能往往不是某個(gè)進(jìn)程引起的，主要有兩個(gè)指標(biāo)：

• 隊(duì)列中等待處理的進(jìn)程數(shù)(TASK_RUNNING狀態(tài)進(jìn)程)
• 等待不可中斷任務(wù)被完成的進(jìn)程數(shù)(TASK_UNINTERRUPTIBLE狀態(tài)進(jìn)程)

如果被阻塞，平均負(fù)載就會(huì)增加，可以通過(guò)uptime查看，往往負(fù)載增加這個(gè)時(shí)候需要優(yōu)化代碼或者增加機(jī)器資源。

(7)運(yùn)行進(jìn)程

當(dāng)前運(yùn)行和已經(jīng)在隊(duì)列中的進(jìn)程數(shù)，往往進(jìn)程過(guò)多會(huì)導(dǎo)致CPU調(diào)度繁忙，比如之前多進(jìn)程的Apache Server，所以可以根據(jù)當(dāng)前CPU的核數(shù)決定進(jìn)程個(gè)數(shù)，一般繁忙情況下的進(jìn)程不建議超過(guò)2倍CPU(當(dāng)前空閑的進(jìn)程也不宜過(guò)大，建議不超過(guò)10倍)。

(8)阻塞進(jìn)程

阻塞進(jìn)程是當(dāng)前未達(dá)到執(zhí)行條件的進(jìn)程，和上面的CPU等待事件對(duì)應(yīng)，一般是IO問題導(dǎo)致，比如寫文件數(shù)據(jù)過(guò)慢，或者socket讀寫數(shù)據(jù)未到達(dá)等等情況，如何分析呢?可以通過(guò)strace跟蹤系統(tǒng)調(diào)用分析。

(9)上下文切換

在系統(tǒng)上發(fā)生上下文切換的情況，也是判斷CPU負(fù)載的重要因素，大量的上下文切換可能和大量中斷或者鎖相關(guān)，上下文切換會(huì)導(dǎo)致CPU的緩存被刷新，數(shù)據(jù)需要從內(nèi)存換入換出等。

排查方案是通過(guò)perf或者vmstat工具查詢，比如vmstat輸出(也可以通過(guò)vmstat -s查看)：

[root@VM-16-16-centos ~]# vmstat 2 2
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 298404  96824 1189732    0    0     1    34    1    0  0  0 99  0  0
 0  0      0 298284  96824 1189736    0    0     0   214  760 1315  1  0 99  1  0

其中system包括：CPU在內(nèi)核態(tài)運(yùn)行信息，包括in中斷次數(shù)，cs上下文切換次數(shù)。

(10)中斷

中斷包含硬中斷和軟中斷，硬中斷是外設(shè)處理過(guò)程中產(chǎn)生的，通過(guò)硬件控制器通知cpu的狀態(tài)變化，而軟中斷是通過(guò)模擬硬中斷的一種信號(hào)處理方式，中斷過(guò)多會(huì)導(dǎo)致CPU花費(fèi)一些時(shí)間相應(yīng)中斷，這里也會(huì)影響性能，如何排查?通過(guò)命令行mpstat -P ALL 5 2可以查看：

[root@VM-16-16-centos ~]# mpstat -P ALL 5 2
Linux 4.18.0-348.7.1.el8_5.x86_64 (VM-16-16-centos)  2023年08月19日  _x86_64_ (2 CPU)

10時(shí)02分15秒  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
10時(shí)02分20秒  all    0.70    0.00    0.80    0.50    0.00    0.00    0.00    0.00    0.00   98.00
10時(shí)02分20秒    0    0.60    0.00    0.80    0.20    0.00    0.00    0.00    0.00    0.00   98.40
10時(shí)02分20秒    1    0.80    0.00    0.80    0.80    0.00    0.00    0.00    0.00    0.00   97.60

其中輸出中包含的：

• %irq：CPU處理硬中斷的時(shí)間占比
• %soft：CPU處理軟中斷的時(shí)間占比

2、內(nèi)存度量

(1)空閑內(nèi)存

通過(guò)free我們能看到當(dāng)前內(nèi)存情況：

[root@VM-0-11-centos ~]# free
              total        used        free      shared  buff/cache   available
Mem:        3880192      407228      713024         872     2759940     3182872
Swap:             0           0           0

• total：物理內(nèi)存總量
• used：已經(jīng)使用的物理內(nèi)存量
• free：尚未使用的物理內(nèi)存量
• shared：被共享使用的物理內(nèi)存量
• buff：被緩存的物理內(nèi)存量
• cache：被緩存的硬盤文件的物理內(nèi)存量
• available：剩余可用的物理內(nèi)存量，包括free + buff + cache - 系統(tǒng)預(yù)留的緩沖區(qū)
• Swap total：交換空間總量
• Swap used：已經(jīng)使用的交換空間量
• Swap free：尚未使用的交換空間量

從上面可以看出，free的內(nèi)存越大越好，這樣有剩余足夠多的物理內(nèi)存可以使用。

(2)Swap

Swap如上面說(shuō)的是交換空間的內(nèi)存數(shù)據(jù)，是linux為了釋放一部分物理內(nèi)存將數(shù)據(jù)臨時(shí)保存在Swap空間中，通過(guò)vmstat -s查看具體信息如下：

[root@VM-16-16-centos ~]# vmstat -s
      1860492 K total memory
       274936 K used memory
       701576 K active memory
       707432 K inactive memory
       299040 K free memory
        96824 K buffer memory
      1189692 K swap cache
            0 K total swap
            0 K used swap
            0 K free swap
     12318019 non-nice user cpu ticks
       124590 nice user cpu ticks
     11848347 system cpu ticks
   2844992141 idle cpu ticks
      4677889 IO-wait cpu ticks
            0 IRQ cpu ticks
       208152 softirq cpu ticks
            0 stolen cpu ticks
     15879112 pages paged in
    985253486 pages paged out
            0 pages swapped in
            0 pages swapped out
   1330511648 interrupts
    260667271 CPU context switches
   1678004734 boot time
     58996940 forks

其中如果pages swapped in和pages swapped out每秒增長(zhǎng)很多大，表示內(nèi)存上遇到了瓶頸，需要升級(jí)機(jī)器的內(nèi)存或者優(yōu)化代碼。

(3)Slab

在Linux中，伙伴系統(tǒng)是以頁(yè)為單位管理和分配內(nèi)存，但是現(xiàn)實(shí)的需求卻以字節(jié)為單位，假如我們需要申請(qǐng)20Bytes，總不能分配一頁(yè)吧?那豈不是嚴(yán)重浪費(fèi)內(nèi)存。那么該如何分配呢?Slab分配器就應(yīng)運(yùn)而生了，專為小內(nèi)存分配而生，Slab分配器分配內(nèi)存以Byte為單位，但是Slab分配器并沒有脫離伙伴系統(tǒng)，而是基于伙伴系統(tǒng)分配的大內(nèi)存進(jìn)一步細(xì)分成小內(nèi)存分配，其作用如下：

• 節(jié)省空間，減少內(nèi)存碎片化，Slab對(duì)小對(duì)象進(jìn)行分配，不用為每個(gè)小對(duì)象分配一頁(yè)
• 提高系統(tǒng)效率：當(dāng)對(duì)象擁有者釋放一個(gè)對(duì)象后，SLAB的處理是僅僅標(biāo)記對(duì)象為空閑，并不做多少處理，而又有申請(qǐng)者申請(qǐng)相應(yīng)大小的對(duì)象時(shí)，Slab會(huì)優(yōu)先分配最近釋放的對(duì)象

如果要排查Slab的詳細(xì)信息，可以通過(guò)slabtop或者cat /proc/slabinfo，輸出如下(執(zhí)行slabtop)：

Active / Total Objects (% used)    : 1074142 / 1101790 (97.5%)
 Active / Total Slabs (% used)      : 39843 / 39843 (100.0%)
 Active / Total Caches (% used)     : 100 / 130 (76.9%)
 Active / Total Size (% used)       : 250498.05K / 253182.16K (98.9%)
 Minimum / Average / Maximum Object : 0.01K / 0.23K / 8.00K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
445302 445302 100%    0.10K  11418  39     45672K buffer_head
249102 249071  99%    0.19K  11862  21     47448K dentry
 83616  83557  99%    1.00K   5226  16     83616K ext4_inode_cache
 63240  40754  64%    0.04K    620 102  2480K ext4_extent_status
 54376  54297  99%    0.57K   3884  14     31072K radix_tree_node
 29547  29487  99%    0.19K   1407  21  5628K kmalloc-192
 28544  28488  99%    0.06K    446  64  1784K kmalloc-64
 21624  21624 100%    0.12K    636  34  2544K kernfs_node_cache
 20400  20400 100%    0.05K    240  85   960K shared_policy_node
 16276  15989  98%    0.58K   1252  13     10016K inode_cache
 10914  10914 100%    0.04K    107 102   428K selinux_inode_security
  7776   7776 100%    0.21K    432  18  1728K vm_area_struct
  7232   3921  54%    0.12K    226  32   904K kmalloc-128
  5376   5376 100%    0.02K     21 256        84K kmalloc-16
  5376   5376 100%    0.03K     42 128   168K kmalloc-32
  5120   5120 100%    0.01K     10 512        40K kmalloc-8
  4344   4306  99%    0.66K    362  12  2896K proc_inode_cache
  4096   4096 100%    0.03K     32 128   128K jbd2_revoke_record_s
  3822   3822 100%    0.09K     91  42   364K kmalloc-96
  3417   3217  94%    0.08K     67  51   268K anon_vma
  3344   3344 100%    0.25K    209  16   836K kmalloc-256
  3136   3136 100%    0.06K     49  64   196K ext4_free_data
  2190   2190 100%    0.05K     30  73   120K avc_xperms_node
  2112   2112 100%    1.00K    132  16  2112K kmalloc-1024

• OBJS：由于Slab是按照object管理的，這里是對(duì)象數(shù)量
• ACTIVE：當(dāng)前活躍的objects數(shù)量
• USE：緩存的利用率
• OBJ SIZE：object的size的大小
• SLABS：Slab的個(gè)數(shù)
• OBJ/SLAB：每個(gè)Slab中object個(gè)數(shù)
• CACHE SIZE：緩存大小，這里是不精確值，可以忽略
• NAME：分配Slab的名字

我們可以從以上的信息中判斷那些內(nèi)核模塊內(nèi)存分配較多(比如OBJ SIZE過(guò)大)，進(jìn)而分析模塊的性能瓶頸。

3、方法論

以下是我參照USE方法論整理排查性能度量指標(biāo)流程，其中最大挑戰(zhàn)點(diǎn)在于如何發(fā)現(xiàn)子模塊中的問題并且分析問題?后續(xù)可以單獨(dú)寫一篇分析。

方法論

第二部分：系統(tǒng)層優(yōu)化

1、CPU

(1)緩存

#define N 2048

long timecost(clock_t t1, clock_t t2)
{
 long elapsed = ((double)t2 - t1) / CLOCKS_PER_SEC * 1000;
 return elapsed;
}

int main(int argc, char **argv)
{
 char arr[N][N];

 {
  clock_t start, end;
  start = clock();
  for (int i = 0; i < N; i++)
  {
   for (int j = 0; j < N; j++)
   {
    arr[i][j] = 0;
   }
  }
  end = clock();
  cout << "timecost: " << timecost(start, end) << endl;
 }
 {
  clock_t start, end;
  start = clock();
  for (int i = 0; i < N; i++)
  {
   for (int j = 0; j < N; j++)
   {
    arr[j][i] = 0;
   }
  }
  end = clock();
  cout << "timecost: " << timecost(start, end) << endl;
 }
}

先來(lái)看一下上面一段代碼，有兩個(gè)timecost輸出，大家覺得哪個(gè)性能更高呢?運(yùn)行輸出：

timecost: 11
timecost: 67

可見第一段代碼性能比第二段代碼性能高6倍，之前了解過(guò)CPU緩存的應(yīng)該都知道其中的原理!先看看這張圖：

性能

CPU分位多級(jí)緩存，每一級(jí)比上一級(jí)耗時(shí)都差幾倍，所以如果寫的代碼讀取數(shù)據(jù)能命令更高級(jí)緩存，那么性能自然就會(huì)提高，我們?cè)倏创a訪問array[i][j]和array[j][i ]的差異，array[i][j]是順序訪問，CPU讀取數(shù)據(jù)時(shí)，后面的元素已經(jīng)載入緩存中了，而array[j][i]是間隔訪問，可能每次都不能命中緩存，既然明白了緩存的作用，那如何判斷我們代碼是否由于緩存未命中而損失性能呢?使用工具perf，執(zhí)行 perf stat -e cache-references -e cache-misses ./a.out，輸出如下：

[root@VM-0-11-centos ~]# perf stat -e cache-references -e cache-misses ./a.out
// 第一段代碼
Performance counter stats for './a.out':

   6,115,254      cache-references
      13,450      cache-misses

// 第二段代碼
Performance counter stats for './a.out':

     913,732      cache-references
      17,954      cache-misses

因此，遇到這種遍歷訪問數(shù)組的情況時(shí)，按照內(nèi)存布局順序訪問將會(huì)帶來(lái)很大的性能提升。

(2)分支預(yù)測(cè)

#define N 128 * 1024 * 10

int main(int argc, char **argv)
{
    ofstream ofs;
    unsigned char arr[N];
    for (long i = 0; i < N; i++)
        arr[i] = rand() % 256;
    ofs.open("rand", ios::out | ios::binary);
    ofs.write((const char*)arr, N);
    ofs.close();
    sort(arr,arr+N);
    ofs.open("sort", ios::out | ios::binary);
    ofs.write((const char*)arr, N);
    ofs.close();

    {
        unsigned char arr[N];
        ifstream ifs;
  ifs.open("rand");
  ifs.read((char *)arr, N);
        clock_t start, end;
        start = clock();
        for (long i = 0; i < N; i++)
        {
            if (arr[i] < 128)
                arr[i] = 0;
        }
        end = clock();
        cout << "timecost: " << timecost(start, end) << endl;
    }
    {
        unsigned char arr[N];
        ifstream ifs;
        ifs.open("sort");
  ifs.read((char *)arr, N);
        clock_t start, end;
        start = clock();
        for (long i = 0; i < N; i++)
        {
            if (arr[i] < 128)
                arr[i] = 0;
        }
        end = clock();
        cout << "timecost: " << timecost(start, end) << endl;
    }
}

以上代碼做了兩個(gè)操作，：一是循環(huán)遍歷數(shù)組，判斷每個(gè)數(shù)字是否小于128，如果小于則把元素的值置為0;二是將數(shù)組排序。那么，先排序再遍歷速度快，還是先遍歷再排序速度快呢?其輸出結(jié)果：

timecost: 11
timecost: 3

從耗時(shí)可以看出排序后的數(shù)據(jù)性能要比未排序的性能高3倍，為什么?我們可以通過(guò)perf stat -e branch-loads,branch-load-misses ./a.out獲得輸出()：

// 第一段代碼
Performance counter stats for './a.out':

    263,372,189      branch-loads
     89,137,210      branch-load-misses

// 第二段代碼
Performance counter stats for './a.out':

    261,134,898      branch-loads
        137,210      branch-load-misses

可見分支預(yù)測(cè)對(duì)于性能提升有很大的影響，如果我們遇到類似的問題，可以通過(guò)優(yōu)化代碼提升指令緩存的命中率。

(3)多核

從CPU的緩存架構(gòu)圖可以看出，多核的CPU的L1，L2緩存是每顆核心獨(dú)享的，如果啟動(dòng)某個(gè)線程，根據(jù)調(diào)度時(shí)間片，可能線程在某個(gè)時(shí)刻運(yùn)行的核心1上，下一個(gè)調(diào)度時(shí)間片可能就在核心2上，這樣L1，L2緩存存在不命中的問題，但是如果我們能讓線程或者進(jìn)程獨(dú)立的跑在一個(gè)核心上，這樣就不需要將緩存換入緩出，理論上就可以提升性能，在Linux系統(tǒng)中的確提供了這種能力，通過(guò)sched_setaffinity可以綁定CPU核心，然后perf查看cpu-migrations的CPU遷移次數(shù)發(fā)現(xiàn)會(huì)減少，這里就不展開代碼了，有興趣的可以研究一下Nginx的worker_cpu_affinity配置，設(shè)置Nginx進(jìn)程與CPU進(jìn)行綁定的。

(4)向量化優(yōu)化(SIMD)

SIMD全稱single-instruction multiple-data(單指令多數(shù)據(jù))，在傳統(tǒng)的計(jì)算機(jī)架構(gòu)中，CPU一次只能處理一個(gè)數(shù)據(jù)元素，但是，許多任務(wù)涉及對(duì)大量數(shù)據(jù)執(zhí)行相同的操作，例如對(duì)數(shù)組中的所有元素進(jìn)行加法、乘法或邏輯操作等，SIMD編程通過(guò)向CPU提供專門的指令集，使得CPU能夠同時(shí)對(duì)多個(gè)數(shù)據(jù)元素執(zhí)行相同的操作，這種處理方式特別適合涉及向量、矩陣、圖像、音頻和視頻等數(shù)據(jù)的計(jì)算，使用樣例如下：

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <emmintrin.h>
#define MAX 200000
#define COUNT 100

void mul_test1(float *buf)
{
    for (int i = 0; i < MAX; ++i)
    {
        buf[i] = buf[i] * buf[i];
    }
}

void mul_test2(float *buf)
{
    for (int i = 0; i < MAX; i += 4)
    {
        _mm_storeu_ps(buf + i, _mm_mul_ps(_mm_loadu_ps(buf + i), _mm_loadu_ps(buf + i)));
    }
}

int main()
{
    float buf[MAX];
    for (int i = 0; i < MAX; ++i)
    {
        buf[i] = (float)(rand() % 1000);
    }

    {
        clock_t start, end;
        float duration;
        for (int i = 0; i < COUNT; ++i)
        {
            start = clock();
            mul_test1(buf);
            end = clock();
            duration += ((double)(end - start)) / CLOCKS_PER_SEC;
        }
        printf("costtime =%.3f\n", duration * 1000 / COUNT);
    }
    {
        clock_t start, end;
        float duration;
        for (int i = 0; i < COUNT; ++i)
        {
            start = clock();
            mul_test2(buf);
            end = clock();
            duration += ((double)(end - start)) / CLOCKS_PER_SEC;
        }
        printf("costtime =%.3f\n", duration * 1000 / COUNT);
    }
    return 0;
}

從輸出來(lái)看，SIMD在性能上比通用寫法要快很多，如下(這里編譯時(shí)關(guān)閉優(yōu)化選項(xiàng)g++ O1/O2/O3等，防止編譯器優(yōu)化可以對(duì)比出性能)：

costtime =0.513
costtime =0.274

(5)PGO和LTO等編譯器優(yōu)化

通常在代碼編譯期間，編譯器會(huì)做優(yōu)化有很多，除了gcc通過(guò)-O1 -O2 -O3，內(nèi)聯(lián)，尾遞歸等優(yōu)化外，現(xiàn)在了解比較多的是PGO和LTO：

• PGO(Profile-guided optimization)通常也叫做FDO(Feedback-directed optimization)，它是一種編譯優(yōu)化技術(shù)，它的原理是編譯器使用程序的運(yùn)行時(shí)profiling信息，生成更高質(zhì)量的代碼，從而提高程序的性能。
• LTO也叫鏈接期優(yōu)化，它相對(duì)于編譯期優(yōu)化的最大優(yōu)勢(shì)在于，在鏈接期，編譯器可以把整個(gè)程序放在一起看，以全局視角進(jìn)行優(yōu)化，達(dá)到更好的效果。

PGO優(yōu)化樣例：

#include <time.h>
#include <iostream>
#include <unistd.h>
#include <stdlib.h>

using namespace std;

long m = 502000000;
char arr[4] = {'1', '2', '3', 0};

long timecost(clock_t t1, clock_t t2)
{
    long elapsed = ((double)t2 - t1) / CLOCKS_PER_SEC * 1000;
    return elapsed;
}

long test()
{
    long sum = 0;
    int a = 0;
    for (a = 0; a < m; ++a)
    {
        sum += atoi(arr + (a % 2));
    }
    return sum;
}
int main(int argc, const char *argv[])
{
    clock_t start, end;
    start = clock();
    long sum = test();
    end = clock();
    cout << "sum: " << sum << ", timecost: " << timecost(start, end) << endl;
    return 0;
}

// 執(zhí)行如下命令：
g++ test5.cc -O2 -o origin
g++ test5.cc -O2 -fprofile-generate -o trace
./trace
g++ test5.cc -O2 -fprofile-use -o optimized 
./origin
./optimized

// 輸出結(jié)果：
[root@VM-0-11-centos ~]# ./trace
sum: 36646000000, timecost: 4710
[root@VM-0-11-centos ~]# g++ test5.cc -O2 -fprofile-use -o optimized
[root@VM-0-11-centos ~]# ./optimized
sum: 36646000000, timecost: 4670
[root@VM-0-11-centos ~]# ./origin
sum: 36646000000, timecost: 4710

從輸出的結(jié)果看提升一小部分性能，如果程序更加復(fù)雜，性能提升會(huì)更多，如果有興趣也可以了解關(guān)于微軟的團(tuán)隊(duì)使用Profile Guided Optimization(PGO)和Link-time Optimization(LTO)來(lái)優(yōu)化Linux內(nèi)核和Redis提升性能。

2、內(nèi)存

(1)內(nèi)存池

內(nèi)存池或者對(duì)象池是高性能編程一種重要的優(yōu)化方式，假設(shè)在實(shí)際代碼開發(fā)過(guò)程中，需要頻繁申請(qǐng)和釋放內(nèi)存4個(gè)字節(jié)的內(nèi)存，與其把這4字節(jié)釋放給操作系統(tǒng)，不如先緩存著放進(jìn)內(nèi)存池里，仍然當(dāng)作用戶態(tài)內(nèi)存留下來(lái)，進(jìn)程再次申請(qǐng)4字節(jié)內(nèi)存時(shí)就可以直接復(fù)用，這樣速度快了很多，其中ptmalloc，tcmalloc和jemalloc庫(kù)都是通過(guò)類似方式實(shí)現(xiàn)，這里為了快速了解，我們直接tcmalloc為例剖析。

tcmalloc

• Front-end：負(fù)責(zé)提供快速分配和重分配內(nèi)存給應(yīng)用，由Per-thread cache和Per-CPU cache兩部分組成，這里是ThreadCache，用于小對(duì)象分配，線程本地緩存，每個(gè)線程獨(dú)立維護(hù)一個(gè)該對(duì)象，多線程在并發(fā)申請(qǐng)內(nèi)存時(shí)不會(huì)產(chǎn)生鎖競(jìng)爭(zhēng);
• Middle-end(中臺(tái))：負(fù)責(zé)給Front-end提供緩存，當(dāng)Front-end緩存內(nèi)存不夠用時(shí)，從Middle-end申請(qǐng)內(nèi)存，這里是CentralCache，全局cache，所有線程共享，當(dāng)thread cache空閑鏈表為空時(shí)，會(huì)批量從CentralCache中申請(qǐng)內(nèi)存，當(dāng)thread cache總內(nèi)存超過(guò)閾值，會(huì)進(jìn)行內(nèi)存垃圾回收，將空閑內(nèi)存返還給CentralCache;
• Back-end(后端)：負(fù)責(zé)從操作系統(tǒng)獲取內(nèi)存，并給Middle-end提供緩存使用，這里包括Page Heap(小/大對(duì)象)和系統(tǒng)內(nèi)存，其中Page Heap(小/大對(duì)象)是全局頁(yè)堆，所有線程共享，對(duì)于小對(duì)象，當(dāng)centralcache為空時(shí)，會(huì)從page heap中申請(qǐng)一個(gè)span，當(dāng)一個(gè)span完全空閑時(shí)，會(huì)將該span返還給page heap，對(duì)于大對(duì)象，直接從page heap中分配，用完直接返還給page heap。而系統(tǒng)內(nèi)存是在當(dāng)page cache內(nèi)存用光后，會(huì)通過(guò)sbrk、mmap等系統(tǒng)調(diào)用向OS申請(qǐng)內(nèi)存;

(2)一些場(chǎng)景下可以優(yōu)先使用棧

從以下代碼我們驗(yàn)證一下堆上和棧上分配內(nèi)存，看看性能對(duì)比(這里取出了編譯器優(yōu)化)：

void test_on_stack()
{
    int a = 10;
}

void test_on_heap()
{
    int *a = (int *)malloc(sizeof(int));
    *a = 10;
    free(a);
}

// 輸出如下：
timecost: 258
timecost: 6664

可見棧上分配內(nèi)存性能更高，為什么?這里主要是棧是編譯期提前分配好了，而且棧是順序訪問，再者棧的數(shù)據(jù)可以直接到寄存器映射，還有一個(gè)最大的優(yōu)勢(shì)是線程在棧是獨(dú)立的，訪問的數(shù)據(jù)是無(wú)需加鎖的，所以在實(shí)際寫代碼過(guò)程中，對(duì)于占用空間少且頻繁訪問的都可以通過(guò)棧上內(nèi)存分配來(lái)操作。順便說(shuō)以下，golang為了更好的性能，底層代碼中很多都是通過(guò)棧分配，當(dāng)分析非逃逸的變量，即使使用make分配內(nèi)存也是在棧上(具體可以讀讀golang的源碼)。

第三部分：鎖

多線程情況下，為了保證臨界區(qū)數(shù)據(jù)一致性，往往通過(guò)加鎖解決問題，包括互斥鎖，自旋鎖，樂觀鎖等等，當(dāng)然不同場(chǎng)景的方式不一樣，那下面我們來(lái)介紹幾種高性能情況下鎖的使用。

(1)互斥鎖與自旋鎖

互斥鎖：當(dāng)你無(wú)法判斷鎖住的代碼會(huì)執(zhí)行多久時(shí)，應(yīng)該首選互斥鎖，互斥鎖是一種獨(dú)占鎖，但是互斥鎖有對(duì)應(yīng)的問題是：內(nèi)核會(huì)不斷嘗試獲取鎖，如果獲取不到就會(huì)休眠，只有獲取到了才會(huì)執(zhí)行邏輯，這里要注意的是在線程獲取鎖失敗時(shí)，會(huì)增加兩次上下文切換的成本，從運(yùn)行中切換為休眠，以及鎖釋放時(shí)從休眠狀態(tài)切換為運(yùn)行中，這種頻繁的上下文切換和休眠在高并發(fā)服務(wù)無(wú)法容忍的行為;

自旋鎖：通常如果對(duì)于一些耗時(shí)很短的操作，可以嘗試使用自旋鎖，自旋鎖比互斥鎖快得多，因?yàn)樗ㄟ^(guò)CPU提供的CAS函數(shù)(全稱 Compare And Swap)，在用戶態(tài)代碼中完成加鎖與解鎖操作，比如while (!(CAS(lock, 0, args))) { ... }，CAS是原子操作，有三個(gè)參數(shù)(內(nèi)存位置V、預(yù)期原值A(chǔ)、新值B)，其中這段代碼如果lock==0則更新lock=args，否則繼續(xù)循環(huán)。但是自旋鎖會(huì)面臨ABA的問題(線程1讀到A值，但是線程2搶占將A改為B，再修改回A，然后線程1搶占就會(huì)認(rèn)為沒有修改，然后繼續(xù)執(zhí)行)，所以在為了追求高性能，同時(shí)也要考慮各個(gè)鎖的缺點(diǎn)，從而避免BUG;

讀寫鎖：如果業(yè)務(wù)場(chǎng)景能明確讀寫，可以選擇使用讀寫鎖，當(dāng)寫鎖未被鎖住時(shí)，讀鎖可以實(shí)現(xiàn)多線程并發(fā)，當(dāng)寫鎖鎖住后，讀鎖阻塞，所以讀寫鎖真正發(fā)揮優(yōu)勢(shì)的場(chǎng)景，必然是讀多寫少的場(chǎng)景，否則讀鎖將很難并發(fā)持有;

(2)樂觀鎖

什么是樂觀鎖?基于樂觀的情況，假設(shè)認(rèn)為數(shù)據(jù)一般情況下不會(huì)造成沖突，所以在數(shù)據(jù)進(jìn)行提交更新的時(shí)候，才會(huì)正式對(duì)數(shù)據(jù)的沖突與否進(jìn)行檢測(cè)。

樂觀鎖常用實(shí)現(xiàn)方式通過(guò)版本號(hào)，每個(gè)數(shù)據(jù)記錄都有一個(gè)對(duì)應(yīng)的版本號(hào)，事務(wù)在更新數(shù)據(jù)時(shí)，先讀取數(shù)據(jù)的當(dāng)前版本號(hào)，并在提交時(shí)檢查該版本號(hào)是否發(fā)生變化，如果沒有變化，說(shuō)明操作是安全的，可以提交，如果發(fā)生變化，就需要進(jìn)行回滾或重試操作。

從樂觀鎖的場(chǎng)景可以看出，對(duì)于讀多寫少的情況下，樂觀鎖是能減少?zèng)_突，提升性能。

(3)無(wú)鎖編程

為了高性能，我們前面提到減少上下文切換，減少臨界區(qū)沖突，其中鎖是最大的障礙之一，如果能通過(guò)無(wú)鎖編程，這樣能提升性能。

樂觀鎖是一種無(wú)鎖編程，上面已經(jīng)介紹了，通過(guò)版本號(hào)或者CAS減少?zèng)_突，能實(shí)現(xiàn)不加鎖;

線程局部變量，通過(guò)在GCC定義__thread變量，實(shí)現(xiàn)線程局部存儲(chǔ)，存取效率可以和全局變量相比，__thread變量每一個(gè)線程有一份獨(dú)立實(shí)體，各個(gè)線程的值互不干擾，某些場(chǎng)景下可以通過(guò)操作線程內(nèi)的局部變量后，統(tǒng)一同步到全局變量，實(shí)現(xiàn)不加鎖或者減少鎖;

臨界區(qū)Hash，之前在業(yè)務(wù)場(chǎng)景中遇到需要頻繁操作指定全局?jǐn)?shù)據(jù)，但是線程之前操作的數(shù)據(jù)卻在某個(gè)時(shí)刻是獨(dú)立，這種場(chǎng)景可以將臨界區(qū)的數(shù)據(jù)Hash到各個(gè)槽中，當(dāng)線程需要操作數(shù)據(jù)，可以先取槽的位置，然后到對(duì)應(yīng)的槽位上操作數(shù)據(jù)即可，這樣減少鎖鎖住的數(shù)據(jù)區(qū)域或者直接不加鎖可以提升性能;

將功能設(shè)計(jì)為單線程，如果是單線程程序自然就不需要加鎖了，比如Redis6.x之前的版本都是單線程處理，這樣數(shù)據(jù)結(jié)構(gòu)簡(jiǎn)單，避免上下文切換等。