摘要 · Summary
系統 · 技術報告Windows · Linux · macOS · Android
執行摘要 · 單頁綜覽
交換空間是回收公平性，不是緊急記憶體
五個平台，一套機制。匿名記憶體 — 程序配置的一切 — 是核心唯一無處安放便無法回收的頁面類型。因此停用交換空間並未消除記憶體壓力，只是把壓力全部轉嫁給頁面快取與程式碼，而它們接著會被反覆從磁碟重讀。如今各大平台的解法一致：先在記憶體中壓縮，唯有壓縮耗盡才寫入持久儲存。Windows 稱之為記憶體壓縮，macOS 稱為 compressor pager，Linux 與 Android 稱為 ZRAM — 但架構完全相同，且交換的代價始終是同一項：以運算週期換取容量。五者之間真正的差異其實很窄，只有三件事重要。
關鍵數據 壓縮與耐久
- ~40%頁面壓縮後佔比（Windows 10 時期數據）
- 3:1Linux ZRAM 典型壓縮比
- 2.4 PB耐久測試中最長壽消費級 SSD 的寫入量
- 16.4 yr600 TBW 硬碟每日寫入 100 GB 的理論壽命
真正重要的三個面向 其餘皆為細節
| 面向 | 它問的問題 | 為何決定設計 |
|---|---|---|
| 持久層 | 是否存在以儲存為後端的交換空間？ | 部分 Android 實作僅調整 ZRAM — 根本沒有可落盤的第二層。 |
| 休眠 | 該層能否承載休眠映像？ | 唯一的硬性功能分界：壓縮層開機即清空，永遠無法承載。 |
| 可調程度 | 暴露了多少調校機制？ | Windows 與 macOS 近乎全自動；Linux 開放參數；Android 僅提供一個滑桿。 |
全文結構 起 · 承 · 轉 · 合
| 段落 | 頁 | 內容 |
|---|---|---|
| 起 · 承 脈絡 | 2 | 各平台共同收斂的兩層架構逐項並列，以及交換空間為何仍有必要。 |
| 轉 轉折 | 3 | 設計的穩固處與吃緊處 — 包含哪些廠商說法經得起實測。 |
| 合 結論 | 4 | 頁面的實際去向、實際存在的調校參數，以及各平台的具體做法。 |
總結
停用交換空間並不能避免記憶體壓力下的磁碟 I/O — 只是把反覆置換從匿名頁面轉移到頁面快取與程式碼，通常更糟。
重新定位
長期偏深的交換使用量是容量訊號，而非調校問題。解法是加記憶體，不是加交換空間。
起承 · 脈絡 · 內容 1 / 3
起 — 兩層架構，五種名稱 各家共同收斂的形狀
第一層 · 位於記憶體
壓縮層
- Windows 記憶體壓縮 — Xpress-Huffman，存放於 System 程序內的壓縮儲存區。
- macOS compressor pager — WKdm；Apple 得以出貨較低記憶體配置的關鍵。
- Linux ZRAM／zswap — zstd、lzo 或 lz4，典型約 3:1。
- Android ZRAM — 永遠是第一道防線，早於任何儲存寫入。
第二層 · 位於儲存
持久層
- Windows
pagefile.sys；另有swapfile.sys，以單次 I/O 搬移暫停應用的整個工作集。 - Linux 分割區或檔案 — 功能等價；檔案以一層檔案系統對映換取彈性。
- macOS 自 Big Sur 起將動態 swapfile 置於專屬 APFS VM 卷宗。
- Android — 選用的 UFS swapfile；這才是廠商「擴充 RAM」的真實內容。
- Windows
逐平台對照 同一機制，不同暴露程度
| 技術 | 後端 | 休眠 | 壓縮 |
|---|---|---|---|
| Windows pagefile | NTFS 上的檔案 | 另存映像 | 是 — Xpress-Huffman |
| Windows swapfile | 檔案，僅限新式應用 | 否 | 是 — 每應用一區 |
| Linux 分割區 | 獨立分割區 | 是 | 否 — 可搭配 zswap |
| Linux 交換檔案 | 檔案系統上的檔案 | 是，需 offset | 否 — 可搭配 zswap |
| Linux ZRAM | 記憶體中的區塊裝置 | 永不 | 是 — 這就是重點 |
| macOS 動態交換 | APFS VM 卷宗 | 是 | 是 — WKdm |
| Android ZRAM | 記憶體中的區塊裝置 | 永不 | 是 — lz4／zstd |
| Android 擴充 RAM | UFS 上的 swapfile | 否 | 先經 ZRAM |
承 — 交換空間為何仍有必要 左文 · 右數據
檔案頁面可丟棄後再讀回；匿名頁面卻無處可去。沒有交換空間，它們就是不可回收的，核心只能改從頁面快取與程式碼中榨取所需的每一位元組。因此支持交換空間最有力的論點不是容量，而是對稱性：讓兩類頁面同等可回收，核心才能淘汰真正較冷的那一邊。這一背書屬制度層面而非修辭 — systemd-oomd 官方 man page 直接引用此論點，並指出應啟用交換空間，否則系統會更快進入 livelock，反而餓死原本要來救援的使用者空間終止程式。
- 2兩類頁面同等可回收
- 4.20+支援 PSI 的核心 — OOM 前即可見壓力
轉 · 轉折 · 內容 2 / 3
轉 — 穩固處與吃緊處 四個面向
| 面向 | 穩固 | 吃緊 |
|---|---|---|
| 休眠 | 實體分割區或檔案可承載映像 | 壓縮層開機即清空 — 永遠無法替代 |
| 快閃壽命 | 六顆消費級 SSD 全數超越標示，其中一顆達 2.4 PB | 低階 eMMC 與伺服器長期寫入仍需審慎 |
| 廠商說法 | 實測檔案系統即可定論 — 有些確實加了真實層級 | 「8GB＋8GB＝16GB」是行銷，不是算術 |
| 混用層級 | 各層單獨使用皆穩健 | ZRAM 與磁碟交換並用會引發 LRU 反轉 |
Android 滑桿的實際作為 以實測定論，而非讀說明
| 行為 | 移動滑桿時實際改變了什麼 | 代價 |
|---|---|---|
| 僅調整 ZRAM 目標 | 分割區與交換區皆無變化 — 只改變分配給壓縮層的記憶體量。 | 運算 |
| 真實儲存交換 | 資料分割區可用空間確實減少所要求的量，而 ZRAM 池不變。 | UFS 寫入 |
| 兩個名稱，一件事 | 排程與記憶體最佳化的行銷名稱並非交換空間；只有 GB 滑桿才是。 | 混淆 |
| 4GB 記憶體以下 | 確有助益 — 更多背景應用得以保活，而非被殺後重載。 | 值得 |
| 12GB 記憶體以上 | 日常幾乎用不到；評測普遍反映關閉後動畫更順。 | 掉幀 |
耐久疑慮，已有定論 左文 · 右數據
「交換空間會磨損硬碟」是最頑固的疑慮，而它大致已有答案。在最著名的長期實驗中，六顆消費級 SSD 被持續寫入至損壞：第一顆故障發生在 700 TB 之後，最後倖存者吸收了 2.4 PB — 每一顆都遠超其標示耐久值。廠商也明言標示數字代表保固終點，而非故障點。換算後更為具體：一顆 600 TBW 的硬碟即使每天寫入 100 GB，理論上仍可用十六年以上，而幾乎沒人寫得這麼多。仍需審慎的只有兩種情況 — 平價手機的低階 eMMC，以及長期高強度寫入的伺服器，後者應依每日寫入量而非容量來選型。
- 6 / 6超越標示壽命的硬碟數
- 2仍需審慎的情況
轉捩點 依時間排序
- 2015長期耐久實驗結束：受測消費級 SSD 全數超越標示壽命，第一顆直到 700 TB 後才故障。
- 2015Windows 10 在分頁活動與 pagefile 之間插入記憶體壓縮，寫入磁碟的頁面約減半。
- 2018回收公平性論點發表，將交換空間從緊急備援重新定位為常規機制。
- 2018PSI 進入核心，使使用者空間能在 OOM killer 介入之前依停頓時間行動。
- 2020macOS 將交換空間移至專屬隱藏 APFS 卷宗，與系統動態共享空間。
- 2020→主流發行版預設啟用 ZRAM，並刻意將其作為唯一交換裝置，以避免混用層級所引發的反轉。
- 2021→Android 廠商推出「擴充 RAM」選項 — 有的僅調整 ZRAM，有的確實寫入儲存。
合 · 結論 · 內容 3 / 3
合 — 一個頁面的去向 依序六步
- 01駐留位於記憶體
- 02壓縮仍在記憶體
- 03落盤寫入磁碟或 UFS
- 04壓力PSI 回報停頓
- 05提早處理使用者空間終止
- 06加記憶體真正的解法
實際存在的調校參數 Linux · 括號內為預設值
| 參數 | 作用 | 何時調整 |
|---|---|---|
| vm.swappiness (60) | 相對於回收頁面快取，核心換出匿名記憶體的積極程度。 | 當交換空間快於檔案系統（如 ZRAM）時，可調高於 100。 |
| vm.vfs_cache_pressure (100) | 相對於頁面快取，回收目錄與 inode 快取的積極程度。 | 少動。設為 0 會招來記憶體不足終止程式。 |
| vm.watermark_scale_factor (10) | 背景回收何時喚醒，以及喚醒後釋放多少。 | 在容易突發大量配置的機器上調高，以保留更多可用記憶體。 |
| Android LMKD 屬性 | 決定何時終止哪個程序的剩餘交換與反覆置換門檻。 | 僅限 root 且依機型而異 — 核心內建終止程式多年前已移除。 |
兩種姿態，而非五套做法 由誰決定 — 廠商，還是你
Windows · macOS
不要干預
- 壓縮與落盤已整合且全自動；沒有可調之處。
- 停用分頁檔會失去當機傾印並降低認可上限 — 不划算。
- 在 macOS 上停用交換空間等同弱化系統保護；正解是加記憶體。
- 看記憶體壓力指標，而非交換空間數字。
Linux · Android
刻意選擇
- 先決定層級 — 是否休眠 — 再決定大小。
- 寫入時複製檔案系統對交換檔案有實質限制；請遵循其專屬流程。
- 讓壓力監測搭配使用者空間終止程式，否則機器卡住前無人處理。
- 在手機上，把滑桿視為以幀率為代價的背景應用保活旋鈕。
建議 依平台
- Windows — 讓系統自動管理 pagefile。為省幾 GB 而停用會失去當機傾印並可能導致不穩；SSD 壽命並非實際考量。
- Linux — 只選一層，不要並用。桌機用 ZRAM（約記憶體一半、zstd）；需休眠則用不小於記憶體的實體分割區或檔案。切勿讓 ZRAM 與磁碟交換並存。
- Linux 伺服器 — 讓 PSI 搭配使用者空間 OOM 守護程式。否則核心終止程式只會在機器已卡住後才動作。
- Android — 4GB 開啟，12GB 關閉。儲存比記憶體慢上數個數量級，旗艦機開啟後的實測代價是掉幀。
最終落點
只需問三個問題：是否需要休眠、是否混用層級、交換深度是否在告訴你該加記憶體？其餘皆為細節。