关于Golang高并发的理解

GO语言在WEB开发领域中的使用越来越广泛，Hired 发布的《2019 软件工程师状态》报告中指出，具有 Go 经验的候选人是迄今为止最具吸引力的。平均每位求职者会收到9 份面试邀请。

想学习go，最基础的就要理解go是怎么做到高并发的。
那么什么是高并发？

高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。

严格意义上说，单核的CPU是没法做到并行的，只有多核的CPU才能做到严格意义上的并行，因为一个CPU同时只能做一件事。那为什么是单核的CPU也能做到高并发。这就是操作系统进程线程调度切换执行，感觉上是并行处理了。所以只要进程线程足够多，就能处理C1K C10K的请求，但是进程线程的数量又受到操作系统内存等资源的限制。每个线程必须分配8M大小的栈内存，不管是否使用。每个php-fpm需要占用大约20M的内存。所以目前有线程的Java就比只有进程的PHP的并发处理能力高。当然了，软件的处理能力不仅仅跟内存有关，还有是否阻塞，是否异步处理，CPU等等。Nginx作为单线程的模型却可以承担几万甚至几十万的并发请求，Nginx的话题说起来也就更多了。
我们继续聊我们的Go，那么是不是可以有一种语言使用更小的处理单元，占用内存比线程更小，那么它的并发处理能力就可以更高。所以Google就做了这件事，就有了golang语言,golang从语言层面就支持了高并发。

go为什么能做到高并发

goroutine是Go并行设计的核心。goroutine说到底其实就是协程，但是它比线程更小，几十个goroutine可能体现在底层就是五六个线程，Go语言内部帮你实现了这些goroutine之间的内存共享。执行goroutine只需极少的栈内存(大概是4~5KB)，当然会根据相应的数据伸缩。也正因为如此，可同时运行成千上万个并发任务。goroutine比thread更易用、更高效、更轻便。

一些高并发的处理方案基本都是使用协程，openresty也是利用lua语言的协程做到了高并发的处理能力，PHP的高性能框架Swoole目前也在使用PHP的协程。
协程更轻量，占用内存更小，这是它能做到高并发的前提。

go web开发中怎么做到高并发的能力

学习go的HTTP代码。先创建一个简单的web服务。

package main import ( "fmt" "log" "net/http" ) func response(w http.ResponseWriter, r *http.Request) { fmt.Fprintf(w, "Hello world!") //这个写入到w的是输出到客户端的 } func main() { http.HandleFunc("/", response) err := http.ListenAndServe(":9000", nil) if err != nil { log.Fatal("ListenAndServe: ", err) } }

然后编译

go build -o test_web.gobin ./test_web.gobin

然后访问

curl 127.0.0.1:9000 Hello world!

这样简单的一个WEB服务就搭建起来。接下来我们一步一步理解这个Web服务是怎么运行的，怎么做到高并发的。
我们顺着http.HandleFunc("/", response)方法顺着代码一直往上看。

func HandleFunc(pattern string, handler func(ResponseWriter, *Request)) { DefaultServeMux.HandleFunc(pattern, handler) } var DefaultServeMux = &defaultServeMux var defaultServeMux ServeMux type ServeMux struct { mu sync.RWMutex//读写锁。并发处理需要的锁 m map[string]muxEntry//路由规则map。一个规则一个muxEntry hosts bool //规则中是否带有host信息 } 一个路由规则字符串，对应一个handler处理方法。 type muxEntry struct { h Handler pattern string }

上面是DefaultServeMux的定义和说明。我们看到ServeMux结构体，里面有个读写锁，处理并发使用。muxEntry结构体，里面有handler处理方法和路由字符串。
接下来我们看下，http.HandleFunc函数，也就是DefaultServeMux.HandleFunc做了什么事。我们先看mux.Handle第二个参数HandlerFunc(handler)

func (mux *ServeMux) HandleFunc(pattern string, handler func(ResponseWriter, *Request)) { mux.Handle(pattern, HandlerFunc(handler)) } type Handler interface { ServeHTTP(ResponseWriter, *Request) // 路由实现器 } type HandlerFunc func(ResponseWriter, *Request) func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) { f(w, r) }

我们看到，我们传递的自定义的response方法被强制转化成了HandlerFunc类型，所以我们传递的response方法就默认实现了ServeHTTP方法的。

我们接着看mux.Handle第一个参数。

func (mux *ServeMux) Handle(pattern string, handler Handler) { mux.mu.Lock() defer mux.mu.Unlock() if pattern == "" { panic("http: invalid pattern") } if handler == nil { panic("http: nil handler") } if _, exist := mux.m[pattern]; exist { panic("http: multiple registrations for " + pattern) } if mux.m == nil { mux.m = make(map[string]muxEntry) } mux.m[pattern] = muxEntry{h: handler, pattern: pattern} if pattern[0] != '/' { mux.hosts = true } }