golang調用彙編代碼,golang調用java代碼

本文目錄一覽：

• 1、GoLang — Gin框架
• 2、徹底理解Golang Map
• 3、golang如何實現urldecode
• 4、bpftrace動態追蹤golang應用-函數內聯問題
• 5、如何在golang 中調用c的靜態庫或者動態庫
• 6、golang項目中使用條件編譯

GoLang — Gin框架

• 何為框架：

框架一直是敏捷開發中的利器，能讓開發者很快的上手並做出應用，甚至有的時候，脫離了框架，一些開發者都不會寫程序了。成長總不會一蹴而就，從寫出程序獲取成就感，再到精通框架，快速構造應用，當這些方面都得心應手的時候，可以嘗試改造一些框架，或是自己創造一個。

Gin是一個golang的微框架，封裝比較優雅，API友好，源碼注釋比較明確，已經發佈了1.0版本。具有快速靈活，容錯方便等特點。其實對於golang而言，web框架的依賴要遠比Python，Java之類的要小。自身的net/http足夠簡單，性能也非常不錯。框架更像是一些常用函數或者工具的集合。藉助框架開發，不僅可以省去很多常用的封裝帶來的時間，也有助於團隊的編碼風格和形成規範。

（1）首先需要安裝，安裝比較簡單，使用go get即可

go get github.com/gin-gonic/gin

如果安裝失敗，直接去Github clone下來，放置到對應的目錄即可。

（2）代碼中使用：

下面是一個使用Gin的簡單例子：

package main

import (

“github.com/gin-gonic/gin”

)

func main() {

router := gin.Default()

router.GET(“/ping”, func(c *gin.Context) {

c.JSON(200, gin.H{

“message”: “pong”,

})

})

router.Run(“:8080”) // listen and serve on 0.0.0.0:8080

}

簡單幾行代碼，就能實現一個web服務。使用gin的Default方法創建一個路由handler。然後通過HTTP方法綁定路由規則和路由函數。不同於net/http庫的路由函數，gin進行了封裝，把request和response都封裝到gin.Context的上下文環境。最後是啟動路由的Run方法監聽端口。麻雀雖小，五臟俱全。當然，除了GET方法，gin也支持POST,PUT,DELETE,OPTION等常用的restful方法。

Gin可以很方便的支持各種HTTP請求方法以及返回各種類型的數據，詳情可以前往查看。

2.1 匹配參數

我們可以使用Gin框架快速的匹配參數，如下代碼所示：

冒號:加上一個參數名組成路由參數。可以使用c.Param的方法讀取其值。當然這個值是字串string。諸如/user/rsj217，和/user/hello都可以匹配，而/user/和/user/rsj217/不會被匹配。

瀏覽器輸入以下測試：

返回結果為：

其中c.String是gin.Context下提供的方法，用來返回字符串。

其中c.Json是gin.Context下提供的方法，用來返回Json。

下面我們使用以下gin提供的Group函數，方便的為不同的API進行分類。

我們創建了一個gin的默認路由，並為其分配了一個組 v1，監聽hello請求並將其路由到視圖函數HelloPage，最後綁定到 0.0.0.0:8000

C.JSON是Gin實現的返回json數據的內置方法，包含了2個參數，狀態碼和返回的內容。http.StatusOK代表返回狀態碼為200，正文為{“message”: 「welcome”}。

註：Gin還包含更多的返回方法如c.String, c.HTML, c.XML等，請自行了解。可以方便的返回HTML數據

我們在之前的組v1路由下新定義一個路由：

下面我們訪問

可以看到，通過c.Param(「key」)方法，Gin成功捕獲了url請求路徑中的參數。同理，gin也可以捕獲常規參數，如下代碼所示：

在瀏覽器輸入以下代碼：

通過c.Query(「key」)可以成功接收到url參數，c.DefaultQuery在參數不存在的情況下，會由其默認值代替。

我們還可以為Gin定義一些默認路由：

這時候，我們訪問一個不存在的頁面：

返回如下所示：

下面我們測試在Gin裏面使用Post

在測試端輸入：

附帶發送的數據，測試即可。記住需要使用POST方法.

繼續修改，將PostHandler的函數修改如下

測試工具輸入：

發送的內容輸入：

返回結果如下：

備註：此處需要指定Content-Type為application/x-www-form-urlencoded，否則識別不出來。

一定要選擇對應的PUT或者DELETE方法。

Gin框架快速的創建路由

能夠方便的創建分組

支持url正則表達式

