Advanced

Go 高级教程：反射 (Reflection) 实战 “反射是魔鬼。” —— 某些性能洁癖者 “没有反射，就没有现代 Web 框架。” —— 现实主义开发者 反射 (Reflection) 赋予了程序在 运行时 (Runtime) 检查和修改自身状态的能力。从 JSON 解析到 ORM 框架（如 GORM），再到依赖注入，它们的底层都离不开反射。 1. 核心概念：Type 和 Value 在 reflect 包中，有两位绝对主角： reflect.Type：这是啥？（类型信息，如 int, string, User） reflect.Value：这值多少？（具体的数据，如 42, “hello”, User{Name:“Hank”}） 一切反射操作的起点都是 interface{}。 1package main 2 3import ( 4 "fmt" 5 "reflect" 6) 7 8func main() { 9 x := 3.14 10 11 // 1. 获取类型 12 t := reflect.TypeOf(x) 13 fmt.Println("Type:", t) // float64 14 15 // 2. 获取值 16 v := reflect.ValueOf(x) 17 fmt.Println("Value:", v) // 3.14 18} graph LR subgraph iface ["interface{}"] direction TB TypePtr["_type pointer"] DataPtr["data pointer"] end TypePtr -->|"reflect.TypeOf"| RType["reflect.Type"] DataPtr -->|"reflect.ValueOf"| RValue["reflect.Value"] style iface fill:#f9f9f9,stroke:#333,stroke-width:2px,color:#333 style TypePtr fill:#e1f5fe,stroke:#01579b,color:#01579b style DataPtr fill:#e1f5fe,stroke:#01579b,color:#01579b style RType fill:#fff9c4,stroke:#fbc02d,color:#333 style RValue fill:#fff9c4,stroke:#fbc02d,color:#333 2. 三大反射定律 Go 的反射有三条铁律（出自 Rob Pike）： ...

Go 高级教程：其他并发工具 如果说 Goroutine 和 Channel 是 Go 并发的“常规武器”，那么 sync 包里的工具就是“特种装备”。虽然不常用，但关键时刻能救命（榨干 CPU 的最后一点性能）。 除了 这里 介绍的诸多基础并发工具外，Go 标准库还提供了一些高级并发工具，下面介绍几个比较常用的。 1. 减轻 GC 压力：sync.Pool 我们在讲 GC 的时候提过，如果你频繁申请和销毁大对象（比如 HTTP Response 对象，或者大的 byte buffer），GC 会鸭梨山大。 sync.Pool 就是为了对象复用而生的。 1.1 示例代码 1package main 2 3import ( 4 "fmt" 5 "sync" 6) 7 8// 定义池子 9var bufPool = sync.Pool{ 10 // New 函数：当池子里没存货时，调用它创建一个新的 11 New: func() interface{} { 12 fmt.Println("Creating new buffer") 13 return make([]byte, 1024) 14 }, 15} 16 17func main() { 18 // 1.Get(): 借一个对象 19 buf := bufPool.Get().([]byte) 20 21 // 用完它... 22 23 // 2. Put(): 还回去，下次给别人用 24 // 注意：还之前最好重置一下状态（比如清空） 25 bufPool.Put(buf) 26 27 // 再次 Get，就不会触发 New，而是直接复用刚才那个 28 buf2 := bufPool.Get().([]byte) 29 _ = buf2 30} 1.2 注意事项 sync.Pool 里的对象随时可能被 GC 回收！所以绝对不要用它存数据库连接、Socket 连接这种必须长久保持的资源。它只适合存“临时垃圾”。 ...

Go 高级教程：深入理解 GMP 调度器 为什么 Go 语言能轻松支撑百万并发？ 为什么 Goroutine 切换成本这么低？ 这一切的背后，都站着一位神秘的大管家 —— GMP 调度器。 1. 为什么需要 GMP？ 在很久很久以前（其实也就几十年前），我们写代码都是直接跟 线程 (Thread) 打交道。线程是操作系统（OS）调度的最小单位。 但是，线程这玩意儿太“贵”了： 内存占用高：一个线程栈大概要几 MB。 切换成本大：线程切换需要陷入内核态，保存寄存器、上下文，这简直就是“劳民伤财”。 这时候，Go 语言的设计师们拍案而起：“我们要造一种更轻量的线程！” 于是，Goroutine (协程) 诞生了。它初始只要几 KB，切换成本极低。 这就带来了一个问题：操作系统只认识线程，不认识 Goroutine。谁来负责把成千上万个 Goroutine 分配给 CPU 跑呢？ 这就需要一个“中间商” —— Go 运行时调度器 (Scheduler)。 图示: Thread 与 Goroutine 的区别 2. GMP 模型大揭秘 GMP 其实是三个角色的缩写： G (Goroutine)：我们写的代码任务，也就是协程。 M (Machine)：工作线程（Thread），对应操作系统的真实线程。它是真正的干活人（搬砖工）。 P (Processor)：逻辑处理器（Context），可以理解为“调度上下文”或“资源”。它是包工头，负责管理 G，并把 G 交给 M 去执行。 形象的比喻 想象一个大型搬砖工地： G (砖头)：待搬运的任务。 M (工人)：负责搬砖的劳动力。 P (手推车)：工人必须推着车才能搬砖（因为车里装着搬砖工具和任务清单）。 如果没有 P（手推车），M（工人）就不知道该干啥。 ...