在runtime中有 runtime.LockOSThread 和 runtime.UnlockOSThread 两个函数，这两个函数有什么作用呢？我们看一下标准库中对它们的解释。

runtime.LockOSThread

// LockOSThread wires the calling goroutine to its current operating system thread.
// The calling goroutine will always execute in that thread,
// and no other goroutine will execute in it,
// until the calling goroutine has made as many calls to
// UnlockOSThread as to LockOSThread.
// If the calling goroutine exits without unlocking the thread,
// the thread will be terminated.
//
// All init functions are run on the startup thread. Calling LockOSThread
// from an init function will cause the main function to be invoked on
// that thread.
//
// A goroutine should call LockOSThread before calling OS services or
// non-Go library functions that depend on per-thread state.

调用 LockOSThread 将 绑定 当前 goroutine 到当前 操作系统线程，此 goroutine 将始终在此线程执行，其它 goroutine 则无法在此线程中得到执行，直到当前调用线程执行了 UnlockOSThread 为止（也就是说 LockOSThread 可以指定一个goroutine 独占 一个系统线程）；

当我们执行一个 go func() 语句的时候，runtime 会通过调用 newproc() 函数来创建G。而内部真正创建创建G的函数为 newproc1()，在没有可以复用的G的情况下，会通过 newg = malg(_StackMin) 语句创建一个包含stack的G。

// Allocate a new g, with a stack big enough for stacksize bytes.
func malg(stacksize int32) *g {
	newg := new(g)
	if stacksize >= 0 {
		stacksize = round2(_StackSystem + stacksize)
		systemstack(func() {
			newg.stack = stackalloc(uint32(stacksize))
		})
		newg.stackguard0 = newg.stack.lo + _StackGuard
		newg.stackguard1 = ^uintptr(0)
		// Clear the bottom word of the stack. We record g
		// there on gsignal stack during VDSO on ARM and ARM64.
		*(*uintptr)(unsafe.Pointer(newg.stack.lo)) = 0
	}
	return newg
}

对新创建的g，需要通过调用 stackalloc() 函数为其分配 stacksize 大小stack，那么分配操作它又是如何工作的呢？

stack的申请

根据申请stack的大小，又分为两种情况，一种是 small stack，另一种是 large stack，两者采用不同的申请策略。主要涉及了内存申请策略，如果对golang 的内存管理比较了解的话，这块理解起来就显的太过于简单了。建议先阅读一下这篇文章《Golang 内存组件之mspan、mcache、mcentral 和 mheap 数据结构》。

func stackalloc(n uint32) stack {
	...

	var v unsafe.Pointer
	if n < _FixedStack<<_NumStackOrders && n < _StackCacheSize {
		order := uint8(0)
		n2 := n
		for n2 > _FixedStack {
			order++
			n2 >>= 1
		}
		var x gclinkptr
		if stackNoCache != 0 || thisg.m.p == 0 || thisg.m.preemptoff != "" {
			// thisg.m.p == 0 can happen in the guts of exitsyscall
			// or procresize. Just get a stack from the global pool.
			// Also don't touch stackcache during gc
			// as it's flushed concurrently.
			lock(&stackpool[order].item.mu)
			x = stackpoolalloc(order)
			unlock(&stackpool[order].item.mu)
		} else {
			c := thisg.m.p.ptr().mcache
			x = c.stackcache[order].list
			if x.ptr() == nil {
				stackcacherefill(c, order)
				x = c.stackcache[order].list
			}
			c.stackcache[order].list = x.ptr().next
			c.stackcache[order].size -= uintptr(n)
		}
		v = unsafe.Pointer(x)
	} else {
		...
	}
	return stack{uintptr(v), uintptr(v) + uintptr(n)}
}

对于small stack,会直接通过从G绑定的P中的 mcache 字段申请，这个字段可以理解为内存资源中心，里面包含有多种不同规格大小的内存块，根据申请大小找到一个可以满足其大小的最小规格的内存区域。

