當(dāng)您對外部模塊的存儲庫進(jìn)行了 fork （例如修復(fù)模塊代碼中的問題或添加功能）時，您可以讓 Go 工具將您的 fork 用于模塊的源代碼。這對于測試您自己的代碼的更改很有用。
創(chuàng)新互聯(lián)是專業(yè)的哈巴河網(wǎng)站建設(shè)公司，哈巴河接單;提供網(wǎng)站建設(shè)、成都網(wǎng)站建設(shè),網(wǎng)頁設(shè)計,網(wǎng)站設(shè)計,建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行哈巴河網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊,希望更多企業(yè)前來合作!
為此，您可以使用go.mod 文件中的replace指令將外部模塊的原始模塊路徑替換為存儲庫中 fork 的路徑。這指示 Go 工具在編譯時使用替換路徑（fork 的位置），例如，同時允許您保留import 原始模塊路徑中的語句不變。
在以下 go.mod 文件示例中，當(dāng)前模塊需要外部模塊example.com/theirmodule。然后該replace指令將原始模塊路徑替換為example.com/myfork/theirmodule模塊自己的存儲庫的分支。
設(shè)置require/replace對時，使用 Go 工具命令確保文件描述的需求保持一致。使用go list命令獲取當(dāng)前模塊正在使用的版本。然后使用go mod edit命令將需要的模塊替換為fork：
注意： 當(dāng)您使用該replace指令時，Go 工具不會像添加依賴項中所述對外部模塊進(jìn)行身份驗證。
您可以使用go get命令從其存儲庫中的特定提交為模塊添加未發(fā)布的代碼。
為此，您使用go get命令，用符號@指定您想要的代碼 。當(dāng)您使用go get時，該命令將向您的 go.mod 文件添加一個 需要外部模塊的require指令，使用基于有關(guān)提交的詳細(xì)信息的偽版本號。
以下示例提供了一些說明。這些基于源位于 git 存儲庫中的模塊。
當(dāng)您的代碼不再使用模塊中的任何包時，您可以停止將該模塊作為依賴項進(jìn)行跟蹤。
要停止跟蹤所有未使用的模塊，請運(yùn)行g(shù)o mod tidy 命令。此命令還可能添加在模塊中構(gòu)建包所需的缺失依賴項。
要刪除特定依賴項，請使用go get，指定模塊的模塊路徑并附加 @none，如下例所示：
go get命令還將降級或刪除依賴于已刪除模塊的其他依賴項。
當(dāng)您使用 Go 工具處理模塊時，這些工具默認(rèn)從 proxy.golang.org（一個公共的 Google 運(yùn)行的模塊鏡像）或直接從模塊的存儲庫下載模塊。您可以指定 Go 工具應(yīng)該使用另一個代理服務(wù)器來下載和驗證模塊。
如果您（或您的團(tuán)隊）已經(jīng)設(shè)置或選擇了您想要使用的不同模塊代理服務(wù)器，您可能想要這樣做。例如，有些人設(shè)置了模塊代理服務(wù)器，以便更好地控制依賴項的使用方式。
要為 Go 工具指定另一個模塊代理服務(wù)器，請將GOPROXY 環(huán)境變量設(shè)置為一個或多個服務(wù)器的 URL。Go 工具將按照您指定的順序嘗試每個 URL。默認(rèn)情況下，GOPROXY首先指定一個公共的 Google 運(yùn)行模塊代理，然后從模塊的存儲庫直接下載（在其模塊路徑中指定）：
您可以將變量設(shè)置為其他模塊代理服務(wù)器的 URL，用逗號或管道分隔 URL。
Go 模塊經(jīng)常在公共互聯(lián)網(wǎng)上不可用的版本控制服務(wù)器和模塊代理上開發(fā)和分發(fā)。您可以設(shè)置 GOPRIVATE環(huán)境變量。您可以設(shè)置GOPRIVATE環(huán)境變量來配置go命令以從私有源下載和構(gòu)建模塊。然后 go 命令可以從私有源下載和構(gòu)建模塊。
GOPRIVATE或環(huán)境變量可以設(shè)置為匹配模塊前綴的全局模式列表，這些GONOPROXY前綴是私有的，不應(yīng)從任何代理請求。例如：
在開始之前，希望你計算一下 Part1 共占用的大小是多少呢？
輸出結(jié)果：
這么一算， Part1 這一個結(jié)構(gòu)體的占用內(nèi)存大小為 1+4+1+8+1 = 15 個字節(jié)。相信有的小伙伴是這么算的，看上去也沒什么毛病
真實情況是怎么樣的呢？我們實際調(diào)用看看，如下：
輸出結(jié)果：
最終輸出為占用 32 個字節(jié)。這與前面所預(yù)期的結(jié)果完全不一樣。這充分地說明了先前的計算方式是錯誤的。為什么呢？
在這里要提到 “內(nèi)存對齊” 這一概念，才能夠用正確的姿勢去計算，接下來我們詳細(xì)的講講它是什么
有的小伙伴可能會認(rèn)為內(nèi)存讀取，就是一個簡單的字節(jié)數(shù)組擺放
上圖表示一個坑一個蘿卜的內(nèi)存讀取方式。但實際上 CPU 并不會以一個一個字節(jié)去讀取和寫入內(nèi)存。相反 CPU 讀取內(nèi)存是 一塊一塊讀取 的，塊的大小可以為 2、4、6、8、16 字節(jié)等大小。塊大小我們稱其為 內(nèi)存訪問粒度 。如下圖：
在樣例中，假設(shè)訪問粒度為 4。 CPU 是以每 4 個字節(jié)大小的訪問粒度去讀取和寫入內(nèi)存的。這才是正確的姿勢
另外作為一個工程師，你也很有必要學(xué)習(xí)這塊知識點哦 :)
在上圖中，假設(shè)從 Index 1 開始讀取，將會出現(xiàn)很崩潰的問題。因為它的內(nèi)存訪問邊界是不對齊的。因此 CPU 會做一些額外的處理工作。如下：
從上述流程可得出，不做 “內(nèi)存對齊” 是一件有點 "麻煩" 的事。因為它會增加許多耗費(fèi)時間的動作
而假設(shè)做了內(nèi)存對齊，從 Index 0 開始讀取 4 個字節(jié)，只需要讀取一次，也不需要額外的運(yùn)算。這顯然高效很多，是標(biāo)準(zhǔn)的 空間換時間 做法
在不同平臺上的編譯器都有自己默認(rèn)的 “對齊系數(shù)”，可通過預(yù)編譯命令 #pragma pack(n) 進(jìn)行變更，n 就是代指 “對齊系數(shù)”。一般來講，我們常用的平臺的系數(shù)如下：
另外要注意，不同硬件平臺占用的大小和對齊值都可能是不一樣的。因此本文的值不是唯一的，調(diào)試的時候需按本機(jī)的實際情況考慮
輸出結(jié)果：
在 Go 中可以調(diào)用 unsafe.Alignof 來返回相應(yīng)類型的對齊系數(shù)。通過觀察輸出結(jié)果，可得知基本都是 2^n ，最大也不會超過 8。這是因為我手提（64 位）編譯器默認(rèn)對齊系數(shù)是 8，因此最大值不會超過這個數(shù)
在上小節(jié)中，提到了結(jié)構(gòu)體中的成員變量要做字節(jié)對齊。那么想當(dāng)然身為最終結(jié)果的結(jié)構(gòu)體，也是需要做字節(jié)對齊的
接下來我們一起分析一下，“它” 到底經(jīng)歷了些什么，影響了 “預(yù)期” 結(jié)果
在每個成員變量進(jìn)行對齊后，根據(jù)規(guī)則 2，整個結(jié)構(gòu)體本身也要進(jìn)行字節(jié)對齊，因為可發(fā)現(xiàn)它可能并不是 2^n ，不是偶數(shù)倍。顯然不符合對齊的規(guī)則
根據(jù)規(guī)則 2，可得出對齊值為 8。現(xiàn)在的偏移量為 25，不是 8 的整倍數(shù)。因此確定偏移量為 32。對結(jié)構(gòu)體進(jìn)行對齊
Part1 內(nèi)存布局：axxx|bbbb|cxxx|xxxx|dddd|dddd|exxx|xxxx
通過本節(jié)的分析，可得知先前的 “推算” 為什么錯誤？
是因為實際內(nèi)存管理并非 “一個蘿卜一個坑” 的思想。而是一塊一塊。通過空間換時間（效率）的思想來完成這塊讀取、寫入。另外也需要兼顧不同平臺的內(nèi)存操作情況
在上一小節(jié)，可得知根據(jù)成員變量的類型不同，其結(jié)構(gòu)體的內(nèi)存會產(chǎn)生對齊等動作。那假設(shè)字段順序不同，會不會有什么變化呢？我們一起來試試吧 :-)
輸出結(jié)果：
通過結(jié)果可以驚喜的發(fā)現(xiàn)，只是 “簡單” 對成員變量的字段順序進(jìn)行改變，就改變了結(jié)構(gòu)體占用大小
接下來我們一起剖析一下 Part2 ，看看它的內(nèi)部到底和上一位之間有什么區(qū)別，才導(dǎo)致了這樣的結(jié)果？
符合規(guī)則 2，不需要額外對齊
Part2 內(nèi)存布局：ecax|bbbb|dddd|dddd
通過對比 Part1 和 Part2 的內(nèi)存布局，你會發(fā)現(xiàn)兩者有很大的不同。如下：
仔細(xì)一看， Part1 存在許多 Padding。顯然它占據(jù)了不少空間，那么 Padding 是怎么出現(xiàn)的呢？
通過本文的介紹，可得知是由于不同類型導(dǎo)致需要進(jìn)行字節(jié)對齊，以此保證內(nèi)存的訪問邊界
那么也不難理解，為什么 調(diào)整結(jié)構(gòu)體內(nèi)成員變量的字段順序 就能達(dá)到縮小結(jié)構(gòu)體占用大小的疑問了，是因為巧妙地減少了 Padding 的存在。讓它們更 “緊湊” 了。這一點對于加深 Go 的內(nèi)存布局印象和大對象的優(yōu)化非常有幫
首先BFE（baidu front end）這個項目是一個功能類似于nginx的項目，并不是大家傳統(tǒng)意義上理解的前端（html＋css＋js）。之所以稱作“frontend”是因為它相對于整個應(yīng)用是處于最前面直接處理用戶的http請求的。
一開始這個項目是使用c語言寫的，因為業(yè)界大多數(shù)http服務(wù)器也都是使用c來開發(fā)的（如apache、nginx）這段時期稱作c-BFE時期。
但是到后期，這個項目遇到了一些問題：
c語言的開發(fā)效率太低了
c語言應(yīng)對需求變更比較吃力
c語言抽象能力不足
c語言需要手動管理內(nèi)存（有些不很優(yōu)秀的組員會寫出導(dǎo)致內(nèi)存泄漏的代碼）
bug越改越多，穩(wěn)定性和功能是一對矛盾
c語言程序員不好招
所以問題基本上是出在c語言不適應(yīng)了現(xiàn)在互聯(lián)網(wǎng)的快速變更的需求。之后百度決定重寫這個項目。
那么在開發(fā)效率上，golang基本上是滿足了百度的需求。首先BFE組有很多優(yōu)秀的c/c++的程序員了，他們轉(zhuǎn)go幾乎沒有什么壓力。對于一些不那么優(yōu)秀的c程序員（比如經(jīng)常漏內(nèi)存的），用golang之后也不會導(dǎo)致一些低級錯誤了。所以在學(xué)習(xí)成本上，更換golang對百度影響不大。
另外，golang本身的并發(fā)模型、語言的描述能力、和內(nèi)存管理等功能，也超過了c語言。所以整體上，開發(fā)效率得到了很大的提升。
使用golang遇到的最大的一個問題就是gc帶來的問題。李炳毅老師也重點是講解了baidu如何解決gc帶來的延遲問題。
在golang的1.3版本，百度的實際測試下，10k個對象大概會帶來1ms的延遲。而BFE一般會維持50萬左右的連接數(shù)，如果不對golang的gc做任何優(yōu)化的情況下，100萬鏈接大概會帶來400ms的延遲。相當(dāng)于一個http請求還沒有打到應(yīng)用上，單單在nginx上就耗費(fèi)了400ms。這肯定不能接受。
重慶分公司
重慶分公司
