我們在找工作時，經常在招聘信息上看到有這麼一條:有構建大型互聯網服務及高併發等經驗，你第一時間想到的是媒體常說的雙十一嗎？帶着問題，我們一起思考技術….
高併發高併發
它是互聯網分佈式系統架構設計中必須考慮的因素之一，通常是指，保證系統能夠同時並行化處理海量請求
同步和異步
- 同步：發送一個請求，等待返回，然後再發送下一個請求。提交請求 -> 等待服務器處理 -> 處理完返回，此期間客戶端瀏覽器不能幹任何事
- 異步：發送一個請求，不等待返回，隨時可以再發送下一個請求。提交請求 -> 服務器處理（這時瀏覽器仍然可以做其他事情）-> 處理完畢
從上圖可以知道，隨着實時間的軌跡，同步一步一步的執行着，在異步中，當一個異步過程調用發出後，調用者不能立即得到結果，實際上會開啓一個線程執行這部分內容，這個線程處理完了之後，通過狀態，通知和回調來通知調用者來處理。
併發和並行
單核CPU(單處理器)上，只可能存在併發而不可能存在並行。 並行在多處理器系統中存在，而併發可以在單處理器和多處理器系統中都存在，併發能夠在單處理器系統中存在是因爲併發是並行的假象，並行要求程序能夠同時執行多個操作，而併發只是要求程序假裝同時執行多個操作（每個小時間片執行一個操作，多個操作快速切換執行
臨界區
臨界區用來表示一種公共資源或者說是共享數據，可以被多個線程使用，但是每一次，只能有一個線程使用它，一旦臨界去資源被佔用，其他線程想要使用這個資源，就必須等待。
這就是我們編程中經常要加鎖的地方，如 Synchronized 關鍵字，或是 Lock 接口。
阻塞和非阻塞
- 阻塞(Blocking)和非阻塞(Non-Blocking)通常用來形容多線程間的相互影響，比如一個線程佔用臨界區資源，那麼其他所有需要這個資源的線程就必須在這個臨界區中進行等待，等待會導致線程掛起，這種情況就是阻塞。如果佔用資源的線程一直不願意釋放資源，那麼其它所有阻塞在這個臨界區上的線程都不能工作。
- 非阻塞允許多個線程同時進入臨界區。
死鎖、飢餓、活鎖
死鎖： 指兩個或兩個以上的進程（或線程）在執行過程中，因爭奪資源而造成的一種互相等待的現象，若無外力作用，它們都將無法推進下去。此時稱系統處於死鎖狀態或系統產生了死鎖，這些永遠在互相等待的進程稱爲死鎖進程。
互斥條件：線程對資源的訪問是排他性的，如果一個線程對佔用了某資源，那麼其他線程必須處於等待狀態，直到資源被釋放。 請求和保持條件：線程T1至少已經保持了一個資源R1佔用,但又提出對另一個資源R2請求，而此時，資源R2被其他線程T2佔用，於是該線程T1也必須等待，但又對自己保持的資源R1不釋放。 不剝奪條件：線程已獲得的資源，在未使用完之前，不能被其他線程剝奪，只能在使用完以後由自己釋放。 環路等待條件：在死鎖發生時，必然存在一個“進程-資源環形鏈”，即：{p0,p1,p2,…pn},進程p0（或線程）等待p1佔用的資源，p1等待p2佔用的資源，pn等待p0佔用的資源。（最直觀的理解是，p0等待p1佔用的資源，而p1而在等待p0佔用的資源，於是兩個進程就相互等待
活鎖： 指線程T1可以使用資源，但它很禮貌，讓其他線程先使用資源，線程T2也可以使用資源，但它很紳士，也讓其他線程先使用資源。這樣你讓我，我讓你，最後兩個線程都無法使用資源。
在街上遇到一妹子，剛好她朝着你的反方向走，與你正面碰到，你們都想讓彼此過去。你往左邊移，她也往左邊移，兩人還是無法過去。這時你往右邊移，她也往右邊移，如此循環下去。
飢餓： 指如果線程T1佔用了資源R，線程T2又請求封鎖R，於是T2等待。T3也請求資源R，當T1釋放了R上的封鎖後，系統首先批准了T3的請求，T2仍然等待。然後T4又請求封鎖R，當T3釋放了R上的封鎖之後，系統又批准了T4的請求……，T2可能永遠等待。
有兩條道A和B上都堵滿了車輛，其中A道堵的時間最長，B相對相對堵的時間較短，這時，前面道路已疏通，交警按照最佳分配原則，示意B道上車輛先過，B道路上過了一輛又一輛，A道上排隊時間最長的確沒法通過，只能等B道上沒有車輛通過的時候再等交警發指令讓A道依次通過，這也就是 ReentrantLock 顯示鎖裏提供的不公平鎖機制（當然了，ReentrantLock 也提供了公平鎖的機制，由用戶根據具體的使用場景而決定到底使用哪種鎖策略），不公平鎖能夠提高吞吐量但不可避免的會造成某些線程的飢餓。
併發級別
分爲 阻塞 和 非阻塞（非阻塞分爲無障礙、無鎖、無等待）
阻塞
當一個線程進入臨界區後，其他線程必須等待
無障礙
- 無障礙是一種最弱的非阻塞調度
- 可自由出入臨界區
- 無競爭時，有限步內完成操作
- 有競爭時，回滾數據
和非阻塞調度相比呢，阻塞調度是一種悲觀的策略，它會認爲說一起修改數據是很有可能把數據改壞的。而非阻塞調度呢，是一種樂觀的策略，它認爲大家修改數據未必把數據改壞。 但是它是一種 寬進嚴出 的策略，當它發現一個進程在臨界區內發生了數據競爭，產生了衝突，那麼無障礙的調度方式則會回滾這條數據。
在這個無障礙的調度方式當中，所有的線程都相當於在拿去一個系統當前的一個快照。他們一直會嘗試拿去的快照是有效的爲止。
無鎖
- 是無障礙的
- 保證有一個線程可以勝出 與無障礙相比，無障礙並不保證有競爭時一定能完成操作，因爲如果它發現每次操作都會產生衝突，那它則會不停地嘗試。如果臨界區內的線程互相干擾，則會導致所有的線程會卡死在臨界區，那麼系統性能則會有很大的影響。
而無鎖增加了一個新的條件，保證每次競爭有一個線程可以勝出，則解決了無障礙的問題。至少保證了所有線程都順利執行下去。
下面代碼是Java中典型的無鎖計算代碼
while (!atomicVar.compareAndSet(localVar, localVar+1)) { localVar = atomicVar.get();}無等待
- 無鎖的
- 要求所有的線程都必須在有限步內完成
- 無飢餓的
無等待的前提是無鎖的基礎上的，無鎖它只保證了臨界區肯定有進也有出，但是如果進的優先級都很高，那麼臨界區內的某些優先級低的線程可能發生飢餓，一直出不了臨界區。那麼無等待解決了這個問題，它保證所有的線程都必須在有限步內完成，自然是無飢餓的。
無等待是並行的最高級別，它能使這個系統達到最優狀態。無等待的典型案例：只有讀線程，沒有寫線程，那麼這個則必然是無等待的。 如果既有讀線程又有寫線程，而每個寫線程之前，都把數據拷貝一份副本，然後修改這個副本，而不是修改原始數據，因爲修改副本，則沒有衝突，那麼這個修改的過程也是無等待的。最後需要做同步的只是將寫完的數據覆蓋原始數據。由於無等待要求比較高，實現起來比較困難，所以無鎖使用得會更加廣泛一些。
關於並行的2個重要定律
兩個定律都與加速比有關
阿姆達爾定律
Amdahl定律(阿姆達爾定律)：定義了串行系統並行化後的加速比的計算公式和理論上限（加速比=優化前系統耗時/優化後系統耗時） 一個程序（或者一個算法）可以按照 是否可以被並行化 分爲下面兩個部分：
- 可以被並行化的部分
- 不可以被並行化的部
假設一個程序處理磁盤上的文件。這個程序的一小部分用來掃描路徑和在內存中創建文件目錄。做完這些後，每個文件交個一個單獨的線程去處理。掃描路徑和創建文件目錄的部分不可以被並行化，不過處理文件的過程可以。
增加CPU處理器的數量並不一定能起到有效的作用，提高系統內可並行化的模塊比重，合理增加並行處理器數量，才能以最小的投入，得到最大的加速比
古斯塔夫森定律
Gustafson定律(古斯塔夫森)：說明處理器個數，串行比例和加速比之間的關係
只要有足夠的並行化，那麼加速比和CPU個數成正比