Go中字符串的遍歷

首先說一下go中的字符串類型：

成都創(chuàng)新互聯(lián)是一家專業(yè)從事成都網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司。作為專業(yè)網(wǎng)站建設(shè)公司,成都創(chuàng)新互聯(lián)依托的技術(shù)實力、以及多年的網(wǎng)站運(yùn)營經(jīng)驗,為您提供專業(yè)的成都網(wǎng)站建設(shè)、全網(wǎng)整合營銷推廣及網(wǎng)站設(shè)計開發(fā)服務(wù)！

字符串就是一串固定長度的字符連接起來的字符序列。Go的字符串是由單個字節(jié)連接起來的。Go語言的字符串的字節(jié)使用UTF-8編碼標(biāo)識Unicode文本。

下面介紹字符串的三種遍歷方式，根據(jù)實際情況選擇即可。

該遍歷方式==缺點==：遍歷是按照字節(jié)遍歷，因此如果有中文等非英文字符，就會出現(xiàn)亂碼,比如要遍歷"abc北京"這個字符串，效果如下:

可見這不是我們想要的效果，根據(jù)utf-8中文編碼規(guī)則，我們要str[3]str[4]str[5]三個字節(jié)合起來組成“北”字及 str[6]str[7]str[8]合起來組成“京”字。由此引出下面第二種遍歷方法。

該方式是按照字符遍歷的，所以不會出現(xiàn)亂碼，如下：

運(yùn)行結(jié)果：

從圖中可以看到第二個漢子“京”的開始下標(biāo)是6，直接跳過了4和5，可見確實依照utf8編碼方式將三個字節(jié)組合成了一個漢字，str[3]-str[5]組合成“北”字，str[6]-str[8]組合成了“京”字。

由于下標(biāo)的不確定性，所以引出了下面的遍歷方式。

1 可以先將字符串轉(zhuǎn)成 []rune 切片

2 再用常規(guī)方法進(jìn)行遍歷

運(yùn)行效果：

由此可見下標(biāo)是按1遞增的，沒有產(chǎn)生跳躍現(xiàn)象。

go語言遞歸掃描指定目錄下文件

使用go語言遞歸查找指定目錄下的文件，根據(jù)正則匹配篩選出需要的文件，并且忽略指定的目錄

先使用 ioutil.ReadDir 遍歷出指定目錄下的文件，再遞歸進(jìn)目錄中遍歷，問題的關(guān)鍵在于識別出文件為目錄， fs.FileInfo 中有一個 IsDir() 函數(shù)可以識別是否是目錄

正則匹配使用 regexp.MatchString ，regexp中有很多正則操作的工具，如根據(jù)正則替換字符串中的指定字符

Go語言使用 map 時盡量不要在 big map 中保存指針

不知道你有沒有聽過這么一句：在使用 map 時盡量不要在 big map 中保存指針。好吧，你現(xiàn)在已經(jīng)聽過了：）為什么呢？原因在于 Go 語言的垃圾回收器會掃描標(biāo)記 map 中的所有元素，GC 開銷相當(dāng)大，直接GG。

這兩天在《Mastering Go》中看到 GC 這一章節(jié)里面對比 map 和 slice 在垃圾回收中的效率對比，書中只給出結(jié)論沒有說明理由，這我是不能忍的，于是有了這篇學(xué)習(xí)筆記。扯那么多，Show Your Code

這是一個簡單的測試程序，保存字符串的 map 和 保存整形的 map GC 的效率相差幾十倍，是不是有同學(xué)會說明明保存的是 string 哪有指針？這個要說到 Go 語言中 string 的底層實現(xiàn)了，源碼在 src/runtime/string.go里，可以看到 string 其實包含一個指向數(shù)據(jù)的指針和一個長度字段。注意這里的是否包含指針，包括底層的實現(xiàn)。

Go 語言的 GC 會遞歸遍歷并標(biāo)記所有可觸達(dá)的對象，標(biāo)記完成之后將所有沒有引用的對象進(jìn)行清理。掃描到指針就會往下接著尋找，一直到結(jié)束。

Go 語言中 map 是基于 數(shù)組和鏈表 的數(shù)據(jù)結(jié)構(gòu)實現(xiàn)的，通過 優(yōu)化的拉鏈法 解決哈希沖突，每個 bucket 可以保存 8 對鍵值，在 8 個鍵值對數(shù)據(jù)后面有一個 overflow 指針，因為桶中最多只能裝 8 個鍵值對，如果有多余的鍵值對落到了當(dāng)前桶，那么就需要再構(gòu)建一個桶（稱為溢出桶），通過 overflow 指針鏈接起來。

因為 overflow 指針的緣故，所以無論 map 保存的是什么，GC 的時候就會把所有的 bmap 掃描一遍，帶來巨大的 GC 開銷。官方 issues 就有關(guān)于這個問題的討論， runtime: Large maps cause significant GC pauses #9477

無腦機(jī)翻如下：

如果我們有一個map [k] v，其中k和v都不包含指針，并且我們想提高掃描性能，則可以執(zhí)行以下操作。

將“ allOverflow [] unsafe.Pointer”添加到 hmap 并將所有溢出存儲桶存儲在其中。 然后將 bmap 標(biāo)記為noScan。 這將使掃描非?？欤驗槲覀儾粫呙枞魏斡脩魯?shù)據(jù)。

實際上，它將有些復(fù)雜，因為我們需要從allOverflow中刪除舊的溢出桶。 而且它還會增加 hmap 的大小，因此也可能需要重新整理數(shù)據(jù)。

最終官方在 hmap 中增加了 overflow 相關(guān)字段完成了上面的優(yōu)化，這是具體的 commit 地址。

下面看下具體是如何實現(xiàn)的，源碼基于 go1.15，src/cmd/compile/internal/gc/reflect.go 中

通過注釋可以看出，如果 map 中保存的鍵值都不包含指針（通過 Haspointers 判斷），就使用一個 uintptr 類型代替 bucket 的指針用于溢出桶 overflow 字段，uintptr 類型在 GO 語言中就是個大小可以保存得下指針的整數(shù)，不是指針，就相當(dāng)于實現(xiàn)了 將 bmap 標(biāo)記為 noScan， GC 的時候就不會遍歷完整個 map 了。隨著不斷的學(xué)習(xí)，愈發(fā)感慨 GO 語言中很多模塊設(shè)計得太精妙了。

差不多說清楚了，能力有限，有不對的地方歡迎留言討論，源碼位置還是問的群里大佬 _

go語言 使用遞歸與循環(huán)兩種方式計算斐波那契數(shù)列

給定一個正整數(shù)n計算出對應(yīng)斐波那契數(shù)列對應(yīng)的值

說明:

用mackbookpro i7 2.7GHZ筆記本進(jìn)行測試，結(jié)果如下:

備注: 當(dāng)n=80時，由于測試等待時間過長，強(qiáng)制中斷了執(zhí)行。

從測試結(jié)果看出，當(dāng)n逐漸增大，遞歸方式計算斐波拉契數(shù)列的時間復(fù)雜性急劇增加。當(dāng)n值較大時可以考慮用循環(huán)方式代替。

類似的方式也可以用于，求階乘、遍歷目錄、漢諾塔等問題的解決。在后期的文章中，我將這些內(nèi)容進(jìn)行補(bǔ)充，敬請期待，謝謝。