事實
作業系統 · 效能工程 · 硬體 · 技術報告2026 年 8 月 11 日發布 · 記錄更新至 2026 年 9 月 3 日
執行摘要 · 單頁綜覽
交換空間是回收公平性，不是緊急記憶體
五個平台，一套機制——但有一個例外。匿名記憶體——程序配置的一切——是核心唯一無處安放便無法回收的頁面類型。因此停用交換空間並未消除記憶體壓力，只是把壓力全部轉嫁給頁面快取與可執行的程式碼，而它們接著會被反覆從磁碟重讀。如今 Windows、macOS 與 Android 的解法一致：先在記憶體中壓縮，唯有壓縮耗盡才寫入持久儲存。Windows 稱之為記憶體壓縮，macOS 稱為 compressor pager，Android 稱為 ZRAM——啟用 ZRAM 的桌面版 Linux 亦然。但 Red Hat Enterprise Linux 目前官方文件說明如何建立交換空間時，完全沒有壓縮這一步：只有分割區或檔案，別無其他。壓縮發生之處，代價始終是同一項：以運算週期換取容量。五者之間真正的差異其實很窄，只有三件事重要。
關鍵數據 壓縮與耐久
- ~40%頁面壓縮後佔比（Windows 10，2015 年）
- 2:1Linux 核心官方文件估算 zram 大小時所採用的壓縮比
- 2.4 PB2015 年 SSD 耐久測試中，最長壽硬碟吸收的寫入量
- 16.4 年600 TBW 硬碟每日寫入 100 GB 的理論壽命
紀錄與確認程度 官方文件優先，裝置實測殿後
| 確認程度 | 事項 | 如何查核 |
|---|---|---|
| 已確認 | Windows、macOS 與 Android 皆先在記憶體中壓縮閒置記憶體，才寫入持久儲存。 | 直接查閱 Microsoft、Apple 與 AOSP 目前各自的官方文件。 |
| 已確認 | Windows 的壓縮儲存區採用一般的 XPRESS 格式——並非 Windows 其他地方所用、附 Huffman 編碼的 XPRESS_HUFF 變體。 | Microsoft 官方 Compression API 參考文件明確將兩者列為不同格式；一份對照《Windows Internals》查核的核心程式碼分析，指出記憶體管理員實際採用哪一種。 |
| 已確認 | Btrfs 自核心 5.0 起支援 swapfile，但僅限單一裝置的檔案系統，且檔案本身不得壓縮、不得校驗。 | 直接查閱 Btrfs 專案官方文件。 |
| 已確認——例外 | Red Hat Enterprise Linux 目前官方指南說明建立交換空間時，只提到分割區或檔案——完全沒有壓縮這一步。 | 直接查閱；該章節共十三個小節，通篇未提及 zram 或 zswap。 |
| 已確認，因裝置而異 | 各廠牌「擴充 RAM」開關，哪些確實動用儲存空間、哪些僅調整 ZRAM 大小。 | 以 adb 實測兩款現行旗艦機——裝置設定頁面的說明文字並不足以判斷其真實做法。 |
時序
轉捩點 依時間排序
- 2015長期耐久實驗結束：六顆消費級 SSD 被持續寫入至故障；每一顆都超越其標示耐久值，第一顆直到 700 TB 後才故障。
- 2015Windows 10 在分頁活動與 pagefile 之間插入記憶體壓縮，寫入磁碟的頁面約減半。
- 2018回收公平性論點發表，將交換空間從緊急備援重新定位為常規機制。
- 2018PSI 併入 Linux 核心 4.20 版，使使用者空間能在 OOM killer 介入之前依停頓時間行動。
- 2019Btrfs 隨核心 5.0 開始支援 swapfile，並附帶實質限制：檔案須位於單一裝置的檔案系統，且不得壓縮。
- 2019macOS 的 APFS 開機架構自 10.15 版起，開始要求以專屬隱藏卷宗存放 swap 檔案。
- 2020Fedora 自第 33 版起，開始預設以 ZRAM 作為唯一交換裝置，即使原本可支援休眠，也捨棄以磁碟為後端的交換空間。
- 2021→Android 廠商推出「擴充 RAM」選項 — 有的僅調整 ZRAM，有的確實寫入儲存。
- 2025針對兩款現行旗艦機的 adb 實測終於定論：某廠牌滑桿僅調整壓縮層大小，另一廠牌則確實寫入儲存空間。
無法繫年者 誠實地留白
有兩件事無法確切繫年。Android 廠商的「擴充 RAM」滑桿是逐機推出，而非單一發表日期，因此上方以區間呈現才誠實。Apple 官方公開的壓縮器原始碼雖清楚寫明所用演算法組合，但該公開檔案對應哪一版 macOS無從確認，現行版本的壓縮器是否與之完全相符也一樣無從確認。
論點
承 — 交換空間為何仍有必要 左文 · 右數據
檔案頁面可丟棄後再讀回；匿名頁面卻無處可去。沒有交換空間，它們就是不可回收的，核心只能改從頁面快取與程式碼中榨取所需的每一位元組。因此支持交換空間最有力的論點不是容量，而是對稱性：讓兩類頁面同等可回收，核心才能淘汰真正較冷的那一邊。這一背書屬制度層面而非修辭 — systemd-oomd 官方 man page 直接引用此論點，並指出應啟用交換空間，否則系統會更快進入 livelock，反而餓死原本要來救援的使用者空間終止程式。
- 2兩類頁面同等可回收
- 4.20+支援 PSI 的核心 — OOM 前即可見壓力
真正重要的三個面向 其餘皆為細節
| 面向 | 它問的問題 | 為何決定設計 |
|---|---|---|
| 持久層 | 是否存在以儲存為後端的交換空間？ | 部分 Android 實作僅調整 ZRAM — 根本沒有可落盤的第二層。 |
| 休眠 | 該層能否承載休眠映像？ | 唯一的硬性功能分界：壓縮層開機即清空，永遠無法承載。 |
| 可調程度 | 暴露了多少調校機制？ | Windows 與 macOS 近乎全自動；Linux 開放參數；Android 僅提供一個滑桿。 |
總結
停用交換空間並不能避免記憶體壓力下的磁碟 I/O — 只是把反覆置換從匿名頁面轉移到頁面快取與程式碼，通常更糟。
重新定位
長期偏深的交換使用量是容量訊號，而非調校問題。解法是加記憶體，不是加交換空間。
補充
起 — 兩層架構，五種名稱 各家共同收斂的形狀
第一層 · 位於記憶體
壓縮層
- Windows 記憶體壓縮——採用一般（非 Huffman）版本的
XPRESS格式，存放於 System 程序內的壓縮儲存區。 - macOS compressor pager — WKdm；Apple 得以出貨較低記憶體配置的關鍵。
- Linux ZRAM／zswap — zstd、lzo 或 lz4，典型約 3:1。
- Android ZRAM — 永遠是第一道防線，早於任何儲存寫入。
- Windows 記憶體壓縮——採用一般（非 Huffman）版本的
第二層 · 位於儲存
持久層
- Windows
pagefile.sys；另有swapfile.sys，以單次 I/O 搬移暫停應用的整個工作集。 - Linux 分割區或檔案 — 功能等價；檔案以一層檔案系統對映換取彈性。
- macOS 動態 swapfile 存放於專屬 APFS VM 卷宗，此為 Apple 開機架構自 10.15 版起的要求。
- Android——各廠牌「擴充 RAM」滑桿做法不一：有些確實新增 UFS swapfile，有些僅調整壓縮層大小，完全不涉及儲存空間。
- Windows
逐平台對照 同一機制，不同暴露程度
| 技術 | 後端 | 休眠 | 壓縮 |
|---|---|---|---|
| Windows pagefile | NTFS 上的檔案 | 另存映像 | 是——一般版 XPRESS |
| Windows swapfile | 檔案，僅限新式應用 | 否 | 是 — 每應用一區 |
| Linux 分割區 | 獨立分割區 | 是 | 否 — 可搭配 zswap |
| Linux 交換檔案 | 檔案系統上的檔案 | 是，需 offset | 否 — 可搭配 zswap |
| Linux ZRAM | 記憶體中的區塊裝置 | 永不 | 是 — 這就是重點 |
| macOS 動態交換 | APFS VM 卷宗 | 是 | 是 — WKdm |
| Android ZRAM | 記憶體中的區塊裝置 | 永不 | 是 — lz4／zstd |
| Android 擴充 RAM | UFS 上的 swapfile | 否 | 先經 ZRAM |
轉 — 穩固處與吃緊處 四個面向
| 面向 | 穩固 | 吃緊 |
|---|---|---|
| 休眠 | 實體分割區或檔案可承載映像 | 壓縮層開機即清空 — 永遠無法替代 |
| 快閃壽命 | 六顆消費級 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仍需審慎的情況
合 — 一個頁面的去向 依序六步
- 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) | 背景回收何時喚醒，以及喚醒後釋放多少。 | 在容易突發大量配置的機器上調高，以保留更多可用記憶體。 |
| ro.lmk.swap_free_low_percentage（10） | 剩餘交換空間占比低於此百分比時，lmkd 即判定系統交換空間告急。 | 僅限 root，依機型設定——核心內建終止程式已隨 Linux 進入 4.12 版而移除。 |
| ro.lmk.psi_complete_stall_ms（700） | PSI 記憶體「完全停頓」（所有工作同時卡住）持續的毫秒數，達此值即觸發最高等級的終止。 | 低記憶體裝置的門檻更低（可低至 70ms）；僅限 root。 |
結論
兩種姿態，而非五套做法 由誰決定 — 廠商，還是你
Windows · macOS
不要干預
- 壓縮與落盤已整合且全自動；沒有可調之處。
- 停用分頁檔會失去當機傾印並降低認可上限 — 不划算。
- 在 macOS 上停用交換空間等同弱化系統保護；正解是加記憶體。
- 看記憶體壓力指標，而非交換空間數字。
Linux · Android
刻意選擇
- 先決定層級 — 是否休眠 — 再決定大小。
- 寫入時複製檔案系統對交換檔案有實質限制；請遵循其專屬流程。
- 讓壓力監測搭配使用者空間終止程式，否則機器卡住前無人處理。
- 在手機上，把滑桿視為以幀率為代價的背景應用保活旋鈕。
建議 依平台
- Windows — 讓系統自動管理 pagefile。為省幾 GB 而停用會失去當機傾印並可能導致不穩；SSD 壽命並非實際考量。
- Linux — 只選一層，不要並用。桌機用 ZRAM（約記憶體一半、zstd）；需休眠則用不小於記憶體的實體分割區或檔案。切勿讓 ZRAM 與磁碟交換並存。
- Linux 伺服器 — 讓 PSI 搭配使用者空間 OOM 守護程式。否則核心終止程式只會在機器已卡住後才動作。
- Android — 4GB 開啟，12GB 關閉。儲存比記憶體慢上數個數量級，旗艦機開啟後的實測代價是掉幀。
例外，重申一次 查清自己所用的發行版
並非同一套慣例
「先壓縮，後落盤」說的是 Windows、macOS、Android，以及啟用 ZRAM 的桌面版 Linux。它並不適用於 Red Hat Enterprise Linux 目前官方文件所載的預設做法——只有分割區或檔案，完全沒有壓縮這一步。以此預設建置的伺服器，在觸及儲存之前並無壓縮層可資緩衝——在假設上述模式適用於它之前，值得先查清楚。
最終落點
只需問三個問題：是否需要休眠、是否混用層級、交換深度是否在告訴你該加記憶體？其餘皆為細節。