文章目錄
- 多級快取-填補記憶體讀寫速度與CPU計算速度的鴻溝
- 區域性原理與Cache Line
- 偽共享
- 對齊填充
- @Contended
- 備注
- 尾巴
對于一個程式來說，幾乎所有的計算任務都不可能僅通過CPU的計算就可以完成，它至少要和記憶體打交道：讀取運算資料、寫入運算結果，
現代CPU的算力已經十分強大，相比之下存盤設備的IO讀寫速度卻發展的十分緩慢，通常情況下，記憶體每完成一次讀寫操作，CPU已經可以進行上百次的運算，為了填補兩者速度上的鴻溝，現代CPU不得不加入一層或多層讀寫速度接近于CPU處理速度的高速快取Cache，CPU會將計算需要的資料讀取到快取中，讓計算可以快速進行，當計算結束后，再將計算結果統一寫回到主存中，這樣CPU就不需要緩慢的等待記憶體讀寫了，
多級快取-填補記憶體讀寫速度與CPU計算速度的鴻溝
筆者畫了一個簡圖，大概表示現代CPU的快取架構，如下：
各級快取的讀寫速度如下：
| 快取 | 時鐘周期(大約) | 時間(大約) |
|---|---|---|
| 主存 | - | 80ns |
| L3 | 40 | 15ns |
| L2 | 10 | 3ns |
| L1 | 3~4 | 1ns |
| 暫存器 | 1 | - |
越靠近CPU的快取讀寫速度越快，相應的 容量越小、且成本越高，
當CPU需要讀取資料時，首先從最近的快取開始找，找不到就逐層往上尋找，如果命中快取，就無需再從主存中去讀取，直接拿來計算，反之從主存中加載資料并依次寫入多級快取中，下次就可以直接從快取中讀資料了，
區域性原理與Cache Line
CPU訪問存盤器時，無論是存取指令還是存取資料，所訪問的存盤單元都趨于聚集在一個較小的連續區域中，
- 當我們需要從記憶體中讀取一個int變數i的值時，CPU真的只會僅僅將這個4位元組的i加載到快取嗎？
答案是：NO！！！
當我們去讀取一個4位元組的int變數時，計算機認為程式接下來很大概率會訪問相鄰的資料，于是會把相鄰的資料給一塊兒加載到快取中，下次再讀取時，就不用訪問主存了，直接從快取中讀取就可以了，減少了CPU訪問主存的次數，提高快取的命中率，
說白了，CPU讀取資料時，總是會一個塊一個塊的讀，哪怕你需要的僅僅是1個位元組的資料，這個【塊】就被稱為【Cache Line】，
不同的CPU，Cache Line大小是不一樣的，Intel的CPU大部分都是64位元組，
多級快取就是由若干個Cache Line組成的，CPU每次從主存中拉取資料時，會把相鄰的資料也存入同一個Cache Line，
如下測驗代碼，各自讀取一千萬次資料，Cache Line失效的耗時11ms，能很好的利用Cache Line特性的只需要3ms，
public class CacheLine {
static int length = 8 * 10000000;
static long[] arr = new long[length];
public static void main(String[] args) {
long temp;// 無特殊含義，讀取出來的資料賦值
// 1.每次讀取都跳8個，下次讀取的資料一定不在上次讀取的Cache Line中，快取全部未命中
long start = System.currentTimeMillis();
for (int i = 0; i < length; i += 8) {
temp = arr[i];
}
long end = System.currentTimeMillis();
System.out.println(end - start);// 11ms
// 2.順序讀取，Cache Line生效，只讀前8分之1的資料
start = System.currentTimeMillis();
for (int i = 0; i < length / 8; i++) {
temp = arr[i];
}
end = System.currentTimeMillis();
System.out.println(end - start);// 3ms
}
}
偽共享
當多個執行緒去同時讀寫共享變數時，由于快取一致性協議，只要Cache Line中任一資料失效，整個Cache Line就會被置為失效，這就會導致本來相互不影響的資料，由于被分配在同一個Cache Line中，雙方在寫資料時，導致對方的Cache Line不斷失效，無法利用Cache Line快取特性的現象就被稱為【偽共享】，
如下代碼，啟動兩個執行緒，分別修改共享變數a和b，由于a個b一共占用16位元組，可以被分配進同一個Cache Line中，本來互相不影響的兩個執行緒修改資料，但是由于a個b被分配到同一個Cache Line中，導致對方的Cache Line不斷失效，不斷的重新發起load指令重主存中重新加載資料，降低程式的性能，
public class FalseShare {
static volatile long a;
static volatile long b;
public static void main(String[] args) throws InterruptedException {
CountDownLatch cdl = new CountDownLatch(2);
long t1 = System.currentTimeMillis();
new Thread(()->{
for (long i = 0; i < 1_0000_0000L; i++) {
// 執行緒只改a
FalseShare.a = i;
}
cdl.countDown();
}).start();
new Thread(()->{
for (long i = 0; i < 1_0000_0000L; i++) {
// 執行緒只改b
FalseShare.b = i;
}
cdl.countDown();
}).start();
cdl.await();
long t2 = System.currentTimeMillis();
System.err.println(t2 - t1);
}
}
程式運行結果：耗時2782ms，
對齊填充
要想解決上面的偽共享問題也很簡單，既然一個Cache Line存放64位元組的資料，只要在a和b變數之間填充7個無意義的Long變數，占滿64位元組，這樣a和b就無法被分配進同一個Cache Line中，執行緒之間修改資料互不影響，就沒有上面的問題了，
解決方法如下：
程式運行結果：耗時752ms，
@Contended
Cache Line對齊其實是一種比較low的解決辦法，因為你無法判斷你寫的程式會被放到哪種CPU上運行，不同的CPU它的Cache Line大小是不一樣的，如果超過了64位元組，填充7個long變數就沒有效果了，還有沒有更好的解決辦法呢？？？
JDK8引入了一個新的注解@Contended，被它修飾的變數，會被存放到一個單獨的Cache Line中，不會和其他變數共享Cache Line，
修改后如下：
程式運行結果：耗時744ms，Cache Line是生效的，
備注
JDK8的老版本中@Contended默認是禁用的，需要手動開啟：
-XX:-RestrictContended，筆者的JDK版本為【1.8.0_191】，-XX:-RestrictContended引數已經沒有用了，默認都會開啟對@Contended注解的支持，
尾巴
理解硬體設計對撰寫高性能程式是有必要的！！！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/159908.html
標籤：其他
上一篇：演算法-二分法