如何正確理解.NET4.5和C#5.0中的async/await異步編程模式？這個(gè)等待，實(shí)際上，只是舊版本C迭代的一個(gè)推廣。現(xiàn)在很多平臺由于某些原因不得不使用舊版本的C，比如unity。如果希望異步，

如何正確理解.NET4.5和C#5.0中的async/await異步編程模式？

這個(gè)等待，實(shí)際上，只是舊版本C迭代的一個(gè)推廣?，F(xiàn)在很多平臺由于某些原因不得不使用舊版本的C，比如unity。如果希望異步，則只能使用迭代器。Async和iterator是語法糖。編譯器將幫助您實(shí)現(xiàn)狀態(tài)機(jī)的匿名類。在實(shí)例中保存一些臨時(shí)變量以記錄當(dāng)前狀態(tài)。根據(jù)您編寫的yield/await，將一個(gè)異步方法拆分為幾個(gè)同步塊。根據(jù)一定的規(guī)則，下一步要定期進(jìn)行。當(dāng)前是一項(xiàng)任務(wù)。然后我將根據(jù)您配置的線程上下文來決定在哪個(gè)線程上運(yùn)行此任務(wù)。在哪個(gè)線程中調(diào)用了用await修改的異步方法？為什么上面的事件處理方法不阻止GUI？我還看到一些其他的描述，async/await異步模式不會生成新線程，那么如何僅在現(xiàn)有線程的基礎(chǔ)上異步運(yùn)行呢？在本例中，此方法在UI線程中調(diào)用，并且沒有configureawait（false），因此執(zhí)行后的同步塊將在當(dāng)前await的UI線程上下文中捕獲。至于它為什么不阻塞，可以簡單理解，在執(zhí)行第一個(gè)塊并遇到延遲（4000）之后，UI線程的計(jì)時(shí)器被掛起4000次，然后調(diào)用下一個(gè)同步塊的回調(diào)。

在JavaScript中，是否存在“同步非阻塞”和“異步阻塞”這兩種情況？

首先，JS是單線程，沒有多線程，也沒有同步異步說。只要JS代碼被執(zhí)行，它就必須被同步。JS中所謂的同步和異步與C和Java中的線程異步不同。它只用于判斷JS執(zhí)行線程在Ajax和網(wǎng)絡(luò)資源處理線程之間切換時(shí)是否等待。如果使用同步請求，JS線程將掛起并等待請求完成，這必須被阻止。使用異步請求，JS線程將在網(wǎng)絡(luò)請求啟動后繼續(xù)向下執(zhí)行。這種阻塞也發(fā)生在實(shí)現(xiàn)引擎的C和C級別，而不是JS本身。當(dāng)顯示警報(bào)和其他彈出框時(shí)，用戶可以直觀地體驗(yàn)到JS級別的“阻塞”。瀏覽器內(nèi)核本身并不阻止警報(bào)，而是在上層阻止警報(bào)。所以我的答案是否定的