主題 達人專欄

從跨語言的字串傳遞,學習記憶體操作

解凍豬腳 | 2021-07-17 19:15:01 | 巴幣 1926 | 人氣 1874

 
  在 coding 這件事情上,從資管出身的我一直以來沒怎麼受過關於底層概念的正式課程,最近總算有機會接觸到這類問題,也藉此弄懂了幾個基本觀念。

  在解決問題的過程當中,也發現了從網路上根本沒辦法找到的完美解法,所以就用這篇文來記錄一下弄了整晚才搞定的坑吧,對於想用 Golang 開發卻苦於 GUI 庫又肥又麻煩的朋友來說,應該會是不錯的素材。



► 目標

  1. 用 Golang 寫一個可以把兩個字串拼接起來的函式
  2. 把這個函式編譯成 DLL 動態連結庫
  3. 用 C# 寫一個 WinForm Application 並引用這個 DLL 檔案
  4. 從 C# 傳入兩個包含中文的字串到 DLL 檔案裡面,再把結果取回來



► 用 Golang 開發 DLL 檔案

  由於 C 語言的運作機制相對來說沒有其他語言那麼複雜,它本身已經成為大家通用的底層標準。

  相較之下,Golang 作為一個複雜的高階語言,它並不像 C 語言一樣原生支援直接把原始碼編譯成 DLL 檔案的功能。為了提高 Golang 的通用性,它本身自帶了一個官方的函式庫叫做「C」,讓我們可以把 Golang 開發的功能用符合 C 語言規範的介面,提供給其他語言使用。

  用白話來講,我們可以把 Golang 和 C 兩種語言嵌合,既能保留 Golang 語言本身的優點,又能用 C 語言的規範來對外溝通,這樣的技術就是所謂的 CGO。

  假設我們想寫一個函式 Add(x, y) = x+y,那麼就把函數寫出來,使用 Golang 的 C 函式庫,再到函式定義的上一行加上 export 標籤,以設立之後編譯成 DLL 所需要的 entry point:


  注意,由於它是要開放給外部使用的,屬於 exported(向外輸出)類型,所以按照 Golang 的命名規範,函式的名稱開頭必須是大寫,這也是為什麼取作 Add 而不是 add。

  CGO 的用法就是把 C 語言的部分寫在 Golang 原始碼的註解上面,綠字部分雖然平常是註解,但使用 CGO 的時候它就變得有意義了,會在編譯時一起被讀進去。我們 import 了 C 函式庫,也在 C 語言的部分引入了 C 語言基本常用的 stdio.h 和 stdlib.h。

  接下來我們使用命令把它編譯成 DLL 檔案:
    go build --buildmode=c-shared -o add.dll .

  當然如果你後面要改成「-o add.dll main.go」的話也是可以的,反正在這個範例裡面也只有一個 main.go。如果只有一個半形的句點,代表的是整個資料夾都一起編譯進去,這跟平常使用的「go build .」是類似的概念。

  如此一來,用 Golang 開發的 DLL 檔案就出爐了。



► 把 DLL 檔案引入 C# 開發的程式裡

  得到 DLL 檔案以後,我們就可以拿到 C# 開發的程式上面測試了。首先把從 C# 新開的專案從方案總管右鍵 > 屬性,把專案的平台目標調成 x64 限定(如果你的 Golang 編譯環境是 32 位元,就選 x86):



  首先引用 System.Runtime.InteropServices,讓程式有能力用 DllImport 語法把外部的 DLL 檔案引用進來。

  接著使用:
        [DllImport("add.dll", EntryPoint = "Add")]
        public extern static int Add(int x, int y);

  這樣子,我們就可以讓 C# 寫的程式載入 DLL 檔案,成為可以直接拿來引用的函數了。隨便綁一個 Form1 的 Load 事件進去,編譯起來跑看看:


  成功!



