Init

2026-05-24 11:42:38 +08:00
commit 30d312ac35
521 changed files with 146481 additions and 0 deletions
@@ -0,0 +1,168 @@
+---
+tags:
+  - 后端
+  - Go
+  - Gin
+  - 并发
+create time: 2026-04-27 10:05
+---
+
+# Context 池化与常见陷阱
+
+## 概述
+
+`gin.Context` 通过 `sync.Pool` 复用以减少 GC 压力，这带来了性能红利，也埋下了并发陷阱。本文深入剖析池化机制、保存 Context 引用会引发的数据错乱问题，以及如何正确使用。
+
+## 正文
+
+### 1. Context 的复用流程
+
+Gin 在每次请求的完整生命周期中复用同一个 `*gin.Context` 对象：
+
+```go
+// gin/engine.go — ServeHTTP 简化版
+func (engine *Engine) ServeHTTP(w http.ResponseWriter, r *http.Request) {
+    c := engine.getContext()       // 从 sync.Pool 取 Context（可能是旧的）
+    c.Reset()                       // 清空所有字段，洗白板
+    c.Request = r
+    c.writermem.reset(w)
+
+    handlers, params, _ := engine.tree.match(r.URL.Path, r.Method)
+    c.handlers = handlers
+    c.params = params
+    c.index = -1
+
+    c.Next()                        // 执行中间件链 + 用户 handler
+
+    engine.freeContext(c)           // 归还到 sync.Pool，等待下次复用
+}
+```
+
+关键链路：**从 pool 取 → Reset 清空 → 填充新数据 → 执行完毕 → 归还 pool**。
+
+这意味着 `sync.Pool` 里存的是**被洗过白板的对象**，不是干净的新对象。
+
+### 2. 陷阱：保存 c 到全局变量
+
+如果在 handler 中把 `c` 保存到全局变量，**下次请求读到的是新请求的上下文**——因为对象被复用，字段被覆盖。
+
+#### 错误示范
+
+```go
+var globalC *gin.Context
+
+func SaveHandler(c *gin.Context) {
+    globalC = c  // 保存的是对象引用，不是副本
+    c.String(200, "saved")
+}
+
+func GetHandler(c *gin.Context) {
+    // 期望读到上次请求的数据，实际读到的是某个并发请求的数据！
+    req := globalC.Request
+    fmt.Println(req.URL.Path) // ← 可能是任意请求的路径
+}
+```
+
+#### 字段被覆盖对照表
+
+| 字段 | 请求 A 写入 | 请求 B 到来后（`c.Reset()`） |
+|------|-----------|--------------------------|
+| `globalC.Request` | A 的 `*http.Request` | **变成 B 的 Request** |
+| `globalC.keys` | `map[string]any{"user": "alice"}` | **被置为 nil，请求 B 重新 Set 后恢复** |
+| `globalC.Params` | A 的路径参数 | **变成 B 的路径参数** |
+| `globalC.writermem` | A 的响应缓冲 | **被重置，A 的已写入响应数据丢失** |
+
+#### 并发场景下的灾难
+
+当多个并发请求到来时，问题会进一步恶化：
+
+```
+时间线：
+T1: 请求 A 进入 → globalC = ctx（指向 pool 中的对象 X）
+T2: 请求 B 进入 → ctx 归还 pool → 新请求 C 从 pool 取出同一个对象 X
+T3: 请求 C 的 c.Reset() → globalC 指向的对象被清空 → 请求 A 的数据丢失！
+T4: GetHandler 读取 globalC → 读到的是请求 C 的数据，不是 A 的
+```
+
+**这不是简单的数据竞争，而是数据错乱**——你读到的既不是上次请求的数据，也不是当前请求的数据，而是**某个并发请求正在使用的数据**。
+
+### 3. 正确做法
+
+#### 方案一：拷贝数据而非保存引用
+
+```go
+var uid string
+
+func SaveHandler(c *gin.Context) {
+    uid = c.GetString("user_id")  // 拷贝值，不是保存 c
+}
+
+func GetHandler(c *gin.Context) {
+    _ = uid  // 安全：拷贝的是基本类型值
+}
+```
+
+#### 方案二：c.Set + c.Copy（推荐用于 goroutine）
+
+如果需要在异步 goroutine 中使用请求数据：
+
+```go
+func MyHandler(c *gin.Context) {
+    c.Set("user_id", "123")
+
+    // ✅ 正确：c.Copy() 创建独立副本
+    go func() {
+        c2 := c.Copy()  // 深拷贝 Context，keys 被浅拷贝到新 map
+        time.Sleep(1 * time.Second)
+        // c2 在这里是安全的，不受 pool 复用影响
+        fmt.Println(c2.GetString("user_id")) // "123"
+    }()
+}
+```
+
+`c.Copy()` 的核心实现：
+
+```go
+func (c *Context) Copy() *Context {
+    copy := &Context{
+        writermem: c.writermem.Clone(),  // 克隆响应缓冲
+        Params:    c.Params,             // Params 是 []Param，线程安全
+        engine:    c.engine,
+    }
+    // 浅拷贝 keys map
+    if c.keys != nil {
+        copy.keys = copyMap(c.keys)  // 创建新 map，拷贝所有键值对
+    }
+    copy.Request = c.Request  // *http.Request 本身是只读的，共享安全
+    return copy
+}
+```
+
+> **重点理解**：`c.Copy()` 做浅拷贝——`keys` map 本身是新的（键值对也是副本），但 `Request` 共享同一个 `*http.Request` 指针（标准库保证了 handler 执行期间 Request 不会被修改）。
+
+### 4. 设计原则总结
+
+```
+Context 池化 = 性能红利 + 并发陷阱
+
+✅ 安全：
+   - 在 handler 同步代码中使用 c
+   - 传给 goroutine 前先用 c.Copy()
+   - 只拷贝需要的数据值（c.GetString 等）
+
+❌ 危险：
+   - 保存 c 的引用到全局/包级变量
+   - 在 handler 中启动 goroutine 直接使用 c
+   - 跨请求传递 c 的引用
+```
+
+### 5. 思考题
+
+1. `c.Copy()` 是深拷贝还是浅拷贝？如果 `c.Set("user", userObj)` 存了一个指针类型，拷贝后两个 Context 里的 `userObj` 指向同一个对象吗？修改其中一个会互相影响吗？
+2. `sync.Pool` 的 Get/Put 是线程安全的，那从 pool 取出的 Context 在并发请求场景下，有没有可能两个请求同时拿到同一个对象？为什么不会？
+
+## 关联笔记
+
+- [[1-gin-architecture]] — Gin 整体架构
+- [[middleware]] — 中间件机制
+- [[engine-handler]] — Gin 与 http.Handler 的关系