8.1。根據(jù)查詢golang打印棧官方公布的參數(shù)顯示，golang打印棧大小為8.1，Go又稱Golang，是Google開發(fā)的一種靜態(tài)強類型、編譯型、并發(fā)型，并具有垃圾回收功能的編程語言。
成都創(chuàng)新互聯(lián)成都企業(yè)網(wǎng)站建設(shè)服務(wù)，提供網(wǎng)站建設(shè)、做網(wǎng)站網(wǎng)站開發(fā),網(wǎng)站定制,建網(wǎng)站,網(wǎng)站搭建,網(wǎng)站設(shè)計,響應(yīng)式網(wǎng)站,網(wǎng)頁設(shè)計師打造企業(yè)風(fēng)格網(wǎng)站,提供周到的售前咨詢和貼心的售后服務(wù)。歡迎咨詢做網(wǎng)站需要多少錢:18982081108
是的，c中數(shù)組定義時要指定大小。
當(dāng)然，萬事也不是絕對的。例如：1.作為形參的時候，可以不指定，因為在函數(shù)調(diào)用的時候，數(shù)組會轉(zhuǎn)為指針的。2.當(dāng)為字符串?dāng)?shù)組時，char ST[]="hello word"這兒定義了一個ST字符數(shù)值，不需要你自己去指定大小，系統(tǒng)會自動生成長度為11.
衍生類型，interface{} , map, [] ，struct等
map類似于java的hashmap，python的dict，php的hash array。
常規(guī)的for循環(huán)，可以用for k,v :=range m {}. 但在下面清空有一個坑注意：
著名的map[string]*struct 副本問題
結(jié)果：
Go 中不存在引用傳遞，所有的參數(shù)傳遞都是值傳遞，而map是等同于指針類型的，所以在把map變量傳遞給函數(shù)時，函數(shù)對map的修改，也會實質(zhì)改變map的值。
slice類似于其他語言的數(shù)組（list，array），slice初始化和map一樣，這里不在重復(fù)
除了Pointer數(shù)組外，len表示使用長度，cap是總?cè)萘浚琺ake([]int, len, cap)可以預(yù)申請 比較大的容量，這樣可以減少容量拓展的消耗，前提是要用到。
cap是計算切片容量，len是計算變量長度的，兩者不一樣。具體例子如下：
結(jié)果：
分析：cap是計算當(dāng)前slice已分配的容量大小，采用的是預(yù)分配的伙伴算法（當(dāng)容量滿時，拓展分配一倍的容量）。
append是slice非常常用的函數(shù)，用于添加數(shù)據(jù)到slice中，但如果使用不好，會有下面的問題：
預(yù)期是[1 2 3 4 5 6 7 8 9 10]， [1 2 3 4 5 6 7 8 9 10 11 12]，但實際結(jié)果是：
注意slice是值傳遞，修改一下：
輸出如下：
== 只能用于判斷常規(guī)數(shù)據(jù)類型，無法使用用于slice和map判斷，用于判斷map和slice可以使用reflect.DeepEqual，這個函數(shù)用了遞歸來判斷每層的k，v是否一致。
當(dāng)然還有其他方式，比如轉(zhuǎn)換成json，但小心有一些異常的bug，比如html編碼，具體這個json問題，待后面在分析。
在開始之前，希望你計算一下 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)存對齊” 是一件有點 "麻煩" 的事。因為它會增加許多耗費時間的動作
而假設(shè)做了內(nèi)存對齊，從 Index 0 開始讀取 4 個字節(jié)，只需要讀取一次，也不需要額外的運算。這顯然高效很多，是標(biāo)準(zhǔn)的 空間換時間 做法
在不同平臺上的編譯器都有自己默認(rèn)的 “對齊系數(shù)”，可通過預(yù)編譯命令 #pragma pack(n) 進(jìn)行變更，n 就是代指 “對齊系數(shù)”。一般來講，我們常用的平臺的系數(shù)如下：
另外要注意，不同硬件平臺占用的大小和對齊值都可能是不一樣的。因此本文的值不是唯一的，調(diào)試的時候需按本機的實際情況考慮
輸出結(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?，F(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)化非常有幫
?? 當(dāng)讀取91.2 MB文件時，read1耗時43ms，read2耗時99ms。
查看源碼：
讀取文件主要是通過 Read(p []byte) (n int, err error) ：
官方文檔中關(guān)于該接口方法的說明：
結(jié)論：
??ReadFile(filename string)方法之所以速度快的原因就是先計算出file文件的size，在初始化對應(yīng)size大小的buff，傳入ReadRead(p []byte) 來讀取字節(jié)流
重慶分公司
重慶分公司
