go語言中的String是什么

字符串概念

字符串是不可變字節(jié)(byte)序列，其本身是一個復雜的結(jié)構(gòu)。默認以UTF-8編碼存儲Unicode字符，內(nèi)置函數(shù)len()返回字節(jié)數(shù)組長度。字符串默認值不是nil，而是""。

在幕后，Go 的字符串 (當前) 表示為 長度和指向字符串數(shù)據(jù)的指針.

字符串駐留

考慮這段代碼:

b := []byte("hello")
s := string(b)
t := string(b)

s 和 t 是字符串，因此它們都有長度和數(shù)據(jù)指針。它們的長度顯然是相同的。那它們的數(shù)據(jù)指針呢？

Go 語言無法為我們提供直接的查找方法。但是我們可以使用 unsafe 來探查：

func pointer(s string) uintptr {
    p := unsafe.Pointer(&s)
    h := *(*reflect.StringHeader)(p)
    return h.Data
}

(此函數(shù)應返回 unsafe.Pointer。詳見 Go 問題 19367。)

如果我們 fmt.Println(pointer(s), pointer(t))，我們會得到類似 4302664 4302632 的信息。指針是不同的；它們有兩個單獨的數(shù)據(jù)副本 hello。

(這是一個練習鏈接。如果你想要嘗試，將 "hello" 變成 "h" 會發(fā)生什么情況？解釋  )

假設您希望重新使用數(shù)據(jù) hello 的單個副本？這就是字符串駐留。字符串駐留有兩個優(yōu)點。明顯的一個優(yōu)點是，你不需要分配和復制數(shù)據(jù)。另一個優(yōu)點是它加快了字符串相等性檢查的速度。如果兩個字符串具有相同的長度和相同的數(shù)據(jù)指針，則它們是相等的；沒有必要檢查字節(jié)。

從 Go 1.14 開始，Go 不會駐留大多數(shù)字符串。與其它形式的緩存一樣，駐留也有成本：并發(fā)安全性的同步，垃圾收集器的復雜性，以及每次創(chuàng)建字符串時要執(zhí)行的額外代碼。而且，就像緩存一樣，在某些情況下它是有害的，而不是有用的。如果你在處理字典里的單詞，則任何單詞都不會出現(xiàn)兩次，這時，字符串駐留既浪費時間又浪費內(nèi)存。

手動字符串駐留

可以在 Go 中手動駐留字符串。我們需要的是一種在給定字節(jié)切片 (byte slice) 的情況下尋找現(xiàn)有字符串以重新使用的方法，也許使用諸如 map[[]byte]string 之類的方法。如果查找成功，則使用現(xiàn)有字符串；如果失敗，我們將轉(zhuǎn)換并存儲該字符串以備將來使用。

這里只有一個問題：您不能使用 []byte 作為 map 的鍵。

多虧了長期的編譯器優(yōu)化，我們可以使用 map[string]string 代替。這里有一個優(yōu)化，鍵是轉(zhuǎn)換后字節(jié)切片的 map 操作實際上不會生成在查找期間會用到的新字符串。

m := make(map[string]string)
b := []byte("hello")
s := string(b) // 分配了
_ = m[string(b)] // 不分配！

(類似的優(yōu)化適用于其他情況，在這些情況下，編譯器可以證明轉(zhuǎn)換后的字節(jié)切片在使用過程中不會被修改，例如 switch string(b)，當所有 switch 情況都沒有副作用時。)

駐留字符串所需的全部代碼是這樣的：

func intern(m map[string]string, b []byte) string {
    // 查找一個存在的字符串來重用
    c, ok := m[string(b)]
    if ok {
        // 找到一個存在的字符串
        return c
    }
    // 沒有找到，所以制作一個并且存儲它
    s := string(b)
    m[s] = s
    return s
}

很簡單

新出現(xiàn)的困難（并發(fā)癥）

請注意，這個手動駐留例程將駐留問題推入了調(diào)用代碼。您需要管理對 map 的并發(fā)訪問；您需要確定 map (以及其中的所有內(nèi)容) 的生命周期；并且您每次需要字符串時都需要付出 map 查找的額外費用。

將這些決定推到調(diào)用代碼上可以產(chǎn)生更好的性能。例如，假設您正在將 json 解碼為 map[string]interface{}。json 解碼器可能不是并發(fā)的。map 的生命周期可以綁定到 json 解碼器。并且此 map 的鍵很可能會經(jīng)常重復，這是字符串駐留的最佳情況；這使得額外的 map 查找成本值得。

一個助手包

如果您不想考慮這些并發(fā)癥中的任何一個，并且愿意接受輕微的性能損失，并且有字符串駐留可能會有所幫助的代碼，則有一個為此的包：github.com/josharian/intern。

它的工作原理是可怕的濫用 sync.Pool。它將駐留 maps 存儲在 sync.Pool 中，根據(jù)需要檢索它們。這很好的解決了并發(fā)訪問問題，因為 sync.Pool 的訪問是并發(fā)安全的。它主要解決了生存期問題，因為在 sync.Pool 中的內(nèi)容通常最終會被垃圾收集。

以上就是Go String 解析的詳細內(nèi)容，更多請關(guān)注億速云其它相關(guān)文章！