大家好，我是你們的老朋友軒轅。
點進這篇文章的朋友，恭喜你們，又要收獲新知識了~
這又是一篇非常硬核的技術文，建議配合一瓶怡寶或營養快線食用，效果更好哦。
很多小伙伴在學操作系統的時候，學習到內存管理的部分時，都會接觸到分段內存管理、分頁內存管理。
但很多人學完以后一頭霧水：
到底現在用的是分段還是分頁？
段寄存器這個東西現在還在用嗎？
為什么在講到虛擬地址翻譯的時候，好像跟段又沒有關系了呢？
之所有有這個問題，是因為很多同學看的教程很多都是偏理論的或者是過時的，根本不給你講現代操作系統中實際的情況（關於這一點我已經吐槽很多次了）。
今天軒轅就帶大家把內存管理的這些疑問一次性弄清楚，分段還是分頁，別再傻傻分不清楚了！
Let's go!
在開始之前，我們還是先來簡單復習一下，操作系統書上講到的Intel x86 CPU架構下的分段式內存管理和分頁式內存管理。
分段式內存管理
早在16位的8086時代，CPU為了能尋址超過16位地址能表示的最大空間（64KB），引入了段寄存器。
通過將內存空間划分為若干個段，然后采用段基地址+段內偏移的方式訪問內存，這樣能訪問1MB的內存空間了！
那時候，段寄存器有4個，分別指向不同的段。
cs: 代碼段
ds: 數據段
ss: 棧段
es：擴展段
在那個時候，段寄存器中存放的是段基地址，注意，是一個地址。
在通過ip寄存器讀取指令的時候，實際上是cs:ip，通過sp寄存器訪問棧的時候，實際上是ss:sp。
我看到網絡上很多文章介紹分段式內存或者介紹段寄存器的時候就止步於此了，而事實上，進入32位時代后，情況已經發生了翻天覆地的變化，只講上面這一部分內容實際上會誤導很多人。
變化1：
在32位時代，段寄存器又增加了兩個：fs、gs，這兩個段寄存器有特殊用途。
變化2：
段寄存器里面存放的不再是段基地址，而是一個叫段選擇子的東西。注意，注意，一切的變化都從這里開始。
段寄存器是16位的寬度，原來這16位是個物理內存地址，但現在，它是這樣一個結構：
實際上，現在的段寄存器中存放的是一個號碼，什么號碼呢？是一個表格中表項的號碼，這個表，有可能是全局描述符表GDT，也有可能是局部描述符表LDT。
那到底是哪個表？是由段選擇子從低到高的第三位來決定的，如果這一位是0，則是GDT，否則就是LDT。
那這兩個表又是啥，表里面裝的又是什么，怎么來尋址呢？
這兩個表的表項叫做段描述符，描述了一個內存段的信息，比如段的基地址、最大長度、訪問屬性等等一系列信息，它長這個樣子：
CPU中單獨添置了兩個寄存器，用來指向這兩個表，分別是gdtr和ldtr。
在尋址的時候，CPU首先根據段寄存器中的號碼，通過gdtr或ldtr來到GDT/LDT中取出對應的段描述符，然后再取出這個段的基地址，最后再結合段內的偏移，完成內存尋址。
也就是說，在16位模式下，段寄存器中直接就是一個地址，相當於一個指針，而到了32位下，則變成了一個句柄，或者說二級指針了。
分頁式內存管理
相比分段式內存管理，可能大家對分頁式內存管理要熟悉的多。
操作系統將內存空間按照“頁”為單位划分了很多頁面，這個頁的大小默認是4KB（當然可以改的），各進程擁有虛擬的完整的地址空間，進程中使用到的頁面會映射到真實的物理內存上，程序中使用的地址是虛擬地址，CPU在運行時自動將其翻譯成真實的物理地址。
既然要翻譯，那就得有地方記錄虛擬地址和物理地址的映射關系，只有根據這個關系，才能完成翻譯。
這個映射關系，是通過頁表來完成的。
頁表是用來記錄虛擬內存頁面和物理內存頁面之間的映射關系的，每一個頁表項記錄一個頁面的映射關系。但進程的地址空間很大，這樣算下來需要的頁表項的數量也會非常多。而實際上進程地址空間中很多頁面都沒有真正使用，也就沒有映射關系，這樣是一種浪費。
為了解決這個問題，CPU引入了多級頁表的機制，在32位下一般是2級頁表，像下面這樣：
將虛擬地址划分了三段：頁目錄索引、頁表索引、頁內偏移。
線程切換時，如果同時發生了進程切換，CPU中的CR3寄存器將會加載當前進程的頁目錄地址。
在尋址的時候，通過CR3，一級一級按表索頁，最終找到對應的物理內存頁面，再結合頁面內的偏移值，實現最終的內存尋址。
現代操作系統實際情況
學完了這兩種內存管理方式，很多人就要懵了：
現在操作系統到底用的哪種方式？ 好像是分頁，但為什么段寄存器好像還是有，到底是怎么一回事？
先說結論，答案就是：分段+分頁相結合的內存管理方式
首先要明確一個前提，這一點非常非常重要：無論是分段還是分頁，這都是x86架構CPU的內存管理機制，這倆是同時存在的（保護模式下），並不是讓操作系統二選一！
既然是同時存在的，那為什么現在將內存地址翻譯時，都是講分頁，而很少談到分段呢？
這一切的一切，都是因為一個原因：操作系統通過巧妙的設置，‘屏蔽’了段的存在。
操作系統怎么做到這一點的，接下來我們就來分析一下，徹底弄清楚背后的貓膩！
段寄存器
讓我們從段寄存器出發，在Win7 32位系統上，使用調試器（我用的WinDbg）隨意調試一個程序，真的，隨意，記事本、瀏覽器、Word，你看上誰就調試誰。
在中斷的上下文中看一下，程序在執行時，段寄存器里面到底裝了啥？
來看下幾個主要的段寄存器的內容：
cs: 001b
ds: 0023
ss: 0023
es: 0023
PS: 可能不同版本的Windows上面的結果不一樣，但這不重要，不影響我們分析問題。
只有0x001b和0x0023兩個值，前面我們說了，這不是一個地址，而是一個段選擇子，按照段選擇子的格式展開來看一下這兩個值指向的是哪個段描述符：
十六進制：001b
二進制：0000000000011 0 11 - 段序號：3 - 表類型：GDT - 特權級：Ring3
十六進制：0023
二進制：0000000000100 0 11 - 段序號：4 - 表類型：GDT - 特權級：Ring3
也就是說，cs段指向的是GDT中的第3個表項，其他三個寄存器指向的是GDT中的第4個表項。
接下來，我們來看一下這個神秘的GDT里面的內容到底是什么？很多人學了內存管理，可能還從來沒看過真實的GDT里面到底是什么數據吧。
GDT是位於操作系統內核地址空間中的，在Windows上有兩種查看方式，一種是通過Windbg，一種是通過一些ARK工具，我這里選擇使用PChunter這個神器進行查看。
前面提到過，GDT中的表項是段描述符，這是一個比較復雜的數據格式，好在，這個神器對段描述符進行了解析，使用表格字段的方式進行了展示，讓我們看起來輕松多了。
廢話不多說了，來看一下這個神秘的GDT吧：
注意看第3個表項和第4個表項哦，看看它們的基地址，都是0x00000000。
再看它們的界限值，都是0x000FFFFF，注意看這個界限的單位，不是字節，而是Page——頁，把這個值乘以頁面的大小4KB，就是0xFFFFF000。也就說這個段的上限到了0xFFFFF000這個頁面，再把這一個頁面的大小加進去，就是0xFFFFFFFF了！
所以，重點來了！看到了嗎，GDT中的第3個和第4個表項所描述的這兩個段，它們的基地址都是0x00000000，整個段的大小都是0xFFFFFFFF，這意味着什么？這意味着整個進程的地址空間實際上就是一個段！
也就是說：進程的代碼段、數據段、棧段、擴展段這四個段全部重合了，而且是整個進程地址空間共計4GB成為了一個段。
說起來是分段，實際上等於沒分了，再加上段的基地址全部是0，那進行地址翻譯的時候，有沒有段都沒什么區別了。
總結一句話：操作系統這樣分段，實際上是相當於把段給架空了！
以上是Windows的情況，我們再來看一下Linux情況呢。
使用GDB隨意調試一個ELF32的可執行文件，使用info r命令查看一下寄存器情況：
段寄存器有0x23和0x2b兩種情況：
十六進制：0023
二進制：0000000000100 0 11 - 段序號：4 - 表類型：GDT - 特權級：Ring3
十六進制：002B
二進制：0000000000101 0 11 - 段序號：5 - 表類型：GDT - 特權級：Ring3
Linux下我沒有找到可以直接用什么命令或者工具查看GDT的方式（如果你知道記得一定告訴我哦），於是去源代碼中尋找答案：
看到了嗎，這兩項所描述的段和Windows一樣，基地址為0，大小為4GB。
Windows和Linux都選擇了通過這種方式架空了CPU的分段內存管理機制。
但需要說明一下的時，雖然兩個操作系統都是這種情況，但並不意味着段機制徹底沒用到，CPU的任務管理TSS還是需要用到，這一點大家知道就行了。
64位情況
看到操作系統們都不待見這個分段式內存管理，Intel似乎也感受到了這玩意確實很雞肋，於是到了64位平台，徹底把段寄存器給打入了冷宮！
在Intel的指令手冊中，關於64位下的段寄存器是這樣描述的：
不管你的段寄存器中指向的段基址是什么內容，都會被當成0來對待。
這一下，分段內存管理，徹底涼涼了···
總結
好了，最后來總結一下。
無論是分段還是分頁，這是CPU自身的機制，操作系統在管理內存時繞不過去，但通過巧妙的分段內存設計，相當於把分段的概念給屏蔽了，由此造成了我們平時在談論虛擬地址翻譯時，忘記了段的存在，但不代表它真的不存在。
CPU硬件層面的工作必須是結合分段+分頁的內存管理機制，操作系統是軟件繞不過去，所以采取了上面的方式應付CPU了事。
從16位到32位再到如今普遍的64位，不同的時代，分段管理的實際情況都不一樣，大家在學習操作系統的時候一定不要死記硬背，而要結合實際情況哦。
現在分段和分頁，你弄清楚了嗎？
覺得有收獲的話，幫忙給軒轅分享轉發支持一下啊~
