GO語言商業案例（十八）：stream

切換到新語言始終是一大步，尤其是當您的團隊成員只有一個時有該語言的先前經驗?，F在，Stream 的主要編程語言從 Python 切換到了 Go。這篇文章將解釋stream決定放棄 Python 并轉向 Go 的一些原因。

站在用戶的角度思考問題，與客戶深入溝通，找到洛陽網站設計與洛陽網站推廣的解決方案，憑借多年的經驗，讓設計與互聯網技術結合，創造個性化、用戶體驗好的作品，建站類型包括：成都網站建設、成都網站制作、企業官網、英文網站、手機端網站、網站推廣、空間域名、虛擬主機、企業郵箱。業務覆蓋洛陽地區。

Go 非?？臁Ｐ阅茴愃朴?Java 或 C++。對于用例，Go 通常比 Python 快 40 倍。

對于許多應用程序來說，編程語言只是應用程序和數據庫之間的粘合劑。語言本身的性能通常并不重要。然而，Stream 是一個API 提供商，為 700 家公司和超過 5 億最終用戶提供提要和聊天平臺。多年來，我們一直在優化 Cassandra、PostgreSQL、Redis 等，但最終，您會達到所使用語言的極限。Python 是一門很棒的語言，但對于序列化/反序列化、排名和聚合等用例，它的性能相當緩慢。我們經常遇到性能問題，Cassandra 需要 1 毫秒來檢索數據，而 Python 會花費接下來的 10 毫秒將其轉換為對象。

看看我如何開始 Go 教程中的一小段 Go 代碼。（這是一個很棒的教程，也是學習 Go 的一個很好的起點。）

如果您是 Go 新手，那么在閱讀那個小代碼片段時不會有太多讓您感到驚訝的事情。它展示了多個賦值、數據結構、指針、格式和一個內置的 HTTP 庫。當我第一次開始編程時，我一直喜歡使用 Python 更高級的功能。Python 允許您在編寫代碼時獲得相當的創意。例如，您可以：

這些功能玩起來很有趣，但是，正如大多數程序員會同意的那樣，在閱讀別人的作品時，它們通常會使代碼更難理解。Go 迫使你堅持基礎。這使得閱讀任何人的代碼并立即了解發生了什么變得非常容易。 注意：當然，它實際上有多“容易”取決于您的用例。如果你想創建一個基本的 CRUD API，我仍然推薦 Django + DRF或 Rails。

作為一門語言，Go 試圖讓事情變得簡單。它沒有引入許多新概念。重點是創建一種非常快速且易于使用的簡單語言。它唯一具有創新性的領域是 goroutine 和通道。（100% 正確CSP的概念始于 1977 年，所以這項創新更多是對舊思想的一種新方法。）Goroutines 是 Go 的輕量級線程方法，通道是 goroutines 之間通信的首選方式。Goroutines 的創建非常便宜，并且只需要幾 KB 的額外內存。因為 Goroutine 非常輕量，所以有可能同時運行數百甚至數千個。您可以使用通道在 goroutine 之間進行通信。Go 運行時處理所有復雜性。goroutines 和基于通道的并發方法使得使用所有可用的 CPU 內核和處理并發 IO 變得非常容易——所有這些都不會使開發復雜化。與 Python/Java 相比，在 goroutine 上運行函數需要最少的樣板代碼。您只需在函數調用前加上關鍵字“go”：

Go 的并發方法很容易使用。與 Node 相比，這是一種有趣的方法，開發人員必須密切關注異步代碼的處理方式。Go 中并發的另一個重要方面是競爭檢測器。這樣可以很容易地確定異步代碼中是否存在任何競爭條件。

我們目前用 Go 編寫的最大的微服務編譯需要 4 秒。與以編譯速度慢而聞名的 Java 和 C++ 等語言相比，Go 的快速編譯時間是一項重大的生產力勝利。我喜歡在程序編譯的時候摸魚，但在我還記得代碼應該做什么的同時完成事情會更好。

