James Hsueh

Goroutine 最佳入門姿勢

共 16 篇文章 • 第 1 / 2 頁

Day 1: Concurrency還是Parallelism？別再傻傻分不清楚！

安安，在接下來的 30 天，我將會與大家一起深入探索 Golang 併發 (Concurrency) 核心——Goroutine。這不僅是我的學習筆記，也希望透過這個系列文章，幫助更多像我一樣的開發者，掌握 Golang 最強大的武器之一

Day 2: 用一行 go 關鍵字，開啟並行的奇幻旅程

在 Day 1 我們釐清了並行 (Concurrency) 與平行 (Parallelism) 的觀念，並了解到 Golang 的設計核心就是讓「並行」的程式設計變得簡單。今天，我們將不再紙上談兵，而是要親手寫下第一段併發程式碼，召喚出我們的主角——Goroutine

Day 3: sync.WaitGroup 你的團隊合作好幫手

在 Day 2 中，我們成功用 `go` 關鍵字啟動了我們的第一個 Goroutine。但我們也留下了一個懸念：如何優雅、可靠地等待一個或多個 Goroutine 完成它們的任務？我們使用了 `time.Sleep` 這個「土法煉鋼」的方式，但我們都知道，這在真實世界中是完全行不通的。

Day 4: Channels 優雅地在並行世界中傳遞訊息

昨天，我們學會了使用 `sync.WaitGroup` 來完美地解決「等待一組 Goroutine 執行完畢」的問題。它就像一位盡責的專案經理，確保所有人都完成工作後才收工。但是，一個新的問題浮現了：如果 Goroutine 完成了工作，需要把「計算結果」回報給主 Goroutine，該怎麼辦呢？`WaitGroup` 只負責同步，不負責溝通。我們總不能把結果存到一個全域變數裡吧？那樣做會引發「競爭條件 (Race Condition)」，需要用複雜的鎖機制來保護，完全違背了 Go 語言簡潔的設計哲學...

Day 5: 無緩衝的同步之舞 vs. 有緩衝的非同步效率

在 Day 4，我們初次體驗了 Channel 的魔力。它不僅能在 Goroutine 之間安全地傳遞資料，其**阻塞**的特性還為我們提供了「免費」的同步。我們昨天使用的 `make(chan T)` 建立的，是 **無緩衝 Channel (Unbuffered Channel)**。然而，Channel 的世界並非只有一種形態。今天，我們要深入探討 Channel 的另一種樣貌——**有緩衝 Channel (Buffered Channel)**，並比較這兩者在不同場景下的優劣。這就像選擇交通工具，有時你需要的是能精準同步的F1賽車（無緩衝），有時你需要的則是可以暫存大量貨物的卡車（有緩衝）。

Day6 優雅地接收: 用 `for...range` 遍歷Channel，直到世界盡頭

在 Day 5，我們探討了無緩衝與有緩衝 Channel 的差異，了解了如何根據場景選擇合適的「管道」。我們學會了如何發送和接收單個數據，但真實世界中的場景往往更複雜：生產者 (Producer) Goroutine 可能會持續不斷地產生資料流，而消費者 (Consumer) Goroutine 需要處理完所有資料。我們如何知道生產者何時停止發送？消費者又該如何優雅地停止接收，而不是因為讀取一個空蕩蕩的 Channel 而永久阻塞下去？今天，我們將學習 `close()` 函式和 `for...range` 語法，這對組合技將完美解決這個問題。

Day 7: select 在多個Channel之間做出選擇

在 [Day 6](https://your-link-to-day-6)，我們學會了如何使用 `close()` 和 `for...range` 來優雅地處理來自單一 Channel 的數據流。這解決了生產者-消費者模型中的一個核心問題。但是，如果一個 Goroutine 需要同時應對**多個** Channel 呢？想像一個更複雜的場景：一個 Worker Goroutine 不僅要從任務 Channel (`tasks`) 接收工作，還要同時監聽一個來自系統的停止信號 Channel (`stopSignal`)。如果它傻傻地先 `<-tasks`，它可能會永遠阻塞在那裡，而錯過了重要的停止信號。這時，我們就需要一個更強大的工具，一個能讓我們在並行的十字路口做出選擇的工具。它就是 Go 語言的 `select` 陳述式。

Day 8: Channel的安全守則 用單向Channel，打造更穩健的API

在過去的幾天裡，我們使用的 Channel 都是**雙向 (Bidirectional)** 的。也就是說，我們用 `make(chan T)` 創建的 Channel，既可以往裡面發送資料(`ch <- data`)，也可以從裡面接收資料(`data := <-ch`)。在 Goroutine 內部自由使用雙向 Channel 是完全沒問題的。但是，當我們開始將 Channel 作為 method 參數，在不同的 Goroutine 之間傳遞時，一個關於「程式碼健壯性」和「API 設計」的問題就出現了：

Day 9: 時間的魔法師 在Goroutine中優雅地處理定時與延遲

在 Day 8，我們透過單向 Channel 為我們的併發 API 加上了型別安全。到目前為止，我們的 Goroutine 都是事件驅動的——它們因為 Channel 裡來了資料而觸發工作。但是，如果我們想引入「時間」這個維度呢？

Day10: 你的Goroutine正在悄悄洩漏 Part 1

在 Day9 的結尾，我們提到了「Goroutine 洩漏 (Goroutine Leak)」，並警告說忘記停止 `Ticker` 是導致洩漏的原因之一。今天，我們要正式面對這個併發程式中極其隱蔽且危險的敵人

Day11: 使用 Context 優雅地發出取消訊號

在 Day 10，我們探討了由於 channel 永久阻塞導致的 goroutine 洩漏問題，並得出結論：必須為每個 goroutine 提供一個明確的退出路徑。但是，如果一個 goroutine 正在執行一個耗時的任務，比如資料庫查詢或 API 請求，我們該如何從外部通知它：「嘿，不用再等了，上游請求已經被用戶取消了！」

Day 12: 你的Goroutine正在悄悄洩漏 Part 2

在 Day 11，我們學會了使用 context 套件來從外部優雅地取消一個 goroutine，解決了因等待外部事件（如用戶取消請求）而可能導致的洩漏問題。context 提供了一個強大的、跨越 `goroutine` 邊界的信號傳遞機制。今天，我們要回到 Day 10 提出的另一個問題：如何避免因 channel 操作本身被阻塞而導致的 goroutine 洩漏？比如，一個 goroutine 嘗試向一個緩衝區已滿且沒有接收者的 channel 發送數據。在這種情況下，沒有外部的 `cancel()` 函式會被調用，洩漏的根源在於 goroutine 內部的通信僵局。