先拋一道阿里面試題給大家熱熱身，引出今天的主角-缺頁異常Page Fault。
談談對缺頁異常Page Fault的理解。
話不多說，集合上車。
2. 術語約定
-
VA：Virtual Address 虛擬地址
-
PA：Physical Address 物理地址
-
MMU：Memory Manage Unit 內存管理單元
-
TLB：Translation Lookaside Buffer 旁路快表緩存/地址變換高速緩存
-
PTE：Page Table Entry 分頁表項
3. 內存的惰性分配
以32位的Linux系統爲例，每個進程獨立擁有4GB的虛擬地址空間，根據局部性原理沒有必要也不可能爲每個進程分配4GB的物理地址空間。
64位系統也是一樣的道理，只不過空間尋址範圍大了很多很多倍，進程的虛擬地址空間會分爲幾個部分：
實際上只有程序運行時用到了纔去內存中尋找虛擬地址對應的頁幀，找不到纔可能進行分配，這就是內存的惰性(延時)分配機制。
對於一個運行中的進程來說，不是所有的虛擬地址在物理內存中都有對應的頁，如圖展示了部分虛擬地址存在對應物理頁的情況：
虛擬地址空間根據固定大小一般是4KB進行劃分，物理內存可以設置不同的頁面大小，通常物理頁大小和虛擬頁大小是一樣的，本文按照物理頁4KB大小展開。
經過前面的分析，我們將面臨一個問題：如何將虛擬地址準確快速地映射到物理頁呢？
>>>高能預警 敲黑板 本段小結<<<
1. Linux的虛擬地址空間就是空頭支票，看着很大但是實際對應的物理空間只有很少的一部分。2.內存的惰性分配是個有效的機制，可以保證內存利用率和服務器利用率，是資源合理配置的方法。
3.大量的虛擬地址到物理地址的快速準確地查詢轉換是一個難題。
4. CPU如果獲取內存中的數據
CPU並不直接和物理內存打交道，而是把地址轉換的活外包給了MMU，MMU是一種硬件電路，其速度很快，主要工作是進行內存管理，地址轉換隻是它承接的業務之一。
一起看看MMU是如何搞定地址轉換的。
4.1 MMU和Page Table
每個進程都會有自己的頁表Page Table，頁表存儲了進程中虛擬地址到物理地址的映射關係，所以就相當於一張地圖，MMU收到CPU的虛擬地址之後開始查詢頁表，確定是否存在映射以及讀寫權限是否正常，如圖：
對於4GB的虛擬地址且大小爲4KB頁，一級頁表將有2^20個表項，頁表佔有連續內存並且存儲空間大，多級頁表可以有效降低頁表的存儲空間以及內存連續性要求，但是多級頁表同時也帶來了查詢效率問題。
我們以2級頁表爲例，MMU要先進行兩次頁表查詢確定物理地址，在確認了權限等問題後，MMU再將這個物理地址發送到總線，內存收到之後開始讀取對應地址的數據並返回。
MMU在2級頁表的情況下進行了2次檢索和1次讀寫，那麼當頁表變爲N級時，就變成了N次檢索+1次讀寫。
可見，頁表級數越多查詢的步驟越多，對於CPU來說等待時間越長，效率越低，這個問題還需要優化纔行。
>> 本段小結 敲黑板 劃重點 <<
1.頁表存在於進程的內存之中，MMU收到虛擬地址之後查詢Page Table來獲取物理地址。2.單級頁表對連續內存要求高，於是引入了多級頁表，但是多級頁表也是一把雙刃劍，在減少連續存儲要求且減少存儲空間的同時降低了查詢效率。
4.2 MMU和TLB的故事
MMU和TLB的故事就這樣開始了...
CPU覺得MMU幹活雖然賣力氣，但是效率有點低，不太想繼續外包給它了，這一下子把MMU急壞了。
MMU於是找來了一些精通統計的朋友，經過一番研究之後發現CPU用的數據經常是一小搓，但是每次MMU都還要重複之前的步驟來檢索，害，就知道埋頭幹活了，也得講究方式方法呀！
找到瓶頸之後，MMU引入了新武器，江湖人稱快表的TLB，別看TLB容量小，但是正式上崗之後幹活還真是不含糊。
當CPU給MMU傳新虛擬地址之後，MMU先去問TLB那邊有沒有，如果有就直接拿到物理地址發到總線給內存，齊活。
TLB容量比較小，難免發生Cache Miss，這時候MMU還有保底的老武器頁表 Page Table，在頁表中找到之後MMU除了把地址發到總線傳給內存，還把這條映射關係給到TLB，讓它記錄一下刷新緩存。
TLB容量不滿的時候就直接把新記錄存儲了，當滿了的時候就開啓了淘汰大法把舊記錄清除掉，來保存新記錄，彷佛完美解決了問題。
在TLB和Page Table加持之下，CPU感覺最近MMU比較給力了，就問MMU怎麼做到的？MMU就一五一十告訴了CPU。
CPU說是個不錯的路子，隨後說出了自己的建議：TLB還是有點小，緩存不命中也是經常發生的，要不要搞個大的，這樣存儲更多訪問更快？
MMU一臉苦笑說道大哥TLB很貴的，要不你給漲點外包費？話音未落，CPU就說漲工資是不可能了，這輩子都不可能了。
>>>高能預警 敲黑板 本段小結<<<
1. CPU要根據用戶進程提供的虛擬地址來獲取真實數據，但是它並不自己做而是交給了MMU。2. MMU也是個聰明的傢伙，集成了TLB來存儲CPU最近常用的頁表項來加速尋址，TLB找不到再去全量頁表尋址，可以認爲TLB是MMU的緩存。
3. TLB的容量畢竟有限，爲此必須依靠Page Table一起完成TLB Miss情況的查詢，並且更新到TLB建立新映射關係。
5.缺頁異常Page Fault大揭祕
設想CPU給MMU的虛擬地址在TLB和Page Table都沒有找到對應的物理頁幀或者權限不對，該怎麼辦呢？
沒錯，這就是缺頁異常Page Fault，它是一個由硬件中斷觸發的可以由軟件邏輯糾正的錯誤。
5.1 PageFault，它來了
假如目標內存頁在物理內存中沒有對應的頁幀或者存在但無對應權限，CPU 就無法獲取數據，這種情況下CPU就會報告一個缺頁錯誤。
由於CPU沒有數據就無法進行計算，CPU罷工了用戶進程也就出現了缺頁中斷，進程會從用戶態切換到內核態，並將缺頁中斷交給內核的 Page Fault Handler 處理。
缺頁異常並不可怕，只要CPU要的虛擬地址經過MMU的一番尋址之後沒有找到或者找到後無權限，就會出現缺頁異常，因此觸發異常後的處理流程將是重點內容。
5.2 缺頁錯誤的分類處理
缺頁中斷會交給PageFaultHandler處理，其根據缺頁中斷的不同類型會進行不同的處理：
-
Hard Page Fault
也被稱爲Major Page Fault，翻譯爲硬缺頁錯誤/主要缺頁錯誤，這時物理內存中沒有對應的頁幀，需要CPU打開磁盤設備讀取到物理內存中，再讓MMU建立VA和PA的映射。 -
Soft Page Fault
也被稱爲Minor Page Fault，翻譯爲軟缺頁錯誤/次要缺頁錯誤，這時物理內存中是存在對應頁幀的，只不過可能是其他進程調入的，發出缺頁異常的進程不知道而已，此時MMU只需要建立映射即可，無需從磁盤讀取寫入內存，一般出現在多進程共享內存區域。 -
Invalid Page Fault
翻譯爲無效缺頁錯誤，比如進程訪問的內存地址越界訪問，又比如對空指針解引用內核就會報segment fault錯誤中斷進程直接掛掉。
5.3 缺頁錯誤出現的原因
不同類型的Page Fault出現的原因也不一樣，常見的幾種原因包括：
-
非法操作訪問越界
這種情況產生的影響也是最大的，也是Coredump的重要來源，比如空指針解引用或者權限問題等都會出現缺頁錯誤。 -
使用malloc新申請內存
malloc機制是延時分配內存，當使用malloc申請內存時並未真實分配物理內存，等到真正開始使用malloc申請的物理內存時發現沒有才會啓動申請，期間就會出現Page Fault。 -
訪問數據被swap換出
物理內存是有限資源，當運行很多進程時並不是每個進程都活躍，對此OS會啓動內存頁面置換將長時間未使用的物理內存頁幀放到swap分區來騰空資源給其他進程，當存在於swap分區的頁面被訪問時就會觸發Page Fault從而再置換回物理內存。
>>> 敲黑板 劃重點 本段小結：<<<
觸發Page Fault的原因可能有很多，歸根到底也只有幾種大類：1. 如使用共享內存區域，沒有存儲VA->PA的映射但是存在物理頁幀的軟缺頁錯誤，在Page Table/TLB中建立映射關係即可。
2. 訪問的地址在物理內存中確實不存在，需要從磁盤/swap分區讀入才能使用，這種性能影響會比較大，因爲磁盤太慢了，儘量使用高性能的SSD來降低延時。
3. 訪問的地址內存非法，缺頁錯誤會升級觸發SIGSEGV信號結束進程，這種屬於可以導致進程掛掉的一種缺頁錯誤。
6.全文總結
本文粗淺地和大家一起學習了Page Fault的相關知識點，包括Linux虛擬地址和物理地址的關係、CPU獲取內存數據的過程、MMU和TLB&頁表的協同配合、缺頁異常產生的原因和分類處理。
本文並沒有對MMU的內部機制、內核態&用戶態缺頁異常、缺頁異常處理函數等內容進行展開，主要是因爲這部分內容相對晦澀，還得靠自己深入研究。
本文旨在把火點燃而不是把桶填滿，對於文中相關知識點，歡迎交流溝通學習。
感謝各位老鐵的傾情安排，下期再見！
作者：後端技術指南針
鏈接：https://juejin.im/post/5f0009f96fb9a07e9824c51c