golang-GMP模型

最新推荐文章于 2025-06-13 11:42:58 发布
最新推荐文章于 2025-06-13 11:42:58 发布
阅读量770 收藏
点赞数 4
CC 4.0 BY-SA版权
文章标签： golang
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_57960197/article/details/132549422

前言

线程数过多，意味着操作系统会不断地切换线程，频繁的上下文切换消耗性能
Golang的调度模型就是GMP模型，它可以提供一种机制，可以在线程中自己实现调度，上下文切换更加轻量，从而达到了线程数少，但是并发数并不少的效果。
描述：runtime准备好G、M、P，然后M绑定P，M从本地队列或全局队列中获取G，切换至G的执行栈上执行G的任务函数，执行完成后返回M，重复此过程。
官方注释：Goroutine 调度器的工作就是把“ready-to-run”的goroutine分发到线程中。

1. 基本概念

1.1 G（goroutine）

  • Go协程：每个关键字go 都会创建一个 goroutine 它存储了 goroutine 执行的 stack 信息、goroutine 状态以及goroutine 的任务函数等。
  • 在G的眼中，只有P，对于G而言 P就是CPU

1.2 M（machine）

  • 工作线程
  • M是真正调度系统的执行者，他会优先从关联的P的本地队列中直接获取可运行的G，如果本地队列中没有的话，再到调度器持有的全局队列中领取一些，或者是从其他的P的队列中偷取，M运行G，G执行之后，M会从P中获取下一个可执行的G

1.3 P（processor）

  • Processor 处理器，它包括了运行 goroutine 的资源
  • 它用于处理M和G的关系，如果线程M想要执行G，必须先获取P，P中还包含了可运行的G队列
  • P的个数在程序启动时确定，默认为CPU核心数，但是也可以通过runtime.GOMAXPROCS() 设置
    M必须拥有P才可以执行G中的代码，P含有一个包含多个G的队列，P可以调度G交由M执行。其关系如下图所示

图中M是交给操作系统调度的线程，M持有一个P，P将G调度进M中执行。P同时还维护着一个包含G的队列（图中灰色部分），可以按照一定的策略将不能的G调度进M中执行。
P的个数在程序启动时决定，默认情况下等同于CPU的核数，由于M必须持有一个P才可以运行Go代码，所以同时运行的M个数，也即线程数一般等同于CPU的个数，以达到尽可能的使用CPU而又不至于产生过多的线程切换开销。

2. 调度策略

2.1 队列轮转

每个P维护着一个包含G的队列，不考虑G进入系统调用或IO操作的情况下，P周期性的将G调度到M中执行，执行一小段时间，将上下文保存下来，然后将G放到队列尾部，然后从队列中重新取出一个G进行调度。
除了每个P维护的G队列以外，还有一个全局的队列，每个P会周期性的查看全局队列中是否有G待运行并将期调度到M中执行，全局队列中G的来源，主要有从系统调用中恢复的G。之所以P会周期性的查看全局队列，也是为了防止全局队列中的G被饿死。

2.2 系统调用

P的个数默认等于CPU核数，每个M必须持有一个P才可以执行G，一般情况下M的个数会略大于P的个数，这多出来的M将会在G产生系统调用时发挥作用。类似线程池，Go也提供一个M的池子，需要时从池子中获取，用完放回池子，不够用时就再创建一个。
当M运行的某个G产生系统调用时，如下图所示：

如图所示，当G0即将进入系统调用时，M0将释放P，进而某个空闲的M1获取P，继续执行P队列中剩下的G。而M0由于陷入系统调用而进被阻塞，M1接替M0的工作，只要P不空闲，就可以保证充分利用CPU。
M1的来源有可能是M的缓存池，也可能是新建的。当G0系统调用结束后，根据M0是否能获取到P，将会将G0做不同的处理：

  1. 如果有空闲的P，则获取一个P，继续执行G0。
  2. 如果没有空闲的P，则将G0放入全局队列，等待被其他的P调度。然后M0将进入缓存池睡眠。
    2.3 工作量窃取
    多个P中维护的G队列有可能是不均衡的，比如下图：

竖线左侧中右边的P已经将G全部执行完，然后去查询全局队列，全局队列中也没有G，而另一个M中除了正在运行的G外，队列中还有3个G待运行。此时，空闲的P会将其他P中的G偷取一部分过来，一般每次偷取一半。偷取完如右图所示。

