.NET非同步開發筆記(一)_Concurrent vs Parallel computing_執行緒_多執行緒與多工
在程式開發實務上會想要將一段程式改為非同步 不外乎是為了提升整體執行效能又或者響應(回應)速度 (例如:使UI不會卡頓) Concurrent computing (台灣翻:並行 計算/大陸翻: 并发计算) ->只有一個處理器(單核心) 數個運算任務同時在特定時間區段內交替地完成，而非依序運行。 通常生活常見可能類似一人多工的感覺 比方一個人負責彈奏2~3種樂器 一個人負責操作兩至三台機台設備 20~30年前早期電腦底層運算就是此模式) 而如今電腦都是多核心了 例如:NodeJs本身單Thread的就一定屬於並行運算 Parallel computing (台灣翻: 平行計算/大陸翻: 并行计算 ) ->可能有不只一個處理器(多核心)(效能相對會較高) 許多運算過程會同時發生 通常就軟體層面我們絕大部分就非同步層面開發 是針對「並行計算」的運算架構在進行設計思考與改善，而不會在意平行計算的範疇。 只要先就單個CPU的程式效能改善做好設計，剩下平行的範疇就通通交給作業系統。 大多數軟體開發人員只需要就並行計算做好設計即可，少數情境才需要就平行計算層面做思考和實踐。 所以通常在C#程式中非同步(Asynchronous programming) 大部分是一種Concurrent處理模式(輪流交替地work) 當啟動一非同步任務(背後類似起另一Thread做處理)後將會立即返回至呼叫端 非同步工作必須提出一承諾，告訴未來的狀態與結果。 常見會需要非同步的情境會分 1. I/O Bound 比方呼叫API、存取DB、檔案讀寫、從網路上取一份資料 因為I/O存取過程會導致CPU閒置，使CPU資源會被浪費。 通常可多採用await做等待非同步執行。 2.CPU Bound 比方圖片轉換處理、大數據計算 若程式可能需要進行大量繁重CPU運算，會導致應用程式會處於長期無法回應的狀態。 這類型應用較建議採TPL實作非同步。 備註:ADO.NET寫TSQL方式(I/O Bound)/EF ORM方式(偏向CPU Bound) 同步跟非同步觀念: 一個普通的方法(沒加上async修飾的)，通常默認就是同步方法是需要排隊等待依序執行的。 再加上async修飾後則代表我將此方法更改為非同步(異步)方法 此時大部分在撰寫程式時候async 跟await還是感覺跟同步沒捨...