盧偉冰長文解析K60至尊版 對Redmi有著里程碑式的意義
在今天的Redmi后性能時代戰略發布會結束之后，Redmi總經理盧偉冰又帶來了一篇長文，詳解了為什么 Redmi 要開啟后性能時代？為什么選擇和 MediaTek、Pixelworks 深度合作？以及后性
Go提供了自動化的內存管理機制，但在某些情況下需要更精細的微調從而避免發生OOM錯誤。本文將討論Go的垃圾收集器、應用程序內存優化以及如何防止OOM(Out-Of-Memory)錯誤。
我不會詳細介紹垃圾收集器如何工作，已經有很多關于這個主題的文章和官方文檔(比如A Guide to the Go Garbage Collector[2]和源碼[3])。但是，我會提到一些有助于理解本文主題的基本概念。
你可能已經知道，Go的數據可以存儲在兩個主要的內存存儲中: 棧(stack)和堆(heap)。
通常，棧存儲的數據的大小和使用時間可以由Go編譯器預測，包括函數局部變量、函數參數、返回值等。
棧是自動管理的，遵循后進先出(LIFO)原則。當調用函數時，所有相關數據都放在棧的頂部，函數結束時，這些數據將從棧中刪除。棧不需要復雜的垃圾收集機制，其內存管理開銷最小，在棧中檢索和存儲數據的過程非?？?。
然而，并不是所有數據都可以存儲在棧中。在執行過程中動態更改的數據或需要在函數范圍之外訪問的數據不能放在棧上，因為編譯器無法預測其使用情況，這種數據應該存儲在堆中。
與棧不同，從堆中檢索數據并對其進行管理的成本更高。
正如前面提到的，棧用于具有可預測大小和壽命的值，例如:
Go編譯器在決定將數據放在棧中還是堆中時會考慮各種細微差別。
例如，預分配大小為64 KB的數據將存儲在棧中，而大于64 KB的數據將存儲在堆中。這同樣適用于數組，如果數組超過10 MB，將存儲在堆中。
可以使用逃逸分析(escape analysis)來確定特定變量的存儲位置。
例如，可以通過命令行編譯參數-gcflags=-m來分析應用程序:
go build -gcflags=-m main.go如果使用-gcflags=-m參數編譯下面的main.go:
package mainfunc main() { var arrayBefore10Mb [1310720]int arrayBefore10Mb[0] = 1 var arrayAfter10Mb [1310721]int arrayAfter10Mb[0] = 1 sliceBefore64 := make([]int, 8192) sliceOver64 := make([]int, 8193) sliceOver64[0] = sliceBefore64[0]}結果是:
# command-line-arguments./main.go:3:6: can inline main./main.go:7:6: moved to heap: arrayAfter10Mb./main.go:10:23: make([]int, 8192) does not escape./main.go:11:21: make([]int, 8193) escapes to heap可以看到arrayAfter10Mb數組被移動到堆中，因為大小超過了10MB，而arrayBefore10Mb仍然留在棧中(對于int變量，10MB等于10 * 1024 * 1024 / 8 = 1310720個元素)。
此外，sliceBefore64沒有存儲在堆中，因為它的大小小于64KB，而sliceOver64被存儲在堆中(對于int變量，64KB等于64 * 1024 / 8 = 8192個元素)。
要了解更多關于在堆中分配的位置和內容，可以參考malloc.go源碼[4]。
因此，使用堆的一種方法是盡量避免用它！但是，如果數據已經落在堆中了呢？
與棧不同，堆的大小是無限的，并且不斷增長。堆存儲動態創建的對象，如結構體、分片和映射，以及由于其限制而無法放入棧中的大內存塊。
在堆中重用內存并防止其完全阻塞的唯一工具是垃圾收集器。
垃圾收集器(GC)是一種專門用于識別和釋放動態分配內存的系統。
Go使用基于跟蹤和標記和掃描算法的垃圾收集算法。在標記階段，垃圾收集器將應用程序正在使用的數據標記為活躍堆。然后，在清理階段，GC遍歷所有未標記為活躍的內存并復用。
垃圾收集器不是免費工作的，需要消耗兩個重要的系統資源: CPU時間和物理內存。
垃圾收集器中的內存由以下部分組成:
垃圾收集器所消耗的CPU時間與其工作細節有關。有一種稱為"stop-the-world"的垃圾收集器實現，它在垃圾收集期間完全停止程序執行，導致CPU時間被花在非生產性工作上。
在Go里，垃圾收集器并不是完全"stop-the-world"，而是與應用程序并行執行其大部分工作(例如標記堆)。
但是，垃圾收集器的操作仍然有一些限制，并且會在一個周期內多次完全停止工作代碼的執行，想要了解更多可以閱讀源碼[5]。
在Go中可以通過某些參數管理垃圾收集器: GOGC環境變量或runtime/debug包中的等效函數SetGCPercent。
GOGC參數確定將觸發垃圾收集的新未分配堆內存相對于活躍內存的百分比。
GOGC的默認值是100，意味著當新內存達到活躍堆內存的100%時將觸發垃圾收集。
當新堆占用活躍堆的100%時，將運行垃圾收集器
我們以示例程序為例，通過go tool trace跟蹤堆大小的變化，我們用Go 1.20.1版本來運行程序。
在本例中，performMemoryIntensiveTask函數使用了在堆中分配的大量內存。這個函數啟動一個隊列大小為NumWorker的工作池，任務數量等于NumTasks。
package mainimport ( "fmt" "os" "runtime/debug" "runtime/trace" "sync")const ( NumWorkers = 4 // Number of workers. NumTasks = 500 // Number of tasks. MemoryIntense = 10000 // Size of memory-intensive task (number of elements).)func main() { // Write to the trace file. f, _ := os.Create("trace.out") trace.Start(f) defer trace.Stop() // Set the target percentage for the garbage collector. Default is 100%. debug.SetGCPercent(100) // Task queue and result queue. taskQueue := make(chan int, NumTasks) resultQueue := make(chan int, NumTasks) // Start workers. var wg sync.WaitGroup wg.Add(NumWorkers) for i := 0; i < NumWorkers; i++ { go worker(taskQueue, resultQueue, &wg) } // Send tasks to the queue. for i := 0; i < NumTasks; i++ { taskQueue <- i } close(taskQueue) // Retrieve results from the queue. go func() { wg.Wait() close(resultQueue) }() // Process the results. for result := range resultQueue { fmt.Println("Result:", result) } fmt.Println("Done!")}// Worker function.func worker(tasks <-chan int, results chan<- int, wg *sync.WaitGroup) { defer wg.Done() for task := range tasks { result := performMemoryIntensiveTask(task) results <- result }}// performMemoryIntensiveTask is a memory-intensive function.func performMemoryIntensiveTask(task int) int { // Create a large-sized slice. data := make([]int, MemoryIntense) for i := 0; i < MemoryIntense; i++ { data[i] = i + task } // Latency imitation. time.Sleep(10 * time.Millisecond) // Calculate the result. result := 0 for _, value := range data { result += value } return result}跟蹤程序執行的結果被寫入文件trace.out:
// Writing to the trace file.f, _ := os.Create("trace.out")trace.Start(f)defer trace.Stop()通過go tool trace，可以觀察堆大小的變化，并分析程序中垃圾收集器的行為。
請注意，go tool trace的精確細節和功能可能因go版本不同而有所差異，因此建議參考官方文檔，以獲取有關其在特定go版本中使用的詳細信息。
GOGC參數可以使用runtime/debug包中的debug.SetGCPercent進行設置，GOGC默認設置為100%。
用下面命令運行程序:
go run main.go程序執行后，將會創建trace.out文件，可以使用go tool工具對其進行分析。要做到這一點，執行命令:
go tool trace trace.out然后可以通過打開web瀏覽器并訪問http://127.0.0.1:54784/trace來查看基于web的跟蹤查看器。
GOGC = 100
在"STATS"選項卡中，可以看到"Heap"字段，顯示了在應用程序執行期間堆大小的變化情況，圖中紅色區域表示堆占用的內存。
在"PROCS"選項卡中，"GC"(垃圾收集器)字段顯示的藍色列表示觸發垃圾收集器的時刻。
一旦新堆的大小達到活動堆大小的100%，就會觸發垃圾收集。例如，如果活躍堆大小為10 MB，則當當前堆大小達到10 MB時將觸發垃圾收集。
跟蹤所有垃圾收集調用使我們能夠確定垃圾收集器處于活動狀態的總時間。
GOGC=100時的GC調用次數
示例中，當GOGC值為100時，將調用垃圾收集器16次，總執行時間為14 ms。
如果我們將debug.SetGCPercent(10)設置為10%后運行代碼，將觀察到垃圾收集器調用的頻率更高?，F在，如果當前堆大小達到活躍堆大小的10%時，將觸發垃圾收集。
換句話說，如果活躍堆大小為10 MB，則當前堆大小達到1 MB時就將觸發垃圾收集。
GOGC = 10
在本例中，垃圾收集器被調用了38次，總垃圾收集時間為28 ms。
GOGC=10時的GC調用次數
可以觀察到，將GOGC設置為低于100%的值可以增加垃圾收集的頻率，可能導致CPU使用率增加并降低程序性能。
如果運行相同程序，但將debug.SetGCPercent(1000)設置為1000%，我們將得到以下結果:
GOGC = 1000
可以看到，當前堆的大小一直在增長，直到達到活躍堆大小的1000%。換句話說，如果活躍堆大小為10 MB，則當前堆大小達到100 MB時將觸發垃圾收集。
GOGC=1000時的GC調用次數
在當前情況下，垃圾收集器被調用一次并執行2毫秒。
還可以通過設置GOGC=off或調用debug.SetGCPercent(-1)來禁用垃圾收集。
下面是禁用垃圾收集器而不設置GOMEMLIMIT時堆的行為:
當GC=off時，堆大小不斷增長。
可以看到，在關閉GC后，應用程序的堆大小一直在增長，直到程序執行為止。
在活躍堆的實際內存分配中，通常不像我們在trace中看到的那樣定期和可預測的工作。
活躍堆隨著每個垃圾收集周期動態變化，并且在某些條件下，其絕對值可能出現峰值。
例如，如果由于多個并行任務的重疊，活躍堆的大小可以增長到800 MB，那么只有在當前堆大小達到1.6 GB時才會觸發垃圾收集。
現代開發通常在具有內存使用限制的容器中運行應用。因此，如果容器將內存限制設置為1 GB，并且總堆大小增加到1.6 GB，則容器將失效，并出現OOM(out of memory)錯誤。
讓我們模擬一下這種情況。例如，我們在內存限制為10 MB的容器中運行程序(僅用于測試目的)。Dockerfile:
FROM golang:latest as builderWORKDIR /srcCOPY . .RUN go env -w GO111MODULE=onRUN go mod vendorRUN CGO_ENABLED=0 GOOS=linux go build -mod=vendor -a -installsuffix cgo -o app ./cmd/FROM golang:latestWORKDIR /root/COPY --from=builder /src/app .EXPOSE 8080CMD ["./app"]Docker-compose描述:
version: '3'services: my-app: build: context: . dockerfile: Dockerfile ports: - 8080:8080 deploy: resources: limits: memory: 10M讓我們使用前面設置GOGC=1000%的代碼啟動容器。
可以使用以下命令運行容器:
docker-compose builddocker-compose up幾秒鐘后，容器將崩潰，并產生與OOM相對應的錯誤。
exited with code 137這種情況非常令人不快: GOGC只控制新堆的相對值，而容器有絕對限制。
從1.19版本開始，在GOMEMLIMIT選項的幫助下，Golang引入了一個名為"軟內存管理"的特性，runtime/debug包中名為SetMemoryLimit的類似函數(可以閱讀48409-soft-memory-limit.md[6]了解有關此選項的一些有趣的設計細節)提供了相同的功能。
GOMEMLIMIT環境變量設置Go運行時可以使用的總體內存限制，例如: GOMEMLIMIT = 8MiB。要設置內存值，需要使用大小后綴，在本例中為8 MB。
讓我們啟動將GOMEMLIMIT境變量設置為8MiB的容器。為此，我們將環境變量添加到docker-compose文件中:
version: '3'services: my-app: environment: GOMEMLIMIT: "8MiB" build: context: . dockerfile: Dockerfile ports: - 8080:8080 deploy: resources: limits: memory: 10M現在，當啟動容器時，程序運行沒有任何錯誤。該機制是專門為解決OOM問題而設計的。
這是因為啟用GOMEMLIMIT=8MiB后，會定期調用垃圾收集器，并將堆大小保持在一定限制內，結果就是會頻繁調用垃圾收集器以避免內存過載。
運行垃圾收集器以使堆大小保持在一定的限制內。
GOMEMLIMIT是強有力的工具，但也可能適得其反。
在上面的堆跟蹤圖中可以看到這種場景的一個示例。
當總內存大小由于活躍堆或持久程序泄漏的增長而接近GOMEMLIMIT時，將開始根據該限制不斷調用垃圾收集器。
由于頻繁調用垃圾收集器，應用程序的運行時可能會無限增加，從而消耗應用程序的CPU時間。
這種行為被稱為死亡螺旋[7]，可能導致應用程序性能下降，與OOM錯誤不同，這種問題很難檢測和修復。
這正是GOMEMLIMIT機制作為軟限制起作用的原因。
Go不能100%保證GOMEMLIMIT指定的內存限制會被嚴格執行，而是會允許使用超出限制的內存，并防止頻繁調用垃圾收集器的情況。
為了實現這一點，需要對CPU使用設置限制。目前，這個限制被設置為所有處理器時間的50%，CPU窗口為2 * GOMAXPROCS秒。
這就是為什么我們不能完全避免OOM錯誤，而是會將其推遲到很久以后發生。
如果默認垃圾收集器設置在大多數情況下是足夠的，那么帶有GOMEMLIMIT的軟內存管理機制可以使我們避免不愉快的情況。
使用GOMEMLIMIT內存限制可能有用的例子:
避免使用GOMEMLIMIT的情況:
如上所述，通過深思熟慮的方法，我們可以管理程序中的微調設置，例如垃圾收集器和GOMEMLIMIT。然而，仔細考慮應用這些設置的策略無疑非常重要。
本文鏈接：http://m.www897cc.com/showinfo-26-61903-0.htmlGo 內存優化與垃圾收集
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 基于 Rust 的 linter 工具速度很快，但有嚴重缺陷...
下一篇： 高可靠的跨系統轉賬如何設計
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號