非同步/等待之爭：為什麼 Go 語言的併發方案可能更好

BigGo Editorial Team

程式設計社群正在就 async/await（非同步/等待）特性展開激烈討論。這個在現代程式語言中普遍存在的特性，最初被譽為解決回撥地獄的良方，但現在卻在開發者中引發爭議，有人認為它帶來的問題比解決的問題更多。

async/await 最受詬病的問題之一是所謂的函式染色問題。當一個函式使用 await 時，它必須被標記為 async，而且這個要求會向上傳遞到整個呼叫棧。這種非同步標記的傳染性已經成為開發者的一大痛點，導致程式碼複雜性增加。

Go 語言的併發方案作為一種潛在的替代方案引起了人們的關注。Go 沒有采用 async/await，而是使用 goroutines 和 channels，實現了所謂的通訊順序程序（CSP）。這種方法允許開發者編寫看似同步的程式碼，而由執行時來處理併發執行的複雜性。

CSP 更簡單。更簡單就更容易做對。在二十年前，我經常用 C 語言編寫非同步伺服器。我覺得很容易，但大多數人並不這麼認為。如今我們有了更好的解決方案。

併發程式設計的主要方法：

許多開發者認為，像 Go 語言中實現的有棧協程，比大多數 async/await 實現中使用的無棧協程提供了更好的抽象。關鍵區別在於執行時如何處理執行上下文。Go 的方案允許開發者編寫更直觀的程式碼，無需顯式標記非同步邊界，同時仍然保持高效的併發執行。

支援 async/await 的一個重要論據來自 UI 程式設計。在 GUI 應用程式中，阻塞主執行緒會導致介面無響應。async/await 為處理後臺操作提供了一種清晰的方式，同時保持 UI 的響應性。這使它在前端開發和桌面應用程式中特別有價值。

最近的發展，如 Java 的虛擬執行緒，對傳統上用來證明 async/await 合理性的效能論據提出了挑戰。一些開發者認為，async/await 帶來的複雜性與其效能優勢不相稱，特別是在上下文切換很少成為瓶頸的典型業務應用中。

雖然 async/await 已經成為許多現代程式語言的標準特性，但關於其優劣的爭論仍在繼續。這場討論凸顯了軟體開發中抽象與複雜性之間的更廣泛張力，以及處理併發操作的不同方法之間的權衡。隨著領域的發展，我們可能會看到新的正規化出現，更好地平衡這些相互競爭的關注點。