RAM 缺？升價？攪清楚先買！

你是否也曾經歷過：明明電腦配備了大量記憶體，但開啟幾個瀏覽器分頁、執行了幾套軟體後，系統便開始哀嚎，風扇狂轉，甚至有程式直接崩潰？很多人將這種現象歸咎於「軟體愈寫愈爛」，但真相遠比這複雜，而且與電腦科學數十年來的記憶體管理演進息息相關。本文將帶你走進記憶體管理的世界，從早期電腦的克難年代，一路講到現代瀏覽器與新世代語言的防衛機制，並揭露許多你可能從未聽聞的冷知識。 一、冷知識篇：關於記憶體，那些被遺忘的往事 1. 磁芯記憶體：一位元便是一枚甜甜圈 在 1950 至 1970 年代，電腦的主記憶體是由無數微小的磁性圓環（磁芯）人手編織而成，每個圓環只能儲存 0 或 1。這些記憶體極其昂貴，一部大型電腦可能只有數 KB 容量。程式設計師必須將「節省每一個位元組」當成信仰，甚至為了省記憶體而使用一些現代看來極度危險的技巧──例如覆寫自己的程式碼本身。這種克難精神，與今日動輒消耗數 GB 的軟體形成強烈對比。 2. 「記憶體洩漏」一詞的由來 「記憶體洩漏」（memory leak）這個生動的比喻，很早便出現於電腦科學領域。當程式向系統借用了記憶體空間，用完卻忘記歸還，這些空間就像水從裂縫中滴漏出去一樣，再也無法被其他程式使用。長時間執行後，可用記憶體愈來愈少，系統最終只得舉手投降。有些嵌入式系統──例如太空探測器上的軟體──甚至設計成定期自動重啟，就是為了清理這些「無主記憶體」。 3. 經典遊戲為何永遠不當機？ 早期的遊戲主機（如任天堂紅白機、Game Boy）幾乎沒有作業系統，遊戲卡匣直接掌控整部機器的硬體。程式設計師對記憶體配置擁有完全的控制權，每一 byte 都經過精心規劃。在這種環境下，記憶體洩漏幾乎不可能發生，因為一旦遊戲結束，主機便重設所有狀態。現代軟體的彈性與便利，反而間接造就了更容易出錯的記憶體環境。 4. 「RAM 吞噬獸」Chrome 其實是故意的 許多人抱怨 Google Chrome 佔用大量記憶體，但這背後是一種刻意的安全與穩定設計。後文將會詳細剖析這項架構決策。 二、管理記憶體的三大流派：手動、自動與所有權 要理解軟體為何會吃掉大量記憶體，必須先明白程式如何向系統「借位」和「還位」。幾十年來，業界發展出三種主要的管理哲學。 1. 手動管理：C 語言之刃 在 C 與 C++ 等語言中，程式設計師必須親自發出 malloc()（借記憶體）與 free()（還記憶體）的指令。這賦予開發者極大的權力，能夠打造非常高效的軟體，但同時也埋下了災難的種子： 忘記歸還：記憶體被借走便永遠消失，形成洩漏。 過早歸還：釋放後的記憶體被其他程式佔用，但原程式仍持有舊地址，形成「懸空指標」，隨時可能導致崩潰或安全漏洞。 重複歸還：對同一塊記憶體釋放兩次，會破壞系統的記憶體管理結構，引發不可預測的錯誤。 這類錯誤極難偵錯，而且在大型專案中成為最主要的資安漏洞來源之一。知名的 Heartbleed 漏洞，本質上正是一宗記憶體越界讀取問題。 2. 自動垃圾回收：Java、C# 的安逸法則 為了解決人類難以完美管理記憶體的痛點，Java、C#、Python 等語言導入了垃圾回收機制（Garbage Collection，簡稱 GC）。程式設計師只管借，不必親自還；背景會有一個「GC 執行緒」定時掃描所有物件，檢查哪些已經不再被參照，並自動回收其佔用的空間。 優點：大幅降低記憶體洩漏的風險，程式設計師能專注於商業邏輯。 代價： Stop-the-world 暫停：某些 GC 演算法在回收時需要暫停整個程式，造成延遲，對遊戲或高頻交易系統可能致命。 記憶體碎片化：反覆分配與回收，會令記憶體變得像瑞士芝士，剩下零散小空間無法滿足大塊需求，迫使系統向作業系統索取更多記憶體。 記憶體胃口變大：為了減少暫停頻率，GC 往往傾向一次向系統大量申請記憶體，用不著也先拿著，令程式的基底記憶體佔用（baseline）遠高於手動管理。 循環參照陷阱：物件之間互相引用，但外部已無路可達，某些簡單的 GC 演算法無法回收，形成隱性洩漏。 這就是為什麼許多用 Java 寫的企業應用，什麼都沒做就先佔去幾百 MB 記憶體。 3. 所有權與借用：Rust 的革命 Rust 語言帶來了一種全新的思路：不靠執行期垃圾收集，也不靠人類胡亂手動釋放，而是在編譯時期就透過「所有權」（ownership）與「借用」（borrowing）規則，嚴格證明每塊記憶體都有一個明確的主人，且所有存取都已授權。程式碼若違反規則，根本無法編譯通過。 這套機制實現了 零成本抽象：執行效能比肩 C++，卻沒有記憶體洩漏或懸空指標的可能性，更天然地防止了多執行緒下的資料競爭問題。Rust 的出現，證明我們不必在「安全」與「效能」之間二選一。許多新世代的基礎軟體，甚至作業系統核心模組，都開始用 Rust 改寫，期待終結記憶體類漏洞。 三、現代軟體的記憶體「大食」成因 在前述背景上，我們便能回答那個核心問題：為何現代的軟體如此「大食」？ 1. 功能通貨膨脹與抽象層層堆疊 今天的軟體承載著遠比三十年前複雜的功能：圖形介面、網路通訊、加密解密、國際化、無障礙支援……每一層功能都疊加了大量抽象層，每個抽象層都可能動態分配緩衝區、建立物件。記憶體消耗便如滾雪球般膨脹。 2. 凡事快取的策略 為追求使用者體驗的流暢，現代軟體普遍採用大規模快取策略。瀏覽器快取網頁圖片、應用程式快取資料庫查詢結果、作業系統快取磁碟讀寫。這些快取能大幅加速運作，但也佔用可觀的記憶體。理想上，當記憶體壓力上升時應該自動釋放，但實際情況往往不如預期。 3. JavaScript 與動態型別的記憶體開銷 JavaScript、Python 等動態語言賦予開發者極大的彈性，但在記憶體使用上卻相當豪爽。一個簡單的數字，在 C 語言可能佔 4 或 8 位元組，到了這些語言中必須包裝成帶有型別標籤、參考計數等額外資訊的物件，體積可能膨脹數倍以上。當代前端框架在執行時大量建立暫時物件，垃圾回收器必須頻繁介入，進一步拖累效能。 4. 瀏覽器之役與 Chrome 的特殊設計 走進最大宗的「吃 RAM 兇手」──瀏覽器。Chrome 採用多進程架構，將每個分頁、每個擴充套件，甚至 GPU 運算都分別放進獨立的作業系統進程裡。這樣的設計好處極大：某一分頁當機不會拖垮整個瀏覽器，惡意網站也更難讀取其他分頁的機密資料。但代價是每個進程都必須各自擁有基礎執行環境的記憶體複本，累積起來便十分可觀。 此外，瀏覽器引擎為了讓網頁跑得更順，內部做了極為複雜的即時編譯與優化快取，這些都是記憶體密集型操作。將這一切都乘上你開啟的十幾二十個分頁，記憶體自然如流水般逝去。 四、我們能做些什麼？── 使用者的生存策略 1. 分頁管理工具 使用分頁休眠或暫停的擴充功能，讓閒置分頁釋放記憶體。 2. 適時重啟應用程式 對於長時間執行的應用程式（特別是那些用 Electron 寫成的桌面 App），定期重啟可清理堆積的碎片與洩漏。 3. 了解軟體的語言特性 若你同時執行多個以 Java 撰寫的大型工具（例如 Eclipse、Android Studio），它們各自的虛擬機都會預佔大量記憶體，可透過設定檔案控制上限。 4. 迎接新世代軟體 許多工具已開始用 Rust、Go 等較高效語言重寫，佔用更少記憶體且更加穩定。例如以 Rust 寫成的終端機模擬器 Alacritty，或以 Go 寫成的容器技術，都為「輕量級」下了新定義。 結語：記憶體管理，是無聲的戰場 從手寫記憶體位址、到垃圾回收自動駕駛，再到 Rust 的編譯期驗證，人類與記憶體管理搏鬥的歷史，正是一部軟體可靠性的演進史。每次當你抱怨 Chrome 搶走了過多的 RAM，其實你正在見證一個為了安全性與隔離性而作出的艱難取捨。理解這些取捨，我們便能更明智地選擇工具、調校系統，甚至更能體諒那些並非故意膨脹的軟體。或許有天，黑洞終將被馴服。