我認為微核心相對於單核心上沒有明顯的技術優勢，微核心一般都宣稱有如下的技術優勢：

1. 各服務可以動態載入插入，使核心很小，減少記憶體。
2. 系統非常靈活。當執行一個應用程式時，只需把選定的系統服務載入到系統中即可。而修改了服務以後可以通過聯機進行測試；並不需要重新構建或者啟動一個新的核心，他們並不影響系統的執行。
3. 各服務地址空間獨立，不影響其它模組（如檔案系統服務呼叫記憶體管理服務的功能）。一個服務元件的失效並不會導致整個系統的崩潰，核心需要做的，僅僅是重新啟動這個元件，而不必影響其它的部分。
4. 可移植性強，各使用者臺服務與硬體無關。

1. 第一點，目前的Linux來說也有核心模組機制解決。當然還有不少功能是直接連結，沒有實現為核心模組形式，但是這是目前實現問題，今後如果必要都是可以實現的（比如VFS元件也可以搞一個ko出來載入進去）。對於這點，微核心並無明顯優勢了。
2. 第二點同上。
3. 第三點，有兩層含義。
  3.1 第一層是本服務實效的問題，這一點。我想Linux也是可以做到的，比如一個"功能"，如VFS，如果其內部全域性變數資料混亂了以後，有可能就會訪問非法地址，現在一般做法是BUG, OOPS或panic。這其實也是可以修改為不進行oops,panic的，而是把資源清理回收一下，把所有的資料重新初始化一下。這個與是否是核心模組無關，目前的核心也可以做。大概你會說，這樣其它的核心部分就會暫時不能使用這個服務了。但是微核心重啟這個元件時，也一樣不能使用該元件。因此微核心並無優勢。
  3.2 第二層含義是影響其它部分，其它部分有三種可能。
  a) 可能是呼叫本功能的使用者態執行緒，目前如果發生oops，該執行緒會被kill，其實也可以修改為不kill，而是取消它的資源。比如如果VFS功能實效，我就強制關閉所有檔案控制代碼，釋放資源如鎖等等。
  b) 二是影響其它的元件，一個比較常見的問題就是VFS如果發生程式碼錯誤有了野指標，修改了網路元件的全域性變數，因為核心的地址空間是所有程式碼共享的。這個問題，也不是沒有辦法解決。目前粗略想到的一個辦法是取消所有程序的核心地址空間共享模式。每個程序有獨立的核心地址空間，在這個空間內，每個核心元件就像一個使用者態程序的一個動態庫，你用的時候進行動態對映。比如你呼叫VFS的系統呼叫時，系統會幫你自動對映VFS程式碼段和資料段到你的核心空間；如果VFS訪問了記憶體管理的API，在呼叫這個元件間API的介面時，進行記憶體元件的對映，同時把VFS解除對映。當記憶體管理分配完記憶體時，再進行VFS對映，記憶體解除對映動作。這樣核心態執行時，在某一時刻只有一個元件存在地址對映，因此它要想非法訪問其它元件的地址必然會引起page fault。至於中斷，也是一樣，在某一時刻必然只會對映一段程式碼。當從中斷返回核心態時，只要恢復被打斷時刻的對映狀態即可。其實對映早就對映好了的，只不過是修改頁目錄項中"存在"的1位標誌而已，效能並不會受到多大的影響。當然這個對映和解除對映的動作，如果現在要全部加在核心中工作量是巨大的。但是如果有必要，我想是可以通過編譯時的插樁技巧來實現的。
  c) 三是核心，就是目前Linux比較嚴重的問題，一般都是oops,panic重啟。這點我前面說了，這個也只是實現的問題，只要3.1, 以及3.2.a), 3.2.b) 三點做好了，可以不用強制重啟核心。
4. 第四點比較牽強，所謂移植，無非就是對一些硬體驅動的修改，CPU體系結構部分的處理等。不管你的服務包括驅動執行在使用者態還是核心態，該修改的還是要修改。與巨集核心，微核心的設計沒有關係。

  綜述，第1，2，3個問題其實都是目前"實現"上的問題，只是因為目前Linux的可靠性，靈活性問題還沒有到非那樣做不可的地步，而並非Linux從設計上就不能那麼實現，因此並不是單核心還是微核心"設計"上的問題。微核心上宣稱的所謂的技術優勢，Linux上也一樣是可以實現的。沒有必要非要通過另外設計一套基於IPC的核心元件服務模型，把問題隱藏。