首先，讓我們從顯而易見的開始：與 C++ 和 Java 等舊語言相比，Go 開發人員的數量并不多。根據StackOverflow的數據， 38% 的開發人員知道 Java， 19.3% 的人知道 C++，只有 4.6% 的人知道 Go。GitHub 數據顯示了類似的趨勢：Go 比 Erlang、Scala 和 Elixir 等語言使用更廣泛，但不如 Java 和 C++ 流行。幸運的是，Go 是一種非常簡單易學的語言。它提供了您需要的基本功能，僅此而已。它引入的新概念是“延遲”聲明和內置的并發管理與“goroutines”和通道。（對于純粹主義者來說：Go 并不是第一種實現這些概念的語言，只是第一種使它們流行起來的語言。）任何加入團隊的 Python、Elixir、C++、Scala 或 Java 開發人員都可以在一個月內在 Go 上發揮作用，因為它的簡單性。與許多其他語言相比，我們發現組建 Go 開發人員團隊更容易。如果您在博爾德和阿姆斯特丹等競爭激烈的生態系統中招聘人員，這是一項重要的優勢。

對于我們這樣規模的團隊（約 20 人）來說，生態系統很重要。如果您必須重新發明每一個小功能，您根本無法為您的客戶創造價值。Go 對我們使用的工具有很好的支持。實體庫已經可用于 Redis、RabbitMQ、PostgreSQL、模板解析、任務調度、表達式解析和 RocksDB。與 Rust 或 Elixir 等其他較新的語言相比，Go 的生態系統是一個重大勝利。它當然不如 Java、Python 或 Node 之類的語言好，但它很可靠，而且對于許多基本需求，你會發現已經有高質量的包可用。

Gofmt 是一個很棒的命令行實用程序，內置在 Go 編譯器中，用于格式化代碼。就功能而言，它與 Python 的 autopep8 非常相似。我們大多數人并不真正喜歡爭論制表符與空格。格式的一致性很重要，但實際的格式標準并不那么重要。Gofmt 通過使用一種正式的方式來格式化您的代碼來避免所有這些討論。

Go 對協議緩沖區和 gRPC 具有一流的支持。這兩個工具非常適合構建需要通過 RPC 通信的微服務。您只需要編寫一個清單，在其中定義可以進行的 RPC 調用以及它們采用的參數。然后從這個清單中自動生成服務器和客戶端代碼。生成的代碼既快速又具有非常小的網絡占用空間并且易于使用。從同一個清單中，您甚至可以為許多不同的語言生成客戶端代碼，例如 C++、Java、Python 和 Ruby。因此，內部流量不再有模棱兩可的 REST 端點，您每次都必須編寫幾乎相同的客戶端和服務器代碼。.

Go 沒有像 Rails 用于 Ruby、Django 用于 Python 或 Laravel 用于 PHP 那樣的單一主導框架。這是 Go 社區內激烈爭論的話題，因為許多人主張你不應該一開始就使用框架。我完全同意這對于某些用例是正確的。但是，如果有人想構建一個簡單的 CRUD API，他們將更容易使用 Django/DJRF、Rails Laravel 或Phoenix。對于 Stream 的用例，我們更喜歡不使用框架。然而，對于許多希望提供簡單 CRUD API 的新項目來說，缺乏主導框架將是一個嚴重的劣勢。

Go 通過簡單地從函數返回錯誤并期望調用代碼來處理錯誤（或將其返回到調用堆棧）來處理錯誤。雖然這種方法有效，但很容易失去問題的范圍，以確保您可以向用戶提供有意義的錯誤。錯誤包通過允許您向錯誤添加上下文和堆棧跟蹤來解決此問題。另一個問題是很容易忘記處理錯誤。像 errcheck 和 megacheck 這樣的靜態分析工具可以方便地避免犯這些錯誤。雖然這些變通辦法效果很好，但感覺不太對勁。您希望該語言支持正確的錯誤處理。

Go 的包管理絕不是完美的。默認情況下，它無法指定特定版本的依賴項，也無法創建可重現的構建。Python、Node 和 Ruby 都有更好的包管理系統。但是，使用正確的工具，Go 的包管理工作得很好。您可以使用Dep來管理您的依賴項，以允許指定和固定版本。除此之外，我們還貢獻了一個名為的開源工具VirtualGo，它可以更輕松地處理用 Go 編寫的多個項目。

我們進行的一個有趣的實驗是在 Python 中使用我們的排名提要功能并在 Go 中重寫它。看看這個排名方法的例子：

Python 和 Go 代碼都需要執行以下操作來支持這種排名方法：

