【设计模式源码作用】【卡盟主站源码.rar】【癞子斗地主 源码下载】mcall源码
1.Golang GMP 原理
2.go源码：Sleep函数与线程
Golang GMP 原理
通常语义中的线程，指的是内核级线程，核心点包括：（1）它是操作系统最小调度单元；（2）创建、销毁、调度交由内核完成，cpu 需完成用户态与内核态间的设计模式源码作用切换；（3）可充分利用多核，实现并行。
协程，又称为用户级线程，核心点如下：（1）与线程存在映射关系，为 M：1；（2）创建、销毁、调度在用户态完成，对内核透明，所以更轻；（3）从属同一个内核级线程，无法并行；一个协程阻塞会导致从属同一线程的所有协程无法执行。
Goroutine，经 Golang 优化后的特殊“协程”，核心点包括：（1）与线程存在映射关系，为 M：N；（2）创建、销毁、调度在用户态完成，对内核透明，足够轻便；（3）可利用多个线程，实现并行；（4）通过调度器的斡旋，实现和线程间的动态绑定和灵活调度；（5）栈空间大小可动态扩缩，因地制宜。
对比三个模型的各项能力：综上，goroutine 可说是博采众长之物。
实际上，“灵活调度” 一词概括得实在过于简要，Golang 在调度 goroutine 时，卡盟主站源码.rar针对“如何减少加锁行为”，“如何避免资源不均”等问题都给出了精彩的解决方案，这一切都得益于经典的 “gmp” 模型。
GMP = goroutine + machine + processor（+ 一套有机组合的机制），下面先单独拆出每个组件进行介绍，最后再总览全局，对 GMP 进行总述。
G = goroutine，是 Golang 中对协程的抽象；（2）g 有自己的运行栈、状态、以及执行的任务函数（用户通过 go func 指定）；（3）g 需要绑定到 p 才能执行，在 g 的视角中，p 就是它的 cpu。
P = processor，是 Golang 中的调度器；（2）p 是 gmp 的中枢，借由 p 承上启下，实现 g 和 m 之间的动态有机结合；（3）对 g 而言，p 是其 cpu，g 只有被 p 调度，才得以执行；（4）对 m 而言，p 是其执行代理，为其提供必要信息的同时（可执行的 g、内存分配情况等），并隐藏了繁杂的调度细节；（5）p 的数量决定了 g 最大并行数量，可由用户通过 GOMAXPROCS 进行设定（超过 CPU 核数时无意义）。
M = machine，是 Golang 中对线程的抽象；（1）m 不直接执行 g，而是先和 p 绑定，由其实现代理；（3）借由 p 的存在，m 无需和 g 绑死，也无需记录 g 的癞子斗地主 源码下载状态信息，因此 g 在全生命周期中可以实现跨 m 执行。
全局有多个 M 和多个 P，但同时并行的 G 的最大数量等于 P 的数量。G 的存放队列有三类：P 的本地队列；全局队列；和 wait 队列（图中未展示，为 io 阻塞就绪态 goroutine 队列）。
M 调度 G 时，优先取 P 本地队列，其次取全局队列，最后取 wait 队列。这样的好处是，取本地队列时，可以接近于无锁化，减少全局锁竞争。为防止不同 P 的闲忙差异过大，设立 work-stealing 机制，本地队列为空的 P 可以尝试从其他 P 本地队列偷取一半的 G 补充到自身队列。
核心数据结构定义于 runtime/runtime2.go 文件中，各个类的成员属性较多，这里只摘取核心字段进行介绍：g 的生命周期由以下几种状态组成：_Gidle（值为 0，为协程开始创建时的状态，此时尚未初始化完成）；_Grunnable（值为 1，协程在待执行队列中，等待被执行）；_Grunning（值为 2，协程正在执行，同一时刻一个 p 中只有一个 g 处于此状态）；_Gsyscall（值为 3，协程正在执行系统调用）；_Gwaiting（值为 4，协程处于挂起态，需要等待被唤醒. gc、channel 通信或者锁操作时经常会进入这种状态）；_Gdead（值为 6，协程刚初始化完成或者已经被销毁，会处于此状态）；_Gcopystack（值为 8，域名防红跳转源码协程正在栈扩容流程中）；_Greempted（值为 9，协程被抢占后的状态）。
文字性总结难免有些过于含糊和空洞，对一些细节的描述总是不够精确的。下面照旧开启源码走读流程，从代码中寻求理论证明和细节补充。
gmp 数据结构定义为 runtime/runtime2.go 文件中，由于各个类的成员属性较多，那么只摘取核心字段进行介绍：（1）m：在 p 的代理，负责执行当前 g 的 m；（2）sched.sp：保存 CPU 的 rsp 寄存器的值，指向函数调用栈栈顶；（3）sched.pc：保存 CPU 的 rip 寄存器的值，指向程序下一条执行指令的地址；（4）sched.ret：保存系统调用的返回值；（5）sched.bp：保存 CPU 的 rbp 寄存器的值，存储函数栈帧的起始位置。其中 g 的生命周期由以下几种状态组成：（1）_Gidle（值为 0，为协程开始创建时的状态，此时尚未初始化完成）；（2）_Grunnable（值为 1，协程在待执行队列中，等待被执行）；（3）_Grunning（值为 2，协程正在执行，同一时刻一个 p 中只有一个 g 处于此状态）；（4）_Gsyscall（值为 3，协程正在执行系统调用）；（5）_Gwaiting（值为 4，协程处于挂起态，需要等待被唤醒. gc、channel 通信或者锁操作时经常会进入这种状态）；（6）_Gdead（值为 6，协程刚初始化完成或者已经被销毁，会处于此状态）；（7）_Gcopystack（值为 8，协程正在栈扩容流程中）；（8）_Greempted（值为 9，协程被抢占后的状态）。
其中，goroutine 的类型可分为两类：（1）I 负责调度普通 g 的 g0，执行固定的代刷网系统源码调度流程，与 m 的关系为一对一；（2）II 负责执行用户函数的普通 g。m 通过 p 调度执行的 goroutine 永远在普通 g 和 g0 之间进行切换。
主动调度是用户主动执行让渡的方式，主要方式是，用户在执行代码中调用了 runtime.Gosched 方法，此时当前 g 会当让出执行权，主动进行队列等待下次被调度执行。被动调度因当前不满足某种执行条件，g 可能会陷入阻塞态无法被调度，直到关注的条件达成后，g 才从阻塞中被唤醒，重新进入可执行队列等待被调度。
正常调度指的是 g 中的执行任务已完成，g0 会将当前 g 置为死亡状态，发起新一轮调度。抢占调度指的是 g 执行系统调用超过指定的时长，且全局的 p 资源比较紧缺，此时将 p 和 g 解绑，抢占出来用于其他 g 的调度。
调度流程的主干方法是位于 runtime/proc.go 中的 schedule 函数。在宏观调度流程中，我们可以尝试对 gmp 的宏观调度流程进行整体串联，包括：（1）以 g0 -> g -> g0 的一轮循环为例进行串联；（2）g0 执行 schedule() 函数，寻找到用于执行的 g；（3）g0 执行 execute() 方法，更新当前 g、p 的状态信息，并调用 gogo() 方法，将执行权交给 g；（4）g 因主动让渡（gosche_m()）、被动调度（park_m()）、正常结束（goexit0()）等原因，调用 m_call 函数，执行权重新回到 g0 手中；（5）g0 执行 schedule() 函数，开启新一轮循环。
在 Golang 中，调度流程的主干方法是位于 runtime/proc.go 中的 schedule 函数，此时的执行权位于 g0 手中。在 findRunnable 方法中，调度流程中，一个非常核心的步骤就是为 m 寻找到下一个执行的 g。在 execute 方法中，当 g0 为 m 寻找到可执行的 g 之后，接下来就开始执行 g。
在 g 执行主动让渡时，会调用 mcall 方法将执行权归还给 g0，并由 g0 调用 gosched_m 方法。在 g 需要被动调度时，会调用 mcall 方法切换至 g0，并调用 park_m 方法将 g 置为阻塞态。当 g 执行完成时，会先执行 mcall 方法切换至 g0，然后调用 goexit0 方法。与 g 的系统调用有关的，视角切换回发生系统调用前，与 g 绑定的原 m 当中，此时执行权同样位于 m 的 g0 手中。在 m 需要执行系统调用前，会先执行位于 runtime/proc.go 的 reentersyscall 的方法。当 m 完成了内核态的系统调用之后，此时会步入位于 runtime/proc.go 的 exitsyscall 函数中。
与 g 的系统调用有关的，视角切换回发生系统调用前，与 g 绑定的原 m 当中，在 m 需要执行系统调用前，会先执行位于 runtime/proc.go 的 reentersyscall 的方法。当 m 完成了内核态的系统调用之后，此时会步入位于 runtime/proc.go 的 exitsyscall 函数中。
当 g 执行完成时，会先执行 mcall 方法切换至 g0，然后调用 goexit0 方法。当 m 完成了内核态的系统调用之后，此时会步入位于 runtime/proc.go 的 exitsyscall 函数中。
对于抢占调度的执行者，不是 g0，而是一个全局的 monitor g，代码位于 runtime/proc.go 的 retake 方法中。与 g 的系统调用有关的，视角切换回发生系统调用前，与 g 绑定的原 m 当中，在 m 需要执行系统调用前，会先执行位于 runtime/proc.go 的 reentersyscall 的方法。当 m 完成了内核态的系统调用之后，此时会步入位于 runtime/proc.go 的 exitsyscall 函数中。
在 Golang 中，调度流程的主干方法是位于 runtime/proc.go 中的 schedule 函数，此时的执行权位于 g0 手中。在 findRunnable 方法中，调度流程中，一个非常核心的步骤就是为 m 寻找到下一个执行的 g。在 execute 方法中，当 g0 为 m 寻找到可执行的 g 之后，接下来就开始执行 g。
在 g 执行主动让渡时，会调用 mcall 方法将执行权归还给 g0，并由 g0 调用 gosched_m 方法。在 g 需要被动调度时，会调用 mcall 方法切换至 g0，并调用 park_m 方法将 g 置为阻塞态。当 g 执行完成时，会先执行 mcall 方法切换至 g0，然后调用 goexit0 方法。当 m 完成了内核态的系统调用之后，此时会步入位于
go源码：Sleep函数与线程
在探索 Go 语言的并发编程中，Sleep 函数与线程的交互方式与 Java 或其他基于线程池的并发模型有所不同。本文将深入分析 Go 语言中 Sleep 函数的实现及其与线程的互动方式，以解答关于 Go 语言中 Sleep 函数与线程关系的问题。
首先，重要的一点是，当一个 goroutine（g）调用 Sleep 函数时，它并不会导致当前线程被挂起。相反，Go 通过特殊的机制来处理这种情景，确保 Sleep 函数的调用不会影响到线程的执行。这一特性是 Go 语言并发模型中独特而关键的部分。
具体来说，当一个 goroutine 调用 Sleep 函数时，它首先将自身信息保存到线程的关键结构体（p）中并挂起。这一过程涉及多个函数调用，包括 `time.Sleep`、`runtime.timeSleep`、`runtime.gopark`、`runtime.mcall`、`runtime.park_m`、`runtime.resetForSleep` 等。最终，该 goroutine 会被放入一个 timer 结构体中，并将其放入到 p 关联的一个最小堆中，从而实现了对当前 goroutine 的保存，同时为调度器提供了切换到其他 goroutine 或 timer 的机会。因此，这里的 timer 实际上代表了被 Sleep 挂起的 goroutine，它在睡眠到期后能够及时得到执行。
接下来，我们深入分析 goroutine 的调度过程。当线程 p 需要执行时，它会通过 `runtime.park_m` 函数调用 `schedule` 函数来进行 goroutine 或 timer 的切换。在此过程中，`runtime.findrunnable` 函数会检查线程堆中是否存在已到期的 timer，如果存在，则切换到该 timer 进行执行。如果 timer 堆中没有已到期的 timer，线程会继续检查本地和全局的 goroutine 队列中是否还有待执行的 goroutine，如果队列为空，则线程会尝试“偷取”其他 goroutine 的任务。这一过程包括了检查 timer 堆、偷取其他 p 中的到期 timer 或者普通 goroutine，确保任务能够及时执行。
在“偷取”任务的过程中，线程会优先处理即将到期的 timer，确保这些 timer 的准时执行。如果当前线程正在执行其他任务（如 epoll 网络），则在执行过程中会定期检查 timer 到期情况。如果发现其他线程的 timer 到期时间早于自身，会首先唤醒该线程以处理其 timer，确保不会错过任何到期的 timer。
为了证明当前线程设置的 timer 能够准时执行，本文提出了两种证明方法。第一种方法基于代码细节，重点分析了线程状态的变化和 timer 的执行流程。具体而言，文章中提到的三种线程状态（正常运行、epoll 网络、睡眠）以及相应的 timer 执行情况，表明在 Go 语言中，timer 的执行策略能够确保其准时执行。第二种方法则从全局调度策略的角度出发，强调了 Go 语言中线程策略的设计原则，即至少有一个线程处于“spinning”状态或者所有线程都在执行任务，这保证了 timer 的准时执行。
总之，Go 语言中 Sleep 函数与线程之间的交互方式，通过特殊的线程管理机制，确保了 goroutine 的 Sleep 操作不会阻塞线程，同时保证了 timer 的准时执行。这一机制是 Go 语言并发模型的独特之处，为开发者提供了一种高效且灵活的并发处理方式。