gopl-zh.github.com/ch13/ch13.md

3.4 KiB
Raw Blame History

第13章 底層編程

Go語言的設計包含了諸多安全策略限製了可能導致程序運行出現錯誤的用法。編譯時類型檢査檢査可以發現大多數類型不匹配的操作例如兩個字符串做減法的錯誤。字符串、map、slice和chan等所有的內置類型都有嚴格的類型轉換規則。

對於無法靜態檢測到的錯誤,例如數組訪問越界或使用空指針,運行時動態檢測可以保證程序在遇到問題的時候立卽終止併打印相關的錯誤信息。自動內存管理(垃圾內存自動迴收)可以消除大部分野指針和內存洩漏相關的問題。

Go語言的實現刻意隱藏了很多底層細節。我們無法知道一個結構體眞實的內存布局也無法獲取一個運行時函數對應的機器碼也無法知道當前的goroutine是運行在哪個操作繫統線程之上。事實上Go語言的調度器會自己決定是否需要將某個goroutine從一個操作繫統線程轉移到另一個操作繫統線程。一個指向變量的指針也併沒有展示變量眞實的地址。因爲垃圾迴收器可能會根據需要移動變量的內存位置當然變量對應的地址也會被自動更新。

總的來説Go語言的這些特性使得Go程序相比較低級的C語言來説更容易預測和理解程序也不容易崩潰。通過隱藏底層的實現細節也使得Go語言編寫的程序具有高度的可移植性因爲語言的語義在很大程度上是獨立於任何編譯器實現、操作繫統和CPU繫統結構的當然也不是完全絶對獨立例如int等類型就依賴於CPU機器字的大小某些表達式求值的具體順序還有編譯器實現的一些額外的限製等

有時候我們可能會放棄使用部分語言特性而優先選擇更好具有更好性能的方法例如需要與其他語言編寫的庫互操作或者用純Go語言無法實現的某些函數。

在本章我們將展示如何使用unsafe包來襬脫Go語言規則帶來的限製講述如何創建C語言函數庫的綁定以及如何進行繫統調用。

本章提供的方法不應該輕易使用譯註屬於黑魔法雖然可能功能很強大但是也容易誤傷到自己。如果沒有處理好細節它們可能導致各種不可預測的併且隱晦的錯誤甚至連有經驗的的C語言程序員也無法理解這些錯誤。使用unsafe包的同時也放棄了Go語言保證與未來版本的兼容性的承諾因爲它必然會在有意無意中會使用很多實現的細節而這些實現的細節在未來的Go語言中很可能會被改變。

要註意的是unsafe包是一個采用特殊方式實現的包。雖然它可以和普通包一樣的導入和使用但它實際上是由編譯器實現的。它提供了一些訪問語言內部特性的方法特别是內存布局相關的細節。將這些特性封裝到一個獨立的包中是爲在極少數情況下需要使用的時候同時引起人們的註意譯註因爲看包的名字就知道使用unsafe包是不安全的。此外有一些環境因爲安全的因素可能限製這個包的使用。

不過unsafe包被廣泛地用於比較低級的包, 例如runtime、os、syscall還有net包等因爲它們需要和操作繫統密切配合但是對於普通的程序一般是不需要使用unsafe包的。