支持參數查找（c.Param c.Query c.PostForm）

請求方法精準匹配

支持404處理

快速的返回給客戶端數據，常用的c.String c.JSON c.Data

徹底理解Golang Map

本文目錄如下，閱讀本文後，將一網打盡下面Golang Map相關面試題

Go中的map是一個指針，佔用8個位元組，指向hmap結構體; 源碼 src/runtime/map.go 中可以看到map的底層結構

每個map的底層結構是hmap，hmap包含若干個結構為bmap的bucket數組。每個bucket底層都採用鏈表結構。接下來，我們來詳細看下map的結構

bmap 就是我們常說的「桶」，一個桶裏面會最多裝 8 個 key，這些 key 之所以會落入同一個桶，是因為它們經過哈希計算後，哈希結果是「一類」的，關於key的定位我們在map的查詢和插入中詳細說明。在桶內，又會根據 key 計算出來的 hash 值的高 8 位來決定 key 到底落入桶內的哪個位置（一個桶內最多有8個位置)。

bucket內存數據結構可視化如下：

注意到 key 和 value 是各自放在一起的，並不是 key/value/key/value/… 這樣的形式。源碼里說明這樣的好處是在某些情況下可以省略掉 padding字段，節省內存空間。

當 map 的 key 和 value 都不是指針，並且 size 都小於 128 位元組的情況下，會把 bmap 標記為不含指針，這樣可以避免 gc 時掃描整個 hmap。但是，我們看 bmap 其實有一個 overflow 的字段，是指針類型的，破壞了 bmap 不含指針的設想，這時會把 overflow 移動到 extra 字段來。

map是個指針，底層指向hmap，所以是個引用類型

golang 有三個常用的高級類型 slice 、map、channel, 它們都是 引用類型 ，當引用類型作為函數參數時，可能會修改原內容數據。

golang 中沒有引用傳遞，只有值和指針傳遞。所以 map 作為函數實參傳遞時本質上也是值傳遞，只不過因為 map 底層數據結構是通過指針指向實際的元素存儲空間，在被調函數中修改 map，對調用者同樣可見，所以 map 作為函數實參傳遞時表現出了引用傳遞的效果。

因此，傳遞 map 時，如果想修改map的內容而不是map本身，函數形參無需使用指針

map 底層數據結構是通過指針指向實際的元素 存儲空間 ，這種情況下，對其中一個map的更改，會影響到其他map

map 在沒有被修改的情況下，使用 range 多次遍歷 map 時輸出的 key 和 value 的順序可能不同。這是 Go 語言的設計者們有意為之，在每次 range 時的順序被隨機化，旨在提示開發者們，Go 底層實現並不保證 map 遍歷順序穩定，請大家不要依賴 range 遍歷結果順序。

map 本身是無序的，且遍歷時順序還會被隨機化，如果想順序遍歷 map，需要對 map key 先排序，再按照 key 的順序遍歷 map。

map默認是並發不安全的，原因如下：

Go 官方在經過了長時間的討論後，認為 Go map 更應適配典型使用場景（不需要從多個 goroutine 中進行安全訪問），而不是為了小部分情況（並發訪問），導致大部分程序付出加鎖代價（性能），決定了不支持。

場景: 2個協程同時讀和寫，以下程序會出現致命錯誤：fatal error: concurrent map writes

如果想實現map線程安全，有兩種方式：

方式一：使用讀寫鎖 map + sync.RWMutex

方式二：使用golang提供的 sync.Map

sync.map是用讀寫分離實現的，其思想是空間換時間。和map+RWLock的實現方式相比，它做了一些優化：可以無鎖訪問read map，而且會優先操作read map，倘若只操作read map就可以滿足要求(增刪改查遍歷)，那就不用去操作write map(它的讀寫都要加鎖)，所以在某些特定場景中它發生鎖競爭的頻率會遠遠小於map+RWLock的實現方式。

golang中map是一個kv對集合。底層使用hash table，用鏈表來解決衝突 ，出現衝突時，不是每一個key都申請一個結構通過鏈表串起來，而是以bmap為最小粒度掛載，一個bmap可以放8個kv。在哈希函數的選擇上，會在程序啟動時，檢測 cpu 是否支持 aes，如果支持，則使用 aes hash，否則使用 memhash。

map有3鍾初始化方式，一般通過make方式創建

map的創建通過生成彙編碼可以知道，make創建map時調用的底層函數是 runtime.makemap 。如果你的map初始容量小於等於8會發現走的是 runtime.fastrand 是因為容量小於8時不需要生成多個桶，一個桶的容量就可以滿足

