上次說到緩存的桌面必須要為整個內存的圖書館劃定相應的空間存放對應的書本，而不是將這些從內存中取出來的數據隨意地擺放在桌面上，經過規劃后的緩存能夠更快地找到CPU內核需要的數據。

首先，緩存是暫時存儲CPU需要經常使用的數據。但CPU在運行過程中，執行的程序指令對于相應數據的指代都是以地址的形式，簡而言之，CPU只認地址。那你緩存中暫存的數據你也得同時標明該數據對應的內存地址是多少。這樣以后，CPU來找緩存要數據的時候，緩存才能通過對應的地址查找到CPU想要的數據。我們都知道一般的電腦地址是32或64位的，即地址線是32或64位。那好，如果我在一個32位計算機中知道一個32位的地址我就可以取出這個精確到1bit的數據。那么一般我們32位的CPU取一次數據也是32位，那么我們緩存中有必要為每個bit的數據都存一個32位的地址嗎？肯定沒必要，否則光是32位的地址就占用了整個緩存99%的空間。我們還用圖書館做比喻，上文討論的問題的實質就是圖書館里的書要有多厚。一本書里就寫一個字嗎？還是一本書就是一個書架的內容？

如果一本書就一個字，那么還得是32個字作為地址，那還存啥數據，緩存的桌面只夠存這些地址了。如果一本書就是一個書架呢？好家伙，原來需要32位的地址現在只要26位了（舉例子），因為書少了，地址位數也少了，有效數據的比例增大了！但是能無限增大嗎？肯定也不行，太大程序不一定有用到，還擠占別的程序的緩存空間。所以現在一般一本書即一個緩存行的大小是64字節，正好是DDR內存一次讀取的數據量，這就很恰好。

中間插一句，緩存對于CPU和程序員是透明的，即CPU和程序員看不到緩存的存在，他們能看到的只有CPU自身的幾個寄存器（指令集定義的）和內存，緩存的存儲和讀取行為是硬件自發的，CPU和程序員無法干涉（不排除一些奇葩硬件，比如某游戲機將緩存放到全局地址空間，可以經過游戲廠商特殊優化加快游戲速度。但這不是一個好辦法，特殊優化費程序員，不如改善緩存讓硬件更好地自行調度）。

綜上，緩存中的空間必須要進行分類規劃，不然緩存控制器找起數據來會很累。【假設數據隨機擺放，那么需要使用CAM存儲器同時對每個數據進行地址匹配，可想而知這需要許多比較器，才可以實現一個周期中完成匹配，并且電路面積和功耗感人（但不是沒有這種緩存，存在即合理）。】那么具體怎么分類呢？現在儲存在緩存行里的地址一共是26位（32位減去行內偏移6位），那么我們就要在這26位上做分類。

比如，可以和擁有五個窗口的某家KFC一樣，尾數為0、1的去一號窗口取餐，2、3、4去二號，以此類推。緩存也是一樣，尾數在緩存中體現為Index，緩存就依據此分組，Index的位數就取決于你有幾個窗口即緩存容量有多大。那么假設緩存容量是64*64字節即64個緩存行的大小，那么Index就是log2（64）=6位數字。

從內存到緩存的分類規則

那么如果CPU現在要某某地址的數據，緩存會將這個地址的Index截取下來在符合該分組的對應緩存行中查找，如果剩下的地址也對應上了，那么就是找到了，否則就往下一級緩存乃至內存中繼續查找。這樣就不需要非常多的比較器，電路的面積和功耗也就合理多了，缺點就是需要耗費兩個時鐘周期，先用MUX選取再比較。不過多周期任務可以用流水線來彌補功耗高的缺點。

緩存到內存之間的控制關系（部分看不懂沒關系）

那如果兩個數據塊都在同一個位置呢？比如最頂部？那么他們就會互相擠用緩存空間，造成乒乓效應。因此我們需要更高效的解決辦法。


審核編輯：劉清