對(duì)于很多人來(lái)說(shuō)，并發(fā)是一個(gè)離不開(kāi)的話題。那么我們平常對(duì)并發(fā)的理解可能局限于某個(gè)方面。去很好的理解并發(fā)，對(duì)于軟件開(kāi)發(fā)很有幫助。怎樣去更好的理解并發(fā)？

　　蘋(píng)果下落，在我們認(rèn)識(shí)牛頓定律之前。如果問(wèn)蘋(píng)果是下落的，我們都會(huì)說(shuō)大家都知道，很清楚，很明白——了解但沒(méi)引起關(guān)注。如果問(wèn)為什么蘋(píng)果下落。我們會(huì)舉出很多相關(guān)的概念來(lái)說(shuō)明蘋(píng)果為什么下落——相似性，但卻沒(méi)有一個(gè)很清晰的概念。在萬(wàn)有引力之后，我們的認(rèn)識(shí)已經(jīng)有一定的高度，甚至對(duì)以后很多科技都很有幫助。

　　所以怎樣去理解并發(fā)，我們不缺乏經(jīng)驗(yàn)。那么我們?nèi)狈Φ木褪悄敲匆粋€(gè)高度，可以理解為深度的認(rèn)識(shí)。

　　可能有人會(huì)講并發(fā)作為一種缺陷，一個(gè)問(wèn)題。此時(shí)，我將他作為一種能力，稱為并發(fā)能力。

　　其實(shí)提升并發(fā)能力，最主要的就是減少無(wú)效線程，減少線程時(shí)間。

　　拋出這樣一句話，相信有很大一部分人很費(fèi)解。并發(fā)跟線程有什么關(guān)系。并發(fā)，我們見(jiàn)得多的字眼可能是“同一時(shí)間訪問(wèn)量”。

　　在分析以上主題也是重點(diǎn)之前，我們先來(lái)看看電腦的線程運(yùn)行的情況。相信有操作系統(tǒng)相關(guān)知識(shí)的人都知道，確切的說(shuō)CPU在某一時(shí)刻處理唯一線程，在這條線程的時(shí)間片段用完會(huì)切換到處理其他線程，從而產(chǎn)生了多線程。

　　“同一時(shí)間訪問(wèn)量”是由多線程去引導(dǎo)處理才會(huì)有“同一時(shí)間訪問(wèn)量”這樣一個(gè)概念。

　　首先說(shuō)的是減少無(wú)效線程，是提升并發(fā)能力的手段之一。過(guò)多的線程切換回產(chǎn)生性能消耗，而且類似于圖片產(chǎn)生的線程對(duì)于網(wǎng)頁(yè)來(lái)說(shuō)，并不是最主要的,我們可以認(rèn)為是無(wú)效線程。其他網(wǎng)站對(duì)于本網(wǎng)站來(lái)說(shuō)，可以認(rèn)為是無(wú)效線程。減少無(wú)效線程從某一個(gè)方面來(lái)說(shuō)也是減少線程時(shí)間。

　　如何減少線程時(shí)間。

　　1. 運(yùn)算能力強(qiáng)

　　2. 粒度夠小。避免死鎖等情況。

　　3. 傳輸夠快。含網(wǎng)絡(luò)傳輸，I/O吞吐量。

　　現(xiàn)在已經(jīng)清晰的認(rèn)識(shí)到并發(fā)能力與線程有關(guān)。為什么減少線程時(shí)間，就是提升了并發(fā)能力。

　　我們已經(jīng)知道同一時(shí)間訪問(wèn)量，嚴(yán)格的說(shuō)不可能是同一時(shí)間，因?yàn)橛芯€程的調(diào)度。如果許多線程能夠快結(jié)束，又有心的線程加入，并不會(huì)影響性能，因此，我所說(shuō)的提升并發(fā)能力，就必須減少線程時(shí)間。

　　下面從層次上來(lái)看減少線程時(shí)間。

　　頁(yè)面，比如說(shuō)我們的后臺(tái)數(shù)據(jù)處理都非常快。但是頁(yè)面文件很大的話，或者并發(fā)的帶寬不夠?qū)挘瑢?dǎo)致傳輸數(shù)據(jù)花很長(zhǎng)的時(shí)間，那么頁(yè)面的線程可能在傳說(shuō)數(shù)據(jù)上花費(fèi)大量的時(shí)間。這樣就導(dǎo)致了并發(fā)能力的降低。因?yàn)榫€程被延長(zhǎng)了。線程的延長(zhǎng)影響了電腦處理軟件的能力，也就是并發(fā)能力的降低。

　　解決方案：靜態(tài)頁(yè)面，分布式，頁(yè)面優(yōu)化，壓縮，緩存，圖片與頁(yè)面服務(wù)器的分離等。

　　后臺(tái)，后臺(tái)是影響并發(fā)的非常關(guān)鍵的因素。架構(gòu)足夠爛，代碼足夠亂等等都是影響性能，從而間接影響并發(fā)。

　　架構(gòu)決定著怎么去編碼。這必然會(huì)影響運(yùn)行時(shí)間。我跟幾位朋友在爭(zhēng)論時(shí)編譯型快還是解釋性快的時(shí)候，我的觀點(diǎn)是解釋性的，其實(shí)我并不支持我這一觀點(diǎn)，但為什么這么說(shuō)。因?yàn)榫幾g型的要做更多的事情，也就是離核心越來(lái)越遠(yuǎn)。如果架構(gòu)足夠爛的網(wǎng)站還不如去用解釋性去做網(wǎng)站。至少微軟很多的東西就足夠讓性能降低非常明顯。

　　其次是代碼細(xì)節(jié)，比如說(shuō)有個(gè)Array的對(duì)象arrObj做下面運(yùn)算：

　　For(var i=0;i<arrObj.Count;i++){}

　　其實(shí)這段代碼，我們看起來(lái)沒(méi)有什么問(wèn)題，其實(shí)他的問(wèn)題大著呢。For的運(yùn)行時(shí)間復(fù)雜度為O(n),其實(shí)arrObj.Count在for中的時(shí)間復(fù)雜度也為O(n)，這樣將會(huì)達(dá)到2個(gè)O(n)的時(shí)間復(fù)雜度。其實(shí)我們可以這樣寫(xiě)，for(var i= arrObj.Count-1;i>=0;i--){}這樣只有一個(gè)O(n)的時(shí)間復(fù)雜度。

　　所以，可能作為后臺(tái)，大家談得更多是性能，其實(shí)說(shuō)性能還是在說(shuō)并發(fā)能力。從架構(gòu)和代碼細(xì)節(jié)上入手將會(huì)有一個(gè)質(zhì)量很高的，并發(fā)能力很強(qiáng)的軟件。

　　數(shù)據(jù)庫(kù)的并發(fā)，主要影響有幾個(gè)方面：一、數(shù)據(jù)庫(kù)的架構(gòu)，二、鎖，三、SQL語(yǔ)句。可能我們對(duì)數(shù)據(jù)的優(yōu)化可能側(cè)重于sql語(yǔ)句，其實(shí)不然。數(shù)據(jù)庫(kù)的架構(gòu)同樣非常的重要，也是影響數(shù)據(jù)庫(kù)操作時(shí)間的因素，從而影響并發(fā)能力。關(guān)于數(shù)據(jù)庫(kù)優(yōu)化的細(xì)節(jié)可以參照相關(guān)資料。

NET技術(shù)：話說(shuō)并發(fā)，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。