makemap函數會通過 fastrand 創建一個隨機的哈希種子，然後根據傳入的 hint 計算出需要的最小需要的桶的數量，最後再使用 makeBucketArray 創建用於保存桶的數組，這個方法其實就是根據傳入的 B 計算出的需要創建的桶數量在內存中分配一片連續的空間用於存儲數據，在創建桶的過程中還會額外創建一些用於保存溢出數據的桶，數量是 2^(B-4) 個。初始化完成返回hmap指針。

找到一個 B，使得 map 的裝載因子在正常範圍內

Go 語言中讀取 map 有兩種語法：帶 comma 和 不帶 comma。當要查詢的 key 不在 map 里，帶 comma 的用法會返回一個 bool 型變量提示 key 是否在 map 中；而不帶 comma 的語句則會返回一個 value 類型的零值。如果 value 是 int 型就會返回 0，如果 value 是 string 類型，就會返回空字符串。

map的查找通過生成彙編碼可以知道，根據 key 的不同類型，編譯器會將查找函數用更具體的函數替換，以優化效率：

函數首先會檢查 map 的標誌位 flags。如果 flags 的寫標誌位此時被置 1 了，說明有其他協程在執行「寫」操作，進而導致程序 panic。這也說明了 map 對協程是不安全的。

key經過哈希函數計算後，得到的哈希值如下（主流64位機下共 64 個 bit 位）：

m: 桶的個數

從buckets 通過 hash m 得到對應的bucket，如果bucket正在擴容，並且沒有擴容完成，則從oldbuckets得到對應的bucket

計算hash所在桶編號：

用上一步哈希值最後的 5 個 bit 位，也就是 01010 ，值為 10，也就是 10 號桶（範圍是0~31號桶）

計算hash所在的槽位:

用上一步哈希值哈希值的高8個bit 位，也就是 10010111 ，轉化為十進制，也就是151，在 10 號 bucket 中尋找** tophash 值（HOB hash）為 151* 的 槽位**，即為key所在位置，找到了 2 號槽位，這樣整個查找過程就結束了。

如果在 bucket 中沒找到，並且 overflow 不為空，還要繼續去 overflow bucket 中尋找，直到找到或是所有的 key 槽位都找遍了，包括所有的 overflow bucket。

通過上面找到了對應的槽位，這裡我們再詳細分析下key/value值是如何獲取的：

bucket 里 key 的起始地址就是 unsafe.Pointer(b)+dataOffset。第 i 個 key 的地址就要在此基礎上跨過 i 個 key 的大小；而我們又知道，value 的地址是在所有 key 之後，因此第 i 個 value 的地址還需要加上所有 key 的偏移。

通過彙編語言可以看到，向 map 中插入或者修改 key，最終調用的是 mapassign 函數。

實際上插入或修改 key 的語法是一樣的，只不過前者操作的 key 在 map 中不存在，而後者操作的 key 存在 map 中。

mapassign 有一個系列的函數，根據 key 類型的不同，編譯器會將其優化為相應的「快速函數」。

我們只用研究最一般的賦值函數 mapassign 。

map的賦值會附帶着map的擴容和遷移，map的擴容只是將底層數組擴大了一倍，並沒有進行數據的轉移，數據的轉移是在擴容後逐步進行的，在遷移的過程中每進行一次賦值（access或者delete）會至少做一次遷移工作。

1.判斷map是否為nil

每一次進行賦值/刪除操作時，只要oldbuckets != nil 則認為正在擴容，會做一次遷移工作，下面會詳細說下遷移過程

根據上面查找過程，查找key所在位置，如果找到則更新，沒找到則找空位插入即可

經過前面迭代尋找動作，若沒有找到可插入的位置，意味着需要擴容進行插入，下面會詳細說下擴容過程

通過彙編語言可以看到，向 map 中刪除 key，最終調用的是 mapdelete 函數

刪除的邏輯相對比較簡單，大多函數在賦值操作中已經用到過，核心還是找到 key 的具體位置。尋找過程都是類似的，在 bucket 中挨個 cell 尋找。找到對應位置後，對 key 或者 value 進行「清零」操作，將 count 值減 1，將對應位置的 tophash 值置成 Empty

再來說觸發 map 擴容的時機：在向 map 插入新 key 的時候，會進行條件檢測，符合下面這 2 個條件，就會觸發擴容：

1、裝載因子超過閾值

