對于很多人來說，并發是一個離不開的話題。那么我們平常對并發的理解可能局限于某個方面。去很好的理解并發，對于軟件開發很有幫助。怎樣去更好的理解并發？

　　蘋果下落，在我們認識牛頓定律之前。如果問蘋果是下落的，我們都會說大家都知道，很清楚，很明白——了解但沒引起關注。如果問為什么蘋果下落。我們會舉出很多相關的概念來說明蘋果為什么下落——相似性，但卻沒有一個很清晰的概念。在萬有引力之后，我們的認識已經有一定的高度，甚至對以后很多科技都很有幫助。

　　所以怎樣去理解并發，我們不缺乏經驗。那么我們缺乏的就是那么一個高度，可以理解為深度的認識。

　　可能有人會講并發作為一種缺陷，一個問題。此時，我將他作為一種能力，稱為并發能力。

　　其實提升并發能力，最主要的就是減少無效線程，減少線程時間。

　　拋出這樣一句話，相信有很大一部分人很費解。并發跟線程有什么關系。并發，我們見得多的字眼可能是“同一時間訪問量”。

　　在分析以上主題也是重點之前，我們先來看看電腦的線程運行的情況。相信有操作系統相關知識的人都知道，確切的說CPU在某一時刻處理唯一線程，在這條線程的時間片段用完會切換到處理其他線程，從而產生了多線程。

　　“同一時間訪問量”是由多線程去引導處理才會有“同一時間訪問量”這樣一個概念。

　　首先說的是減少無效線程，是提升并發能力的手段之一。過多的線程切換回產生性能消耗，而且類似于圖片產生的線程對于網頁來說，并不是最主要的,我們可以認為是無效線程。其他網站對于本網站來說，可以認為是無效線程。減少無效線程從某一個方面來說也是減少線程時間。

　　如何減少線程時間。

　　1. 運算能力強

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

　　3. 傳輸夠快。含網絡傳輸，I/O吞吐量。

　　現在已經清晰的認識到并發能力與線程有關。為什么減少線程時間，就是提升了并發能力。

　　我們已經知道同一時間訪問量，嚴格的說不可能是同一時間，因為有線程的調度。如果許多線程能夠快結束，又有心的線程加入，并不會影響性能，因此，我所說的提升并發能力，就必須減少線程時間。

　　下面從層次上來看減少線程時間。

　　頁面，比如說我們的后臺數據處理都非常快。但是頁面文件很大的話，或者并發的帶寬不夠寬，導致傳輸數據花很長的時間，那么頁面的線程可能在傳說數據上花費大量的時間。這樣就導致了并發能力的降低。因為線程被延長了。線程的延長影響了電腦處理軟件的能力，也就是并發能力的降低。

　　解決方案：靜態頁面，分布式，頁面優化，壓縮，緩存，圖片與頁面服務器的分離等。

　　后臺，后臺是影響并發的非常關鍵的因素。架構足夠爛，代碼足夠亂等等都是影響性能，從而間接影響并發。

　　架構決定著怎么去編碼。這必然會影響運行時間。我跟幾位朋友在爭論時編譯型快還是解釋性快的時候，我的觀點是解釋性的，其實我并不支持我這一觀點，但為什么這么說。因為編譯型的要做更多的事情，也就是離核心越來越遠。如果架構足夠爛的網站還不如去用解釋性去做網站。至少微軟很多的東西就足夠讓性能降低非常明顯。

　　其次是代碼細節，比如說有個Array的對象arrObj做下面運算：

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

　　其實這段代碼，我們看起來沒有什么問題，其實他的問題大著呢。For的運行時間復雜度為O(n),其實arrObj.Count在for中的時間復雜度也為O(n)，這樣將會達到2個O(n)的時間復雜度。其實我們可以這樣寫，for(var i= arrObj.Count-1;i>=0;i--){}這樣只有一個O(n)的時間復雜度。

　　所以，可能作為后臺，大家談得更多是性能，其實說性能還是在說并發能力。從架構和代碼細節上入手將會有一個質量很高的，并發能力很強的軟件。

　　數據庫的并發，主要影響有幾個方面：一、數據庫的架構，二、鎖，三、SQL語句。可能我們對數據的優化可能側重于sql語句，其實不然。數據庫的架構同樣非常的重要，也是影響數據庫操作時間的因素，從而影響并發能力。關于數據庫優化的細節可以參照相關資料。