3. 数据结构

3.1 g

type g struct {
    // ...
    m         *m      
    // ...
    sched     gobuf
    // ...
}


type gobuf struct {
    sp   uintptr
    pc   uintptr
    ret  uintptr
    bp   uintptr // for framepointer-enabled architectures
}
  • m：在 p 的代理，负责执行当前 g 的 m；
  • sched.sp：保存 CPU 的 rsp 寄存器的值，指向函数调用栈栈顶；
  • sched.pc：保存 CPU 的 rip 寄存器的值，指向程序下一条执行指令的地址；
  • sched.ret：保存系统调用的返回值；
  • sched.bp：保存 CPU 的 rbp 寄存器的值，存储函数栈帧的起始位置.
    状态
const(
  _Gidle = itoa // 0 为协程开始创建时的状态，此时尚未初始化完成；
  _Grunnable // 1 协程在待执行队列中，等待被执行；
  _Grunning // 2 协程正在执行，同一时刻一个 p 中只有一个 g 处于此状态；
  _Gsyscall // 3 协程正在执行系统调用；
  _Gwaiting // 4 协程处于挂起态，需要等待被唤醒. gc、channel 通信或者锁操作时经常会进入这种状态；
  _Gdead // 6 协程刚初始化完成或者已经被销毁，会处于此状态；
  _Gcopystack // 8 协程正在栈扩容流程中；
  _Gpreempted // 9 协程被抢占后的状态.
)

3.2 m

type m struct {
    g0      *g     // goroutine with scheduling stack
    // ...
    tls           [tlsSlots]uintptr // thread-local storage (for x86 extern register)
    // ...
}
  • g0：一类特殊的调度协程，不用于执行用户函数，负责执行 g 之间的切换调度. 与 m 的关系为 1:1；
  • tls：thread-local storage，线程本地存储，存储内容只对当前线程可见. 线程本地存储的是 m.tls 的地址，m.tls[0] 存储的是当前运行的 g，因此线程可以通过 g 找到当前的 m、p、g0 等信息.

3.3 p

type p struct {
    // ...
    runqhead uint32
    runqtail uint32
    runq     [256]guintptr
    
    runnext guintptr
    // ...
}
  • runq：本地 goroutine 队列，最大长度为 256.
  • runqhead：队列头部；
  • runqtail：队列尾部；
  • runnext：下一个可执行的 goroutine.

3.4 schedt

type schedt struct {
    // ...
    lock mutex
    // ...
    runq     gQueue
    runqsize int32
    // ...
}

sched 是全局 goroutine 队列的封装：

  • lock：一把操作全局队列时使用的锁；
  • runq：全局 goroutine 队列；
  • runqsize：全局 goroutine 队列的容量.

4. 调度流程

4.1 两种g的切换

goroutine 的类型可分为两类：

  1. 负责调度普通 g 的 g0，执行固定的调度流程，与 m 的关系为一对一；
  2. 负责执行用户函数的普通 g.
    m 通过 p 调度执行的 goroutine 永远在普通 g 和 g0 之间进行切换，当 g0 找到可执行的 g 时，会调用 gogo 方法，调度 g 执行用户定义的任务；当 g 需要主动让渡或被动调度时，会触发 mcall 方法，将执行权重新交还给 g0.

4.2 调度类型

通常，调度指的是由 g0 按照特定策略找到下一个可执行 g 的过程. 而本小节谈及的调度类型是广义上的“调度”，指的是调度器 p 实现从执行一个 g 切换到另一个 g 的过程.

