對于一個程式來說，幾乎所有的計算任務都不可能僅通過CPU的計算就可以完成，它至少要和記憶體打交道：讀取運算資料、寫入運算結果，

現代CPU的算力已經十分強大，相比之下存盤設備的IO讀寫速度卻發展的十分緩慢，通常情況下，記憶體每完成一次讀寫操作，CPU已經可以進行上百次的運算，為了填補兩者速度上的鴻溝，現代CPU不得不加入一層或多層讀寫速度接近于CPU處理速度的高速快取Cache，CPU會將計算需要的資料讀取到快取中，讓計算可以快速進行，當計算結束后，再將計算結果統一寫回到主存中，這樣CPU就不需要緩慢的等待記憶體讀寫了，

多級快取-填補記憶體讀寫速度與CPU計算速度的鴻溝

筆者畫了一個簡圖，大概表示現代CPU的快取架構，如下：

各級快取的讀寫速度如下：

越靠近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注解的支持，

尾巴

理解硬體設計對撰寫高性能程式是有必要的！！！