背景：
背景：Java過長的瓶頸，無法有效利用TB 級記憶體。隨著 Go GC 的優化，人們不禁好奇它是否能在 TB 級記憶體環境下實現足夠短的 GC 中斷時間。
是否有相關的基準測試？ 是否可以使用一款具有 GC 的語言來管理如此龐大的記憶體？
答案：
在目前的後台 GC 模式下，GC 工作負載往往比 GC 中斷時間更為關鍵。 GC 工作負載可以用 指標數量 * 分配速率 / 剩餘記憶體 來表示。在使用大量記憶體的應用中，只有指標數量較少或分配較少的應用程式才能保持較低的 GC 工作負載。
詳細內容：
Go 堆具有 512 GB 的限制，已實際測試的最大堆大小為 240 GB。 Go 1.5 GC 旨在減少 GC 中斷時間，而不是減少 GC 工作。程式碼在 GC 掃描堆疊和全域變數中的指標時會中斷。 根據GopherCon 2015 演講中的圖表，1.5 GC 在擁有約18GB 堆的GC 基準測試中具有較短的中斷時間，如圖所示：[圖表：GC 中斷時間與堆疊大小關係，顯示了1.5 版本的改進]在實際應用中，一些原本GC中斷時間為 300ms 的程序報告下降至 4ms 和 20ms，另一個應用程式報告 95th 百分位數 GC 時間從 279ms 降至 10ms。 Go 1.6 進一步最佳化，將部分工作置於後台。結果是，即使堆疊大小超過200GB，測試中的最大中斷時間仍為20ms，如下圖所示：[圖表：1.6 GC 時間隨堆大小變化，在180GB 附近達到20ms]在1.6 版本中，堆大小約為8GB、每分鐘分配約150M 的應用，其中斷時間從20ms 降至 3-4ms。
Twitch 使用 Go 來運行聊天服務，他們報告說在 1.7 版本中，暫停時間已減少到 1ms，而同時運行大量協程。
1.8 將堆疊掃描移出停止世界階段，將大多數中斷時間控制在 1ms 以內，即使是在大堆記憶體情況下。早期測試結果顯示情況良好。有時，應用程式中仍然存在著使協程難以中斷的程式碼模式，從而有效延長了所有其他執行緒的中斷時間，但總體來說，GC 的後台工作通常比 GC 中斷時間更為重要。 一般性觀察：換句話說，即使應用會存取大量內存，如果指針數量較少（例如，它處理相對較少的[] byte 緩衝區），且分配速率很低（例如，因為在最容易溢位記憶體的場景中套用了sync.Pool 來重複使用記憶體），則GC 問題可能會不存在。
因此，如果您考慮使用包含數百GB 堆的大型計算機，並且其本質上不適合GC，我建議您考慮以下選項：
以上是Go 1.5 的垃圾收集器準備好進行 TB 級記憶體管理了嗎？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