源碼里定義的閾值是 6.5 (loadFactorNum/loadFactorDen)，是經過測試後取出的一個比較合理的因子

我們知道，每個 bucket 有 8 個空位，在沒有溢出，且所有的桶都裝滿了的情況下，裝載因子算出來的結果是 8。因此當裝載因子超過 6.5 時，表明很多 bucket 都快要裝滿了，查找效率和插入效率都變低了。在這個時候進行擴容是有必要的。

對於條件 1，元素太多，而 bucket 數量太少，很簡單：將 B 加 1，bucket 最大數量( 2^B )直接變成原來 bucket 數量的 2 倍。於是，就有新老 bucket 了。注意，這時候元素都在老 bucket 里，還沒遷移到新的 bucket 來。新 bucket 只是最大數量變為原來最大數量的 2 倍( 2^B * 2 ) 。

2、overflow 的 bucket 數量過多

在裝載因子比較小的情況下，這時候 map 的查找和插入效率也很低，而第 1 點識別不出來這種情況。表面現象就是計算裝載因子的分子比較小，即 map 里元素總數少，但是 bucket 數量多（真實分配的 bucket 數量多，包括大量的 overflow bucket）

不難想像造成這種情況的原因：不停地插入、刪除元素。先插入很多元素，導致創建了很多 bucket，但是裝載因子達不到第 1 點的臨界值，未觸發擴容來緩解這種情況。之後，刪除元素降低元素總數量，再插入很多元素，導致創建很多的 overflow bucket，但就是不會觸發第 1 點的規定，你能拿我怎麼辦？overflow bucket 數量太多，導致 key 會很分散，查找插入效率低得嚇人，因此出台第 2 點規定。這就像是一座空城，房子很多，但是住戶很少，都分散了，找起人來很困難

對於條件 2，其實元素沒那麼多，但是 overflow bucket 數特別多，說明很多 bucket 都沒裝滿。解決辦法就是開闢一個新 bucket 空間，將老 bucket 中的元素移動到新 bucket，使得同一個 bucket 中的 key 排列地更緊密。這樣，原來，在 overflow bucket 中的 key 可以移動到 bucket 中來。結果是節省空間，提高 bucket 利用率，map 的查找和插入效率自然就會提升。

由於 map 擴容需要將原有的 key/value 重新搬遷到新的內存地址，如果有大量的 key/value 需要搬遷，會非常影響性能。因此 Go map 的擴容採取了一種稱為「漸進式」的方式，原有的 key 並不會一次性搬遷完畢，每次最多只會搬遷 2 個 bucket。

上面說的 hashGrow() 函數實際上並沒有真正地「搬遷」，它只是分配好了新的 buckets，並將老的 buckets 掛到了 oldbuckets 字段上。真正搬遷 buckets 的動作在 growWork() 函數中，而調用 growWork() 函數的動作是在 mapassign 和 mapdelete 函數中。也就是插入或修改、刪除 key 的時候，都會嘗試進行搬遷 buckets 的工作。先檢查 oldbuckets 是否搬遷完畢，具體來說就是檢查 oldbuckets 是否為 nil。

如果未遷移完畢，賦值/刪除的時候，擴容完畢後（預分配內存），不會馬上就進行遷移。而是採取 增量擴容 的方式，當有訪問到具體 bukcet 時，才會逐漸的進行遷移（將 oldbucket 遷移到 bucket）

nevacuate 標識的是當前的進度，如果都搬遷完，應該和2^B的長度是一樣的

在evacuate 方法實現是把這個位置對應的bucket，以及其衝突鏈上的數據都轉移到新的buckets上。

轉移的判斷直接通過tophash 就可以，判斷tophash中第一個hash值即可

遍歷的過程，就是按順序遍歷 bucket，同時按順序遍歷 bucket 中的 key。

map遍歷是無序的，如果想實現有序遍歷，可以先對key進行排序

為什麼遍歷 map 是無序的？

如果發生過遷移，key 的位置發生了重大的變化，有些 key 飛上高枝，有些 key 則原地不動。這樣，遍歷 map 的結果就不可能按原來的順序了。

如果就一個寫死的 map，不會向 map 進行插入刪除的操作，按理說每次遍歷這樣的 map 都會返回一個固定順序的 key/value 序列吧。但是 Go 杜絕了這種做法，因為這樣會給新手程序員帶來誤解，以為這是一定會發生的事情，在某些情況下，可能會釀成大錯。

