在非同步的模型下，不會持續等待，而是繼續執行，這不只是針對跨越行程、跨越機器的情境下，也能套用在同一行程中的不同執行緒間。
註解： 非同步的重點模型 不會持續等待 , 而是繼續執行
顧名思義,「同步」就是協同步伐,但是,不同的工作性質不同 ,需要的時間也不同,即使可以並行執行,所需的時間也不盡相同 。 協同步伐指的就像是Ａ工作和B工作同時進行, 但Ａ工作需要 Ｂ 工作完成後的結果,因此 ,Ａ工作和Ｂ工作之間必須協同步伐,也就是同步。說的具體一點,A 工作必須等待Ｂ 工作之間必須協同步伐, 也就是同步。說的更具體一點 ,Ａ工作必須等待完成後, 依據其結果來繼續執行,這就是同步的本質和特性。
相反的,在非同步的程式模型底下 ,則不會採用這種持續等待的方式。雖然Ａ工作終究是需要得到Ｂ工作的執行結果，以便進行其他的活動, 但是 Ａ工作並不持續等待,他可以繼續執行,但透過其他的途徑察知Ｂ工作是否完成,以及完成後的結果。在前文中提到, 在非同步的程式模型底下 ,可以透過 「等待直到完成」,「 回成 （callback) 」以及 「 輪詢 （polling)」,來得到非同步執行之後的結果。
一般來說,同步程式設計模式在概念上簡單,因為工作間循序執行,得到一個工作的結果後,才繼續執行下一個。但是,因為需要等待,一來可能缺乏效率（等待使得程式失去了執行其他工作的機會）,二來,等待的時間難以估量 , 有些應用情境不允許無限制或長期的等待。
舉例來說,對基於HTTP協定的Web應用程式而言,收到來自於客戶端的HTTP請求之後 ,Ｗeb應用程式執行對應的動作,再回傳HTTP回應內容。由於客戶端等待連線的時間通常會有逾時值之後,即時Web應用程式尚在執行,客戶端（例如瀏覽器）就會放棄連線。因此,對於採用同步程式設計模型的Web 應用程式,若是處理動作過久,就會衍生無法及時回應客戶端的問題。
為此，就必須採用非同步的程式設計模型，在收到來自於客戶端的請求時，便以非同步的方式啟動工作的進行，但在該工作未完成前，先回覆客戶端。此時的意義像是「工作請求已收到，敬請等帶執行結果（通常會回傳一個Task ID以資識別）。那麼，客戶端要怎麼得知工作完成與否，以及結果呢？雖然這是跨行程、 甚至是跨機器的主從架構，但是一樣可以使用「等待直到完成」 、「回乎」、以及「輪詢」這幾種方式。
note:為什麼要用非同步的方式寫網頁前端呢？
已瀏覽器對Web應用伺服器上的應用程式來說,最常見的大概就是輪詢。使用輪詢的方式,便是客戶端定期向伺服器的應用程式，查詢所指定Task ID 對應的工作是否完成，以及其完成結果。
對於一些B2B的應用來說,由於輪詢比較耗用資源，同時，受限在輪詢的週期，若週期太長，則
對於一些B2B的應用來說，由於輪詢比較耗用資源，同時，受限在輪詢的週期，若週期太長，則反應時間就拉長，若週期太短，耗用資源就更多，所以，這些應用並不採用輪詢的方式，而是採用回呼的方式。在回呼的方式下，當客戶端請求執行工作的時候，會提供伺服器一個回呼的位置（對Web應用程式來?，多半就是另一個HTTP的URL），而伺服器端會暫時回應，並回傳允許客戶端日後對應至該工作的相關資訊，例如Task ID。另一方面，伺服器端會執行工作，待工作完作後，便會依據客戶端當初提供的回呼位置，連線回去，並且提供工作執行的結果。這時候，當初的客戶端程式，便可因此而收到通知。
使用回呼的方式，不僅節省資源（不需要反覆地不斷請求）而且即時，不會受限在輪詢的週期長短。但是，對於客戶端來說，就需要提供可供連線的伺服器條件。所以，像以瀏覽器為基礎的客戶端就不適合，而像B2B這種，其實是伺服器對伺服器的應用中，卻相當適合。
非同步應用的範圍很廣
在上述的例子中，非同步的模型應用在跨越行程、跨越機器的情境下。事實上，即使是同一行程中的不同執行緒間，一樣可以套用相同的概念。
在同一個行程中，要進行非同步的作業，多執行緒是一個常見的實作方式。當主執行緒A打算執行某個工作B時，它可以產生另一個獨立的執行緒以執行工作B，而自己仍可在不停滯等待的情況下，繼續執行其他的工作。當然，主執行緒A很有可能必須知道工作B是否完成，以便處理不同的工作或做不同的決策。那麼它要怎麼知道呢？它可以運用像是「等待直到完成」，以及「輪詢（polling）」這幾種方式。
當執行緒A已經完成所有必要的工作，只剩等待B的完成後，它可以利用多執行緒程式庫或API提供的函式，來等待執行B工作的執行緒的結束。在該執行緒結束之後，便可以結束等待，取得執行結果並且繼續執行。這就是「等待直到完成」。
執行緒A也可以和B約定特定的變數來做為輪詢的對象。在啟動B的執行之後，A可以在需要時，查詢所約定變數之值。若該變數之值已指出B的執行完成或到達特定階段，A便可以處理不同的工作或做不同的決策。
不論是單一行程的多執行緒下，或跨越行程、跨越機器的網路應用程式間的通訊，非同步的設計觀念都是相同的，只是採取的實作手法有所變化。
當非同步工作太多時，怎麼辦？
此外，有些時候我們可能會同時要求多個非同步工作的執行，但是，受限於資源（例如計算力不足），所以，同時間只能執行一定數目的非同步工作。這時候，時常會運用所謂的工作佇列（Task Queue或Job Queue）。當要求非同步工作的執行時，便將相關的工作資訊置入工作佇列中，而每當有閒置可用的計算資源，例如執行緒時，便從工作佇列中取出工作資訊，並且加以執行。而實作工作佇列的方式也有很多種，可以使用資料庫來自行實作，也有很多人使用專門的訊息佇列伺服器（Message Queue）。
此外，為了控制同時間用於非同步工作的計算資源，通常也會利用像Process Pool或Thread Pool的機制，透過Pool的容量，便可以控制用於非同步工作的計算資源。當我們將工作佇列和Thread Pool搭配使用時，便會有一個角色，負責檢視Thread Pool中是否有可用的Thread，倘若有，便自工作佇列中取出工作並執行。
採用多執行緒的方式來做非同步的設計，基本上對主執行緒而言是非同步，但在處理各工作的執行緒中，仍是同步的觀念。正如前段文字中所提到的，同步的設計模型優點是簡單較容易處理。所以使用同執行緒時，便可以藉此得到這個優點，只不過仍有可能得處理執行緒間的同步問題。
像在網路伺服器的設計中，同一個伺服器必須同時間服務多個客戶端，所以其本質必須是非同步的（若是同步，則一次只能服務一個）。若採多執行緒的方式來設計，在主執行緒接收到來自客戶端的連線請求時，便可以產生一個新的執行緒（或從Thread Pool中取得）來專門服務該連線請求。在服務該連線的過程中，概念上還是同步的，所以這種模型在概念上很簡單也容易設計。
還有另一種設計方式，便是只利用一個執行緒來達成伺服器的實作。但因為要同時服務多個連線請求，所以主執行緒不能夠受任何同步的操作影響，而停滯執行。為此，所有操作必須是非同步的。所以像Socket的各項操作，包括接受連線、讀取、寫作等等，都不能夠造成等待的情況。如果你熟悉Socket的程式設計，你就會知道這通常是利用select()函式來做到。這樣的控制，程式模型就會變複雜許多，但是優點則是節省資源，只需要利用一個執行緒，就可以服務多個客戶端的連線請求。
由上例可見，同一種應用，還是可以利用不同的設計模型來達成，只是需要視其實際的需求，還有應用的限制，來決定究竟採用那一種較為適合。
留言列表
