AMD 將於七月透過 BIOS 更新恢復 Ryzen 9000 系列的記憶體加密功能
Tom's Hardware · 2026-06-20
AMD 確認將於 2026 年 7 月發布 BIOS 更新，為搭載 Zen 5 架構的 Ryzen 9000 系列處理器重新啟用安全記憶體加密（SME）與透明記憶體加密（TME）功能。這兩項加密機制原本是保護記憶體內容不被實體存取竊取的重要防線，卻因發現韌體層級錯誤而在 Ryzen 9000 上遭到停用。此次修復對於重視資料安全的伺服器及雲端部署場景意義重大。
SME 與 TME：記憶體靜態保護的關鍵技術
AMD 安全記憶體加密（SME）是一項由硬體支援的機制，在資料寫入 DRAM 時即時進行 AES-128 加密，即便攻擊者能直接存取實體記憶體條，也無法讀取有效資料。TME（透明記憶體加密）則是整機全記憶體加密的變體，對所有記憶體位址皆套用加密，無需應用程式或作業系統進行任何修改。兩者皆在 CPU 內部完成加解密，對效能影響極低，且對上層軟體完全透明。
這類技術在雲端虛擬化環境中尤為關鍵：當多個租戶共用同一實體主機時，記憶體靜態保護（data-at-rest-in-memory）可防止惡意 hypervisor 或其他 VM 透過旁路攻擊竊取敏感資料。對於處理個人健康資訊、金融交易或加密金鑰的工作負載而言，SME/TME 是合規架構不可或缺的一環。
Zen 5 為何停用此功能
Ryzen 9000 系列採用 AMD 最新的 Zen 5 微架構，理論上應全面支援 SME/TME。然而在出貨前測試中，AMD 工程師發現一個與記憶體加密相關的韌體錯誤，可能導致系統不穩定，因此決定在 AGESA（AMD 通用封裝環境軟體架構）韌體中暫時停用這兩項功能，以防範潛在的資料損毀風險。這項決定雖然保障了平台穩定性，卻也讓 Ryzen 9000 在安全性訴求較高的企業與伺服器市場失去了一項重要賣點。
AMD 表示，根除該錯誤所需的修復已整合至即將發布的 AGESA 1.2.0.Cb 版本中，主機板廠商將以 BIOS 更新的形式發布給終端用戶，預計於 2026 年 7 月內完成各主流平台的鋪設。目前已確認受惠的平台包含 AM5 腳位的桌上型 Ryzen 9000 系列，以及對應的行動版本。
對資料工作負載的實際影響
對於資料庫管理員與雲端架構師而言，重新啟用 SME/TME 意味著可在不修改任何應用程式碼的情況下獲得記憶體層級的加密保護。這對於在 AMD 平台上部署 PostgreSQL、MySQL 或 Redis 等記憶體密集型資料庫的場景尤其有利——靜態記憶體加密可作為縱深防禦策略的底層保障，補足應用層加密的不足。
值得注意的是，SME/TME 保護的是「記憶體靜態資料」，即儲存於 DRAM 中尚未被 CPU 處理的資料；主動被 CPU 核心存取的資料在暫存器中仍為明文，因此無法取代完整的機密運算（Confidential Computing）方案，但可與 AMD SEV（安全加密虛擬化）搭配使用，構成更完整的防護鏈。系統管理員在 BIOS 更新後，需在主機板 UEFI 設定中手動確認 SME/TME 選項已啟用。
原始來源：Tom's Hardware
十年磨一劍：Project Valhalla 的 Value Types 如何在 JDK 28 改寫 Java 記憶體模型
JVM Weekly · 2026-06-18
歷經超過十年的設計迭代，Project Valhalla 的核心特性「值類別（Value Classes）」終於確定在 JDK 28 正式落地。這項改變讓 Java 物件可以宣告為「無身份識別（no identity）」的值類型，從而在陣列與堆積中以內聯（inline）方式儲存，徹底消除過去因物件頭（object header）與間接指標（indirection pointer）所帶來的記憶體膨脹問題，對資料密集型應用的效能提升潛力不容小覷。
什麼是值類別，它解決了什麼問題
傳統 Java 物件具有「身份（identity）」：每個實例在記憶體中都有唯一位址，因此即使兩個物件欄位完全相同，它們也是不同的物件。這種設計帶來了鎖定（synchronization）與 == 比較的語意，但代價是每個物件至少需要 16 位元組的標頭（header），加上一個間接指標，導致大量小型物件造成嚴重的記憶體碎片與 GC 壓力。值類別宣告後，JVM 可將其實例直接內嵌於容器的記憶體區塊中，不再需要額外的堆積分配。
以一個儲存二維座標的類別為例，在 Valhalla 之前，一個 Point[] 陣列實際上儲存的是指向各個 Point 物件的參考，每次存取都需要間接定址；啟用值類別後，陣列中的每個元素直接包含 x 與 y 兩個欄位的位元組資料，存取時 CPU 快取命中率大幅提升。
// JDK 28 值類別語法範例
value class Point {
double x;
double y;
Point(double x, double y) {
this.x = x;
this.y = y;
}
}
// 陣列內聯儲存，無物件標頭開銷
Point[] points = new Point[1_000_000];
十年設計歷程的關鍵取捨
Project Valhalla 由 Brian Goetz 於 2014 年提出，核心命題是「讓 JVM 的行為更像硬體」。設計過程中最棘手的問題是如何在不破壞既有型別系統的前提下引入無身份物件：Java 的泛型、反射、同步語意以及 null 的處理方式，都需要在值類別的框架下重新定義邊界。早期的 JEP 草案歷經多次重大修訂，從「inline types」到「primitive classes」再到最終的「value classes」，每次命名變更背後都是一次語意範圍的重新校準。
最終方案選擇了「分層漸進」的路徑：值類別不能被繼承（但可實作介面），不能作為同步鎖的監視器（monitor），且欄位預設為 final。這些限制並非設計缺陷，而是確保 JVM 能安全地進行記憶體平坦化（flattening）的必要條件。開發者可透過 value 關鍵字選擇性地採用，不影響現有程式碼。
對資料密集型 Java 應用的意義
在資料工程領域，Java 被廣泛用於 Apache Flink、Spark、Kafka Streams 等大資料框架。這些框架的核心熱路徑往往涉及數以千萬計的小型物件——時間戳記、鍵值對、統計累加器——每個物件都有獨立的記憶體分配，對 GC 造成持續壓力。採用值類別後，這些物件可以內聯到陣列或集合容器中，記憶體用量預計可降低 50% 以上，GC 暫停時間也將顯著縮短，直接改善串流處理的延遲表現。
JDK 28 預計以預覽（preview）或正式特性的形式交付值類別，具體 API 仍可能在正式發布前有所調整。框架開發者現在可開始評估哪些核心資料結構適合改寫為值類別，尤其是那些生命週期短暫、數量龐大且不需要物件身份語意的值物件（Value Object），例如金融計算中的貨幣金額、科學計算中的向量座標等。Valhalla 的到來，或許是自 Java 5 引入泛型以來，Java 型別系統最深刻的一次演進。
原始來源：JVM Weekly