Go的GMP模型真的“简单”

于 2024-08-07 08:01:44 发布
阅读量69 收藏
点赞数
文章标签： golang 开发语言 后端
原文链接：https://mp.weixin.qq.com/s?__biz=MzA4ODg0NDkzOA==&mid=2247510109&idx=1&sn=a84894479eb788f8c18abf4ee8d80293&chksm=911e7b45c596028d643269fcc71f4c8716ea3378716f4f2ffe4b0b22479eac281169e5fc9af6&scene=126&sessionid=0
版权

前言

关于GMP模型网上已经有很多文章，讲的内容大多都是如下图的逻辑，本系列不再赘述。本系列换个视角，核心搞清楚两个问题：

  • GMP到底是什么？

  • goroutine如何恢复和保存上下文的？

2fc24ebd531fa85437b8501bea175053.png

正文开始。

GMP只是结构体

GMP并不是你想象的那么神奇的存在，其实就是普通的结构体，如同你写业务代码定义的结构体一样，如下：

// Goroutine
// 代码位置：go1.19/src/runtime/proc.go
type g struct {
    stack     stack
    //...略...
    gopc      uintptr 
    startpc   uintptr
    sched     struct {
        sp   uintptr
        pc   uintptr
        //...略...
        bp   uintptr
     }
    //...略...
}
// Machine
// 代码位置：go1.19/src/runtime/proc.go
type m struct {
    g0            *g     
    //...略...
    curg          *g
    p             puintptr
    nextp         puintptr
    //...略...

    mOS 
}
// Processor
// 代码位置：go1.19/src/runtime/proc.go
type p struct {
    id          int32
    //...略...
    m           muintptr 
    mcache      *mcache
    //...略...
    runqhead uint32
    runqtail uint32
    runq     [256]guintptr
    runnext guintptr
    //...略... 
    gFree struct {
        gList
        n int32
    }
    //...略...
    mspancache struct {
        len int
        buf [128]*mspan
    }
    //...略...
    gcw gcWork
}

GMP是系统线程运行的代码片段

GMP和你写的业务代码一样，都是由系统线程运行。

020e7667da97d2c60dda4b3f50bec11d.png

GMP是类似面相对象的封装

