這是golang拾遺系列的第六篇。這個系列主要用來記錄一些平時不常見的知識點，偶爾也會實現些有意思的小功能，比如這篇。
golang拾遺系列目錄：
在本篇中我們將實現一個無法被複制的型別，順便加深對參照型別、值傳遞以及指標的理解。
閱讀本文前需要你擁有一定的前置知識，包括掌握基本的golang語法，能理解並應用介面，對sync包下的內容有粗略的瞭解。如果你準備好了，就可以接著往下看了。
本文索引
不考慮IDE提供的程式碼分析和go vet之類的靜態分析工具，golang裡幾乎所有的型別都能被複制。
// 基本標量型別和指標
var i int = 1
iCopy := i
str := "string"
strCopy := str
pointer := &i
pointerCopy := pointer
iCopy2 := *pointer // 解除參照後進行復制
// 結構體和陣列
arr := [...]int{1, 2, 3}
arrCopy := arr
type Obj struct {
i int
}
obj := Obj{}
objCopy := obj
除了這些，golang還有函數和參照型別（slice、map、interface），這些型別也可以被複制，但稍有不同：
func f() {...}
f1 := f
f2 := f1
fmt.Println(f1, f2) // 0xabcdef 0xabcdef 列印出來的值是一樣的
fmt.Println(&f1 == &f2) // false 雖然值一樣，但確實是兩個不同的變數
這裡並沒有真正複製處三份f的程式碼，f1和f2均指向f，f的程式碼始終只會有一份。map、slice和interface與之類似：
m := map[int]string{
0: "a",
1: "b",
}
mCopy := m // 兩者參照同樣的資料
mCopy[0] := "unknown"
m[0] == "unknown" // True
// slice的複製和map相同
interface是比較另類的，它的行為要分兩種情況：
s := "string"
var i1 any = s
var i2 any = s
// 當把非指標和介面型別的值賦值給interface，會導致原來的物件被複制一份
s := "string"
var i1 any = s
var i2 any = i2
// 當把介面賦值給介面，底層參照的資料不會被複制，i1會複製s，i2此時和i1共有一個s的副本
ss := "string but pass by pointer"
var i3 any = &ss
var i4 any = i3
// i3和i4均參照ss，此時ss沒有被複制，但指向ss的指標的值被複制了兩次
上面的結果會一定程度上被編譯優化干擾，比如少數情況下編譯器可以確認賦值給介面的值從來沒被修改並且生命週期不比源物件長，則可能不會進行復制。
所以這裡有個小提示：如果要賦值給介面的資料比較大，那麼最好以指標的形式賦值給介面，複製指標比複製大量的資料更高效。
從上一節可以看到，允許複製時會在某些情況下「闖禍」。比如：
sync.Mutex，複製一個鎖並使用其副本會導致死鎖顯然在一些情況下禁止複製是合情合理的，這也是為什麼我會寫這篇文章。
但具體情況具體分析，不是說複製就是萬惡之源，什麼時候該支援複製，什麼時候應該禁止，應該結合自己的實際情況。
想在別的語言禁止某個型別被複制，方法有很多，用c++舉一例：
struct NoCopy {
NoCopy(const NoCopy &) = delete;
NoCopy &operator=(const NoCopy &) = delete;
};
可惜在golang裡不支援這麼做。
另外，因為golang沒有運運算元過載，所以很難在賦值的階段就進行攔截，所以我們的側重點在於「複製之後可以儘快檢測到」。
所以我們先實現在物件被複制後報錯的功能。雖然不如c++編譯期就可以禁止複製那樣優雅，但也算實現了功能，至少不什麼都沒有要強一些。
那麼如何直到物件是否被複制了？很簡單，看它的地址就行了，地址一樣那必然是同一個物件，不一樣了那說明覆製出一個新的物件了。
順著這個思路，我們需要一個機制來儲存物件第一次建立時的地址，並在後續進行比較，於是第一版程式碼誕生了：
import "unsafe"
type noCopy struct {
p uintptr
}
func (nc *noCopy) check() {
if uintptr(unsafe.Pointer(nc)) != nc.p {
panic("copied")
}
}
邏輯比較清晰，每次呼叫check來檢查當前的呼叫者的地址和儲存地址是否相同，如果不同就panic。
為什麼沒有建立這個型別的方法？因為我們沒法得知自己被其他型別建立時的地址，所以這塊得讓其他使用noCopy的型別代勞。
使用的時候需要把noCopy嵌入自己的struct，注意不能以指標的形式嵌入：
type SomethingCannotCopy struct {
noCopy
...
}
func (s *SomethingCannotCopy) DoWork() {
s.check()
fmt.Println("do something")
}
func NewSomethingCannotCopy() *SomethingCannotCopy {
s := &SomethingCannotCopy{
// 一些初始化
}
// 繫結地址
s.noCopy.p = unsafe.Pointer(&s.noCopy)
return s
}
注意初始化部分的程式碼，在這裡我們需要把noCopy物件的地址繫結進去。現在可以實現執行時檢測了：
func main() {
s1 := NewSomethingCannotCopy()
pointer := s1
s1Copy := *s1 // 這裡實際上進行了複製，但需要呼叫方法的時候才能檢測到
pointer.DoWork() // 正常列印出資訊
s1Copy.DoWork() // panic
}
解釋下原理：當SomethingCannotCopy被複制的時候，noCopy也會被複制，因此複製出來的noCopy的地址和原先的那個是不一樣的，但他們內部記錄的p是一樣的，這樣當被複製出來的noCopy物件呼叫check方法的時候就會觸發panic。這也是為什麼不要用指標形式嵌入它的原因。
功能實現了，但程式碼實在是太醜，而且耦合嚴重：只要用了noCopy，就必須在建立物件的同時初始化noCopy的範例，noCopy的初始化邏輯會侵入到其他物件的初始化邏輯中，這樣的設計是不能接受的。
那麼有沒有更好的實現？答案是有的，而且在標準庫裡。
標準庫的號誌sync.Cond是禁止複製的，而且比Mutex更為嚴格，因為複製它比複製鎖更容易導致死鎖和崩潰，所以標準庫加上了執行時的動態檢查。
主要程式碼如下：
type Cond struct {
// L is held while observing or changing the condition
L Locker
...
// 複製檢查
checker copyChecker
}
// NewCond returns a new Cond with Locker l.
func NewCond(l Locker) *Cond {
return &Cond{L: l}
}
func (c *Cond) Signal() {
// 檢查自己是否被複制
c.checker.check()
runtime_notifyListNotifyOne(&c.notify)
}
checker實現了執行時檢測是否被複制，但初始化的時候並不需要特殊處理這個checker，這是用了什麼手法做到的呢？
看程式碼：
type copyChecker uintptr
func (c *copyChecker) check() {
if uintptr(*c) != uintptr(unsafe.Pointer(c)) && // step 1
!atomic.CompareAndSwapUintptr((*uintptr)(c), 0, uintptr(unsafe.Pointer(c))) && // step 2
uintptr(*c) != uintptr(unsafe.Pointer(c)) { //step 3
panic("sync.Cond is copied")
}
}
看著很複雜，連原子操作都來了，這都是啥啊。但別怕，我給你捋一捋就明白了。
首先是checker初始化之後第一次呼叫：
step 1失敗，進入step 2；step 2是False，判斷流程直接結束；step 2是會失敗的，這是要進入step 3；step 3再次比較c的值和它自己的地址是否相同，相同說明多個goroutine共用了一個checker，沒有發生複製，所以檢測通過不會panic。step 3的比較發現不相等，那麼說明被複制了，直接panic然後我們再看其他情況下checker的流程：
step 1的結果是False，判斷流程結束，不會panic；step 2，因為這裡c的值不為0，所以表示式結果一定是True，所以進入step 3；step 3和step 1一樣，結果是True，地址不同說明被複制，這時候if裡面的語句會執行，因此panic。搞得這麼麻煩，其實就是為了能幹乾淨淨地初始化。這樣任何型別都只需要帶上checker作為自己的欄位就行，不用關心它是這麼初始化的。
還有個小問題，為什麼設定checker的值需要原子操作，但讀取就不用呢？
因為讀取一個uintptr的值，在現代的x86和arm處理器上只要一個指令，所以要麼讀到過時的值要麼讀到最新的值，不會讀到錯誤的或者寫了一半的不完整的值，對於讀到舊值的情況（主要出現在第一次呼叫check的時候），還有step 3做進一步的檢查，因此不會影響整個檢測邏輯。而「比較並交換」顯然一條指令做不完，如果在中間步驟被打斷那麼整個操作的結果很可能就是錯的，從而影響整個檢測邏輯，所以必須要用原子操作才行。
那麼在讀取的時候也使用atomic.Load行嗎？當然行，但一是這麼做仍然避免不了step 3的檢測，可以思考下是為什麼；二是原子操作相比直接讀取會帶來效能損失，在這裡不使用原子操作也能保證正確性的情況下這是得不償失的。
因為是執行時檢測，所以我們得看看會對效能帶來多少影響。我們使用改進版的checker。
type CheckBench struct {
num uint64
checker copyChecker
}
func (c *CheckBench) CheckCopy() {
c.checker.check()
c.num++
}
// 不進行檢測
func (c *CheckBench) NoCheck() {
c.num++
}
func BenchmarkCheckBench_NoCheck(b *testing.B) {
c := CheckBench{}
for i := 0; i < b.N; i++ {
for j := 0; j < 50; j++ {
c.NoCheck()
}
}
}
func BenchmarkCheckBench_WithCheck(b *testing.B) {
c := CheckBench{}
for i := 0; i < b.N; i++ {
for j := 0; j < 50; j++ {
c.CheckCopy()
}
}
}
測試結果如下：
cpu: Intel(R) Core(TM) i5-10200H CPU @ 2.40GHz
BenchmarkCheckBench_NoCheck-8 17689137 68.36 ns/op
BenchmarkCheckBench_WithCheck-8 17563833 66.04 ns/op
幾乎可以忽略不計，因為我們這裡沒有發生複製，所以幾乎每次檢測都是通過的，這對cpu的分支預測非常友好，所以效能損耗幾乎可以忽略。
所以我們給cpu添點堵，讓分支預測沒那麼容易：
func BenchmarkCheckBench_WithCheck(b *testing.B) {
for i := 0; i < b.N; i++ {
c := &CheckBench{}
for j := 0; j < 50; j++ {
c.CheckCopy()
}
}
}
func BenchmarkCheckBench_NoCheck(b *testing.B) {
for i := 0; i < b.N; i++ {
c := &CheckBench{}
for j := 0; j < 50; j++ {
c.NoCheck()
}
}
}
現在分支預測沒那麼容易了而且要多付出初始化時使用atomic的代價，測試結果會變成這樣：
cpu: Intel(R) Core(TM) i5-10200H CPU @ 2.40GHz
BenchmarkCheckBench_WithCheck-8 15552717 74.84 ns/op
BenchmarkCheckBench_NoCheck-8 26441635 44.74 ns/op
差不多會慢40%。當然，實際的程式碼不會有這麼極端，所以最壞可能也只會產生20%的影響，通常不太會成為效能瓶頸，執行時檢測是否有影響還需結核profile。
優點：
缺點：
動態檢測的缺點不少，能不能像c++那樣編譯期就禁止複製呢？
也可以，但得配合靜態程式碼檢測工具，比如自帶的go vet。看下程式碼：
// 實現sync.Locker介面
type noCopy struct{}
func (*noCopy) Lock() {}
func (*noCopy) Unlock() {}
type SomethingCannotCopy struct {
noCopy
}
這樣就行了，不需要再新增其他的程式碼。解釋下原理：任何實現了sync.Locker的型別都不應該被拷貝，靜態程式碼檢測會檢測出這些情況並報錯。
所以類似下邊的程式碼都是無法通過靜態程式碼檢測的：
func f(s SomethingCannotCopy) {
// 報錯，因為引數會導致複製
// 返回SomethingCannotCopy也是不行的
}
func (s SomethingCannotCopy) Method() {
// 報錯，因為非指標型別接收器會導致複製
}
func main() {
s := SomethingCannotCopy{}
sCopy := s // 報錯
sInterface := any(s) // 報錯
sPointer := &s // OK
sCopy2 := *sPointer // 報錯
sInterface2 := any(sPointer) // OK
sCopy3 := *(sInterface2.(*SomethingCannotCopy)) // 報錯
}
基本上涵蓋了所以會產生複製操作的地方，基本能在編譯期完成檢測。
如果跳過go vet，直接使用go run或者go build，那麼上面的程式碼可以正常編譯並執行。
因為只有靜態檢測，因此沒有什麼執行時開銷，所以效能這節就不需要費筆墨了。主要來看下這種方案的優缺點。
優點：
缺點：
sync.Locker，然而很多時候我們的型別並不是類似鎖的資源，使用這個介面只是為了靜態檢測，這會帶來程式碼被誤用的風險標準庫也使用的這套方案，建議仔細閱讀這個issue裡的討論。
看過執行時檢測和靜態檢測兩種方案之後，我們會發現這些做法多少都有些問題，不盡如人意。
所以我們還是要追求一種更好用的，更符合golang風格的做法。幸運的是，這樣的做法是存在的。
首先我們建立一個worker包，裡面定義一個Worker介面，包中的資料對外以Worker介面的形式提供：
package worker
import (
"fmt"
)
// 對外只提供介面來存取資料
type Worker interface {
Work()
}
// 內部型別不匯出，以介面的形式供外部使用
type normalWorker struct {
// data members
}
func (*normalWorker) Work() {
fmt.Println("I am a normal worker.")
}
func NewNormalWorker() Worker {
return &normalWorker{}
}
type specialWorker struct {
// data members
}
func (*specialWorker) Work() {
fmt.Println("I am a special worker.")
}
func NewSpecialWorker() Worker {
return &specialWorker{}
}
worker包對外只提供Worker介面，使用者可以使用NewNormalWorker和NewSpecialWorker來生成不同種類的worker，使用者不需要關心具體的返回型別，只要使用得到的Worker介面即可。
這麼做的話，在worker包之外是看不到normalWorker和specialWorker這兩個型別的，所以沒法靠反射和型別斷言取出介面參照的資料；因為我們傳給介面的是指標，因此源資料不會被複制；同時我們在第一節提到過，把一個介面賦值給另一個介面（worker包之外你只能這麼做），底層被參照的資料不會被複制，因此在包外始終不會在這兩個型別上產生複製的行為。
因此下面這樣的程式碼是不可能通過編譯的：
func main() {
w := worker.NewSpecialWorker()
// worker.specialWorker 在worker包以外不可見，因此編譯錯誤
wCopy := *(w.(*worker.specialWorker))
wCopy.Work()
}
這樣就實現了worker包之外的禁止複製，下面來看看優缺點。
優點：
缺點：
綜合來說，這種方案是實現成本最低的。
現在我們有三種方式防止我們的型別被複制：
一共三種方案，選擇困難症彷彿要發作了。彆著急，我們一起看看標準庫是怎麼做的：
sync.Cond同時使用了方案一和方案二，因為設計者確實很不希望條件變數被複制sync.Mutex、sync.Pool和sync.WaitGroup使用了方案二，需要配合go vetcrypto包下的那些Hash和Cipher確實沒什麼意義會帶來誤用，正好藉著方案三避免了這些問題綜合來看首選的應該是方案三；但也有需要使用方案二的時候，比如sync包中的那些同步機構；使用最少的是方案一，儘可能地不要設計出類似的程式碼。
還有一點需要注意，如果你的型別裡有欄位是sync.Pool、sync.WaitGroup、sync.RWMutex、sync.Mutex、sync.Cond、sync.Map或sync.Once，那麼這個型別本身也是不可複製的，也不需要額外實現禁止複製的功能，因為那些欄位自帶了。
最後，我只想說golang的語言技能實在是太簡陋了，想只依賴語言特性實現禁止複製的功能不太現實，更多的還是需要靠「設計」。