《Go程序設(shè)計語言中文版》百度網(wǎng)盤pdf最新全集下載:
10年積累的成都網(wǎng)站設(shè)計、成都做網(wǎng)站、外貿(mào)網(wǎng)站建設(shè)經(jīng)驗(yàn)，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識你，你也不認(rèn)識我。但先網(wǎng)站設(shè)計后付款的網(wǎng)站建設(shè)流程，更有高密免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
鏈接：
?pwd=0cii 提取碼：0cii
簡介：本書由《C程序設(shè)計語言》的作者Kernighan和谷歌公司Go團(tuán)隊(duì)主管Alan Donovan聯(lián)袂撰寫，是學(xué)習(xí)Go語言程序設(shè)計的指南。本書共13章，主要內(nèi)容包括：Go的基礎(chǔ)知識、基本結(jié)構(gòu)、
基本數(shù)據(jù)類型、復(fù)合數(shù)據(jù)類型、函數(shù)、方法、接口、goroutine、通道、共享變量的并發(fā)性、包、go工具、測試、反射等。
本書適合作為計算機(jī)相關(guān)專業(yè)的教材，也可供Go語言愛好者閱讀?
Go語言于2009年11月正式宣布推出，成為開放源代碼項(xiàng)目，并在Linux及Mac OS X平臺上進(jìn)行了實(shí)現(xiàn)，后追加Windows系統(tǒng)下的實(shí)現(xiàn)。
谷歌資深軟件工程師羅布·派克(Rob Pike)表示，“Go讓我體驗(yàn)到了從未有過的開發(fā)效率?！迸煽吮硎荆徒裉斓腃++或C一樣，Go是一種系統(tǒng)語言。他解釋道，“使用它可以進(jìn)行快速開發(fā)，同時它還是一個真正的編譯語言，我們之所以現(xiàn)在將其開源，原因是我們認(rèn)為它已經(jīng)非常有用和強(qiáng)大?！?/p>
2007年，谷歌把Go作為一個20%項(xiàng)目開始研發(fā)，即讓員工抽出本職工作之外時間的20%，投入在該項(xiàng)目上。除了派克外，該項(xiàng)目的成員還有其它一些谷歌工程師。
派克表示，編譯后Go代碼的運(yùn)行速度與C語言非常接近，而且編譯速度非?？欤拖裨谑褂靡粋€交互式語言。
現(xiàn)有編程語言均未專門對多核處理器進(jìn)行優(yōu)化。派克表示，Go就是谷歌工程師為這類程序編寫的一種語言。它不是針對編程初學(xué)者設(shè)計的，但學(xué)習(xí)使用它也不是非常困難。Go支持面向?qū)ο?，而且具有真正的封裝(closures)和反射(reflection)等功能。
在學(xué)習(xí)曲線方面，派克認(rèn)為Go與Java類似，對于Java開發(fā)者來說，應(yīng)該能夠輕松學(xué)會Go。
之所以將Go作為一個開源項(xiàng)目發(fā)布，目的是讓開源社區(qū)有機(jī)會創(chuàng)建更好的工具來使用該語言，例如Eclipse IDE中的插件。目前還沒有支持Go的IDE。
在目前谷歌公開發(fā)布的所有網(wǎng)絡(luò)應(yīng)用中，均沒有使用Go。但是谷歌已經(jīng)使用該語言開發(fā)了幾個內(nèi)部項(xiàng)目。
派克表示，Go是否會對谷歌即將推出的Chrome OS產(chǎn)生影響，現(xiàn)在還言之尚早，不過Go的確可以和Native Client配合使用。他表示，“Go可以讓應(yīng)用完美的運(yùn)行在瀏覽器內(nèi)?！崩纾褂肎o可以更高效的實(shí)現(xiàn)Wave，無論是在前端還是后臺。
Go語言是一種新的語言，一種并發(fā)的、帶垃圾回收的、快速編譯的語言。它具有以下特點(diǎn)：
1.它可以在一臺計算機(jī)上用幾秒鐘的時間編譯一個大型的Go程序。
2.Go語言為軟件構(gòu)造提供了一種模型，它使依賴分析更加容易，且避免了大部分C風(fēng)格include文件與庫的開頭。
3.Go語言是靜態(tài)類型的語言，它的類型系統(tǒng)沒有層級。因此用戶不需要在定義類型之間的關(guān)系上花費(fèi)時間，這樣感覺起來比典型的面向?qū)ο笳Z言更輕量級。
4.Go語言完全是垃圾回收型的語言，并為并發(fā)執(zhí)行與通信提供了基本的支持。
按照其設(shè)計，Go打算為多核機(jī)器上系統(tǒng)軟件的構(gòu)造提供一種方法。
Go語言是一種編譯型語言，它結(jié)合了解釋型語言的游刃有余，動態(tài)類型語言的開發(fā)效率，以及靜態(tài)類型的安全性。它也打算成為現(xiàn)代的，支持網(wǎng)絡(luò)與多核計算的語言。要滿足這些目標(biāo)，需要解決一些語言上的問題：一個富有表達(dá)能力但輕量級的類型系統(tǒng)，并發(fā)與垃圾回收機(jī)制，嚴(yán)格的依賴規(guī)范等等。這些無法通過庫或工具解決好，因此Go也就應(yīng)運(yùn)而生了。
在前一小節(jié)中介紹了點(diǎn)亮第一個LED燈，這里我們準(zhǔn)備進(jìn)階嘗試下，輸出第一段PWM波形。（PWM也就是脈寬調(diào)制，一種可調(diào)占空比的技術(shù)，得到的效果就是：如果用示波器測量引腳會發(fā)現(xiàn)有方波輸出，而且高電平、低電平的時間是可調(diào)的。）
這里爪爪熊準(zhǔn)備寫成一個golang的庫，并開源到github上，后續(xù)更新將直接更新到github中，如果你有興趣可以和我聯(lián)系。 github.com/dpawsbear/bear_rpi_go
我在很多的教程中都看到說樹莓派的PWM（硬件）只有一個GPIO能夠輸出，就是 GPIO1 。這可是不小的打擊，因?yàn)槲蚁胧褂弥辽偎膫€ PWM ，還是不死心，想通過硬件手冊上找尋蛛絲馬跡，看看究竟怎么回事。
手冊上找尋東西稍等下講述，這里先提供一種方法測試 樹莓派3B 的 PWM 方法：用指令控制硬件PWM。
這里通過指令的方式掌握了基本的pwm設(shè)置技巧，決定去翻一下手冊看看到底PWM怎么回事，這里因?yàn)闆]有 BCM2837 的手冊，根據(jù)之前文章引用官網(wǎng)所說， BCM2835 和 BCM2837 應(yīng)該是一樣的。這里我們直接翻閱 BCM2835 的手冊，直接找到 PWM 章節(jié)。找到了如下圖：
圖中可以看到在博通的命名規(guī)則中 GPIO 12、13、18、19、40、41、45、52、53 均可以作為PWM輸出。但是只有兩路PWM0 PWM1。根據(jù)我之前所學(xué)知識，不出意外應(yīng)該是PWM0 和 PWM1可以輸出不一樣的占空比，但是頻率應(yīng)該是一樣的。因?yàn)闆]有示波器，暫時不好測試。先找到下面對應(yīng)圖：
根據(jù)以上兩個圖對比可以發(fā)現(xiàn)如下規(guī)律：
對照上面的表可以看出從 BCM2837 中印出來的能夠使用在PWM上的就這幾個了。
為了驗(yàn)證個人猜想是否正確，這里先直接使用指令的模式，模擬配置下是否能夠正常輸出。
通過上面一系列指令模擬發(fā)現(xiàn)，（GPIO1、GPIO26）、（GPIO23、GPIO24）是綁定在一起的，調(diào)節(jié)任意一個，另外一個也會發(fā)生變化。也即是PWM0、PWM1雖然輸出了兩路，可以理解成兩路其實(shí)都是連在一個輸出口上。這里由于沒有示波器或者邏輯分析儀這類設(shè)備（僅有一個LED燈），所以測試很簡陋，下一步是使用示波器這類東西對頻率以及信號穩(wěn)定性進(jìn)行下測試。
小節(jié)：樹莓派具有四路硬件輸出PWM能力，但是四路中只能輸出兩個獨(dú)立（占空比獨(dú)立）的PWM，同時四路輸出的頻率均是恒定的。
上面大概了解清楚了樹莓派3B的PWM結(jié)構(gòu)，接下來就是探究如何使用Go語言進(jìn)行設(shè)置。
因?yàn)槟玫搅耸謨?，這里我想直接操作寄存器的方式進(jìn)行設(shè)置，也是順便學(xué)習(xí)下Go語言處理寄存器的過程。首先需要拿到pwm 系列寄存器的基地址，但是翻了一圈手冊，發(fā)現(xiàn)只有偏移，沒有找到基地址。
經(jīng)過了一段時間的努力后，決定寫一個 樹莓派3B golang包開源放在github上，只需要寫相關(guān)程序進(jìn)行調(diào)用就可以了，以下是相關(guān)demo（pwm）（在GPIO.12 上輸出PWM波，放上LED燈會有呼吸燈的效果，具體多少頻率還沒有進(jìn)行測試）
以下是demo(pwm) 源碼
Go 語言較之 C 語言一個很大的優(yōu)勢就是自帶 GC 功能，可 GC 并不是沒有代價的。寫 C 語言的時候，在一個函數(shù)內(nèi)聲明的變量，在函數(shù)退出后會自動釋放掉，因?yàn)檫@些變量分配在棧上。如果你期望變量的數(shù)據(jù)可以在函數(shù)退出后仍然能被訪問，就需要調(diào)用 malloc 方法在堆上申請內(nèi)存，如果程序不再需要這塊內(nèi)存了，再調(diào)用 free 方法釋放掉。Go 語言不需要你主動調(diào)用 malloc 來分配堆空間，編譯器會自動分析，找出需要 malloc 的變量，使用堆內(nèi)存。編譯器的這個分析過程就叫做逃逸分析。
所以你在一個函數(shù)中通過 dict := make(map[string]int) 創(chuàng)建一個 map 變量，其背后的數(shù)據(jù)是放在?？臻g上還是堆空間上，是不一定的。這要看編譯器分析的結(jié)果。
可逃逸分析并不是百分百準(zhǔn)確的，它有缺陷。有的時候你會發(fā)現(xiàn)有些變量其實(shí)在棧空間上分配完全沒問題的，但編譯后程序還是把這些數(shù)據(jù)放在了堆上。如果你了解 Go 語言編譯器逃逸分析的機(jī)制，在寫代碼的時候就可以有意識地繞開這些缺陷，使你的程序更高效。
Go 語言雖然在內(nèi)存管理方面降低了編程門檻，即使你不了解堆棧也能正常開發(fā)，但如果你要在性能上較真的話，還是要掌握這些基礎(chǔ)知識。
這里不對堆內(nèi)存和棧內(nèi)存的區(qū)別做太多闡述。簡單來說就是， 棧分配廉價，堆分配昂貴。 ?？臻g會隨著一個函數(shù)的結(jié)束自動釋放，堆空間需要時間 GC 模塊不斷地跟蹤掃描回收。如果對這兩個概念有些迷糊，建議閱讀下面 2 個文章：
這里舉一個小例子，來對比下堆棧的差別：
stack 函數(shù)中的變量 i 在函數(shù)退出會自動釋放；而 heap 函數(shù)返回的是對變量 i 的引用，也就是說 heap() 退出后，表示變量 i 還要能被訪問，它會自動被分配到堆空間上。
他們編譯出來的代碼如下：
邏輯的復(fù)雜度不言而喻，從上面的匯編中可看到， heap() 函數(shù)調(diào)用了 runtime.newobject() 方法，它會調(diào)用 mallocgc 方法從 mcache 上申請內(nèi)存，申請的內(nèi)部邏輯前面文章已經(jīng)講述過。堆內(nèi)存分配不僅分配上邏輯比棧空間分配復(fù)雜，它最致命的是會帶來很大的管理成本，Go 語言要消耗很多的計算資源對其進(jìn)行標(biāo)記回收（也就是 GC 成本）。
Go 編輯器會自動幫我們找出需要進(jìn)行動態(tài)分配的變量，它是在編譯時追蹤一個變量的生命周期，如果能確認(rèn)一個數(shù)據(jù)只在函數(shù)空間內(nèi)訪問，不會被外部使用，則使用棧空間，否則就要使用堆空間。
我們在 go build 編譯代碼時，可使用 -gcflags '-m' 參數(shù)來查看逃逸分析日志。
以上面的兩個函數(shù)為例，編譯的日志輸出是：
日志中的 i escapes to heap 表示該變量數(shù)據(jù)逃逸到了堆上。
需要使用堆空間，所以逃逸，這沒什么可爭議的。但編譯器有時會將 不需要 使用堆空間的變量，也逃逸掉。這里是容易出現(xiàn)性能問題的大坑。網(wǎng)上有很多相關(guān)文章，列舉了一些導(dǎo)致逃逸情況，其實(shí)總結(jié)起來就一句話：
多級間接賦值容易導(dǎo)致逃逸 。
這里的多級間接指的是，對某個引用類對象中的引用類成員進(jìn)行賦值。Go 語言中的引用類數(shù)據(jù)類型有 func , interface , slice , map , chan , *Type(指針) 。
記住公式 Data.Field = Value ，如果 Data , Field 都是引用類的數(shù)據(jù)類型，則會導(dǎo)致 Value 逃逸。這里的等號 = 不單單只賦值，也表示參數(shù)傳遞。
根據(jù)公式，我們假設(shè)一個變量 data 是以下幾種類型，相應(yīng)的可以得出結(jié)論：
下面給出一些實(shí)際的例子：
如果變量值是一個函數(shù)，函數(shù)的參數(shù)又是引用類型，則傳遞給它的參數(shù)都會逃逸。
上例中 te 的類型是 func(*int) ，屬于引用類型，參數(shù) *int 也是引用類型，則調(diào)用 te(j) 形成了為 te 的參數(shù)(成員) *int 賦值的現(xiàn)象，即 te.i = j 會導(dǎo)致逃逸。代碼中其他幾種調(diào)用都沒有形成 多級間接賦值 情況。
同理，如果函數(shù)的參數(shù)類型是 slice , map 或 interface{} 都會導(dǎo)致參數(shù)逃逸。
匿名函數(shù)的調(diào)用也是一樣的，它本質(zhì)上也是一個函數(shù)變量。有興趣的可以自己測試一下。
只要使用了 Interface 類型(不是 interafce{} )，那么賦值給它的變量一定會逃逸。因?yàn)? interfaceVariable.Method() 先是間接的定位到它的實(shí)際值，再調(diào)用實(shí)際值的同名方法，執(zhí)行時實(shí)際值作為參數(shù)傳遞給方法。相當(dāng)于 interfaceVariable.Method.this = realValue
向 channel 中發(fā)送數(shù)據(jù)，本質(zhì)上就是為 channel 內(nèi)部的成員賦值，就像給一個 slice 中的某一項(xiàng)賦值一樣。所以 chan *Type , chan map[Type]Type , chan []Type , chan interface{} 類型都會導(dǎo)致發(fā)送到 channel 中的數(shù)據(jù)逃逸。
這本來也是情理之中的，發(fā)送給 channel 的數(shù)據(jù)是要與其他函數(shù)分享的，為了保證發(fā)送過去的指針依然可用，只能使用堆分配。
可變參數(shù)如 func(arg ...string) 實(shí)際與 func(arg []string) 是一樣的，會增加一層訪問路徑。這也是 fmt.Sprintf 總是會使參數(shù)逃逸的原因。
例子非常多，這里不能一一列舉，我們只需要記住分析方法就好，即，2 級或更多級的訪問賦值會 容易 導(dǎo)致數(shù)據(jù)逃逸。這里加上 容易 二字是因?yàn)殡S著語言的發(fā)展，相信這些問題會被慢慢解決，但現(xiàn)階段，這個可以作為我們分析逃逸現(xiàn)象的依據(jù)。
下面代碼中包含 2 種很常規(guī)的寫法，但他們卻有著很大的性能差距，建議自己想下為什么。
Benchmark 和 pprof 給出的結(jié)果:
熟悉堆棧概念可以讓我們更容易看透 Go 程序的性能問題，并進(jìn)行優(yōu)化。
多級間接賦值會導(dǎo)致 Go 編譯器出現(xiàn)不必要的逃逸，在一些情況下可能我們只需要修改一下數(shù)據(jù)結(jié)構(gòu)就會使性能有大幅提升。這也是很多人不推薦在 Go 中使用指針的原因，因?yàn)樗鼤黾右患壴L問路徑，而 map , slice , interface{} 等類型是不可避免要用到的，為了減少不必要的逃逸，只能拿指針開刀了。
大多數(shù)情況下，性能優(yōu)化都會為程序帶來一定的復(fù)雜度。建議實(shí)際項(xiàng)目中還是怎么方便怎么寫，功能完成后通過性能分析找到瓶頸所在，再對局部進(jìn)行優(yōu)化。
不知道你有沒有聽過這么一句：在使用 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 的底層實(shí)現(xiàn)了，源碼在 src/runtime/string.go里，可以看到 string 其實(shí)包含一個指向數(shù)據(jù)的指針和一個長度字段。注意這里的是否包含指針，包括底層的實(shí)現(xiàn)。
Go 語言的 GC 會遞歸遍歷并標(biāo)記所有可觸達(dá)的對象，標(biāo)記完成之后將所有沒有引用的對象進(jìn)行清理。掃描到指針就會往下接著尋找，一直到結(jié)束。
Go 語言中 map 是基于 數(shù)組和鏈表 的數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)的，通過 優(yōu)化的拉鏈法 解決哈希沖突，每個 bucket 可以保存 8 對鍵值，在 8 個鍵值對數(shù)據(jù)后面有一個 overflow 指針，因?yàn)橥爸凶疃嘀荒苎b 8 個鍵值對，如果有多余的鍵值對落到了當(dāng)前桶，那么就需要再構(gòu)建一個桶（稱為溢出桶），通過 overflow 指針鏈接起來。
因?yàn)?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。 這將使掃描非?？欤?yàn)槲覀儾粫呙枞魏斡脩魯?shù)據(jù)。
實(shí)際上，它將有些復(fù)雜，因?yàn)槲覀冃枰獜腶llOverflow中刪除舊的溢出桶。 而且它還會增加 hmap 的大小，因此也可能需要重新整理數(shù)據(jù)。
最終官方在 hmap 中增加了 overflow 相關(guān)字段完成了上面的優(yōu)化，這是具體的 commit 地址。
下面看下具體是如何實(shí)現(xiàn)的，源碼基于 go1.15，src/cmd/compile/internal/gc/reflect.go 中
通過注釋可以看出，如果 map 中保存的鍵值都不包含指針（通過 Haspointers 判斷），就使用一個 uintptr 類型代替 bucket 的指針用于溢出桶 overflow 字段，uintptr 類型在 GO 語言中就是個大小可以保存得下指針的整數(shù)，不是指針，就相當(dāng)于實(shí)現(xiàn)了 將 bmap 標(biāo)記為 noScan， GC 的時候就不會遍歷完整個 map 了。隨著不斷的學(xué)習(xí)，愈發(fā)感慨 GO 語言中很多模塊設(shè)計得太精妙了。
差不多說清楚了，能力有限，有不對的地方歡迎留言討論，源碼位置還是問的群里大佬 _
重慶分公司
重慶分公司
