Linux高性能網絡編程十談 | 性能優化（CPU和內存）
上一篇文章講了高性能編程的工具，這一篇我們基于前面的一些知識點和工具來聊一下Linux下的性能優化(本知識點分為兩篇，當前主要介紹CPU和內存性能優化)。
第一部分：CPU和內存性能度量
系統調用
這張圖闡述一個應用程序需要經過這些模塊調用，對于性能每一部分都可能會有影響，那么我們先需要了解每個模塊需要怎么度量?
1、CPU度量
(1)CPU使用率
CPU使用率是最直觀描述當前服務狀態的情況，如果CPU使用率過高，則表示當前遇到了性能瓶頸，其中過高的這個具體值在線上一般是70%-90%之間，要么擴容服務，要么就排查性能問題。
查看性能工具有很多，最常用的是通過top -p <進程ID>或者通過查看線程top -H -p <進程ID>觀察，另外可以使用上一篇的工具：mpstat -P ALL 1 2。
(2)用戶進程消耗CPU
用戶進程消耗CPU是常見的情況，往往和業務代碼或者使用的庫相關，比如大量的循環，JSON解析大包等，在用戶代碼層有很多耗CPU的操作，都會表現CPU使用率異常，定位其問題可以通過以下方式：
- 先通過ps或者top查詢具體進程或者線程CPU消耗過高，然后查詢pidstat -p <進程ID>判斷%usr %system %guest占比情況，判斷是否為用戶態消耗
- 由于用戶態涉及用戶代碼，可以通過perf top查看具體調用函數或者查看查看日志分析;
(3)內核消耗CPU
消耗CPU不止用戶進程，還包括內核進程，系統調用等內核消耗CPU，可能的原因有大量的內存拷貝，鎖，大量的上下文切換等等，具體分析和上面類似：
- 先通過ps或者top查詢具體進程或者線程CPU消耗過高，然后查詢pidstat -p <進程ID>判斷%usr %system %guest占比情況，判斷是否為內核態消耗;
- 然后可以通過perf top或者strace查看系統調用情況，或者通過mpstat分析，總結中斷或者上下文切換頻率來判斷;
(4)CPU等待
CPU花費在等待上的時間，主要是看是否大量的IO導致，也可以通過top定位具體進程，然后跟蹤和分析該進程或者線程的網絡調用情況。
(5)Nice消耗CPU
描述的是花費的re-nicing進程上時間占比，主要是更改了進程的執行順序或者優先級。
(6)平均負載
平均負載是一個判斷系統快慢的重要原因，可能往往不是某個進程引起的，主要有兩個指標：
- 隊列中等待處理的進程數(TASK_RUNNING狀態進程)
- 等待不可中斷任務被完成的進程數(TASK_UNINTERRUPTIBLE狀態進程)
如果被阻塞，平均負載就會增加，可以通過uptime查看，往往負載增加這個時候需要優化代碼或者增加機器資源。
(7)運行進程
當前運行和已經在隊列中的進程數，往往進程過多會導致CPU調度繁忙，比如之前多進程的Apache Server，所以可以根據當前CPU的核數決定進程個數，一般繁忙情況下的進程不建議超過2倍CPU(當前空閑的進程也不宜過大，建議不超過10倍)。
(8)阻塞進程
阻塞進程是當前未達到執行條件的進程，和上面的CPU等待事件對應，一般是IO問題導致，比如寫文件數據過慢，或者socket讀寫數據未到達等等情況，如何分析呢?可以通過strace跟蹤系統調用分析。
(9)上下文切換
在系統上發生上下文切換的情況，也是判斷CPU負載的重要因素，大量的上下文切換可能和大量中斷或者鎖相關，上下文切換會導致CPU的緩存被刷新，數據需要從內存換入換出等。
排查方案是通過perf或者vmstat工具查詢，比如vmstat輸出(也可以通過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在內核態運行信息，包括in中斷次數，cs上下文切換次數。
(10)中斷
中斷包含硬中斷和軟中斷，硬中斷是外設處理過程中產生的，通過硬件控制器通知cpu的狀態變化，而軟中斷是通過模擬硬中斷的一種信號處理方式，中斷過多會導致CPU花費一些時間相應中斷，這里也會影響性能，如何排查?通過命令行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時02分15秒 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
10時02分20秒 all 0.70 0.00 0.80 0.50 0.00 0.00 0.00 0.00 0.00 98.00
10時02分20秒 0 0.60 0.00 0.80 0.20 0.00 0.00 0.00 0.00 0.00 98.40
10時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處理硬中斷的時間占比
- %soft：CPU處理軟中斷的時間占比
2、內存度量
(1)空閑內存
通過free我們能看到當前內存情況：
[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：物理內存總量
- used：已經使用的物理內存量
- free：尚未使用的物理內存量
- shared：被共享使用的物理內存量
- buff：被緩存的物理內存量
- cache：被緩存的硬盤文件的物理內存量
- available：剩余可用的物理內存量，包括free + buff + cache - 系統預留的緩沖區
- Swap total：交換空間總量
- Swap used：已經使用的交換空間量
- Swap free：尚未使用的交換空間量
從上面可以看出，free的內存越大越好，這樣有剩余足夠多的物理內存可以使用。
(2)Swap
Swap如上面說的是交換空間的內存數據，是linux為了釋放一部分物理內存將數據臨時保存在Swap空間中，通過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每秒增長很多大，表示內存上遇到了瓶頸，需要升級機器的內存或者優化代碼。
(3)Slab
在Linux中，伙伴系統是以頁為單位管理和分配內存，但是現實的需求卻以字節為單位，假如我們需要申請20Bytes，總不能分配一頁吧?那豈不是嚴重浪費內存。那么該如何分配呢?Slab分配器就應運而生了，專為小內存分配而生，Slab分配器分配內存以Byte為單位，但是Slab分配器并沒有脫離伙伴系統，而是基于伙伴系統分配的大內存進一步細分成小內存分配，其作用如下：
- 節省空間，減少內存碎片化，Slab對小對象進行分配，不用為每個小對象分配一頁
- 提高系統效率：當對象擁有者釋放一個對象后，SLAB的處理是僅僅標記對象為空閑，并不做多少處理，而又有申請者申請相應大小的對象時，Slab會優先分配最近釋放的對象
如果要排查Slab的詳細信息，可以通過slabtop或者cat /proc/slabinfo，輸出如下(執行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管理的，這里是對象數量
- ACTIVE：當前活躍的objects數量
- USE：緩存的利用率
- OBJ SIZE：object的size的大小
- SLABS：Slab的個數
- OBJ/SLAB：每個Slab中object個數
- CACHE SIZE：緩存大小，這里是不精確值，可以忽略
- NAME：分配Slab的名字
我們可以從以上的信息中判斷那些內核模塊內存分配較多(比如OBJ SIZE過大)，進而分析模塊的性能瓶頸。
3、方法論
以下是我參照USE方法論整理排查性能度量指標流程，其中最大挑戰點在于如何發現子模塊中的問題并且分析問題?后續可以單獨寫一篇分析。
方法論
第二部分：系統層優化
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;
}
}先來看一下上面一段代碼，有兩個timecost輸出，大家覺得哪個性能更高呢?運行輸出：
timecost: 11
timecost: 67可見第一段代碼性能比第二段代碼性能高6倍，之前了解過CPU緩存的應該都知道其中的原理!先看看這張圖：
性能
CPU分位多級緩存，每一級比上一級耗時都差幾倍，所以如果寫的代碼讀取數據能命令更高級緩存，那么性能自然就會提高，我們再看代碼訪問array[i][j]和array[j][i ]的差異，array[i][j]是順序訪問，CPU讀取數據時，后面的元素已經載入緩存中了，而array[j][i]是間隔訪問，可能每次都不能命中緩存，既然明白了緩存的作用，那如何判斷我們代碼是否由于緩存未命中而損失性能呢?使用工具perf，執行 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因此，遇到這種遍歷訪問數組的情況時，按照內存布局順序訪問將會帶來很大的性能提升。
(2)分支預測
#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;
}
}以上代碼做了兩個操作，：一是循環遍歷數組，判斷每個數字是否小于128，如果小于則把元素的值置為0;二是將數組排序。那么，先排序再遍歷速度快，還是先遍歷再排序速度快呢?其輸出結果：
timecost: 11
timecost: 3從耗時可以看出排序后的數據性能要比未排序的性能高3倍，為什么?我們可以通過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可見分支預測對于性能提升有很大的影響，如果我們遇到類似的問題，可以通過優化代碼提升指令緩存的命中率。
(3)多核
從CPU的緩存架構圖可以看出，多核的CPU的L1，L2緩存是每顆核心獨享的，如果啟動某個線程，根據調度時間片，可能線程在某個時刻運行的核心1上，下一個調度時間片可能就在核心2上，這樣L1，L2緩存存在不命中的問題，但是如果我們能讓線程或者進程獨立的跑在一個核心上，這樣就不需要將緩存換入緩出，理論上就可以提升性能，在Linux系統中的確提供了這種能力，通過sched_setaffinity可以綁定CPU核心，然后perf查看cpu-migrations的CPU遷移次數發現會減少，這里就不展開代碼了，有興趣的可以研究一下Nginx的worker_cpu_affinity配置，設置Nginx進程與CPU進行綁定的。
(4)向量化優化(SIMD)
SIMD全稱single-instruction multiple-data(單指令多數據)，在傳統的計算機架構中，CPU一次只能處理一個數據元素，但是，許多任務涉及對大量數據執行相同的操作，例如對數組中的所有元素進行加法、乘法或邏輯操作等，SIMD編程通過向CPU提供專門的指令集，使得CPU能夠同時對多個數據元素執行相同的操作，這種處理方式特別適合涉及向量、矩陣、圖像、音頻和視頻等數據的計算，使用樣例如下：
#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;
}從輸出來看，SIMD在性能上比通用寫法要快很多，如下(這里編譯時關閉優化選項g++ O1/O2/O3等，防止編譯器優化可以對比出性能)：
costtime =0.513
costtime =0.274(5)PGO和LTO等編譯器優化
通常在代碼編譯期間，編譯器會做優化有很多，除了gcc通過-O1 -O2 -O3，內聯，尾遞歸等優化外，現在了解比較多的是PGO和LTO：
- PGO(Profile-guided optimization)通常也叫做FDO(Feedback-directed optimization)，它是一種編譯優化技術，它的原理是編譯器使用程序的運行時profiling信息，生成更高質量的代碼，從而提高程序的性能。
- LTO也叫鏈接期優化，它相對于編譯期優化的最大優勢在于，在鏈接期，編譯器可以把整個程序放在一起看，以全局視角進行優化，達到更好的效果。
PGO優化樣例：
#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;
}
// 執行如下命令：
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
// 輸出結果：
[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從輸出的結果看提升一小部分性能，如果程序更加復雜，性能提升會更多，如果有興趣也可以了解關于微軟的團隊使用Profile Guided Optimization(PGO)和Link-time Optimization(LTO)來優化Linux內核和Redis提升性能。
2、內存
(1)內存池
內存池或者對象池是高性能編程一種重要的優化方式，假設在實際代碼開發過程中，需要頻繁申請和釋放內存4個字節的內存，與其把這4字節釋放給操作系統，不如先緩存著放進內存池里，仍然當作用戶態內存留下來，進程再次申請4字節內存時就可以直接復用，這樣速度快了很多，其中ptmalloc，tcmalloc和jemalloc庫都是通過類似方式實現，這里為了快速了解，我們直接tcmalloc為例剖析。
tcmalloc
- Front-end：負責提供快速分配和重分配內存給應用，由Per-thread cache和Per-CPU cache兩部分組成，這里是ThreadCache，用于小對象分配，線程本地緩存，每個線程獨立維護一個該對象，多線程在并發申請內存時不會產生鎖競爭;
- Middle-end(中臺)：負責給Front-end提供緩存，當Front-end緩存內存不夠用時，從Middle-end申請內存，這里是CentralCache，全局cache，所有線程共享，當thread cache空閑鏈表為空時，會批量從CentralCache中申請內存，當thread cache總內存超過閾值，會進行內存垃圾回收，將空閑內存返還給CentralCache;
- Back-end(后端)：負責從操作系統獲取內存，并給Middle-end提供緩存使用，這里包括Page Heap(小/大對象)和系統內存，其中Page Heap(小/大對象)是全局頁堆，所有線程共享，對于小對象，當centralcache為空時，會從page heap中申請一個span，當一個span完全空閑時，會將該span返還給page heap，對于大對象，直接從page heap中分配，用完直接返還給page heap。而系統內存是在當page cache內存用光后，會通過sbrk、mmap等系統調用向OS申請內存;
(2)一些場景下可以優先使用棧
從以下代碼我們驗證一下堆上和棧上分配內存，看看性能對比(這里取出了編譯器優化)：
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可見棧上分配內存性能更高，為什么?這里主要是棧是編譯期提前分配好了，而且棧是順序訪問，再者棧的數據可以直接到寄存器映射，還有一個最大的優勢是線程在棧是獨立的，訪問的數據是無需加鎖的，所以在實際寫代碼過程中，對于占用空間少且頻繁訪問的都可以通過棧上內存分配來操作。順便說以下，golang為了更好的性能，底層代碼中很多都是通過棧分配，當分析非逃逸的變量，即使使用make分配內存也是在棧上(具體可以讀讀golang的源碼)。
第三部分：鎖
多線程情況下，為了保證臨界區數據一致性，往往通過加鎖解決問題，包括互斥鎖，自旋鎖，樂觀鎖等等，當然不同場景的方式不一樣，那下面我們來介紹幾種高性能情況下鎖的使用。
(1)互斥鎖與自旋鎖
互斥鎖：當你無法判斷鎖住的代碼會執行多久時，應該首選互斥鎖，互斥鎖是一種獨占鎖，但是互斥鎖有對應的問題是：內核會不斷嘗試獲取鎖，如果獲取不到就會休眠，只有獲取到了才會執行邏輯，這里要注意的是在線程獲取鎖失敗時，會增加兩次上下文切換的成本，從運行中切換為休眠，以及鎖釋放時從休眠狀態切換為運行中，這種頻繁的上下文切換和休眠在高并發服務無法容忍的行為;
自旋鎖：通常如果對于一些耗時很短的操作，可以嘗試使用自旋鎖，自旋鎖比互斥鎖快得多，因為它通過CPU提供的CAS函數(全稱 Compare And Swap)，在用戶態代碼中完成加鎖與解鎖操作，比如while (!(CAS(lock, 0, args))) { ... }，CAS是原子操作，有三個參數(內存位置V、預期原值A、新值B)，其中這段代碼如果lock==0則更新lock=args，否則繼續循環。但是自旋鎖會面臨ABA的問題(線程1讀到A值，但是線程2搶占將A改為B，再修改回A，然后線程1搶占就會認為沒有修改，然后繼續執行)，所以在為了追求高性能，同時也要考慮各個鎖的缺點，從而避免BUG;
讀寫鎖：如果業務場景能明確讀寫，可以選擇使用讀寫鎖，當寫鎖未被鎖住時，讀鎖可以實現多線程并發，當寫鎖鎖住后，讀鎖阻塞，所以讀寫鎖真正發揮優勢的場景，必然是讀多寫少的場景，否則讀鎖將很難并發持有;
(2)樂觀鎖
什么是樂觀鎖?基于樂觀的情況，假設認為數據一般情況下不會造成沖突，所以在數據進行提交更新的時候，才會正式對數據的沖突與否進行檢測。
樂觀鎖常用實現方式通過版本號，每個數據記錄都有一個對應的版本號，事務在更新數據時，先讀取數據的當前版本號，并在提交時檢查該版本號是否發生變化，如果沒有變化，說明操作是安全的，可以提交，如果發生變化，就需要進行回滾或重試操作。
從樂觀鎖的場景可以看出，對于讀多寫少的情況下，樂觀鎖是能減少沖突，提升性能。
(3)無鎖編程
為了高性能，我們前面提到減少上下文切換，減少臨界區沖突，其中鎖是最大的障礙之一，如果能通過無鎖編程，這樣能提升性能。
樂觀鎖是一種無鎖編程，上面已經介紹了，通過版本號或者CAS減少沖突，能實現不加鎖;
線程局部變量，通過在GCC定義__thread變量，實現線程局部存儲，存取效率可以和全局變量相比，__thread變量每一個線程有一份獨立實體，各個線程的值互不干擾，某些場景下可以通過操作線程內的局部變量后，統一同步到全局變量，實現不加鎖或者減少鎖;
臨界區Hash，之前在業務場景中遇到需要頻繁操作指定全局數據，但是線程之前操作的數據卻在某個時刻是獨立，這種場景可以將臨界區的數據Hash到各個槽中，當線程需要操作數據，可以先取槽的位置，然后到對應的槽位上操作數據即可，這樣減少鎖鎖住的數據區域或者直接不加鎖可以提升性能;
將功能設計為單線程，如果是單線程程序自然就不需要加鎖了，比如Redis6.x之前的版本都是單線程處理，這樣數據結構簡單，避免上下文切換等。
