1. 保留但大幅度簡化指針
讓客戶滿意是我們工作的目標，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴，公司提供的服務項目有：主機域名、網(wǎng)絡空間、營銷軟件、網(wǎng)站建設、沙灣網(wǎng)站維護、網(wǎng)站推廣。
Go語言保留著C中值和指針的區(qū)別，但是對于指針繁瑣用法進行了大量的簡化，引入引用的概念。所以在Go語言中，你幾乎不用擔心會因為直接操作內(nèi)寸而引起各式各樣的錯誤。
2. 多參數(shù)返回
還記得在C里面為了回饋多個參數(shù)，不得不開辟幾段指針傳到目標函數(shù)中讓其操作么？在Go里面這是完全不必要的。而且多參數(shù)的支持讓Go無需使用繁瑣的exceptions體系，一個函數(shù)可以返回期待的返回值加上error，調(diào)用函數(shù)后立刻處理錯誤信息，清晰明了。
3. Array，slice，map等內(nèi)置基本數(shù)據(jù)結(jié)構(gòu)
如果你習慣了Python中簡潔的list和dict操作，在Go語言中，你不會感到孤單。一切都是那么熟悉，而且更加高效。如果你是C++程序員，你會發(fā)現(xiàn)你又找到了STL的vector 和 map這對朋友。
4. Interface
Go語言最讓人贊嘆不易的特性，就是interface的設計。任何數(shù)據(jù)結(jié)構(gòu)，只要實現(xiàn)了interface所定義的函數(shù)，自動就implement了這個interface，沒有像Java那樣冗長的class申明，提供了靈活太多的設計度和OO抽象度，讓你的代碼也非常干凈。千萬不要以為你習慣了Java那種一條一條加implements的方式，感覺還行，等接口的設計越來越復雜的時候，無數(shù)Bug正在后面等著你。
同時，正因為如此，Go語言的interface可以用來表示任何generic的東西，比如一個空的interface，可以是string可以是int，可以是任何數(shù)據(jù)類型，因為這些數(shù)據(jù)類型都不需要實現(xiàn)任何函數(shù)，自然就滿足空interface的定義了。加上Go語言的type assertion，可以提供一般動態(tài)語言才有的duck typing特性， 而仍然能在compile中捕捉明顯的錯誤。
5. OO
Go語言本質(zhì)上不是面向?qū)ο笳Z言，它還是過程化的。但是，在Go語言中， 你可以很輕易的做大部分你在別的OO語言中能做的事，用更簡單清晰的邏輯。是的，在這里，不需要class，仍然可以繼承，仍然可以多態(tài)，但是速度卻快得多。因為本質(zhì)上，OO在Go語言中，就是普通的struct操作。
6. Goroutine
這個幾乎算是Go語言的招牌特性之一了，我也不想多提。如果你完全不了解Goroutine，那么你只需要知道，這玩意是超級輕量級的類似線程的東西，但通過它，你不需要復雜的線程操作鎖操作，不需要care調(diào)度，就能玩轉(zhuǎn)基本的并行程序。在Go語言里，觸發(fā)一個routine和erlang spawn一樣簡單。基本上要掌握Go語言，以Goroutine和channel為核心的內(nèi)存模型是必須要懂的。不過請放心，真的非常簡單。
7. 更多現(xiàn)代的特性
和C比較，Go語言完全就是一門現(xiàn)代化語言，原生支持的Unicode, garbage collection, Closures(是的，和functional programming language類似), function是first class object，等等等等。
看到這里，你可能會發(fā)現(xiàn)，我用了很多輕易，簡單，快速之類的形容詞來形容Go語言的特點。我想說的是，一點都不夸張，連Go語言的入門學習到提高，都比別的語言門檻低太多太多。在大部分人都有C的背景的時代，對于Go語言，從入門到能夠上手做項目，最多不過半個月。Go語言給人的感覺就是太直接了，什么都直接，讀源代碼直接，寫自己的代碼也直接。
Go 語言較之 C 語言一個很大的優(yōu)勢就是自帶 GC 功能，可 GC 并不是沒有代價的。寫 C 語言的時候，在一個函數(shù)內(nèi)聲明的變量，在函數(shù)退出后會自動釋放掉，因為這些變量分配在棧上。如果你期望變量的數(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ù)是放在棧空間上還是堆空間上，是不一定的。這要看編譯器分析的結(jié)果。
可逃逸分析并不是百分百準確的，它有缺陷。有的時候你會發(fā)現(xiàn)有些變量其實在棧空間上分配完全沒問題的，但編譯后程序還是把這些數(shù)據(jù)放在了堆上。如果你了解 Go 語言編譯器逃逸分析的機制，在寫代碼的時候就可以有意識地繞開這些缺陷，使你的程序更高效。
Go 語言雖然在內(nèi)存管理方面降低了編程門檻，即使你不了解堆棧也能正常開發(fā)，但如果你要在性能上較真的話，還是要掌握這些基礎(chǔ)知識。
這里不對堆內(nèi)存和棧內(nèi)存的區(qū)別做太多闡述。簡單來說就是， 棧分配廉價，堆分配昂貴。 ?？臻g會隨著一個函數(shù)的結(jié)束自動釋放，堆空間需要時間 GC 模塊不斷地跟蹤掃描回收。如果對這兩個概念有些迷糊，建議閱讀下面 2 個文章：
這里舉一個小例子，來對比下堆棧的差別：
stack 函數(shù)中的變量 i 在函數(shù)退出會自動釋放；而 heap 函數(shù)返回的是對變量 i 的引用，也就是說 heap() 退出后，表示變量 i 還要能被訪問，它會自動被分配到堆空間上。
他們編譯出來的代碼如下：
邏輯的復雜度不言而喻，從上面的匯編中可看到， heap() 函數(shù)調(diào)用了 runtime.newobject() 方法，它會調(diào)用 mallocgc 方法從 mcache 上申請內(nèi)存，申請的內(nèi)部邏輯前面文章已經(jīng)講述過。堆內(nèi)存分配不僅分配上邏輯比?？臻g分配復雜，它最致命的是會帶來很大的管理成本，Go 語言要消耗很多的計算資源對其進行標記回收（也就是 GC 成本）。
Go 編輯器會自動幫我們找出需要進行動態(tài)分配的變量，它是在編譯時追蹤一個變量的生命周期，如果能確認一個數(shù)據(jù)只在函數(shù)空間內(nèi)訪問，不會被外部使用，則使用?？臻g，否則就要使用堆空間。
我們在 go build 編譯代碼時，可使用 -gcflags '-m' 參數(shù)來查看逃逸分析日志。
以上面的兩個函數(shù)為例，編譯的日志輸出是：
日志中的 i escapes to heap 表示該變量數(shù)據(jù)逃逸到了堆上。
需要使用堆空間，所以逃逸，這沒什么可爭議的。但編譯器有時會將 不需要 使用堆空間的變量，也逃逸掉。這里是容易出現(xiàn)性能問題的大坑。網(wǎng)上有很多相關(guān)文章，列舉了一些導致逃逸情況，其實總結(jié)起來就一句話：
多級間接賦值容易導致逃逸 。
這里的多級間接指的是，對某個引用類對象中的引用類成員進行賦值。Go 語言中的引用類數(shù)據(jù)類型有 func , interface , slice , map , chan , *Type(指針) 。
記住公式 Data.Field = Value ，如果 Data , Field 都是引用類的數(shù)據(jù)類型，則會導致 Value 逃逸。這里的等號 = 不單單只賦值，也表示參數(shù)傳遞。
根據(jù)公式，我們假設一個變量 data 是以下幾種類型，相應的可以得出結(jié)論：
下面給出一些實際的例子：
如果變量值是一個函數(shù)，函數(shù)的參數(shù)又是引用類型，則傳遞給它的參數(shù)都會逃逸。
上例中 te 的類型是 func(*int) ，屬于引用類型，參數(shù) *int 也是引用類型，則調(diào)用 te(j) 形成了為 te 的參數(shù)(成員) *int 賦值的現(xiàn)象，即 te.i = j 會導致逃逸。代碼中其他幾種調(diào)用都沒有形成 多級間接賦值 情況。
同理，如果函數(shù)的參數(shù)類型是 slice , map 或 interface{} 都會導致參數(shù)逃逸。
匿名函數(shù)的調(diào)用也是一樣的，它本質(zhì)上也是一個函數(shù)變量。有興趣的可以自己測試一下。
只要使用了 Interface 類型(不是 interafce{} )，那么賦值給它的變量一定會逃逸。因為 interfaceVariable.Method() 先是間接的定位到它的實際值，再調(diào)用實際值的同名方法，執(zhí)行時實際值作為參數(shù)傳遞給方法。相當于 interfaceVariable.Method.this = realValue
向 channel 中發(fā)送數(shù)據(jù)，本質(zhì)上就是為 channel 內(nèi)部的成員賦值，就像給一個 slice 中的某一項賦值一樣。所以 chan *Type , chan map[Type]Type , chan []Type , chan interface{} 類型都會導致發(fā)送到 channel 中的數(shù)據(jù)逃逸。
這本來也是情理之中的，發(fā)送給 channel 的數(shù)據(jù)是要與其他函數(shù)分享的，為了保證發(fā)送過去的指針依然可用，只能使用堆分配。
可變參數(shù)如 func(arg ...string) 實際與 func(arg []string) 是一樣的，會增加一層訪問路徑。這也是 fmt.Sprintf 總是會使參數(shù)逃逸的原因。
例子非常多，這里不能一一列舉，我們只需要記住分析方法就好，即，2 級或更多級的訪問賦值會 容易 導致數(shù)據(jù)逃逸。這里加上 容易 二字是因為隨著語言的發(fā)展，相信這些問題會被慢慢解決，但現(xiàn)階段，這個可以作為我們分析逃逸現(xiàn)象的依據(jù)。
下面代碼中包含 2 種很常規(guī)的寫法，但他們卻有著很大的性能差距，建議自己想下為什么。
Benchmark 和 pprof 給出的結(jié)果:
熟悉堆棧概念可以讓我們更容易看透 Go 程序的性能問題，并進行優(yōu)化。
多級間接賦值會導致 Go 編譯器出現(xiàn)不必要的逃逸，在一些情況下可能我們只需要修改一下數(shù)據(jù)結(jié)構(gòu)就會使性能有大幅提升。這也是很多人不推薦在 Go 中使用指針的原因，因為它會增加一級訪問路徑，而 map , slice , interface{} 等類型是不可避免要用到的，為了減少不必要的逃逸，只能拿指針開刀了。
大多數(shù)情況下，性能優(yōu)化都會為程序帶來一定的復雜度。建議實際項目中還是怎么方便怎么寫，功能完成后通過性能分析找到瓶頸所在，再對局部進行優(yōu)化。
需要寫一個方法，把json數(shù)據(jù)轉(zhuǎn)換成list集合數(shù)據(jù)
public static List jsonToBean(String data, Object bean) {
List list = new ArrayList();
try {
JSONArray array;
try {
array = new JSONArray(data);
for (int i = 0; i array.length(); i++) {
Object toBean = getBean(bean);
JSONObject ob = new JSONObject();
ob = (JSONObject) array.get(i);
toBean = jsonStrToBean(ob, toBean);
list.add(toBean);
}
return list;
} catch (JSONException e) {
try {
Object obj = null;
JSONObject jsonObj = new JSONObject(data);
Object toBean = getBean(bean);
toBean = jsonStrToBean(jsonObj, toBean);
list.add(toBean);
return list;
} catch (JSONException e1) {
log.error("Error covert String to JSONObject", e);
e1.printStackTrace();
}
e.printStackTrace();
log.error("Error covert String to JSONArray", e);
}
} catch (SecurityException e) {
e.printStackTrace();
}
return list;
}
所謂Go語言式的接口，就是不用顯示聲明類型T實現(xiàn)了接口I，只要類型T的公開方法完全滿足接口I的要求，就可以把類型T的對象用在需要接口I的地方。這種做法的學名叫做Structural Typing，有人也把它看作是一種靜態(tài)的Duck Typing。除了Go的接口以外，類似的東西也有比如Scala里的Traits等等。有人覺得這個特性很好，但我個人并不喜歡這種做法，所以在這里談談它的缺點。當然這跟動態(tài)語言靜態(tài)語言的討論類似，不能簡單粗暴的下一個“好”或“不好”的結(jié)論。
我的觀點:
Go的隱式接口Duck Typing確實不是新技術(shù), 但是在主流靜態(tài)編程語言中支持Duck Typing應該是很少的(不清楚目前是否只有Go語言支持).
靜態(tài)類型和動態(tài)類型雖然沒有絕對的好和不好, 但是每個都是有自己的優(yōu)勢的, 沒有哪一個可以包辦一切. 而Go是試圖結(jié)合靜態(tài)類型和動態(tài)類型(interface)各自的優(yōu)勢.
那么就從頭談起：什么是接口。其實通俗的講，接口就是一個協(xié)議，規(guī)定了一組成員，例如.NET里的ICollection接口：
public interface ICollection {
int Count { get; }
object SyncRoot { get; }
bool IsSynchronized { get; }
void CopyTo(Array array, int index);
}
這就是一個協(xié)議的全部了嗎？事實并非如此，其實接口還規(guī)定了每個行為的“特征”。打個比方，這個接口的Count除了需要返回集合內(nèi)元素的數(shù)目以外，還隱含了它需要在O(1)時間內(nèi)返回這個要求。這樣一個使用了ICollection接口的方法才能放心地使用Count屬性來獲取集合大小，才能在知道這些特征的情況下選用正確的算法來編寫程序，而不用擔心帶來性能問題，這才能實現(xiàn)所謂的“面向接口編程”。當然這種“特征”并不但指“性能”上的，例如Count還包含了例如“不修改集合內(nèi)容”這種看似十分自然的隱藏要求，這都是ICollection協(xié)議的一部分。
重慶分公司
重慶分公司