開發 Python 版本的排名代碼大約花了 3 天時間。這包括編寫代碼、單元測試和文檔。接下來，我們花了大約 2 周的時間優化代碼。其中一項優化是將分數表達式 (simple_gauss(time)*popularity) 轉換為抽象語法樹. 我們還實現了緩存邏輯，可以在未來的特定時間預先計算分數。相比之下，開發此代碼的 Go 版本大約需要 4 天時間。性能不需要任何進一步的優化。因此，雖然 Python 的最初開發速度更快，但基于 Go 的版本最終需要我們團隊的工作量大大減少。另外一個好處是，Go 代碼的執行速度比我們高度優化的 Python 代碼快大約 40 倍?，F在，這只是我們通過切換到 Go 體驗到的性能提升的一個示例。

與 Python 相比，我們系統的其他一些組件在 Go 中構建所需的時間要多得多。作為一個總體趨勢，我們看到 開發 Go 代碼需要更多的努力。但是，我們花更少的時間 優化 代碼以提高性能。

我們評估的另一種語言是Elixir.。Elixir 建立在 Erlang 虛擬機之上。這是一種迷人的語言，我們之所以考慮它，是因為我們的一名團隊成員在 Erlang 方面擁有豐富的經驗。對于我們的用例，我們注意到 Go 的原始性能要好得多。Go 和 Elixir 都可以很好地服務數千個并發請求。但是，如果您查看單個請求的性能，Go 對于我們的用例來說要快得多。我們選擇 Go 而不是 Elixir 的另一個原因是生態系統。對于我們需要的組件，Go 有更成熟的庫，而在許多情況下，Elixir 庫還沒有準備好用于生產環境。培訓/尋找開發人員使用 Elixir 也更加困難。這些原因使天平向 Go 傾斜。Elixir 的 Phoenix 框架看起來很棒，絕對值得一看。

Go 是一種非常高性能的語言，對并發有很好的支持。它幾乎與 C++ 和 Java 等語言一樣快。雖然與 Python 或 Ruby 相比，使用 Go 構建東西確實需要更多時間，但您將節省大量用于優化代碼的時間。我們在Stream有一個小型開發團隊，為超過 5 億最終用戶提供動力和聊天。Go 結合了 強大的生態系統 、新開發人員的 輕松入門、快速的性能 、對并發的 可靠支持和高效的編程環境 ，使其成為一個不錯的選擇。Stream 仍然在我們的儀表板、站點和機器學習中利用 Python 來提供個性化的訂閱源. 我們不會很快與 Python 說再見，但今后所有性能密集型代碼都將使用 Go 編寫。我們新的聊天 API也完全用 Go 編寫。

淺談Go語言函數與方法的區別

前段時間，我們實驗室用go作為后臺開發語言開發了一個web項目，由于這是自己第一次使用go語言進行開發，在開發過程中，一味著追求完成任務，在編碼的時候沒有太注重性能，雖然勉強實現了功能，但是對go語言的理解還是比較淺顯的。下面來談談自己對go語言中函數與方法的理解。

普通函數:

go函數可以返回多個值

值傳遞: 值傳遞是指在調用函數時將實際參數復制一份傳遞到函數中，這樣函數中如果對參數進行修改，將不會影響到實際參數

引用傳遞: 引用傳遞是指在調用函數將實際參數的地址傳遞到函數中，那么在函數中對參數進行的修改，將影響到實際參數。

一般來說go語言函數的 接收者(也就是形參)一般放在函數名后面 ，不能將指針類型的數據直接傳遞，也就是說函數形參如果是值類型，調用者必須使用值作為實參過來，如果函數形參是指針類型，則函數調用者需使用指針作為實參來調用。

普通方法:

接收者是在func關鍵字后面，而不是在函數名稱后面，接收者可以是自己定義的一個類型，這個類型可以是struct、interface，一個方法就是一個包含了接收者的函數，接收者可以是命名類型或者是結構體類型的一個值或者是一個指針。

下面是一個例子來說明方法和函數的區別（重點）

國內重要的 Go 語言項目：TiDB 3.0 GA，穩定性和性能大幅提升

TiDB 是 PingCAP 自主研發的開源分布式關系型數據庫，具備商業級數據庫的數據可靠性，可用性，安全性等特性，支持在線彈性水平擴展，兼容 MySQL 協議及生態，創新性實現 OLTP 及 OLAP 融合。

