為什么 Go 語言的性能還不如java

Go語言自亮相以來并沒有展示一個(gè)明確的方向，Google員工將Go語言稱為一個(gè)“試驗(yàn)性語言”，稱其試圖融合Python等動(dòng)態(tài)語言的開發(fā)速度和C或C++等編譯語言的性能和安全。一位Go語言的支持者概括而言Go語言如下：簡單、快速、安全、并發(fā)、快樂編程、開源；但Go語言缺乏方向以及其“集大成者”的嘗試很容易會(huì)導(dǎo)致其學(xué)貓不成學(xué)狗也不成，淪為四不像。盡管如此，編者仍然覺得Go語言有相當(dāng)大的潛力：很多開發(fā)者對(duì)它感興趣——不僅它的最初設(shè)計(jì)者陣容強(qiáng)大，而且在參與修改源代碼的人群中也不乏大牛級(jí)人物。這很有可能幫助Go語言找到適合自己的方向，開拓系統(tǒng)編程的新方向。

10年積累的成都網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、外貿(mào)網(wǎng)站建設(shè)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先制作網(wǎng)站后付款的網(wǎng)站建設(shè)流程，更有潁東免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

如何使用Golang進(jìn)行無心智負(fù)擔(dān)的編程

不知讀者是否也會(huì)時(shí)刻想: 我該怎么寫這段代碼才優(yōu)雅, 后期改起來方便?

努力思考卻還是得不到最佳答案, 煩躁等負(fù)面情緒不約而來。這便是在編程過程中的心智負(fù)擔(dān)。

這篇文章將從多個(gè)方面來簡化思考, 希望它能給努力思考的你帶來一點(diǎn)小靈感.

java的23種設(shè)計(jì)模式? 再見.

不是說他們沒有作用，只是說它們太死板復(fù)雜，學(xué)習(xí)它們通常入不敷出。

對(duì)于編程還有很多需要注意的地方（下文），而不要只局限于設(shè)計(jì)模式。

我給出的建議是只需要理解一個(gè)大概，在平時(shí)編程中能用則用。

Golang相比Java來說, 對(duì)"面向?qū)ο?這件事的支持是"不完整"的.

但話又說回來現(xiàn)在的"面向?qū)ο缶幊?漸漸被扭曲為了"面向類編程"（COP），而COP是復(fù)雜并難以理解的，COP有好處但要發(fā)揮出來并不容易。所以Golang決定拋棄所有不必要的概念以改善這個(gè)問題。

現(xiàn)在不必再理解 封裝(這個(gè)簡單到不需要理解), 多態(tài), 繼承.

在golang中只需要理解兩個(gè)更實(shí)在的東西: 接口, 組合.

接口

在Golang中只需要記得一個(gè)東西: Interface(接口).

參見io.Reader接口就知道這種設(shè)計(jì)有多厲害.

讀文件是它, 讀網(wǎng)絡(luò)請(qǐng)求也是它, 更騷的是 對(duì)于linux(Every thing is a file)來說用它就能操作近乎整個(gè)系統(tǒng)了.

簡單的說: 當(dāng)某個(gè)功能(如去北京)有多種(或者以后可能有多種)實(shí)現(xiàn)方式(如坐火車/飛機(jī)/騎車)的時(shí)候, 用接口.

組合

組合理解起來并不復(fù)雜, 不過是一個(gè)語法糖, 就算沒有組合功能也毫不影響Go程序的運(yùn)行.

如下代碼, 沒有組合換一種寫法即可.

簡單的說: 組合能用則用，如果你不知道如何使用或者不用也并無大礙。

"開閉原則"對(duì)我啟發(fā)很大.

原文是這樣:

但其實(shí)我們?cè)陂_發(fā)的時(shí)候并不是一直都在和對(duì)象打交道.

在我看來, "開閉原則"適用于平時(shí)寫的任何代碼.

完整理解"開閉原則"可能還是會(huì)造成心智負(fù)擔(dān), 所以先打住, 只需要這樣:

這便是 "對(duì)修改閉合, 對(duì)擴(kuò)展開放".

這里不得不在提及"面向函數(shù)編程", 它的思想包括但不限于:

它正好利于修改, 利于寫出符合"開閉原則"的代碼.

默認(rèn)的errors包在對(duì)于多層的復(fù)雜應(yīng)用是不夠的，這種情況下建議自行封裝，但別太追求完美 在項(xiàng)目中夠用就好。我們等待官方方案即可:

restful能解決大部分命名問題.

你的代碼完全可以這樣無腦命名而不失優(yōu)雅.

這樣的白話文真的很好命名與理解(根本不需要詞匯量).

無腦Goroution, 80%的情況下都沒問題.

如果你實(shí)在擔(dān)心, 用channel的做下并發(fā)數(shù)量控制就好, 或者使用更完整的工具叫"協(xié)程池", 他們的實(shí)現(xiàn)都不復(fù)雜.

得益于golang的開源和這幾年的蓬勃發(fā)展，golang的生態(tài)已經(jīng)十分完善，所以很多情況下我們應(yīng)該"面相github編程"，第三方提供的代碼已能滿足我們大多數(shù)需求。同時(shí) 選用一個(gè)受歡迎的第三方代碼庫通常比自己的更可靠，后續(xù)維護(hù)也省心很多。

最省心的行為是: 先跟隨團(tuán)隊(duì)再提出意見

為什么要使用 Go 語言，Go 語言的優(yōu)勢(shì)在哪里

部署簡單。Go編譯生成的是一個(gè)靜態(tài)可執(zhí)行文件，除了glibc外沒有其他外部依賴。這讓部署變得異常方便：目標(biāo)機(jī)器上只需要一個(gè)基礎(chǔ)的系統(tǒng)和必要的管理、監(jiān)控工具，完全不需要操心應(yīng)用所需的各種包、庫的依賴關(guān)系，大大減輕了維護(hù)的負(fù)擔(dān)。這和Python有著巨大的區(qū)別。由于歷史的原因，Python的部署工具生態(tài)相當(dāng)混亂【比如setuptools,distutils,pip,

buildout的不同適用場(chǎng)合以及兼容性問題】。官方PyPI源又經(jīng)常出問題，需要搭建私有鏡像，而維護(hù)這個(gè)鏡像又要花費(fèi)不少時(shí)間和精力。

并發(fā)性好。Goroutine和channel使得編寫高并發(fā)的服務(wù)端軟件變得相當(dāng)容易，很多情況下完全不需要考慮鎖機(jī)制以及由此帶來的各種問題。單個(gè)Go應(yīng)用也能有效的利用多個(gè)CPU核，并行執(zhí)行的性能好。這和Python也是天壤之比。多線程和多進(jìn)程的服務(wù)端程序編寫起來并不簡單，而且由于全局鎖GIL的原因，多線程的Python程序并不能有效利用多核，只能用多進(jìn)程的方式部署;如果用標(biāo)準(zhǔn)庫里的multiprocessing包又會(huì)對(duì)監(jiān)控和管理造成不少的挑戰(zhàn)【我們用的supervisor管理進(jìn)程，對(duì)fork支持不好】。部署Python應(yīng)用的時(shí)候通常是每個(gè)CPU核部署一個(gè)應(yīng)用，這會(huì)造成不少資源的浪費(fèi)，比如假設(shè)某個(gè)Python應(yīng)用啟動(dòng)后需要占用100MB內(nèi)存，而服務(wù)器有32個(gè)CPU核，那么留一個(gè)核給系統(tǒng)、運(yùn)行31個(gè)應(yīng)用副本就要浪費(fèi)3GB的內(nèi)存資源。

良好的語言設(shè)計(jì)。從學(xué)術(shù)的角度講Go語言其實(shí)非常平庸，不支持許多高級(jí)的語言特性;但從工程的角度講，Go的設(shè)計(jì)是非常優(yōu)秀的：規(guī)范足夠簡單靈活，有其他語言基礎(chǔ)的程序員都能迅速上手。更重要的是Go自帶完善的工具鏈，大大提高了團(tuán)隊(duì)協(xié)作的一致性。比如gofmt自動(dòng)排版Go代碼，很大程度上杜絕了不同人寫的代碼排版風(fēng)格不一致的問題。把編輯器配置成在編輯存檔的時(shí)候自動(dòng)運(yùn)行g(shù)ofmt，這樣在編寫代碼的時(shí)候可以隨意擺放位置，存檔的時(shí)候自動(dòng)變成正確排版的代碼。此外還有g(shù)ofix,

govet等非常有用的工具。

執(zhí)行性能好。雖然不如C和Java，但通常比原生Python應(yīng)用還是高一個(gè)數(shù)量級(jí)的，適合編寫一些瓶頸業(yè)務(wù)。內(nèi)存占用也非常省。