Go 做得更絕，當我們在遍歷 map 時，並不是固定地從 0 號 bucket 開始遍歷，每次都是從一個**隨機值序號的 bucket 開始遍歷，並且是從這個 bucket 的一個 隨機序號的 cell **開始遍歷。這樣，即使你是一個寫死的 map，僅僅只是遍歷它，也不太可能會返回一個固定序列的 key/value 對了。

golang如何實現urldecode

首先你的理解是錯的，不管用戶態的API(syscall)是否是同步還是異步，在kernel層面都是異步的。

其實實現原理很簡單，就是利用C(嵌入彙編)語言可以直接修改寄存器(setcontext/setjmp/longjmp均是類似原理，修改程序指針eip實現跳轉，棧指針實現上線文切換)來實現從func_a調進去，從func_b返回出來這種行為。對於golang來說，func_a/func_b屬於不同的goroutine，從而就實現了goroutine的調度切換。

另外對於所有可能阻塞的syscall，golang對其進行了封裝，底層實際是epoll方式做的，註冊回調後切換到另一個runnable的goroutine。

bpftrace動態追蹤golang應用-函數內聯問題

在上一篇文章的golang代碼中，函數add的上一行，增加了一條注釋語句： //go:noinline 。在bpftrace追蹤時，是否可以去掉？有什麼作用？

為了說明該問題，設計一個例子。

golang代碼中，有兩個求和函數。其中，add1加上 //go:noinline ，另一個add2不加。代碼如下：

bpftrace程序分別對函數add1和add2的輸入參數、返回值進行追蹤，代碼如下：

執行程序後，可以看到bpftrace程序能夠正常追蹤到函數add1，但是無法追蹤到函數add2。

通過上文中的示例代碼，可以看到，沒有加 //go:noinline 的函數無法被bpftrace程序追蹤到。通過查閱golang相關文檔，可以知道， //go:noinline 表示該函數在編譯時，不會被內聯。

使用 objump -S 生成golang程序的彙編代碼如下：

通過彙編代碼，我們可以看到，主函數中，地址 0x498e52 處 callq 498e00 調用了add1函數，地址 0x498ebb 處 movq $0x4,(%rsp) 直接計算求值。

因此，golang編譯器在編譯代碼時，會對代碼進行分析，並按照內聯規則，將某些函數生成內聯代碼。一旦函數被內聯，bpftrace將無法追蹤到對應函數。也就是，上文中函數 add2 無法被追蹤到。

針對golang程序中編譯器內聯的問題，可以通過禁止內聯的方式來解決。禁止內聯的方式有：

在實踐中，可以通過 go build -gcflags=”-m -m” 來查看，哪些函數會在編譯時執行內聯，如：

從輸出中，可以看到：

關於golang編譯器進行內聯的場景，可以參考golang源碼：。

由於golang編譯器內聯優化，bpftrace可能無法正常追蹤golang程序。在編寫bpftrace腳本時，可以先使用 nm 命令查看一下可執行程序，是否存在需要追蹤的函數的符號信息。如果沒有則bpftrace將不能對其進行追蹤。

前面的示例中，都是對 int 類型的參數進行追蹤，那對於 string 類型的參數，是否也可以用同樣的方式進行追蹤？將在下一篇中進行討論。

如何在golang 中調用c的靜態庫或者動態庫

Cgo 使得Go程序能夠調用C代碼. cgo讀入一個用特別的格式寫的Go語言源文件, 輸出Go和C程序, 使得C程序能打包到Go語言的程序包中.

舉例說明一下. 下面是一個Go語言包, 包含了兩個函數 — Random 和 Seed — 是C語言庫中random和srandom函數的馬甲.

package rand

/*

#include stdlib.h

*/ import “C” func Random() int { return int(C.random()) } func Seed(i int) { C.srandom(C.uint(i)) }

我們來看一下這裡都有什麼內容. 開始是一個包的導入語句.

rand包導入了”C”包, 但你會發現在Go的標準庫里沒有這個包. 那是因為C是一個”偽包”, 一個為cgo引入的特殊的包名, 它是C命名空間的一個引用.

rand 包包含4個到C包的引用: 調用 C.random和C.srandom, 類型轉換 C.uint(i)還有引用語句.

Random函數調用libc中的random函數, 然後回返結果. 在C中, random返回一個C類型的長整形值, cgo把它輪換為C.long. 這個值必需轉換成Go的類型, 才能在Go程序中使用. 使用一個常見的Go類型轉換:

func Random() int { return int(C.random()) }

這是一個等價的函數, 使用了一個臨時變量來進行類型轉換:

func Random() int { var r C.long = C.random() return int(r) }