左右滑动查看
类型结构体含义结构体职责
GGoroutine，代表协程1. 封装可被并发执行的函数片段，比如 go func() {// 函数A}()
G-2. 保存函数片段(协程)切换时的上下文信息
G-3. 封装g的栈内存空间，暂存函数片段(协程)执行时的临时变量的
MMachine，和系统线程建立映射，结构体绑定一个系统线程1. 绑定真正执行代码的系统线程，系统线程执行`G`的调度，和被调度的`G`绑定的函数
M-2. 维护P链表（可以从下一个P的队列找G）
PProcessor，和逻辑处理器建立映射1. 维护可执行G的队列(M从该队列找可执行的G)；
P-2. 堆内存缓存层（mcache）
P-3. 维护g的闲置队列

G职责解析

接下来，展开关于G展开两个关键问题：

  • G和函数绑定过程

  • G切换上下文过程

G和函数绑定过程

当你使用go关键字执行一个函数时go func(){}()：

  1. G和func具体绑定在哪？

  2. G和func何时绑定？

func main() {
    // 使用go 关键并发执行一个函数
    go func() {
        fmt.Println("demo")
    }()
}

G和func具体绑定在哪？

位于g的结构体 g.startpc属性，详细如下：

// Goroutine
// 代码位置：go1.19/src/runtime/proc.go
type g struct {
 //...略...
 gopc      uintptr  // go关键字创建Goroutine的代码位置
 //...略...
 startpc   uintptr // Goroutine绑定的函数代码地址
 //...略...
}

G和func何时绑定？

  1. 当通过go关键字运行一个函数时

  2. 从g的闲置队列获取一个g，并通过g.startpc属性绑定上待执行的函数fn

// 当你用go关键字执行一个函数
// 通过这个函数 绑定 g 和 待被执行的函数fn
func newproc(fn *funcval) {
    gp := getg()
    // 获取使用go关键字调用fn的代码位置
    // 方便fn执行完成之后跳回原代码位置
    pc := getcallerpc()
    systemstack(func() {
         // 绑定过程在这个函数中
         // 下面进一步分析newproc1
         newg := newproc1(fn, gp, pc)
         _p_ := getg().m.p.ptr()
         // 放入本地队列
         // 等待调度
         runqput(_p_, newg, true)
    })
}

// 绑定过程在这个函数中 分析newproc1
func newproc1(fn *funcval, callergp *g, callerpc uintptr) *g {
    //...略...
    newg := gfget(_p_) // 从g的闲置队列获取一个g
    //...略...
    newg.gopc = callerpc // 重点：设置go关键字的位置，便于fn执行完毕跳回原代码位置
    newg.startpc = fn.fn // 重点：这里绑定待被执行的函数fn
    //...略...
    return newg
}

函数绑定过程如下：

fd228191d2ab71adf146fdad9850f628.png

G切换上下文过程

  1. goroutine的上下文信息具体保存在哪？

  2. goroutine的上下文如何切换？

goroutine的上下文信息具体保存在哪？

位于g的结构体 g.sched属性，详细如下：

// Goroutine
// 代码位置：go1.19/src/runtime/proc.go
type g struct {
 stack     stack // 协程栈 执行过程临时变量存放的地方
 sched     gobuf // Goroutine上下文信息 保存在这个结构
    //...略...
}

// Goroutine上下文信息
type gobuf struct {
 sp   uintptr // 栈指针：指向栈顶
 pc   uintptr // 代码(指令)执行位置的地址
 //...略...
 bp   uintptr // 基指针：指向栈基
}

 goroutine的上下文如何切换？

  • g恢复上下文过程

  • g保存上下文过程

g恢复上下文过程

触发调度时：

  1. 找到可执行的g（来源本地队列、全局队列、netpoll list 读或写就绪的g列表）

  2. 把g的上下文g.sched通过汇编代码中的函数gogo恢复到对应的寄存器中

// g的调度方法
func schedule() {
 //...略...
 // 找可执行的g (本地队列、全局队列、netpoll list 读或写就绪的g列表 等)
 gp, inheritTime, tryWakeP := findRunnable() 
 //...略...
 //在这里 继续往下看
 execute(gp, inheritTime)
}

func execute(gp *g, inheritTime bool) {
 //...略...
 // 关键就是通过gogo这个函数 恢复
 gogo(&gp.sched)
}

gogo函数汇编代码，arm64架构示例汇编代码如下：

// void gogo(Gobuf*)
// restore state from Gobuf; longjmp
TEXT runtime·gogo(SB), NOSPLIT|NOFRAME, $0-8
 MOVD buf+0(FP), R5
 MOVD gobuf_g(R5), R6
 MOVD 0(R6), R4
 B gogo<>(SB)

TEXT gogo<>(SB), NOSPLIT|NOFRAME, $0
 MOVD R6, g
 BL runtime·save_g(SB)

 MOVD gobuf_sp(R5), R0 // 恢复栈指针
 MOVD R0, RSP
 MOVD gobuf_bp(R5), R29 // 恢复基指针
 MOVD gobuf_lr(R5), LR 
 MOVD gobuf_ret(R5), R0
 MOVD gobuf_ctxt(R5), R26
 MOVD $0, gobuf_sp(R5)
 MOVD $0, gobuf_bp(R5)
 MOVD $0, gobuf_ret(R5)
 MOVD $0, gobuf_lr(R5)
 MOVD $0, gobuf_ctxt(R5)
 CMP ZR, ZR 
 MOVD gobuf_pc(R5), R6 // 恢复PC计数器 指向下一个待执行的指令
 B (R6

g恢复上下文过程：

3f9010d9a3c6e51b25a009c62d9a8aa7.png

g保存上下文过程：

其中两个关键函数如下

  1. func save(pc, sp uintptr)触发保存上下文

  2. func mcall(fn func(*g))触发保存上下文

save函数

func save(pc, sp uintptr) {
 _g_ := getg()
 //...略...
 _g_.sched.pc = pc // 保存代码执行位置
 _g_.sched.sp = sp // 保存栈指针
 //...略...

调用func save(pc, sp uintptr)的场景如下：

  • 进入系统调用时

// 进入系统调用
func entersyscall() {
 reentersyscall(getcallerpc(), getcallersp())
}

func reentersyscall(pc, sp uintptr) {
 _g_ := getg()
 //...略...
 // 保存上下文
 save(pc, sp)
 _g_.syscallsp = sp
 _g_.syscallpc = pc
 casgstatus(_g_, _Grunning, _Gsyscall)
 //...略...
}

g保存上下文过程(进入系统调用通过save函数触发)：

284d20cd00fab6b0db779387001762e2.png

mcall函数

func mcall(fn func(*g))执行过程中，从g切换到g0，并执行fn。fn内部会执行调度函数shedule()，触发新的调度，下面会举一个例子。

TEXT runtime·mcall<ABIInternal>(SB), NOSPLIT|NOFRAME, $0-8
 MOVD R0, R26 

 MOVD RSP, R0
 MOVD R0, (g_sched+gobuf_sp)(g) // 保存当前g的栈指针
 MOVD R29, (g_sched+gobuf_bp)(g) // 保存当前g的基指针
 MOVD LR, (g_sched+gobuf_pc)(g)// 保存当前g的下一个待执行指令的位置 PC计数器
 MOVD $0, (g_sched+gobuf_lr)(g)

 // 切换到g0，并执行函数fn
 MOVD g, R3
 MOVD g_m(g), R8
 MOVD m_g0(R8), g
 BL runtime·save_g(SB)
 CMP g, R3
 BNE 2(PC)
 B runtime·badmcall(SB)

 MOVD (g_sched+gobuf_sp)(g), R0
 MOVD R0, RSP 
 MOVD (g_sched+gobuf_bp)(g), R29
 MOVD R3, R0 
 MOVD $0, -16(RSP)
 SUB $16, RSP
 MOVD 0(R26), R4
 BL (R4)
 B runtime·badmcall2(SB)

g保存上下文过程(通过mcall函数触发)：

400f9dfbd3bf92a71bd0949424cee18e.png

调用func mcall(fn func(*g))的场景如下：

  1. Gosched()：触发协作&抢占式式调度时

  2. gopark：g从运行状态转换为等待状态时

  3. goexit1()goroutine执行完成时

  4. exitsyscall()退出系统调用时

  5. 等

详细展开，Gosched()：触发协作&抢占式式调度时看看，如下

// 触发调度
func Gosched() {
 checkTimeouts()
 mcall(gosched_m)
}

func gosched_m(gp *g) {
 //...略...
 goschedImpl(gp)
}

func goschedImpl(gp *g) {
 //...略...
 // 正在运行状态转变为 可运行状态
 casgstatus(gp, _Grunning, _Grunnable)
 dropg()
 lock(&sched.lock)
 globrunqput(gp) // 放入全局队列
 unlock(&sched.lock)
 // 触发调度
 schedule()
}

func schedule() {
 //...略...
 // 找到下一个可执行的g
 gp, inheritTime, tryWakeP := findRunnable() 
 //...略...
 // 执行下一个g
 execute(gp, inheritTime)
}

func execute(gp *g, inheritTime bool) {
 //...略...
 // 恢复上下文
 gogo(&gp.sched)
}

// gogo汇编代码(arm64架构)
TEXT gogo<>(SB), NOSPLIT|NOFRAME, $0
 //...略...
 MOVD gobuf_sp(R5), R0 // 恢复栈指针
 MOVD gobuf_bp(R5), R29 // 恢复基指针
 //...略..

  • park_m 把g从运行状态转换为等待状态时

func gopark(unlockf func(*g, unsafe.Pointer) bool, lock unsafe.Pointer, reason waitReason, traceEv byte, traceskip int) {
 //...略...
 mcall(park_m)
}

func park_m(gp *g) {
 //...略...
 casgstatus(gp, _Grunning, _Gwaiting)
 dropg()
 //...略...
 // 触发调度
 schedule()
}

//...略...
// 同上`Gosched()

  • goexit1()goroutine执行完成时

func goexit1() {
 //...略...
 mcall(goexit0)
}

// goexit continuation on g0.
func goexit0(gp *g) {
 //...略...
 // 触发调度
 schedule()
}

//...略...
// 同上`Gosched()`

  • exitsyscall()退出系统调用时

func exitsyscall() {
 //...略...
 mcall(exitsyscall0)
 //...略...
}

func exitsyscall0(gp *g) {
 casgstatus(gp, _Gsyscall, _Grunnable)
 dropg()
 //...略...
 stopm()
 // 触发调度
 schedule()
}

/...略...
// 同上`Gosched()`

g保存上下文过程(通过mcall函数触发)：

36cd846f3c7de2441366e491c7a4b244.png

g的完整切换过程：

  • 当前g保存上下文（save/mcall）

  • 当前g切换到g0，g0执行schedule调度，找到新的可执行的g

  • 新的g恢复上下文（gogo）

  • 最后，实际以上操作都是有系统线程运行的。


M职责解析

  1. 绑定真正执行代码的系统线程

  2. 执行G的调度

  3. 执行被调度的G绑定的函数

  4. 维护P链表（可以从下一个P的队列找G）

// Machine
// 代码位置：go1.19/src/runtime/proc.go
type m struct {
 g0            *g     
 //...略...
 curg          *g  // 当前执行的g
 p             puintptr // m绑定的p
 nextp         puintptr // 4. 维护`P`链表（可以从下一个`P`的队列找`G`）
 //...略...

 // 1. 绑定真正执行代码的系统线程
 // 2. 执行`G`的调度
 // 3. 执行被调度的`G`绑定的函数
 mOS 

 //...略...
}

P职责解析

  1. 维护可执行G的队列(M从该队列找可执行的G)；

  2. 堆内存缓存层（mcache）

  3. 维护g的闲置队列

// Processor
// 代码位置：go1.19/src/runtime/proc.go
type p struct {
 id          int32
 //...略...
 m           muintptr 
 mcache      *mcache // 堆内存缓存层（`mcache`)
 //...略...
 runqhead uint32 // 1. 维护可执行`G`的队列(`M`从该队列找可执行的`G`)；
 runqtail uint32 // 1. 维护可执行`G`的队列(`M`从该队列找可执行的`G`)；
 runq     [256]guintptr // 1. 维护可执行`G`的队列(`M`从该队列找可执行的`G`)；
 runnext guintptr // 1. 维护可执行`G`的队列(`M`从该队列找可执行的`G`)；
 //...略... 
 // 3. 维护g的闲置队列
 gFree struct {
  gList
  n int32
 }
 //...略...
 mspancache struct {
  len int
  buf [128]*mspan
 }
 //...略...
 gcw gcWork
}

总结

再来回头看开篇的两个问题？

  • GMP到底是什么？

  • goroutine如何恢复和保存上下文的？

是不是已经很清晰。

  • 关于问题一，GMP是三个各司其职的结构体，被系统线程运行。

    类型结构体含义结构体职责
    GGoroutine，代表协程1. 封装可被并发执行的函数片段，比如 go func() {// 函数A}()
    G-2. 暂存函数片段(协程)切换时的上下文信息
    G-3. 封装g的栈内存空间，暂存函数片段(协程)执行时的临时变量的
    MMachine，和系统线程建立映射，结构体绑定一个系统线程1. 绑定真正执行代码的系统线程，系统线程执行`G`的调度，和被调度的`G`绑定的函数
    M-2. 维护`P`链表（可以从下一个`P`的队列找`G`）
    PProcessor，和逻辑处理器建立映射1. 维护可执行G的队列(M从该队列找可执行的G)；
    P-2. 堆内存缓存层（mcache）
    P-3. 维护g的闲置队列

  • 关于问题二，goroutine恢复和保存上下文过程（具体如下图所示）

  1. 当前g保存上下文（save/mcall汇编）

  2. 当前g切换到g0，g0执行schedule调度，找到新的可执行的g

  3. 新的g恢复上下文（gogo汇编）

    01df6eed324ae6773de86fafda2ac655.png

- END -

推荐阅读:

6 个必须尝试的将代码转换为引人注目的图表的工具

Go 1.23新特性前瞻

Gopher的Rust第一课：第一个Rust程序

Go早期是如何在Google内部发展起来的

2024 Gopher Meetup 武汉站活动

go 中更加强大的 traces

「GoCN酷Go推荐」我用go写了魔兽世界登录器?

Go区不大，创造神话，科目三杀进来了

想要了解Go更多内容，欢迎扫描下方👇关注公众号，扫描 [实战群]二维码  ,即可进群和我们交流~

- 扫码即可加入实战群 -

3eaaf6ecb1506bb29a1487e64663f2f2.png

7860ed5cbf401026cedf875a360ab824.png

分享、在看与点赞Go 6a123de325802ec821b7c232fdc2bbce.gif

Go中国
关注
GO调度模型：GMP
qq_33690342的博客
03-25 4412
GO的调度模型： 可以抽象出三个实体：M（machine）、P（processor）、G（goroutine）。 G：GO运行时对goroutine的描述，G中存放并发执行的代码入口地址、上下文、运行环境（关联的P和M）、运行栈等执行相关的信息。G的新建、休眠、恢复、停止都受到Go运行时的管理。 GO运行时的监控线程会监控G的调度，G不会长久地阻塞系统线程，运行时的调度器会自动切换到其他G上运行。G新建或恢复时会添加到运行队列，等待M取出并运行。 M：OS内核线程，是操作系...
深入理解 Go 语言的 GMP 调度模型
最新发布
禅与代码的艺术
08-21 1237
首先引入 Go 语言中经典的 GMP 模型，随后详细介绍 Go 语言协程的实现原理，以及 Go 语言调度器原理。
聊聊go语言中的GMP模型
Hi，我是sharkchili，CSDN Java领域博客专家，开源项目JavaGuide维护人员，我想写一些有意思的东西，希望对你有帮助。
04-24 662
因为近期收到很多读者的私信，所以也专门创建了一个交流群，感兴趣的读者可以通过上方的公众号获取笔者的联系方式完成好友添加，点击备注。因为近期收到很多读者的私信，所以也专门创建了一个交流群，感兴趣的读者可以通过上方的公众号获取笔者的联系方式完成好友添加，点击备注。对每一个线程的利用都做到的极致的压榨，一旦线程对应协程队列为空时，且全局的协程队列也为空的时候，当前处理器p就会采取。的工作流程后，我们就可以通过源码的方式印证这个问题，首先来看看处理器模型的源码，通过。这里我们不妨看看从全局队列获取协程的源码。
GO的GMP的理解
changzhaoliuting的博客
04-02 1731
系列文章目录 提示：这里可以添加系列文章的所有文章的目录，目录需要自己手动添加 例如：第一章 Python 机器学习入门之pandas的使用 提示：写完文章后，目录可以自动生成，如何生成可参考右边的帮助文档 文章目录系列文章目录一，GPM各个的意思和作用二、GPM之间的配合作用1）G的出现2）G的调度其实是一种抢占式的调度。（饥饿游戏-抢）3）GPM之间的关系图三.GPM的调度详细分析1.抢占式调度1）带有函数被抢占的形式2）channel阻塞或network I/O情况下的调度3）syscall阻塞下的
go语言GMP模式介绍以及协程案例展示
qq_49195366的博客
01-16 2134
Go语言的调度模型被称为GMP，这是一个高效且复杂的调度系统，用于在可用的物理线程上调度goroutines（Go的轻量级线程）。GMP模型由三个主要组件构成：Goroutine、M（机器）和P（处理器）。：管道在内部实现了必要的同步机制，因此在多个goroutines访问时是安全的。关闭管道后，不能再向管道发送数据，但仍可以接收管道中已存在的数据。：无缓冲管道在发送或接收时会阻塞，直到另一端准备好。尝试向已关闭的管道发送数据会引发panic。循环从管道接收数据，直到管道被关闭。
golang gmp模型入门
04-23
Golang GMP 模型入门 Golang 调度器是 Golang 语言的核心组件之一，负责管理 goroutine 的执行和调度。Golang 调度器的 GMP 模型是 Golang 调度器的核心思想，G 代表 goroutine，M 代表线程，P 代表处理器。 ...
学习资料 golang的GMP调度模型
11-02
在编程领域，Go语言（Golang）以其独特的并发模型闻名，这一模型主要基于Goroutines和 channels，而GMP调度模型则是理解Go并发性能的关键。本资料包包含了一个关于GMP调度模型的全面学习资源，包括视频教程、笔记和...
分析一下golang的gmp模型
weixin_35756892的博客
12-26 129
GMP (GNU Multiple Precision Arithmetic Library) 是一个开源的多精度数学库，支持高精度的整数和浮点数运算。Golang 有一个内置的多精度数学包(math/big)，它使用了 GMP 库来实现高精度运算。 Golang 的 math/big 包提供了一些基本的数学运算，包括加法、减法、乘法、除法和模运算。它还提供了一些高级的函数，如幂运算、对数、三角函...
【go基础】2.GMP调度模型
lixiaonan0318的博客
03-22 619
每个P都拥有自己的本地队列，当P上的M执行完当前goroutine后，可以直接从本地队列中取出下一个goroutine来执行，而无需与其他P的队列进行交互。M0：M0是启动程序后的编号为0的主线程，这个M对应的实例会在全局变量runtime.m0中，不需要在heap上分配，M0负责执行初始化操作和启动第一个G， 在之后M0就和其他的M一样了。从缓存区取G的过程，如果本地P为空，从调度器中取P容量的一半个G，放到自己的P里，根据work stealing，偷取的是其他P的一半，所以是否所有P容量相同？
GO高阶: 调度器 GMP 原理与调度全分析
琦彦
10-02 446
目录 Golang的协程调度器原理及GMP设计思想？ 一、Golang“调度器”的由来？ (1) 单进程时代不需要调度器 (2)多进程/线程时代有了调度器需求 (3)协程来提高CPU利用率 (4)Go语言的协程goroutine (5)被废弃的goroutine调度器 二、Goroutine调度器的GMP模型的设计思想 (1)GMP模型 (2)调度器的设计策略 (3) go func() 调度流程 (4)调度器的生命周期 (5)可视化GMP编程 三、Go调度器调度场景过程全解
Golang——GMP原理与调度
weixin_57023347的博客
04-25 1917
我们知道，一切软件都跑在操作系统上，真正用来干活(计算)的是CPU。早期的操作系统每一个程序就是一个进程，直到一个程序运行完，才能进行下一个进程，就是"单进程时代"。一切程序只能串行发生。那么能不能有有个进程来宏观一起来执行多个任务呢？后来操作系统就具有了最早的并发能力：多进程并发，当一个进程阻塞时，切换到另外一个等待执行的进程，这样就能尽量把CPU利用起来，CPU就不浪费了。
golang——GMP调度模型详解
weixin_45627369的博客
10-03 6107
GMP调度模型
【golang】深入理解GMP调度模型
m0_53328239的博客
09-15 718
为了提高系统的性能，P 的数量肯定不是越小越好，所以官方默认值就是 CPU 的核心数，设置的过小的话，如果一个持有 P 的 M， 由于 P 当前执行的 G 调用了 syscall 而导致 M 被阻塞，那么此时关键点： GO 的调度器是迟钝的，它很可能什么都没做，直到 M 阻塞了相当长时间以后，才会发现有一个 P/M 被 syscall 阻塞了。调度器把G都分配M上，不同的G在不同的M并发运行时，都需要向系统申请资源，比如堆栈内存等，因为资源是全局的，就会因为资源竞争造成很多性能损耗。的栈空间，全局变量的。
一文解析golang中的协程与GMP模型
幸平的博客
04-25 1483
并发(并行）一直是在编程领域中一直受关注的一个核心主题。而go语言在诞生之初就带着「 高并发 」的明星光环，进入开发者的视野。而golang的高并发则是由goroutine与GMP调度模型实现的，因此探究goroutine与GMP的实现变得尤为重要。
go面试题系列-GMP模型
weixin_44937358的博客
09-28 294
GMP面试题
GO语言基础介绍
lxlmycsdnfree的博客
12-12 633
go语言的GMP模型（协程并发模型），P是go语言本身内部实现的调度器，它是基于协程队列的，协程在调度器面前就类似一个个独立的任务；P一般数量上是处理器内核数。
golang大杀器GMP模型
fengxiandada的博客
03-11 4559
golang大杀器GMP模型学习
Golang GMP调度模型详解
爱意时刻减淡，玫瑰不再浪漫
05-02 3905
文章目录前言1. Goroutine调度器的基本概念2. Goruntine调度策略2.1 work stealing机制2.2 hand off 机制 前言      线程数过多，意味着操作系统会不断地切换线程，频繁的上下文切换就成了性能瓶颈。      Golang的调度模型是GMP模型，它提供一种机制，可以在线程中自己实现调度，上下文切换更轻量，从而达到了线程数少，而并发数并不少的效果。而线程中调度的就
Go语言深度解析：GMP模型与协程实战
"这份Go语言学习课件涵盖了Go语言的核心特性，包括GMP模型、defer关键字、panic/recover机制、MySQL操作、类型转换以及JSON处理。深入解析了Go语言的并发模型，强调了协程、线程和处理器的关系，以及如何通过runtime...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值