梳理 golang 專案原始碼時的幾點收穫

2021-10-05 02:34:11 字數 1411 閱讀 9070

今天在看乙個 golang 專案的原始碼時，有幾個地方沒明白，然後順手谷歌了一會，初步知道了原因。

假設介面如下：

type imodule inte***ce
某個需要實現該介面的結構體如下：

type statmodule struct
現在的問題是，如何確保 statmodule 實現了 imodule，當然可以人工核對，但未免太費精力，而且人工也容易出錯，那當然要去尋找自動核對的方法了，目前有兩種：

其中一種基本上會用到，即在引數傳遞的時候，當把該結構體的物件傳到以該介面為形參的方法中時，編譯器會報錯，提示結構體未實現介面。

另外一種保險的做法是，在結構體定義處定義乙個匿名結構體物件，型別為介面：

var _ imodule = &statmodule{}


type statmodule struct
發現檔案有幾個全域性變數並未在原始碼中有對應的賦值語句，但是有**使用了它們，那 c/c++ 開發經驗的朋友肯定會想，這不就是使用了未初始化的變數，但在 golang 中，這些變數的賦值還可以通過編譯選項 -ldflags 來指定，比如 main 包有 build、commit、host、version 幾個全域性變數，那麼在編譯的時候可以通過下面的命令來指定它們的值：

go build -o main -ldflags "-x main.build="`date '+%y-%m-%dt%h:%m:%s%z'`" -x main.commit="123456" -x main.host="`hostname`" -x main.version="" "
服務端經常需要配置各種各樣的引數，viper 包對於引數解析來說功能非常豐富，簡單易用，

如果需要修改配置檔案，而不重啟服務怎麼辦呢，可以在初始化函式裡面呼叫 viper.onconfigchage() 和 viper.watchconfig() 來實現這一目的，這兩個函式的先後順序沒有要求， 但是需要在呼叫 viper.watchconfig() 之前完成配置檔案的讀取，否則 watchconfig 無法知道監聽哪個配置檔案的更改。

當你使用編輯器或者 echo 命令修改完配置檔案後，viper 會立馬感知到這次修改。但如果使用 truncate 命令對配置檔案的大小進行修改了，比如清空配置檔案了（truncate -s 0 cfgfile）， viper 無法感知到。

但 viper 僅僅是監聽配置檔案修改而已，至於修改後要做什麼事情，就需要開發人員控制了，當然在程式中稍後會用到的配置項內容也會更新，如果配置項只在程式啟動時用了一次，那麼即使修改了也不會生效，比如監聽的埠。

因此如果要不重新啟動服務來修改服務經常會用到的配置項，那麼 viper watchconfig 是乙個不錯的選擇，但如上所述，它有自己的侷限性，不如 nginx 的 reload 那麼強大

spark原始碼梳理 0 說明

本系列文章為對spark主要邏輯原始碼學習整理。主要參考 spark技術內幕 一書 簡稱 內幕 內幕 主要以原始碼模組為主線進行橫向解析。本文則致力於由 事件 觸發的縱向邏輯為主線，例如action運算元 transform運算元 集群啟動等，這個角度基本spark執行時的呼叫棧。各主線直接沒有必然...

Hive cli原始碼閱讀和梳理

對cli的重新認識 hive cli有兩種模式,本地模式 採用持有的driver物件來處理,遠端模式 通過連線hiveserver來實現,由此可見之前的架構圖中的描述還是模糊且帶有誤導性 支援singal的處理支援,比如對ctrl c中斷,需要兩次才完全退出互動 互動式命令處理模式 原始碼閱讀 si...

React react原始碼梳理筆記（二）

其中，事件機制在invokeguardedcallbackdev上。先學下別人對於react事件的理解。import from react vdom function render element,container export default import from createelement ...