TiDB 3.0 版本顯著提升了大規模集群的穩定性，集群支持 150+ 存儲節點，300+TB 存儲容量長期穩定運行。易用性方面引入大量降低用戶運維成本的優化，包括引入 Information_Schema 中的多個實用系統視圖、EXPLAIN ANALYZE、SQL Trace 等。在性能方面，特別是 OLTP 性能方面，3.0 比 2.1 也有大幅提升，其中 TPC-C 性能提升約 4.5 倍，Sysbench 性能提升約 1.5 倍，OLAP 方面，TPC-H 50G Q15 因實現 View 可以執行，至此 TPC-H 22 個 Query 均可正常運行。新功能方面增加了窗口函數、視圖（實驗特性）、分區表、插件系統、悲觀鎖（實驗特性）。

截止本文發稿時 TiDB 已在 500+ 用戶的生產環境中長期穩定運行，涵蓋金融、保險、制造，互聯網， 游戲 等領域，涉及交易、數據中臺、 歷史 庫等多個業務場景。不同業務場景對關系型數據庫的訴求可用 “百花齊放”來形容，但對關系數據庫最根本的訴求未發生任何變化，如數據可靠性，系統穩定性，可擴展性，安全性，易用性等。請跟隨我們的腳步梳理 TiDB 3.0 有什么樣的驚喜。

3.0 與 2.1 版本相比，顯著提升了大規模集群的穩定性，支持單集群 150+ 存儲節點，300+TB 存儲容量長期穩定運行，主要的優化點如下：

1. 優化 Raft 副本之間的心跳機制，按照 Region 的活躍程度調整心跳頻率，減小冷數據對集群的負擔。

2. 熱點調度策略支持更多參數配置，采用更高優先級，并提升熱點調度的準確性。

3. 優化 PD 調度流程，提供調度限流機制，提升系統穩定性。

4. 新增分布式 GC 功能，提升 GC 的性能，降低大集群 GC 時間，提升系統穩定性。

眾所周知，數據庫查詢計劃的穩定性對業務至關重要，TiDB 3.0 版本采用多種優化手段提升查詢計劃的穩定性，如下：

1. 新增 Fast Analyze 功能，提升收集統計信息的速度，降低集群資源的消耗及對業務的影響。

2. 新增 Incremental Analyze 功能，提升收集單調遞增的索引統計信息的速度，降低集群資源的消耗及對業務的影響。

3. 在 CM-Sketch 中新增 TopN 的統計信息，緩解 CM-Sketch 哈希沖突導致估算偏大，提升代價估算的準確性，提升查詢計劃的穩定性。

4. 引入 Skyline Pruning 框架，利用規則防止查詢計劃過度依賴統計信息，緩解因統計信息滯后導致選擇的查詢計劃不是最優的情況，提升查詢計劃的穩定性。

5. 新增 SQL Plan Management 功能，支持在查詢計劃不準確時手動綁定查詢計劃，提升查詢計劃的穩定性。

1. OLTP

3.0 與 2.1 版本相比 Sysbench 的 Point Select，Update Index，Update Non-Index 均提升約 1.5 倍，TPC-C 性能提升約 4.5 倍。主要的優化點如下：

1. TiDB 持續優化 SQL 執行器，包括：優化 NOT EXISTS 子查詢轉化為 Anti Semi Join，優化多表 Join 時 Join 順序選擇等。

2. 優化 Index Join 邏輯，擴大 Index Join 算子的適用場景并提升代價估算的準確性。

3. TiKV 批量接收和發送消息功能，提升寫入密集的場景的 TPS 約 7%，讀密集的場景提升約 30%。

4. TiKV 優化內存管理，減少 Iterator Key Bound Option 的內存分配和拷貝，多個 Column Families 共享 block cache 提升 cache 命中率等手段大幅提升性能。

5. 引入 Titan 存儲引擎插件，提升 Value 值超過 1KB 時性能，緩解 RocksDB 寫放大問題，減少磁盤 IO 的占用。

6. TiKV 新增多線程 Raftstore 和 Apply 功能，提升單節點內可擴展性，進而提升單節點內并發處理能力和資源利用率，降低延時，大幅提升集群寫入能力。