► 在不同語言之間傳遞字串

  講到這裡,問題就會開始多起來了,可能有些地方看起來有些拗口,建議先確保自己精神狀態好再繼續看下去。

  近代的高階語言為了提供更多的功能,通常 string 型態不會只是單純由 char 組成的 array。不同語言間對於 string 型態的定義、實作細節都不太一樣,這意味著 C# 的 string 和 Golang 的 string 結構不同,自然就沒辦法直接當成相同的資料類型來互相傳遞。

  所以我們在 Golang 這端不能用 Golang 的 string 型態來接收 C# 的 string,而是應該兩邊各退一步,統一規定傳遞以 byte 為單位的 array。

  這裡又牽涉到一個問題了:怎樣的型態才是以 byte 為單位的 array?

  既然 C 語言在這裡扮演 C# 和 Golang 的橋樑,我們當然必須以 C 語言的型態為主。就好像如果有一個西班牙人和一個法國人都會英文的話,那麼兩個人應該要用英文來溝通,一樣的道理。

  C 語言裡面最接近字串的型態就是 char array 了。在 C 語言裡,一個 char 佔用 8 bits(也就是一個 byte)的大小,寬度都是固定的。而本質上,傳遞一個 array 的同時就相當於傳遞一個指標位址,所以我們在 Golang 一端,應該要用 *C.char 作為接收和傳遞用的型態:

    func ConcatString(str1, str2 *C.char) *C.char {
        // ...
    }

  接著我們遇上了一個新的問題:C# 同時提供了 char[]、byte[] 兩種資料型態,傳入 DLL 時應該要選哪個才正確呢?

  這兩個型態看起來很像,但其實 C# 的 char[] 是以字元為單位,可能有些文字佔用 8 bits、有些文字佔用 16 bits,這些內容並不是等寬的。至於 byte[] 資料型態,顧名思義就是以 byte 為單位,顯然 C# 的 byte array 比較接近 C 語言的 char array。

  接下來,我們事先預想到了 Golang 一端會傳送一個 C 的 char array 回來。既然 Golang 一端是用 *C.char 這樣的指標變數來接收地址,那麼當 Golang 一端傳回一個 C.char array 的時候,我們在 C# 這邊也應該用指標的型態 IntPtr 來接收從 Golang 傳過來的 C.char array:

        [DllImport("add.dll", EntryPoint = "ConcatString")]
        public extern static IntPtr ConcatString(byte[] str1, byte[] str2);

  到這裡,我們基本上確立了兩邊的介面應該如何定義。



► 轉換字串

  接下來的問題就是兩邊如何各自處理字串了。

  在 Golang 裡面,處理字串時預設使用的是 UTF-8 編碼,所以我們在 C# 一端應該要把字串轉換成由 UTF-8 編碼而成的 byte array,才接著傳進 DLL 裡面:

        byte[] byteArray1 = Encoding.UTF8.GetBytes("abc中文");
        byte[] byteArray2 = Encoding.UTF8.GetBytes("123測試def");
        IntPtr resultPointer = ConcatString(byteArray1, byteArray2);

  我們最後會得到一個 IntPtr,如何處理這個指標則待會再說。我們把兩個字串傳到 Golang 一端以後,可以使用 Golang 的 C 函式庫提供的 GoString 函式,把一個 *C.char 轉換成 Golang 的 string 型態。

  反之,我們要想把一個 Golang 的 string 轉換成 *C.char,可以使用 C.CString:

    //export ConcatString
    func ConcatString(str1, str2 *C.char) *C.char {
        goStr1 := C.GoString(str1)
        goStr2 := C.GoString(str2)
        return C.CString(goStr1+goStr2)
    }

  這樣就可以用 Golang 的方式把兩個字串連接起來,再轉成 C string(C char array)傳回去。

  在 C# 一端得到一個 IntPtr 之後,接著要煩惱的問題就是:「如何從得到的 IntPtr 位置讀出字串來?」這個問題我本來 Google 查過,人家的建議是:

    string resultString = Marshal.PtrToStringAnsi(resultPointer);

  不過這接著會有一個問題,Marshal 函式庫只有給 Unicode、ANSI 等解析方式,並沒有提供 PtrToStringUtf8 這樣的方法(注意:Unicode 跟 UTF-8 不同)

  所以上述這個方式對於純英數字串確實是絕對沒有問題的,畢竟半形的英文數字無論在哪個編碼裡面都一樣,但只要遇上了中文、日文等 ASCII 無法表現的文字,就會變成亂碼:


  幸好 C# 的 Encoding 函式庫還是有提供把 byte array 用 UTF-8 轉換成 string 的函式——因此,我們需要想辦法從 IntPtr 記錄的位址開始逐個 byte 讀取,組成一個 byte array,然後再用 UTF-8 的編碼把這個 byte array 轉換成 string:

    public string IntPtrToStringUTF8(IntPtr byteArrayPointer) {
        int length = 0;
        while (Marshal.ReadByte(byteArrayPointer + length) != 0) {
            length++;
        }
        byte[] buffer = new byte[length];
        Marshal.Copy(byteArrayPointer, buffer, 0, length);
        return System.Text.Encoding.UTF8.GetString(buffer);
    }

  我們知道字串通常不會穿插空字元 0x00 在中間,所以當我們讀到 0x00 的時候就知道這個字串已經讀到底了,藉此就能首先得到字串的長度,再直接把「該位址算起,按照字串的長度」得到的資料內容複製一份到新的 byte array 裡面,就可以把這個新的 byte array 用 UTF-8 的方式轉換回 C# 的 string:


  大功告成。有了這些背景知識,我們就可以在 C# 和 Golang 寫成的 DLL 之間任意傳遞字串,而且還能避免亂碼的問題。如果不想踩更多關於指標的坑,我們還可以統一把資料轉成 JSON 格式的字串再互傳,這樣就可以應付很多不同的狀況了。