现状

目前在网络编程中，golang采用的是一种 goroutine-per-connection 的模式，即为每一个连接都分配一个goroutine，一个连接就是一个goroutine，多个连接之间没有关系。

package main

import (
	"fmt"
	"io/ioutil"
	"net"
	"time"
)

//模拟server端
func main() {
	tcpServer, _ := net.ResolveTCPAddr("tcp4", ":8080")
	listener, _ := net.ListenTCP("tcp", tcpServer)

	for {
		//当有新的客户端请求来的时候，拿到与客户端的连接
		conn, err := listener.Accept()
		if err != nil {
			fmt.Println(err)
			continue
		}

		// 处理逻辑 goroutine-per-connection
		go handle(conn)
	}
}

func handle(conn net.Conn) {
	defer conn.Close()

	//读取客户端传送的消息
	go func() {
		response, _ := ioutil.ReadAll(conn)
		fmt.Println(string(response))
	}()

	//向客户端发送消息
	time.Sleep(1 * time.Second)
	now := time.Now().String()
	conn.Write([]byte(now))
}

这种模式看起来非常的舒服，简单易懂，大大减少了开发者的心智负担，深受开发者的喜爱。

存在的问题

对于 goroutine-per-connection 这种模式，真的就不有一点问题的吗？

假如现在只有两个 P，正常情况下每秒可以处理 10000 个 goroutine 连接。突然有1秒并发量极其的大，此时有 100万 个请求发送过来（极少出现这种极端情况，但并不表示不存在），根据 goroutine-per-connection 模式服务端会为这些连接创建 100万 个 goroutine，每个goroutine表示一个请求连接。

Golang中的内存组件关系如下图所示

在学习golang 内存时，经常会涉及几个重要的数据结构，如果不熟悉它们的情况下，理解起来就显得格外的吃力，所以本篇主要对相关的几个内存组件做下数据结构的介绍。

在 Golang 中，mcache、mspan、mcentral 和 mheap 是内存管理的四大组件，mcache 管理线程在本地缓存的 mspan，而 mcentral 管理着全局的 mspan 为所有 mcache 提供所有线程。

根据分配对象的大小，内部会使用不同的内存分配机制，详细参考函数 mallocgo()

• <16KB 会使用微小对象内存分配器从 P 中的 mcache 分配，主要使用 mcache.tinyXXX 这类的字段
• 16-32KB 从 P 中的 mcache 中分配
• >32KB 直接从 mheap 中分配

对于golang中的内存申请流程，大家应该都非常熟悉了，这里不再进行详细描述。

mcache

在GPM关系中，会在每个 P 下都有一个 mcache 字段，用来表示内存信息。

在 Go 1.2 版本前调度器使用的是 GM 模型，将 mcache 放在了 M 里，但发现存在诸多问题，期中对于内存这一块存在着巨大的浪费。每个 M 都持有 mcache 和 stack alloc，但只有在 M 运行 Go 代码时才需要使用的内存(每个 mcache 可以高达2mb)，当 M 在处于 syscall 或 网络请求 的时候是不需要的，再加上 M 又是允许创建多个的，这就造成了很大的浪费。所以从go 1.3版本开始使用了GPM模型，这样在高并发状态下，每个G只有在运行的时候才会使用到内存，而每个 G 会绑定一个P，所以它们在运行只占用一份 mcache，对于 mcache 的数量就是P 的数量，同时并发访问时也不会产生锁。

对于 GM 模型除了上面提供到内存浪费的问题，还有其它问题，如单一全局锁sched.Lock、goroutine 传递问题和内存局部性等。

在 P 中，一个 mcache 除了可以用来缓存小对象外，还包含一些本地分配统计信息。由于在每个P下面都存在一个mcache ，所以多个 goroutine 并发请求内存时是无锁的。