TiDB Lightning 性能與 2019 年年初相比提升 3 倍，從 100GB/h 提升到 300GB/h，即 28MB/s 提升到 85MB/s，優化點，如下：

1. 提升 SQL 轉化成 KV Pairs 的性能，減少不必要的開銷。

2. 提升單表導入性能，單表支持批量導入。

3. 提升 TiKV-Importer 導入數據性能，支持將數據和索引分別導入。

4. TiKV-Importer 支持上傳 SST 文件限速功能。

RBAC（Role-Based Access Control，基于角色的權限訪問控制） 是商業系統中最常見的權限管理技術之一，通過 RBAC 思想可以構建最簡單“用戶-角色-權限”的訪問權限控制模型。RBAC 中用戶與角色關聯，權限與角色關聯，角色與權限之間一般是多對多的關系，用戶通過成為什么樣的角色獲取該角色所擁有的權限，達到簡化權限管理的目的，通過此版本的迭代 RBAC 功能開發完成。

IP 白名單功能（企業版特性） ：TiDB 提供基于 IP 白名單實現網絡安全訪問控制，用戶可根據實際情況配置相關的訪問策略。

Audit log 功能（企業版特性） ：Audit log 記錄用戶對數據庫所執行的操作，通過記錄 Audit log 用戶可以對數據庫進行故障分析，行為分析，安全審計等，幫助用戶獲取數據執行情況。

加密存儲（企業版特性） ：TiDB 利用 RocksDB 自身加密功能，實現加密存儲的功能，保證所有寫入到磁盤的數據都經過加密，降低數據泄露的風險。

完善權限語句的權限檢查 ，新增 ANALYZE，USE，SET GLOBAL，SHOW PROCESSLIST 語句權限檢查。

1. 新增 SQL 方式查詢慢查詢，豐富 TiDB 慢查詢日志內容，如：Coprocessor 任務數，平均/最長/90% 執行/等待時間，執行/等待時間最長的 TiKV 地址，簡化慢查詢定位工作，提高排查慢查詢問題效率，提升產品易用性。

2. 新增系統配置項合法性檢查，優化系統監控項等，提升產品易用性。

3. 新增對 TableReader、IndexReader 和 IndexLookupReader 算子內存使用情況統計信息，提高 Query 內存使用統計的準確性，提升處理內存消耗較大語句的效率。

4. 制定日志規范，重構日志系統，統一日志格式，方便用戶理解日志內容，有助于通過工具對日志進行定量分析。

5. 新增 EXPLAIN ANALYZE 功能，提升SQL 調優的易用性。

6. 新增 SQL 語句 Trace 功能，方便排查問題。

7. 新增通過 unix_socket 方式連接數據庫。

8. 新增快速恢復被刪除表功能，當誤刪除數據時可通過此功能快速恢復數據。

TiDB 3.0 新增 TiFlash 組件，解決復雜分析及 HTAP 場景。TiFlash 是列式存儲系統，與行存儲系統實時同步，具備低延時，高性能，事務一致性讀等特性。 通過 Raft 協議從 TiKV 中實時同步行存數據并轉化成列存儲格式持久化到一組獨立的節點，解決行列混合存儲以及資源隔離性問題。TiFlash 可用作行存儲系統（TiKV）實時鏡像，實時鏡像可獨立于行存儲系統，將行存儲及列存儲從物理隔離開，提供完善的資源隔離方案，HTAP 場景最優推薦方案；亦可用作行存儲表的索引，配合行存儲對外提供智能的 OLAP 服務，提升約 10 倍復雜的混合查詢的性能。

TiFlash 目前處于 Beta 階段，計劃 2019 年 12 月 31 日之前 GA，歡迎大家申請試用。

未來我們會繼續投入到系統穩定性，易用性，性能，彈性擴展方面，向用戶提供極致的彈性伸縮能力，極致的性能體驗，極致的用戶體驗。

穩定性方面 V4.0 版本將繼續完善 V3.0 未 GA 的重大特性，例如：悲觀事務模型，View，Table Partition，Titan 行存儲引擎，TiFlash 列存儲引擎；引入近似物理備份恢復解決分布數據庫備份恢復難題；優化 PD 調度功能等。

性能方面 V4.0 版本將繼續優化事務處理流程，減少事務資源消耗，提升性能，例如：1PC，省去獲取 commit ts 操作等。

