本文目錄一覽：
golang是什麼意思？
Go(又稱Golang)是Google的Robert Griesemer，Rob Pike及Ken Thompson開發的一種靜態強類型、編譯型語言。Go語言語法與C相近，但功能上有：內存安全，GC(垃圾回收)，結構形態及CSP-style並發計算。
深入理解golang
最近三年，在工作中使用go開發了不少服務。深感go的便捷，以及它的runtime的複雜。我覺得需要定期的進行總結，因此決定寫這篇文章，也許更準確的，應該叫筆記。
最近終於解決了一個和cgo有關的問題。這個問題從發現到解決前後經歷了接近4個月，當然，和人手不足也有關係。而對於我個人而言，這個問題其實歷時2年！這得從頭說起。
在上一家公司的一個項目里，有一個服務做音視頻數據的提取，這個服務運行在嵌入式設備TX2上。音視頻提取這一關鍵功能主要利用nvidia基於gstreamer開發的插件，這個插件可以發揮nvidia gpu的硬體解碼功能。當時這個服務使用go和c混編的方式，問題的癥狀是服務運行一段時間後，不輸出音視頻數據。遺憾的是，由於疫情，項目停止，因此沒有機會繼續研究這個問題。
時間來到去年底。當前這個項目進行壓力測試，發現關鍵的語音處理服務運行一段時間後，會出現不拉流的情況，因此也沒有後續的結果輸出。癥狀和上一個項目非常像。雖然使用的第三方SDK不一樣，但同樣用了go和c混編的方式。一開始，焦點就放在go的運行時上，覺得可能是go和c相互調用的方式不對。經過合理猜測，並用測試進行驗證後，發現問題還是在第三方拉流的SDK上，它們的回調函數必須要快，否則有可能會阻塞它們的回調線程。當然，在go調用c的時候，如果耗時比較長，會對go的運行時造成一些副作用；在c回調go的時候，go的運行時也有可能阻塞c的回調線程。但go的運行時已經比較成熟，因此我覺得它對這個問題的貢獻不大。以上採用了假設-驗證的方法，主要的原因還是第三方的拉流SDK不開源。在定位問題的過程中，使用了gdb的gcore來生成堆棧；也搭建了灰度環境來進行壓力測試，以及完善監控，這些都是解決方法的一部分。
正是這一問題，促使我更多的了解go的運行時。而我看得越多，越覺得go的運行時是一個龐大的怪物。因此，抱著能了解一點是一點的心態，不斷的完善這篇筆記。
（十一）golang 內存分析
編寫過C語言程序的肯定知道通過malloc()方法動態申請內存，其中內存分配器使用的是glibc提供的ptmalloc2。 除了glibc，業界比較出名的內存分配器有Google的tcmalloc和Facebook的jemalloc。二者在避免內存碎片和性能上均比glic有比較大的優勢，在多線程環境中效果更明顯。
Golang中也實現了內存分配器，原理與tcmalloc類似，簡單的說就是維護一塊大的全局內存，每個線程(Golang中為P)維護一塊小的私有內存，私有內存不足再從全局申請。另外，內存分配與GC（垃圾回收）關係密切，所以了解GC前有必要了解內存分配的原理。
為了方便自主管理內存，做法便是先向系統申請一塊內存，然後將內存切割成小塊，通過一定的內存分配演算法管理內存。 以64位系統為例，Golang程序啟動時會向系統申請的內存如下圖所示：
預申請的內存劃分為spans、bitmap、arena三部分。其中arena即為所謂的堆區，應用中需要的內存從這裡分配。其中spans和bitmap是為了管理arena區而存在的。
arena的大小為512G，為了方便管理把arena區域劃分成一個個的page，每個page為8KB,一共有512GB/8KB個頁；
spans區域存放span的指針，每個指針對應一個page，所以span區域的大小為(512GB/8KB)乘以指針大小8byte = 512M
bitmap區域大小也是通過arena計算出來，不過主要用於GC。
span是用於管理arena頁的關鍵數據結構，每個span中包含1個或多個連續頁，為了滿足小對象分配，span中的一頁會劃分更小的粒度，而對於大對象比如超過頁大小，則通過多頁實現。
根據對象大小，劃分了一系列class，每個class都代表一個固定大小的對象，以及每個span的大小。如下表所示：
上表中每列含義如下：
class： class ID，每個span結構中都有一個class ID, 表示該span可處理的對象類型
bytes/obj：該class代表對象的位元組數
bytes/span：每個span佔用堆的位元組數，也即頁數乘以頁大小
objects: 每個span可分配的對象個數，也即（bytes/spans）/（bytes/obj）waste
bytes: 每個span產生的內存碎片，也即（bytes/spans）%（bytes/obj）上表可見最大的對象是32K大小，超過32K大小的由特殊的class表示，該class ID為0，每個class只包含一個對象。
span是內存管理的基本單位,每個span用於管理特定的class對象, 跟據對象大小，span將一個或多個頁拆分成多個塊進行管理。src/runtime/mheap.go:mspan定義了其數據結構：
以class 10為例，span和管理的內存如下圖所示：
spanclass為10，參照class表可得出npages=1,nelems=56,elemsize為144。其中startAddr是在span初始化時就指定了某個頁的地址。allocBits指向一個點陣圖，每位代表一個塊是否被分配，本例中有兩個塊已經被分配，其allocCount也為2。next和prev用於將多個span鏈接起來，這有利於管理多個span，接下來會進行說明。
有了管理內存的基本單位span，還要有個數據結構來管理span，這個數據結構叫mcentral，各線程需要內存時從mcentral管理的span中申請內存，為了避免多線程申請內存時不斷的加鎖，Golang為每個線程分配了span的緩存，這個緩存即是cache。src/runtime/mcache.go:mcache定義了cache的數據結構
alloc為mspan的指針數組，數組大小為class總數的2倍。數組中每個元素代表了一種class類型的span列表，每種class類型都有兩組span列表，第一組列表中所表示的對象中包含了指針，第二組列表中所表示的對象不含有指針，這麼做是為了提高GC掃描性能，對於不包含指針的span列表，沒必要去掃描。根據對象是否包含指針，將對象分為noscan和scan兩類，其中noscan代表沒有指針，而scan則代表有指針，需要GC進行掃描。mcache和span的對應關係如下圖所示：
mchache在初始化時是沒有任何span的，在使用過程中會動態的從central中獲取並緩存下來，跟據使用情況，每種class的span個數也不相同。上圖所示，class 0的span數比class1的要多，說明本線程中分配的小對象要多一些。
cache作為線程的私有資源為單個線程服務，而central則是全局資源，為多個線程服務，當某個線程內存不足時會向central申請，當某個線程釋放內存時又會回收進central。src/runtime/mcentral.go:mcentral定義了central數據結構：
lock: 線程間互斥鎖，防止多線程讀寫衝突
spanclass : 每個mcentral管理著一組有相同class的span列表
nonempty: 指還有內存可用的span列表
empty: 指沒有內存可用的span列表
nmalloc: 指累計分配的對象個數線程從central獲取span步驟如下：
將span歸還步驟如下：
從mcentral數據結構可見，每個mcentral對象只管理特定的class規格的span。事實上每種class都會對應一個mcentral,這個mcentral的集合存放於mheap數據結構中。src/runtime/mheap.go:mheap定義了heap的數據結構：
lock： 互斥鎖
spans: 指向spans區域，用於映射span和page的關係
bitmap：bitmap的起始地址
arena_start: arena區域首地址
arena_used: 當前arena已使用區域的最大地址
central: 每種class對應的兩個mcentral
從數據結構可見，mheap管理著全部的內存，事實上Golang就是通過一個mheap類型的全局變數進行內存管理的。mheap內存管理示意圖如下：
系統預分配的內存分為spans、bitmap、arean三個區域，通過mheap管理起來。接下來看內存分配過程。
針對待分配對象的大小不同有不同的分配邏輯：
(0, 16B) 且不包含指針的對象： Tiny分配
(0, 16B) 包含指針的對象：正常分配
[16B, 32KB] : 正常分配
(32KB, -) : 大對象分配其中Tiny分配和大對象分配都屬於內存管理的優化範疇，這裡暫時僅關注一般的分配方法。
以申請size為n的內存為例，分配步驟如下：
Golang內存分配是個相當複雜的過程，其中還摻雜了GC的處理，這裡僅僅對其關鍵數據結構進行了說明，了解其原理而又不至於深陷實現細節。1、Golang程序啟動時申請一大塊內存並劃分成spans、bitmap、arena區域
2、arena區域按頁劃分成一個個小塊。
3、span管理一個或多個頁。
4、mcentral管理多個span供線程申請使用
5、mcache作為線程私有資源，資源來源於mcentral。
這可能是最全的golang的”==”比較規則了吧
大家經常用”==”來比較兩個變數是否相等。但是golang中的”==”有很多細節的地方，跟php是不一樣的。很多時候不能直接用”==”來比較，編譯器會直接報錯。
golang中基本類型的比較規則和複合類型的不一致，先介紹下golang的變數類型：
golang中的基本類型
比較的兩個變數類型必須相等。而且，golang沒有隱式類型轉換，比較的兩個變數必須類型完全一樣，類型別名也不行。如果要比較，先做類型轉換再比較。
複合類型是逐個欄位，逐個元素比較的。需要注意的是， array 或者struct中每個元素必須要是可比較的，如果某個array的元素 or struct的成員不能比較(比如是後面介紹的slice，map等)，則此複合類型也不能比較。
逐個成員比較類型和值。每個對應成員的比較遵循基本類型變數的比較規則。
但是如果struct中有不可比較的成員類型時：
可以看到，struct中有slice這種不可比較的成員時，整個struct都不能做比較，即使沒有對slice那個成員賦值(slice默認值為nil)
slice和map的比較規則比較奇怪，我們先說普通的變數引用類型val和channel的比較規則。
引用類型變數存儲的是某個變數的內存地址。所以引用類型變數的比較，判斷的是這兩個引用類型存儲的是不是同一個變數。
上面看起來比較廢話，但是得理解引用類型的含義。不然對判斷規則還是不清楚。
slice類型不可比較，只能與零值nil做比較。
關於slice類型不可比較的原因，後面會專門寫文章做討論。
map類型和slice一樣，不能比較，只能與nil做比較。
介面類型的變數，包含該介面變數存儲的值和值的類型兩部分組成，分別稱為介面的動態類型和動態值。 只有動態類型和動態值都相同時，兩個介面變數才相同:
而且介面的動態類型必須要是可比較的，如果不能比較(比如slice，map)，則運行時會報panic。因為編譯器在編譯時無法獲取介面的動態類型，所以編譯能通過，但是運行時直接panic:
golang的func作為一等公民，也是一種類型，而且不可比較
上面說過，map和slice是不可比較類型，但是有沒有特殊的方法來對slice和map做比較呢，有
reflect.DeepEqual函數可以用來比較兩個任意類型的變數
對map類型做比較：
對slice類型做比較：
對struct類型做比較：
可以發現，只要變數的類型和值相同的話，reflect.DeepEqual比較的結果就為true
直接看用例：
結果為：
1， golang的類型再定義和類型別名
2，golang的slice和map為什麼不可以比較
1，
2，
3，
Golang 真的好用嗎？
好用，優點如下：
並發簡單、效率高
函數可以返回多個參數
垃圾回收（相比c/c++。不過java、c#都有這個優勢）
簡單易上手，語言特性少（也算缺點）
配套工具完善（pprof太好用了）
簡介
Go（又稱Golang）是Google開發的一種靜態強類型、編譯型、並髮型，並具有垃圾回收功能的編程語言。
羅伯特·格瑞史莫（Robert Griesemer），羅勃·派克（Rob Pike）及肯·湯普遜（Ken Thompson）於2007年9月開始設計Go，稍後Ian Lance Taylor、Russ Cox加入項目。Go是基於Inferno操作系統所開發的。Go於2009年11月正式宣布推出，成為開放源代碼項目。
並在Linux及Mac OS X平台上進行了實現，後來追加了Windows系統下的實現。在2016年，Go被軟體評價公司TIOBE 選為「TIOBE 2016 年最佳語言」。 目前，Go每半年發布一個二級版本（即從a.x升級到a.y）。
原創文章，作者：小藍，如若轉載，請註明出處：https://www.506064.com/zh-tw/n/153215.html
微信掃一掃 
支付寶掃一掃 