这种广义“调度”可分为几种类型：

  1. 主动调度
    一种用户主动执行让渡的方式，主要方式是，用户在执行代码中调用了 runtime.Gosched 方法，此时当前 g 会当让出执行权，主动进行队列等待下次被调度执行.
  2. 被动调度
    因当前不满足某种执行条件，g 可能会陷入阻塞态无法被调度，直到关注的条件达成后，g才从阻塞中被唤醒，重新进入可执行队列等待被调度.
    常见的被动调度触发方式为因 channel 操作或互斥锁操作陷入阻塞等操作，底层会走进 gopark 方法.
  3. 正常调度
    g 中的执行任务已完成，g0 会将当前 g 置为死亡状态，发起新一轮调度.
  4. 抢占调度：
    倘若 g 执行系统调用超过指定的时长，且全局的 p 资源比较紧缺，此时将 p 和 g 解绑，抢占出来用于其他 g 的调度. 等 g 完成系统调用后，会重新进入可执行队列中等待被调度.
    值得一提的是，前 3 种调度方式都由 m 下的 g0 完成，唯独抢占调度不同.
    因为发起系统调用时需要打破用户态的边界进入内核态，此时 m 也会因系统调用而陷入僵直，无法主动完成抢占调度的行为.
    因此，在 Golang 进程会有一个全局监控协程 monitor g 的存在，这个 g 会越过 p 直接与一个 m 进行绑定，不断轮询对所有 p 的执行状况进行监控. 倘若发现满足抢占调度的条件，则会从第三方的角度出手干预，主动发起该动作.
    4.3 宏观调度流程
  5. 以 g0 -> g -> g0 的一轮循环为例进行串联；
  6. g0 执行 schedule() 函数，寻找到用于执行的 g；
  7. g0 执行 execute() 方法，更新当前 g、p 的状态信息，并调用 gogo() 方法，将执行权交给 g；
  8. g 因主动让渡( gosche_m() )、被动调度( park_m() )、正常结束( goexit0() )等原因，调用 m_call 函数，执行权重新回到 g0 手中；
  9. g0 执行 schedule() 函数，开启新一轮循环.

4.4 schedule函数

调度流程的主干方法是位于 runtime/proc.go 中的 schedule 函数，此时的执行权位于 g0 手中：

func schedule() {
    // ...
    gp, inheritTime, tryWakeP := findRunnable() // blocks until work is available


    // ...
    execute(gp, inheritTime)
}
  • 寻找到下一个执行的 goroutine；
  • 执行该 goroutine.

4.5 findRunnable函数

调度流程中，一个非常核心的步骤，就是为 m 寻找到下一个执行的 g，这部分内容位于 runtime/proc.go 的 findRunnable 方法中：