彈性擴展方面，PD 將提供彈性擴展所需的元信息供外部系統調用，外部系統可根據元信息及負載情況動態伸縮集群規模，達成節省成本的目標。

我們相信戰勝“未知”最好的武器就是社區的力量，基礎軟件需要堅定地走開源路線。截止發稿我們已經完成 41 篇源碼閱讀文章。TiDB 開源社區總計 265 位 Contributor，6 位 Committer，在這里我們對社區貢獻者表示由衷的感謝，希望更多志同道合的人能加入進來，也希望大家在 TiDB 這個開源社區能夠有所收獲。

TiDB 3.0 GA Release Notes：

Golang實驗性功能SetMaxHeap 固定值GC

簡單來說， SetMaxHeap 提供了一種可以設置固定觸發閾值的 GC （Garbage Collection垃圾回收）方式

官方源碼鏈接

大量臨時對象分配導致的 GC 觸發頻率過高， GC 后實際存活的對象較少，

或者機器內存較充足，希望使用剩余內存，降低 GC 頻率的場景

GC 會 STW （ Stop The World ），對于時延敏感場景，在一個周期內連續觸發兩輪 GC ，那么 STW 和 GC 占用的 CPU 資源都會造成很大的影響， SetMaxHeap 并不一定是完美的，在某些場景下做了些權衡，官方也在進行相關的實驗，當前方案仍沒有合入主版本。

先看下如果沒有 SetMaxHeap ，對于如上所述的場景的解決方案

這里簡單說下 GC 的幾個值的含義，可通過 GODEBUG=gctrace=1 獲得如下數據

這里只關注 128-132-67 MB 135 MB goal ，

分別為 GC開始時內存使用量 - GC標記完成時內存使用量 - GC標記完成時的存活內存量 本輪GC標記完成時的 預期 內存使用量（上一輪 GC 完成時確定）

引用 GC peace設計文檔 中的一張圖來說明

對應關系如下：

簡單說下 GC pacing （信用機制）

GC pacing 有兩個目標，

那么當一輪 GC 完成時，如何只根據本輪 GC 存活量去實現這兩個小目標呢？

這里實際是根據當前的一些數據或狀態去 預估 “未來”，所有會存在些誤差

首先確定 gc Goal goal = memstats.heap_marked + memstats.heap_marked*uint64(gcpercent)/100

heap_marked 為本輪 GC 存活量， gcpercent 默認為 100 ，可以通過環境變量 GOGC=100 或者 debug.SetGCPercent(100) 來設置

那么默認情況下 goal = 2 * heap_marked

gc_trigger 是與 goal 相關的一個值（ gc_trigger 大約為 goal 的 90% 左右），每輪 GC 標記完成時，會根據 |Ha-Hg| 和實際使用的 cpu 資源 動態調整 gc_trigger 與 goal 的差值

goal 與 gc_trigger 的差值即為，為 GC 期間分配的對象所預留的空間

GC pacing 還會預估下一輪 GC 發生時，需要掃描對象對象的總量，進而換算為下一輪 GC 所需的工作量，進而計算出 mark assist 的值

本輪 GC 觸發（ gc_trigger ），到本輪的 goal 期間，需要盡力完成 GC mark 標記操作，所以當 GC 期間，某個 goroutine 分配大量內存時，就會被拉去做 mark assist 工作，先進行 GC mark 標記賺取足夠的信用值后，才能分配對應大小的對象

根據本輪 GC 存活的內存量（ heap_marked ）和下一輪 GC 觸發的閾值（ gc_trigger ）計算 sweep assist 的值，本輪 GC 完成，到下一輪 GC 觸發（ gc_trigger ）時，需要盡力完成 sweep 清掃操作

預估下一輪 GC 所需的工作量的方式如下：

繼續分析文章開頭的問題，如何充分利用剩余內存，降低 GC 頻率和 GC 對 CPU 的資源消耗

如上圖可以看出， GC 后，存活的對象為 2GB 左右，如果將 gcpercent 設置為 400 ，那么就可以將下一輪 GC 觸發閾值提升到 10GB 左右

前面一輪看起來很好，提升了 GC 觸發的閾值到 10GB ，但是如果某一輪 GC 后的存活對象到達 2.5GB 的時候，那么下一輪 GC 觸發的閾值，將會超過內存閾值，造成 OOM （ Out of Memory ），進而導致程序崩潰。

