"Concurrency"
- 1.1 channel ownership 與關閉責任
判斷誰能送出、接收與關閉 channel
- 4.1 goroutine：輕量並發工作
用 goroutine 啟動並發工作，並設計清楚的退出條件
- 1.2 select loop 的生命週期設計
理解長時間運行 goroutine 如何同時處理事件、ticker 與取消
- 4.2 channel：資料傳遞與 backpressure 理解 channel 如何在 goroutine 之間傳遞資料並形成 backpressure
- 1.3 非阻塞送出與事件丟棄策略
設計 channel 滿載時的服務行為
- 4.3 select：同時等待多種事件
用 select 建立事件迴圈
- 5.3 race condition 檢查
用 go test -race 找資料競爭
- 1.4 共享狀態與複製邊界
用 lock 與 copy 保護長期服務的狀態資料
- 4.4 sync.RWMutex：保護共享狀態
用讀寫鎖保護共享狀態
- 6.4 如何新增背景工作流程
接入 context、channel 與 shutdown
- 7.4 狀態管理的安全邊界
用 lock、copy 與 API 限制保護共享狀態
- 0.5 Go 和其他並發語言的差異
比較 Go、Java、C#、Rust、Node.js、Python async、Erlang/Elixir 在並發服務中的工程定位
- 4.5 高併發控制與 backpressure 用 bounded concurrency、backpressure 與 cancellation 控制 goroutine 的成長
- 1.5 bounded worker pool
限制同時執行的 goroutine 數量，讓背景工作有明確容量邊界
- 1.6 rate limiting 與 backpressure 用本地速率限制與 backpressure 策略保護服務入口與下游依賴
- 5.6 並發行為測試
測試 channel、goroutine 與狀態更新
- 3.7 context：取消、逾時與生命週期
用 context 傳遞取消、逾時與請求生命週期
- PostgreSQL MVCC + Lock Model：為什麼 PG 比 MySQL 少 deadlock、但 vacuum 是別的代價
PG 用 *MVCC-heavy + 少 explicit lock* 的並行控制、跟 MySQL InnoDB 的 *lock-based*（record / gap / next-key）相反。本文走 MVCC 機制（tuple version + xmin/xmax + visibility）、PG 4 種 lock（row-level / table-level / advisory / predicate）、預測 SERIALIZABLE 行為、5 production 踩雷（idle transaction 卡 vacuum / SELECT FOR UPDATE 跨 transaction / advisory lock 沒釋放 / bloat 不是 vacuum 問題 / predicate lock 在 SSI 下 rollback）、跟 MySQL lock-contention sibling 對比
- 4.0 Go 並發模型總覽
先理解 goroutine、OS thread 與 runtime 排程，再看高併發應用怎麼設計