Seed函數則相反. 它接受一個Go語言的int類型, 轉換成C語言的unsigned int類型, 然後傳遞給C的srandom函數.

func Seed(i int) { C.srandom(C.uint(i)) }

需要注意的是, cgo中的unsigned int類型寫為C.uint; cgo的文檔中有完整的類型列表.

這個例子中還有一個細節我們沒有說到, 那就是導入語句上面的注釋.

/*

#include stdlib.h

*/ import “C”

Cgo可以識別這個注釋, 並在編譯C語言程序的時候將它當作一個頭文件來處理. 在這個例子中, 它只是一個include語句, 然而其實它可以是使用有效的C語言代碼. 這個注釋必需緊靠在import “C”這個語句的上面, 不能有空行, 就像是文檔注釋一樣.

Strings and things

與Go語言不同, C語言中沒有顯式的字符串類型. 字符串在C語言中是一個以0結尾的字符數組.

Go和C語言中的字符串轉換是通過C.CString, C.GoString,和C.GoStringN這些函數進行的. 這些轉換將得到字符串類型的一個副本.

下一個例子是實現一個Print函數, 它使用C標準庫中的fputs函數把一個字符串寫到標準輸出上:

package print // #include stdio.h // #include stdlib.h import “C” import “unsafe” func Print(s string) { cs := C.CString(s) C.fputs(cs, (*C.FILE)(C.stdout)) C.free(unsafe.Pointer(cs)) }

在C程序中進行的內存分配是不能被Go語言的內存管理器感知的. 當你使用C.CString創建一個C字符串時(或者其它類型的C語言內存分配), 你必需記得在使用完後用C.free來釋放它.

調用C.CString將返回一個指向字符數組開始處的指錯, 所以在函數退出前我們把它轉換成一個unsafe.Pointer(Go中與C的void 等價的東西), 使用C.free來釋放分配的內存. 一個慣用法是在分配內存後緊跟一個defer(特別是當這段代碼比較複雜的時候), 這樣我們就有了下面這個Print函數:

func Print(s string) { cs := C.CString(s) defer C.free(unsafe.Pointer(cs)) C.fputs(cs, (*C.FILE)(C.stdout)) }

構建 cgo 包

如果你使用goinstall, 構建cgo包就比較容易了, 只要調用像平常一樣使用goinstall命令, 它就能自動識別這個特殊的import “C”, 然後自動使用cgo來編譯這些文件.

如果你想使用Go的Makefiles來構建, 那在CGOFILES變量中列出那些要用cgo處理的文件, 就像GOFILES變量包含一般的Go源文件一樣.

rand包的Makefile可以寫成下面這樣:

include $(GOROOT)/src/Make.inc

TARG=goblog/rand

CGOFILES=\ rand.go\ include $(GOROOT)/src/Make.pkg

然後輸入gomake開始構建.

更多 cgo 的資源

cgo的文檔中包含了關於C偽包的更多詳細的說明, 以及構建過程. Go代碼樹中的cgo的例子給出了更多更高級的用法.

一個簡單而又符合Go慣用法的基於cgo的包是Russ Cox寫的gosqlite. 而Go語言的網站上也列出了更多的的cgo包.

最後, 如果你對於cgo的內部是怎麼運作這個事情感到好奇的話, 去看看運行時包的cgocall.c文件的注釋吧.

golang項目中使用條件編譯

golang中沒有類似C語言中條件編譯的寫法，比如在C代碼中可以使用如下語法做一些條件編譯，結合宏定義來使用可以實現諸如按需編譯release和debug版本代碼的需求

build tags 是通過代碼注釋的形式實現的，要寫在文件的最頂端；

go build指令在編譯項目的時候會檢查每一個文件的build tags，用來決定是編譯還是跳過該文件

build tags遵循以下規則

示例：

約束此文件只能在支持kqueue的BSD系統上編譯

一個文件可能包含多行條件編譯註釋，比如：

約束該文件在linux/386 或 darwin/386平台編譯

需要注意的點

正確的寫法如下：

編譯方法:

具有_$GOOS.go後綴的go文件在編譯的時候會根據當前平台來判斷是否將該文件導入並編譯；同樣適用於處理器架構判斷 _$GOARCH.go。

兩者可以結合起來使用，形式為： _$GOOS_$GOARCH.go

示例：

文件名必須提供，如果只由後綴的文件名會被編譯器忽略，比如：

這兩個文件會被編譯器忽略，因為以下劃線開頭的文件都會被忽略