可以通過 GOGC=off 或者 debug.SetGCPercent(-1) 來關閉 GC

可以通過進程外監控內存使用狀態，使用信號觸發的方式通知程序，或 ReadMemStats 、或 linkname runtime.heapRetained 等方式進行堆內存使用的監測

可以通過調用 runtime.GC() 或者 debug.FreeOSMemory() 來手動進行 GC 。

這里還需要說幾個事情來解釋這個方案所存在的問題

通過 GOGC=off 或者 debug.SetGCPercent(-1) 是如何關閉 GC 的？

gc 4 @1.006s 0%: 0.033+5.6+0.024 ms clock, 0.27+4.4/11/25+0.19 ms cpu, 428-428-16 MB, 17592186044415 MB goal, 8 P (forced)

通過 GC trace 可以看出，上面所說的 goal 變成了一個很詭異的值 17592186044415

實際上關閉 GC 后， Go 會將 goal 設置為一個極大值 ^uint64(0) ，那么對應的 GC 觸發閾值也被調成了一個極大值，這種處理方式看起來也沒什么問題，將閾值調大，預期永遠不會再觸發 GC

那么如果在關閉 GC 的情況下，手動調用 runtime.GC() 會導致什么呢？

由于 goal 和 gc_trigger 被設置成了極大值， mark assist 和 sweep assist 也會按照這個錯誤的值去計算，導致工作量預估錯誤，這一點可以從 trace 中進行證明

可以看到很詭異的 trace 圖，這里不做深究，該方案與 GC pacing 信用機制不兼容

記住，不要在關閉 GC 的情況下手動觸發 GC ，至少在當前 Go1.14 版本中仍存在這個問題

SetMaxHeap 的實現原理，簡單來說是強行控制了 goal 的值

注： SetMaxHeap ，本質上是一個軟限制，并不能解決 極端場景 下的 OOM ，可以配合內存監控和 debug.FreeOSMemory() 使用

SetMaxHeap 控制的是堆內存大小， Go 中除了堆內存還分配了如下內存，所以實際使用過程中，與實際硬件內存閾值之間需要留有一部分余量。

對于文章開始所述問題，使用 SetMaxHeap 后，預期的 GC 過程大概是這個樣子

簡單用法1

該方法簡單粗暴，直接將 goal 設置為了固定值

注：通過上文所講，觸發 GC 實際上是 gc_trigger ，所以當閾值設置為 12GB 時，會提前一點觸發 GC ，這里為了描述方便，近似認為 gc_trigger=goal

簡單用法2

當不關閉 GC 時， SetMaxHeap 的邏輯是， goal 仍按照 gcpercent 進行計算，當 goal 小于 SetMaxHeap 閾值時不進行處理；當 goal 大于 SetMaxHeap 閾值時，將 goal 限制為 SetMaxHeap 閾值

注：通過上文所講，觸發 GC 實際上是 gc_trigger ，所以當閾值設置為 12GB 時，會提前一點觸發 GC ，這里為了描述方便，近似認為 gc_trigger=goal

切換到 go1.14 分支，作者選擇了 git checkout go1.14.5

選擇官方提供的 cherry-pick 方式(可能需要梯子，文件改動不多，我后面會列出具體改動)

git fetch "" refs/changes/67/227767/3 git cherry-pick FETCH_HEAD

需要重新編譯Go源碼

注意點：

下面源碼中的官方注釋說的比較清楚，在一些關鍵位置加入了中文注釋

入參bytes為要設置的閾值

notify 簡單理解為 GC 的策略 發生變化時會向 channel 發送通知，后續源碼可以看出“策略”具體指哪些內容

返回值為本次設置之前的 MaxHeap 值

$GOROOT/src/runtime/debug/garbage.go

$GOROOT/src/runtime/mgc.go

注：作者盡量用通俗易懂的語言去解釋 Go 的一些機制和 SetMaxHeap 功能，可能有些描述與實現細節不完全一致，如有錯誤還請指出

本文題目：go語言實驗樓 go 語言實戰 pdf
本文鏈接：http://vcdvsql.cn/article46/dopgchg.html

成都網站建設公司_創新互聯，為您提供建站公司、網站改版、動態網站、用戶體驗、響應式網站、做網站

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