► 記憶體流失(Memory Leak)

  接下來才正式涉及到記憶體「管理」的層面。

  電腦程式使用記憶體來存放變數,一般分為兩種類型,一種是 heap、另外一種是 stack。真要把兩種的差別細說起來一時半刻講不完,但在 C 語言裡,我們可以粗略地把 heap 理解成「由程式設計師手動申請和釋放的記憶體空間」,而 stack 則是「在它所在的函式結束後會自動釋放的記憶體空間」,例如我們直接在函式裡宣告的一般變數。

  通常像 Golang、Python 等等的近代高階語言,都具備 GC(Garbage Collectiion)的功能,會自動釋放那些很可能不會再用到的記憶體空間,讓那些記憶體空間得以重複使用而不會一直處在佔用狀態。

  然而 C 語言作為一個相對純淨、底層的語言,它是沒有原生提供 GC 功能的。當我們使用 C 語言的 malloc 函數,在 C 的 heap 上面申請記憶體空間,就應該要在使用完畢後找個合適的時機,利用 free 函數把該空間釋放出來。

  倘若我們沒有好好地讓這些記憶體空間「善終」,也許是忘記了、也許是邏輯不夠嚴謹而沒保證讓它釋放,那塊記憶體空間就會一直佔用在那裡(即便它不再有人使用),這樣的情況只要多了,你就會發現你的程式佔用了超大量的電腦記憶體,這也就連帶造成了程式會隨著運作時間而越來越胖,沒辦法穩定在電腦上長久運作。

  這樣的現象,就稱為記憶體流失(Memory Leak)。

  當我們使用 C.CString 把一個 Golang 的 string 轉換成 C 的 string 時,實際上這個函式是用 malloc 函數來實作,過程中在 C 語言部分的 heap 上面申請了一塊記憶體空間。所以如果我們在 CGO 裡面用 C.CString 產生了一個 C 的 string:

    func f() {
        a := C.CString("abcdefg")
    }

  這個變數 a 即使在函式結束以後,它仍然會存在 C 的 heap 上面,而不會像 stack 上面的變數一樣自動被釋放。所以,我們應該要在 CGO 上面使用 C.free 函式,在變數 a 不用之後把它釋放掉:

    func f() {
        a := C.CString("abcdefg")
        C.free(unsafe.Pointer(a))
    }

  在 free 之後,那塊記憶體空間就是自由的了,可以被重新分配利用。



