局部性原理

程序在訪問數據時，都趨于聚集在一片連續的區域中，這被稱為局部性原理。

按時間和空間劃分為兩類：

時間局部性：如果一個數據正在被訪問，那么近期它很可能再次被訪問。 空間局部性：如果某一個位置的數據被訪問，那么這個問題附近的數據很可能被訪問。

針對局部性原理，CPU和操作系統都有具體的實現。

本文主要總結梳理CPU和操作系統的局部性原理在Java后端中的影響與意義。

CPU空間局部性

如下圖是Java的內存模型

我們知道CPU為提高從內存中讀數據的性能，有L1、L2、L3三個級別的高速緩存。

CPU利用局部性原理，在從內存讀取數據項到緩存時，將該內存附近的數據塊也一并讀取到緩存中，這一過程稱為預讀。

即讀取連續空間的內存要比內存隨機訪問的性能要高，這一點用Java程序可以證明。

public static void main(String[] args) {int[][] arr = new int[10000][10000];int sum = 0;long startTime = System.currentTimeMillis();for (int i = 0; i < arr.length; i++) { for (int j = 0; j < arr[0].length; j++) {sum += arr[i][j]; }}System.out.println('數組順序訪問耗時：' + (System.currentTimeMillis() - startTime) + 'ms');sum = 0;startTime = System.currentTimeMillis();for (int i = 0; i < arr.length; i++) { for (int j = 0; j < arr[0].length; j++) {sum += arr[j][i]; }}System.out.println('數組非順序訪問耗時：' + (System.currentTimeMillis() - startTime) + 'ms'); }

這是一段對二維數組循環讀取的代碼。

程序的上半部分是按數組的第二維開始順序讀取，即二維數組逐行按內存連續空間順序訪問。

下半部分則是按數組的第一維按列讀取，不是順序訪問。

分別經過10000*10000次的數組訪問后，其運行結果如下：

由此可見，對內存的順序訪問性能優于隨機訪問。

磁盤空間局部性

在Java日常開發中，很多的中間件都需要跟磁盤文件打交道，這些磁盤數據的高性能訪問也都依托于局部性原理，比如：

MySql的日志文件 MQ消息數據

我們知道MySql的數據最終都保存在磁盤中，為減少磁盤IO提高性能，InnoDB引擎底層依托BufferPoll+redo log機制來提高mySql讀寫性能（具體可參考MySql原理總結）。而針對redo log、undo log、binlog的讀寫避免不了磁盤IO，那么這里就利用操作系統的PageCache機制，對磁盤數據順序讀寫，使得磁盤IO的性能近乎于內存性能。

我們常說kafka和rocketMQ是高性能的消息中間件，其中一部分高性能就依托于對磁盤文件的順序讀寫。比如commit log的順序寫入，kafka中partition、rockerMQ中consumerQueue中消息的順序讀寫。同樣的也是利用操作系統的PageCache機制。

PageCache

頁緩存（PageCache)是OS對文件的緩存，用于加速對文件的讀寫。一般來說，程序對文件進行順序讀寫的速度幾乎接近于內存的讀寫速度，主要原因就是由于OS使用PageCache機制對讀寫訪問操作進行了性能優化，將一部分的內存用作PageCache。

對于數據的寫入，OS會先寫入至Cache內，隨后通過異步的方式由pdflush內核線程將Cache內的數據刷盤至物理磁盤上。

對于數據的讀取，如果一次讀取文件時出現未命中PageCache的情況，OS從物理磁盤上訪問讀取文件的同時，會順序對其他相鄰塊的數據文件進行預讀取。

而PageCache就是局部性原理的實現。

時間局部性

時間局部性可能在我們日常業務開發中體現得更明顯。

類似LRU緩存都是其具體實現。

另外CPU的指令重排序也貼點邊，比如對一個數據的訪問計算，優先將于這數據有關的指令排在一起處理。

參考

知乎：如何理解操作系統中的局部性原理 gitHub：RocketMQ設計文檔總結

到此這篇通過Java視角簡單談談局部性原理的文章就介紹到這了,更多相關Java局部性原理內容請搜索好吧啦網以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持好吧啦網！