func findRunnable() (gp *g, inheritTime, tryWakeP bool) {
    _g_ := getg()


top:
    _p_ := _g_.m.p.ptr()
    // ...
    if _p_.schedtick%61 == 0 && sched.runqsize > 0 {
        lock(&sched.lock)
        gp = globrunqget(_p_, 1)
        unlock(&sched.lock)
        if gp != nil {
            return gp, false, false
        }
    }
    
    // ...
    if gp, inheritTime := runqget(_p_); gp != nil {
        return gp, inheritTime, false
    }
    
    // ...
    if sched.runqsize != 0 {
        lock(&sched.lock)
        gp := globrunqget(_p_, 0)
        unlock(&sched.lock)
        if gp != nil {
            return gp, false, false
        }
    }




    if netpollinited() && atomic.Load(&netpollWaiters) > 0 && atomic.Load64(&sched.lastpoll) != 0 {
        if list := netpoll(0); !list.empty() { // non-blocking
            gp := list.pop()
            injectglist(&list)
            casgstatus(gp, _Gwaiting, _Grunnable)
            return gp, false, false
        }
    }


    // ...
    procs := uint32(gomaxprocs)
    if _g_.m.spinning || 2*atomic.Load(&sched.nmspinning) < procs-atomic.Load(&sched.npidle) {
        if !_g_.m.spinning {
            _g_.m.spinning = true
            atomic.Xadd(&sched.nmspinning, 1)
        }




        gp, inheritTime, tnow, w, newWork := stealWork(now)
        now = tnow
        if gp != nil {
            // Successfully stole.
            return gp, inheritTime, false
        }
        if newWork {
            // There may be new timer or GC work; restart to
            // discover.
            goto top
        }
        if w != 0 && (pollUntil == 0 || w < pollUntil) {
            // Earlier timer to wait for.
            pollUntil = w
        }
    }
  • p 每执行 61 次调度，会从全局队列中获取一个 goroutine 进行执行，并将一个全局队列中的 goroutine 填充到当前 p 的本地队列中
if _p_.schedtick%61 == 0 && sched.runqsize > 0 {
        lock(&sched.lock)
        gp = globrunqget(_p_, 1)
        unlock(&sched.lock)
        if gp != nil {
            return gp, false, false
        }
 }

除了获取一个 g 用于执行外，还会额外将一个 g 从全局队列转移到 p 的本地队列，让全局队列中的 g 也得到更充分的执行机会.

func globrunqget(_p_ *p, max int32) *g {
    if sched.runqsize == 0 {
        return nil
    }


    n := sched.runqsize/gomaxprocs + 1
    if n > sched.runqsize {
        n = sched.runqsize
    }
    if max > 0 && n > max {
        n = max
    }
    if n > int32(len(_p_.runq))/2 {
        n = int32(len(_p_.runq)) / 2
    }


    sched.runqsize -= n


    gp := sched.runq.pop()
    n--
    for ; n > 0; n-- {
        gp1 := sched.runq.pop()
        runqput(_p_, gp1, false)
    }
    return gp
 }
  • 尝试从 p 本地队列中获取一个可执行的 goroutine，核心逻辑位于 runqget 方法中：
func runqget(_p_ *p) (gp *g, inheritTime bool) {
    if next != 0 && _p_.runnext.cas(next, 0) {
        return next.ptr(), true
    }




    for {
        h := atomic.LoadAcq(&_p_.runqhead) // load-acquire, synchronize with other consumers
        t := _p_.runqtail
        if t == h {
            return nil, false
        }
        gp := _p_.runq[h%uint32(len(_p_.runq))].ptr()
        if atomic.CasRel(&_p_.runqhead, h, h+1) { // cas-release, commits consume
            return gp, false
        }
    
    ...
}
  • 倘若当前 p 的 runnext 非空，直接获取即可
  • 加锁从 p 的本地队列中获取 g.
    需要注意，虽然本地队列是属于 p 独有的，但是由于 work-stealing 机制的存在，其他 p 可能会前来执行窃取动作，因此操作仍需加锁.
    但是，由于窃取动作发生的频率不会太高，因此当前 p 取得锁的成功率是很高的，因此可以说p 的本地队列是接近于无锁化，但没有达到真正意义的无锁.
  • 倘若本地队列为空，直接终止并返回；
  • 倘若本地队列存在 g，则取得队首的 g，解锁并返回.
  • 倘若本地队列没有可执行的 g，会从全局队列中获取：加锁，尝试并从全局队列中取队首的元素.
  • 倘若本地队列和全局队列都没有 g，则会获取准备就绪的网络协程：
    需要注意的是，刚获取网络协程时，g 的状态是处于 waiting 的，因此需要先更新为 runnable 状态.
  • work-stealing: 从其他 p 中偷取 g.
    偷取操作至多会遍历全局的 p 队列 4 次，过程中只要找到可窃取的 p 则会立即返回.
    为保证窃取行为的公平性，遍历的起点是随机的.

4.6 execute函数

当 g0 为 m 寻找到可执行的 g 之后，接下来就开始执行 g. 这部分内容位于 runtime/proc.go 的 execute 方法中：

func execute(gp *g, inheritTime bool) {
    _g_ := getg()


    _g_.m.curg = gp
    gp.m = _g_.m
    casgstatus(gp, _Grunnable, _Grunning)
    gp.waitsince = 0
    gp.preempt = false
    gp.stackguard0 = gp.stack.lo + _StackGuard
    if !inheritTime {
        _g_.m.p.ptr().schedtick++
    }

gogo(&gp.sched)
  • 更新 g 的状态信息，建立 g 与 m 之间的绑定关系；
  • 更新 p 的总调度次数；
  • 调用 gogo 方法，执行 goroutine 中的任务.
  • List item
从源码角度详解Golang调度GMP
yonggeit的博客
07-23 457
前面都是各种初始化操作，在这里开启了调度器的第一个调度循环。(这里启动的 M 就是 M0)下面来围绕 G、M、P 三个概念介绍 Goroutine 调度循环的运作流程。
GO调度模型：GMP
qq_33690342的博客
03-25 4510
GO的调度模型： 可以抽象出三个实体：M（machine）、P（processor）、G（goroutine）。 G：GO运行时对goroutine的描述，G中存放并发执行的代码入口地址、上下文、运行环境（关联的P和M）、运行栈等执行相关的信息。G的新建、休眠、恢复、停止都受到Go运行时的管理。 GO运行时的监控线程会监控G的调度，G不会长久地阻塞系统线程，运行时的调度器会自动切换到其他G上运行。G新建或恢复时会添加到运行队列，等待M取出并运行。 M：OS内核线程，是操作系...
golang之GMP调度模型
Qiaoshurui的博客
07-14 1319
G:一个G代表一个goroutine，协程的本质是用户态的线程，用户对其有控制权限，内存占用少，切换代价低。 M:内核态线程,一个M代表了一个内核线程，等同于系统线程，所有的G都要放在M上才能运行。 P:逻辑处理器,可以承载若干个G，并且使这些G适时的与M对接，一个P代表了M所需的上下文环境。P的个数取决于设置的GOMAXPROCS， go新版本默认使用最大内核数，比如你有8核处理器，那么P的数量就是8M的数量和P不一定匹配，可以设置很多M，M和P绑定后才可运行，多余的M处于休眠状态。 系统会通过调度器从全
Go中GMP调度模型详解(通俗易懂)
最新发布
bojinyuan00的博客
06-13 1198
本文详细解释了go语言中GMP调度模型相关的知识，包含了GMP调度模型的各个组成部分、整体的调度逻辑过程、特殊情况的处理机制等等，帮助大家更好的理解go语言的高并发机制
Golang - GMP模型
qq_39679639的博客
04-23 2810
线程池的缺陷 我们以网络模型为例。互联网早起的网络模型有PPC和TPC: PPC: 即Process Per Connection, 每个网络连接都新fork一个进程来处理 TPC: 即Thread Per Connection, 每个网络连接都新建一个线程来处理 不管是fork进程还是新建线程，都存在较大的系统开销（线程相对更小），于是工程师们想到了PreFork和PreThread网络模型： PreFork, 即预先创建好进程，新网络连接到来之后直接使用之前新建的进程，而不用临时创建，降低网络请求
golang大杀器GMP模型
fengxiandada的博客
03-11 5856
golang大杀器GMP模型学习
golang GMP模型
小张编程旅途的博客
08-27 1278
gmp模型能够在高并发场景下高效地管理和执行goroutine，最大化利用系统资源，同时保证系统的公平性和负载均衡。如果您觉得有帮助，请关注我，另公众号【小张的编程世界】，如有任何错误或建议，欢迎指出。
golang-操作系统知识点
09-05
GMP模型通过灵活的调度策略，使得在大量goroutine并发执行时，系统资源得到高效利用。这一部分的知识点涵盖了协程的创建与销毁、调度器的运行机制以及如何管理和分配处理器资源等内容。 其次，Golang中的调试技术...
学习资料 golang的GMP调度模型
11-02
通过学习资源包中的视频教程，你可以直观地看到GMP模型如何工作，了解Goroutine的调度流程、P和M的交互以及垃圾回收对性能的影响。PPT则提供了更详细的理论介绍和实例分析，帮助巩固理解。思维导图则可以作为快速...
golang gmp模型入门
04-23
Golang GMP 模型入门 Golang 调度器是 Golang 语言的核心组件之一，负责管理 goroutine 的执行和调度。Golang 调度器的 GMP 模型是 Golang 调度器的核心思想，G 代表 goroutine，M 代表线程，P 代表处理器。 ...
Golang GMP解读
HideonHacker的博客
04-24 1387
如果 g 执行系统调度时间过长，超过了指定的市场，且全局的 p 资源比较紧缺，此时将 p 和 g 解绑，抢占出来用于其他 g 调度。等 g 完成系统调用后，会重新进入可执行队列中等待被调度。通常，调度指的是由 g0 按照特定策略找到下一个可执行 g 的过程. 而本小节谈及的调度类型是广义上的“调度”，指的是调度器 p 实现从执行一个 g 切换到另一个 g 的过程.需要注意，虽然本地队列是属于 p 独有的，但是由于 work-stealing 机制的存在，其他 p 可能会前来执行窃取动作，因此操作仍需加锁.
golang之gmp调度模型
Xiang_lhh的博客
01-19 3697
原始调度模型 我们把线程分为内核级线程和用户态线程，内核级的线程在切换线程时，开销比较大，需要系统调用，但是，用户态线程不是这样，用户态的线程之间的切换不需要系统调用，从而把切换的开销比较小。 golang开始并没有使用gmp调度模型，只有gm。 也就是说没有局部队列，每一个m执行完一个g之后，从全局队列中拿到一个g运行，这样的结果就是每一个m从全局队列中拿取g时，都要对全局队列加锁。这也是导致原始调度模型效率低的一个原因。 GMP调度模型 G：goroutine ，协程，用户态线程 M：thread，对应
Golang GMP调度模型详解
爱意时刻减淡，玫瑰不再浪漫
05-02 4312
文章目录前言1. Goroutine调度器的基本概念2. Goruntine调度策略2.1 work stealing机制2.2 hand off 机制 前言      线程数过多，意味着操作系统会不断地切换线程，频繁的上下文切换就成了性能瓶颈。      Golang的调度模型是GMP模型，它提供一种机制，可以在线程中自己实现调度，上下文切换更轻量，从而达到了线程数少，而并发数并不少的效果。而线程中调度的就
Golang GMP调度模型
Martian
04-24 1134
1. 背景 单进程时代 每个程序就是一个进程，一个程序运行完，才能进行下一个进程，串行化执行，当一个进程被IO阻塞时，CPU只能等待IO事件就绪继续执行，而不能切换到其他进程执行，造成CPU资源的浪费。 多进程时代 后来操作系统具备了最早的并发能力：多进程并发，当一个进程阻塞的时候，切换到其他等待的进程执行，这样就减少了CPU资源的浪费。 调度cpu的算法可以保证在运行的进程都可以被分配到CPU的运行时间片。宏观上看，似乎多个进程同时运行。但新的问题就又出现了，进程拥有太多的资源，进程的创建、切换、销
Go gmp调度模型
Stephen.K
04-22 452
协程调度模型：协程是轻量的线程，在线程基础上，没有上下文切换，无锁，效率高；协程有自己的调度模型，即gmp模型； g：代表go关键字开的协程； p：逻辑处理器，绑定一个m处理g；包括上下文信息，维护了自己需要调度的g的局部队列，一个go新建优先放入局部队列，局部队列小于256，超过拿一半放入全局队列；由GOMAXPROCS设置个数； m：对应一个系统线程，内核态；m绑定p处理局部go队列，如果没有从全局队列拿一批，若全局队列没有，从其他p局部队列偷一半(即m空闲时，会从其他队列偷取，不会直接销毁线程)
Go语言GMP模型
bingshiwuyu的专栏
08-04 4264
前言线程的代价如何改变文本的样式插入链接与图片如何插入一段漂亮的代码片生成一个适合你的列表创建一个表格设定内容居中、居左、居右SmartyPants创建一个自定义列表如何创建一个注脚注释也是必不可少的KaTeX数学公式新的甘特图功能，丰富你的文章UML 图表FLowchart流程图导出与导入导出导入 帝国时代 线程的代价 使用过C++/Java的同学应该都知道在做服务端开发的时候，对于多线程的使用，繁琐程度，以及对于多线程情况下异常情况的分析，是何等头疼，如果线上流量过大，对于这种多线程的操作更是得慎重，当
GO语言GMP模型
myIddddd的博客
04-25 386
G：goroutine协程。P：processor处理器。起承上启下的作用，对于G来说是处理器，对于M来说用于屏蔽对G的调度，内存控制等逻辑。M：thread线程。
Golang的GMP模型
寻找到底哪里有蓝天
04-13 293
一、调度器的由来和分析 单进程时代的两个问题： 单一执行流程、计算机只能一个任务一个任务处理 进程阻塞所代理的CPU浪费时间 多进程和多线程的问题： 多进程/多线程解决了阻塞问题 但是引入了新的问题 进程/线程的数量越多，切换成本就越大，也就越浪费 多线程随着同步竞争(如锁、竞争资源冲突等)开发设计变得越来越复杂 老的调度器的几个缺点： 创建、销毁、调度G都需要每个M获取锁，这就形成了...
分析一下golang的gmp模型
09-16
总结来说，Golang的gmp模型提供了一种简洁而高效的并发编程模型，使得我们能够轻松地实现并发编程，并充分利用多核处理器的计算能力。通过合理地使用Goroutine、Mutex和Channel，我们能够编写出高效且可靠的并发程序...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值