► 回傳 CString 的狀況下該如何釋放空間

  問題來了!在這次的例子裡,我們希望在 Golang 一端處理完字串,然後回傳一個 C string 到 C# 這端,回傳之後這個函式就執行完而結束了,我們勢必沒有好的時機在這個函式裡面把這塊空間釋放掉。

  如果在回傳結果之前,就提前釋放掉這塊記憶體,那麼這塊記憶體空間就會變成自由狀態。基於殘值的原理,我們還是有可能會得到正確的結果:



  但在你釋放了記憶體空間之後,這塊記憶體空間就隨時都可以被其他的程式拿去用。你如何保證在 C# 一端接收並讀取完資料之前,這塊記憶體空間的內容不會被佔用、修改呢?

  所以,我們可以另外獨立出一個專門用來釋放記憶體空間的函式,在 C# 一端確認已經讀取完字串之後,再把指標傳回去由 CGO 釋放它:



  實驗一下:分成兩種方式各執行 50 萬次,一種正常執行 FreeCString 函式,另一種完全不去執行 FreeCString。用工作管理員比較看看兩者的記憶體佔用量,我這邊測試出來的數據分別是 17.6 MB 和 63.6 MB,可以感受得到剛才定義的 FreeCString 有正確地釋放記憶體空間。

  至此,基本上就解決了 C# 和 CGO 之間的型態問題、編碼問題、記憶體流失問題。



► 如果從 DLL 直接回傳 GoString

  本文前面所談到的方法都是相對合理、步驟比較少的最佳解,像是統一轉換成 C# byte array(C char array)之後互傳,採取這樣的策略都有現成的簡單方法可以互相轉換,也保證能夠在 UTF-8 的編碼下運作。

  但這也不代表傳入其他類型就絕對無可能。例如,我們可以在 C# 一端定義 GoString 型態:

    public struct GoString {
        public IntPtr p;
        public int n;
        public GoString(IntPtr n1, int n2) {
            p = n1;
            n = n2;
        }
    }

  用 C# 一端自行定義的 GoString 資料型態,接收從 DLL 傳回來的 Golang string,仍然可以成功。只是,在 DLL 裡面產生的 Golang string 畢竟是由 Golang 申請的記憶體空間,這個型態的結構本身包含了由 Golang 產生(並管理)的指標,CGO 預設是不能把這樣的指標傳出來的,這麼做的話執行的時候會告訴你「cgo result has Go pointer」,除非你在 C# 一端把 cgocheck 的環境變數從預設的 1 改為 0:

    // cgocheck 參數可以是 0~2,其中 2 最為嚴格
    Environment.SetEnvironmentVariable("GODEBUG", "cgocheck=0");

  但即使把它強制設為 0、繞過安全檢查機制而成功避免程式被終止,你仍然沒辦法保證這個字串的記憶體空間會不會在什麼時候被 Golang 的 GC 機制回收,所以到頭來還是用前面所提到轉為 CString 的方法最保險,至少我們都能清楚地掌握這個變數空間的流向,也就比較不容易產生資料意外損毀的問題。

  掌握這些細節之後,我們就可以用 C# 開發 GUI、用 Golang 開發核心功能,兩種語言各自的優點也就能同時拿來利用了。
 
送禮物贊助創作者 !
30
留言

創作回應

費玟
golang原來還能用內建函式庫就可以直接使用C語言的語法 (雖然是包含在註解裡)
2021-07-17 19:48:36
費玟
學到了,以前也有用過golang來做side-project,真的有體會到這語言的方便
雖然記憶體方面我現在可能還用不太到,不過也許哪天在工作的時候會用得到
先收藏來當參考
2021-07-17 19:49:47
解凍豬腳
自從學 Golang 之後就不大想用其他語言了,能編譯成 DLL 實在太香,而且也不用像一些語言一樣還要用包裝的方式才能弄成 PE 格式
2021-07-18 04:18:46
屁寶
我看不懂,我也可以去你的房間學習嗎(。•ω•。)ノ
2021-07-18 11:41:42
解凍豬腳
ㄋ長得可愛的話我考慮
2021-07-18 11:42:35
魔化鬼鬼
期待跟著豬腳go起來
2021-07-18 12:17:15
解凍豬腳
有這個打算,其實 Go 語言最重要的就是 goroutine / channel 的用法,這個真的用了很舒服
2021-07-18 12:19:10
小紅帽向創作者進行贊助 ✦
我想體驗一下當課金大佬的感覺
2021-08-16 00:26:47
解凍豬腳
謝謝 帽帽現在是我婆ㄌ… [e5]
2021-08-16 01:29:23

相關創作

更多創作