13518219792
1．Docker項目
專注于為中小企業提供成都網站設計、成都網站制作服務,電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業長子免費做網站提供優質的服務。我們立足成都，凝聚了一批互聯網行業人才，有力地推動了上千多家企業的穩健成長，幫助中小企業通過網站建設實現規模擴充和轉變。
網址為 。
介紹：Docker是一種操作系統層面的虛擬化技術，可以在操作系統和應用程序之間進行隔離，也可以稱之為容器。Docker可以在一臺物理服務器上快速運行一個或多個實例。例如，啟動一個Cent OS操作系統，并在其內部命令行執行指令后結束，整個過程就像自己在操作系統一樣高效。
2．golang項目
網址為 。
介紹：Go語言的早期源碼使用C語言和匯編語言寫成。從Go 1.5版本自舉后，完全使用Go語言自身進行編寫。Go語言的源碼對了解Go語言的底層調度有極大的參考意義，建議希望對Go語言有深入了解的讀者讀一讀。
3．Kubernetes項目
網址為 。
介紹：Google公司開發的構建于Docker之上的容器調度服務，用戶可以通過Kubernetes集群進行云端容器集群管理。
4．etcd項目
網址為 。
介紹：一款分布式、可靠的KV存儲系統，可以快速進行云配置。
5．beego項目
網址為 。
介紹：beego是一個類似Python的Tornado框架，采用了RESTFul的設計思路，使用Go語言編寫的一個極輕量級、高可伸縮性和高性能的Web應用框架。
6．martini項目
網址為 。
介紹：一款快速構建模塊化的Web應用的Web框架。
7．codis項目
網址為 Labs/codis。
介紹：國產的優秀分布式Redis解決方案。
8．delve項目
網址為 。
介紹：Go語言強大的調試器，被很多集成環境和編輯器整合。
1、服務器編程：以前你如果使用C或者C++做的那些事情，用Go來做很合適，例如處理日志、數據打包、虛擬機處理、文件系統等。
2、分布式系統、數據庫代理器、中間件：例如Etcd。
3、網絡編程：這一塊目前應用最廣，包括Web應用、API應用、下載應用，而且Go內置的net/http包基本上把我們平常用到的網絡功能都實現了。
4、開發云平臺：目前國外很多云平臺在采用Go開發，我們所熟知的七牛云、華為云等等都有使用Go進行開發并且開源的成型的產品。
5、區塊鏈：目前有一種說法，技術從業人員把Go語言稱作為區塊鏈行業的開發語言。如果大家學習區塊鏈技術的話，就會發現現在有很多很多的區塊鏈的系統和應用都是采用Go進行開發的，比如ehtereum是目前知名度最大的公鏈，再比如fabric是目前最知名的聯盟鏈，兩者都有go語言的版本，且go-ehtereum還是以太坊官方推薦的版本。
自1.0版發布以來，go語言引起了眾多開發者的關注，并得到了廣泛的應用。go語言簡單、高效、并發的特點吸引了許多傳統的語言開發人員，其數量也在不斷增加。
使用 Go 語言開發的開源項目非常多。早期的 Go 語言開源項目只是通過 Go 語言與傳統項目進行C語言庫綁定實現，例如 Qt、Sqlite 等。
后期的很多項目都使用 Go 語言進行重新原生實現，這個過程相對于其他語言要簡單一些，這也促成了大量使用 Go 語言原生開發項目的出現。
在開始之前，希望你計算一下 Part1 共占用的大小是多少呢？
輸出結果：
這么一算， Part1 這一個結構體的占用內存大小為 1+4+1+8+1 = 15 個字節。相信有的小伙伴是這么算的，看上去也沒什么毛病
真實情況是怎么樣的呢？我們實際調用看看，如下：
輸出結果：
最終輸出為占用 32 個字節。這與前面所預期的結果完全不一樣。這充分地說明了先前的計算方式是錯誤的。為什么呢？
在這里要提到 “內存對齊” 這一概念，才能夠用正確的姿勢去計算，接下來我們詳細的講講它是什么
有的小伙伴可能會認為內存讀取，就是一個簡單的字節數組擺放
上圖表示一個坑一個蘿卜的內存讀取方式。但實際上 CPU 并不會以一個一個字節去讀取和寫入內存。相反 CPU 讀取內存是 一塊一塊讀取 的，塊的大小可以為 2、4、6、8、16 字節等大小。塊大小我們稱其為 內存訪問粒度 。如下圖：
在樣例中，假設訪問粒度為 4。 CPU 是以每 4 個字節大小的訪問粒度去讀取和寫入內存的。這才是正確的姿勢
另外作為一個工程師，你也很有必要學習這塊知識點哦 :)
在上圖中，假設從 Index 1 開始讀取，將會出現很崩潰的問題。因為它的內存訪問邊界是不對齊的。因此 CPU 會做一些額外的處理工作。如下：
從上述流程可得出，不做 “內存對齊” 是一件有點 "麻煩" 的事。因為它會增加許多耗費時間的動作
而假設做了內存對齊，從 Index 0 開始讀取 4 個字節，只需要讀取一次，也不需要額外的運算。這顯然高效很多，是標準的 空間換時間 做法
在不同平臺上的編譯器都有自己默認的 “對齊系數”，可通過預編譯命令 #pragma pack(n) 進行變更，n 就是代指 “對齊系數”。一般來講，我們常用的平臺的系數如下：
另外要注意，不同硬件平臺占用的大小和對齊值都可能是不一樣的。因此本文的值不是唯一的，調試的時候需按本機的實際情況考慮
輸出結果：
在 Go 中可以調用 unsafe.Alignof 來返回相應類型的對齊系數。通過觀察輸出結果，可得知基本都是 2^n ，最大也不會超過 8。這是因為我手提（64 位）編譯器默認對齊系數是 8，因此最大值不會超過這個數
在上小節中，提到了結構體中的成員變量要做字節對齊。那么想當然身為最終結果的結構體，也是需要做字節對齊的
接下來我們一起分析一下，“它” 到底經歷了些什么，影響了 “預期” 結果
在每個成員變量進行對齊后，根據規則 2，整個結構體本身也要進行字節對齊，因為可發現它可能并不是 2^n ，不是偶數倍。顯然不符合對齊的規則
根據規則 2，可得出對齊值為 8。現在的偏移量為 25，不是 8 的整倍數。因此確定偏移量為 32。對結構體進行對齊
Part1 內存布局：axxx|bbbb|cxxx|xxxx|dddd|dddd|exxx|xxxx
通過本節的分析，可得知先前的 “推算” 為什么錯誤？
是因為實際內存管理并非 “一個蘿卜一個坑” 的思想。而是一塊一塊。通過空間換時間（效率）的思想來完成這塊讀取、寫入。另外也需要兼顧不同平臺的內存操作情況
在上一小節，可得知根據成員變量的類型不同，其結構體的內存會產生對齊等動作。那假設字段順序不同，會不會有什么變化呢？我們一起來試試吧 :-)
輸出結果：
通過結果可以驚喜的發現，只是 “簡單” 對成員變量的字段順序進行改變，就改變了結構體占用大小
接下來我們一起剖析一下 Part2 ，看看它的內部到底和上一位之間有什么區別，才導致了這樣的結果？
符合規則 2，不需要額外對齊
Part2 內存布局：ecax|bbbb|dddd|dddd
通過對比 Part1 和 Part2 的內存布局，你會發現兩者有很大的不同。如下：
仔細一看， Part1 存在許多 Padding。顯然它占據了不少空間，那么 Padding 是怎么出現的呢？
通過本文的介紹，可得知是由于不同類型導致需要進行字節對齊，以此保證內存的訪問邊界
那么也不難理解，為什么 調整結構體內成員變量的字段順序 就能達到縮小結構體占用大小的疑問了，是因為巧妙地減少了 Padding 的存在。讓它們更 “緊湊” 了。這一點對于加深 Go 的內存布局印象和大對象的優化非常有幫
