Uber Go 出了個靜態分析工具 NilAway，還挺實用！

來源：腦子進煎魚了

大家好，我是煎魚。

風水輪流轉，Go 程式寫多了。總是會這有點問題，那有點問題。問題積累久了就容易出點事件，甚至是事故。

這種時候大家往往會想著引入一些靜態分析工具來解決這個問題。

NilAway 分析工具

最近 Uber 開發和開源了一個挺不錯的靜態分析工具 NilAway：

使用場景是：在 Go 程式編譯時就能捕獲 nil，達到幫助開發人員規避在生產中出現 nil panic 的問題。

官方認為其具備以下三個重要的特點，讓其脫穎而出：

1. 完全自動化：該分析工具只需要使用者提供標準的 Go 程式碼就可以使用了。不需要其他任何額外的資訊。
2. 速度快：在設計上，NilAway 保持速度快且可擴充套件，目標是大型程式碼庫也可以使用。在官方的效能測量中，啟用 NilAway 時構建時間開銷不到 5%。
3. 很實用：它不能防止程式碼中所有可能的 nil panic，但能捕獲我們在生產中觀察到的大部分潛在 nil panic，從而使 NilAway 在實用性和構建時間開銷之間保持良好的平衡。

安裝

我們只需要在命令列執行如下命令安裝：

$ go install go.uber.org/nilaway/cmd/nilaway@latest

nilaway 能夠遍歷掃描目錄下的所有檔案：

$ nilaway ./...

也可以掃描單獨的檔案：

$ nilaway demo.go

注：本文安裝 @latest 的原因，是因為寫此文時 nilaway 還在積極開發階段，暫時沒有釋出正式的版本。如果後續有正式版本，也可以指定相應版本號。

程式碼示例

案例一

看看如下的程式碼，是在什麼場景下有問題：

var p *P
if someCondition {
      p = &P{}
}
print(p.f) // nilness reports NO error here, but NilAway does.

在上述程式碼中，當 someCondition 變數值為 true 時，才會初始化結構體 P。如果 someCondition 變數為 false 時，就會出現空指標呼叫的 panic 問題。

NilAway 工具可以捕獲這種錯誤並報告，會報告如下錯誤：

go.uber.org/example.go:12:9: error: Potential nil panic detected. Observed nil flow from source to dereference point:
    -> go.uber.org/example.go:12:9: unassigned variable `p` accessed field `f`

如果我們增加 if p != nil 來做防禦，報告的錯誤就會消失。

案例二

看看如下的程式碼，是為什麼有問題：

func foo() *int {
 return nil
}
func bar() {
 print(*foo())
}

func main() {
 // 煎魚正在乾點什麼...
 bar() // nilness reports NO error here, but NilAway does.
}

函式 foo 返回了一個 nil 指標，該指標在函式 bar 中被直接取消引用，導致每當呼叫函式 bar 時都會出現 panic 問題。

NilAway 工具也能捕獲這類跨函式的的問題，會報告如下錯誤：

➜  ~ nilaway demo.go 
/Users/eddycjy/demo.go:7:9: error: Potential nil panic detected. Observed nil flow from source to dereference point: 
 -> eddycjy/demo.go:4:9: literal `nil` returned from `foo()` in position 0
 -> eddycjy/demo.go:7:9: result 0 of `foo()` dereferenced

上面的例子雖然是同 package 內跨函式的問題識別，但實際上該工具也嫩能夠分析跨 package 的呼叫。

總結

今天針對 Go 裡最常見的 nil 指標問題進行了靜態分析工具 NilAway 的分享。雖然目前該工具還沒有正式的生產可用。