最后更新時間: 2017/06/12
- 增加5. golang 列出依賴的包
1. slice make時候如果len不為0, 則slice內(nèi)有值, append時候只會往后append
a := make([]int, 2, 5)
a = append(a, 3)
// a: [0, 0, 3]
// cap 5 則表示, 如果append之后不超過5的話, 不會重新申請內(nèi)存
// 所以如果想用append給slice賦值的話, make時候len應該設為0
2. float64類型, 計算之后的值可能不是想要的那個, 做對比也坑
var c float64 = 0
var d float64 = 100
for i := 0; i < 5000; i++ {
c += .01 // 想象中應該是50
}
for i := 0; i < 5000; i++ {
d -= .01 // 想象中應該是50
}
Println(c, d, c == d, IsEqual(c, d), IsEqual(d, c))
// 打印內(nèi)容:49.99999999999862 49.999999999984375 false true true
解決辦法: 就是上面代碼中的IsEqual函數(shù)啦
const MIN = 0.000001
func IsEqual(a, b float64) bool {
return math.Dim(a, b) < MIN
}
// MIN就是最小精度, 可設置
// Dim就是差值
3. os.File與bufio.Writer的并發(fā)安全性
直接上結(jié)論:
os.File的os.O_APPEND是并發(fā)安全的, 或者說, File的每次寫都是原子性的. 并發(fā)寫時, 不會出現(xiàn)斷句或者兩句夾雜的情況.
bufio不是并發(fā)安全的, 并發(fā)寫時, 會出現(xiàn)斷句或者兩句字符串夾雜的情況. 所以bufio寫時, 需要加鎖(mutex)
另外, File與bufio寫的性能差距大概是3倍, File性能比較差點.(macbook 2015中測試)
4. bufio與bytes.Buffer
一度很疑惑bufio與bytes.Buffer的區(qū)別, 因為兩者的功能很像, 實現(xiàn)的結(jié)構(gòu), 提供的成員函數(shù)也一樣. 經(jīng)過研究與跟其他gopher討論, 得出一些結(jié)論, 也希望看到本文的gopher也能發(fā)表一些看法, 相互交流
- buffer是reader, writer的實現(xiàn). 類似的還有file, conn等等.
- bufio是一個reader, writer的包裝. 接收的參數(shù)就是reader, writer.
也就是bufio是接收buffer, file, conn等作為參數(shù)的包裝.
同時還有一個很重要的點: bufio是提供緩存的io, 使得io不發(fā)生阻塞.
還有一個注意點, bufio的緩存機制(來自<go并發(fā)編程實戰(zhàn)(第二版) 郝林>):
bufio在很多時候, 會讀取比足夠多的更多一點的數(shù)據(jù)到其緩存區(qū)中
另一位群友的總結(jié)(感謝icexin):
bufio是個裝飾器拥诡，接收一個reader返回一個reader
bytes.buffer就是個內(nèi)存類文件對象
前者的目的是為了減少io次數(shù)
后者提供了一種用操作文件的方式來操作內(nèi)存的機制
5. golang 列出依賴的包
之前遇到過一個 cycle import 的問題. 出現(xiàn)這個問題, 說明設計上就有問題了.
代碼重構(gòu)之后, 主要是把數(shù)據(jù)層跟邏輯層劃分開, 解決了這個問題.
解決過程中, 有個命令很好用, 現(xiàn)在記錄下來:
go list -f '{{join .Deps "\n"}}' <import-path>
這個命令主要是列出所有依賴的包. <imort-path> 是一個包名, 注意要設置好GOPATH, 才能使用.
另外也可以用來查看某個包的init函數(shù)是否有運行, 來覺得是否要匿名import該包.
PS: 沒太理解'{{join .Deps "\n"}}', 如果有明白, 請不吝賜教, 大謝.
