golang 記憶體 Clerk

背景

go的很多東西是內斂的，提倡大道至簡，但是，我們也看到過對於一些對效能要求比較高的業務情境(比如遊戲的某些業務情境)，使用cgo等技術手段來繞過go的記憶體回收。所以說，我們不要把所有的目光都盯到那95%上，依然還有5%的情況是需要我們來處理的。即便在今天來看，記憶體依然是非常緊缺的資源，那麼我們可以想象一下，如何管理和分配記憶體資源，這是一個非常有挑戰的話題。

下面我們來看一下這段代碼，看看記憶體究竟發生來什麼。

package mainfunc A() *int {  x := 100  return &x}

但是如果有c語言經驗的人，會知道這個代碼是有問題的，我們來簡單測試一下這個代碼。

package mainimport "testing"func BenchmarkA (b *testing.B){  for i := 0; i < b.N; i++{    A()  }}

執行go test -v -test.bench . -benchmem之後，測試結果如下：

goos: darwingoarch: amd64pkg: golang/runtimeBenchmarkA-4    2000000000               0.32 ns/op            0 B/op          0 allocs/opPASSok      golang/runtime  0.739s

感覺沒有什麼問題，只是做效能測試，那麼我在不修改參數的情況下，加一個參數，禁止函數內聯，我們再進行一下測試

執行go test -v -test.bench . -benchmem -gcflags -l，繼續執行，測試情況如下：

goos: darwingoarch: amd64pkg: golang/runtimeBenchmarkA-4    100000000               15.8 ns/op             8 B/op          1 allocs/opPASSok      golang/runtime  1.646s

我們可以看到效能下降的很嚴重，關鍵是，它每次執行都會在記憶體上進行一次
分配， 64位系統的是8位元組（整數指標），很顯然，go對於記憶體配置的這種行為是由運行時和編譯器來決定的，跟我們寫的代碼無關，也就是當我們寫下這段代碼的時候，我們並不能保證我們的變數是分配在棧上還是堆上的。

應用系統可能有時候不太關心，但是我們可以想象一下，每秒鐘會在記憶體中分配幾十萬個臨時對象，這幾十萬個臨時對象會對GC造成多大的壓力。因為有時候記憶體回收並不在乎你這個對象是大是小，而在乎的是你這個對象有多少個，為什嗎？因為他需要檢查你的每個對象究竟是不是可達的，他需要把所有可達對象保留下來，把所有不可達對象回收了。也就是說，在單位時間內，堆上的臨時對象越多，記憶體回收的壓力越大。小小的一個控制開關，會導致你的效能有很大的影響。記憶體在棧上分配，變成了在堆上分配。

記憶體 Clerk由來

記憶體單元

初始化和基本架構

記憶體配置

記憶體回收

實體記憶體釋放