先對這裡的非同步任務做下解釋： 這裡的意思是，該任務有幾種狀態，建立，等待，執行，結束；其中等待是因為，該任務要正常執行，需要其他執行緒（或程序）提供相應的條件（或觸發事件），然後才會執行。    針對這種要非同步處理（等待）的任務佇列管理模式，個人理解有兩種處理方法。

第一種： 

也是最常規的一種，定義一個佇列，建立任務，然後push到佇列裡面去，每個任務建立之後，（或接到開啟命令）啟動等待（定時器），等待所需條件（或事件），如果等待，那麼就正常執行，然後結束，如果超時，那麼就直接結束。  

這種方法的缺點就是，必須要有等待（定時器），這會消耗資源，影響效率。

優點就是不會有任務丟失。

第二種：

定義一個定長（較大）的任務陣列， 任務全部初始化為建立狀態，當有一個任務來的時候，那麼就查詢陣列中free的任務obj，注意這裡查詢，要從上一個已經使用的index往後查，（比如，現在已經存了3個有效任務，每次使用一個新的，都會記錄index, 那麼index應該等於2，那麼要查詢未被使用的任務obj,這裡應該從index=3開始查，這樣就不會把之前的任務沖掉） ，查的時候，只要狀態不是在執行就可以。   注意：這裡其實已啟用的任務，可能是出於等待狀態的，那麼當它的執行條件（事件）來的時候，那麼就要從之前已經存的啟動任務中去找（這裡要從記錄的index往前找，因為我們記錄的順序是從前往後的，前面的都是在等待或者已經運行了的），當找到後，就將任務狀態改為執行。

這裡寫的有些含糊，但是隻要細細理解，應該就能明白，這其實就是一個迴圈利用一開始就申請好的陣列佇列。

這中方法的優點就是 不用啟用定時器，節省資源，效率高，且不會有殭屍任務（比如方法一種如果沒有定時器，那麼就有可能出現一直在等待的任務）出現。 缺點就是，最多隻能有一開始建立的陣列大小個任務並行（這個缺點，可以通過變長陣列，或vector解決），還有一個缺點就是，有可能會有前面的等待任務，誤被當做free任務obj而被沖掉，所以這種方法適合那種快速響應的非同步任務（就是它建立了，它對應的啟動執行條件很快就會來，等待時間很短）。

兩種方法各有優缺點，需根據不同情況選擇。