南通工程建设信息网站,南沙定制型网站建设,网站管理助手4.0破解,成都家装设计公司排名前面的例子显示当一个任务时没有必要时使用 goroutine。但使用 Go 语言的原因之一是该语言提供的并发功能。实际上#xff0c;很多情况下你希望利用硬件中可用的并行性。为此#xff0c;你必须使用 goroutines。
这个简单的应用程序在两个不同的端口上提供 http 服务#x…前面的例子显示当一个任务时没有必要时使用 goroutine。但使用 Go 语言的原因之一是该语言提供的并发功能。实际上很多情况下你希望利用硬件中可用的并行性。为此你必须使用 goroutines。
这个简单的应用程序在两个不同的端口上提供 http 服务端口 8080 用于应用程序服务端口 8001 用于访问 /debug/pprof 终端。
package mainimport (
fmt
net/http
_ net/http/pprof
)func main() {
mux : http.NewServeMux()
mux.HandleFunc(/, func(resp http.ResponseWriter, req *http.Request) {
fmt.Fprintln(resp, Hello, QCon!)
})
go http.ListenAndServe(127.0.0.1:8001, http.DefaultServeMux) // debug
http.ListenAndServe(0.0.0.0:8080, mux) // app traffic
}虽然这个程序不是很复杂但它代表了真实应用程序的基础。
该应用程序存在一些问题因为它随着应用程序的增长而显露出来所以我们现在来解决其中的一些问题。
func serveApp() {
mux : http.NewServeMux()
mux.HandleFunc(/, func(resp http.ResponseWriter, req *http.Request) {
fmt.Fprintln(resp, Hello, QCon!)
})
http.ListenAndServe(0.0.0.0:8080, mux)
}func serveDebug() {
http.ListenAndServe(127.0.0.1:8001, http.DefaultServeMux)
}func main() {
go serveDebug()
serveApp()
}通过将 serveApp 和 serveDebug 处理程序分解成为它们自己的函数我们将它们与 main.main 分离。 也遵循了上面的建议并确保 serveApp 和 serveDebug 将它们的并发性留给调用者。
但是这个程序存在一些可操作性问题。 如果 serveApp 返回那么 main.main 将返回导致程序关闭并由你使用的进程管理器来重新启动。 贴士: 正如 Go 语言中的函数将并发性留给调用者一样应用程序应该将监视其状态和检测是否重启的工作留给另外的程序来做。 不要让你的应用程序负责重新启动自己最好从应用程序外部处理该过程。 然而serveDebug 是在一个单独的 goroutine 中运行的返回后该 goroutine 将退出而程序的其余部分继续。 由于 /debug 处理程序已停止工作很久因此操作人员不会很高兴发现他们无法在你的应用程序中获取统计信息。
我们想要确保的是如果任何负责提供此应用程序的 goroutine 停止我们将关闭该应用程序。
func serveApp() {
mux : http.NewServeMux()
mux.HandleFunc(/, func(resp http.ResponseWriter, req *http.Request) {
fmt.Fprintln(resp, Hello, QCon!)
})
if err : http.ListenAndServe(0.0.0.0:8080, mux); err ! nil {
log.Fatal(err)
}
}func serveDebug() {
if err : http.ListenAndServe(127.0.0.1:8001, http.DefaultServeMux); err ! nil {
log.Fatal(err)
}
}func main() {
go serveDebug()
go serveApp()
select {}
}现在 serverApp 和 serveDebug 检查从 ListenAndServe 返回的错误并在需要时调用 log.Fatal。因为两个处理程序都在 goroutine 中运行所以我们将 main goroutine 停在 select{} 中。
这种方法存在许多问题
如果 ListenAndServer 返回 nil 错误则不会调用 log.Fatal并且该端口上的 HTTP 服务将在不停止应用程序的情况下关闭。log.Fatal 调用 os.Exit它将无条件地退出程序; defer 不会被调用其他 goroutines 也不会被通知关闭程序就停止了。 这使得编写这些函数的测试变得困难。 贴士: 只在 main.main 或 init 函数中的使用 log.Fatal。 我们真正想要的是任何错误发送回 goroutine 的调用者以便它可以知道 goroutine 停止的原因可以干净地关闭程序进程。
func serveApp() error {
mux : http.NewServeMux()
mux.HandleFunc(/, func(resp http.ResponseWriter, req *http.Request) {
fmt.Fprintln(resp, Hello, QCon!)
})
return http.ListenAndServe(0.0.0.0:8080, mux)
}func serveDebug() error {
return http.ListenAndServe(127.0.0.1:8001, http.DefaultServeMux)
}func main() {
done : make(chan error, 2)
go func() {
done - serveDebug()
}()
go func() {
done - serveApp()
}()for i : 0; i cap(done); i {
if err : -done; err ! nil {
fmt.Println(error: %v, err)
}
}
}我们可以使用通道来收集 goroutine 的返回状态。通道的大小等于我们想要管理的 goroutine 的数量这样发送到 done 通道就不会阻塞因为这会阻止 goroutine 的关闭导致它泄漏。
由于没有办法安全地关闭 done 通道我们不能使用 for range 来循环通道直到获取所有 goroutine 发来的报告而是循环我们开启的多个 goroutine即通道的容量。
现在我们有办法等待每个 goroutine 干净地退出并记录他们遇到的错误。所需要的只是一种从第一个 goroutine 转发关闭信号到其他 goroutine 的方法。
事实证明要求 http.Server 关闭是有点牵扯的所以我将这个逻辑转给辅助函数。serve 助手使用一个地址和 http.Handler类似于 http.ListenAndServe还有一个 stop 通道我们用它来触发 Shutdown 方法。
func serve(addr string, handler http.Handler, stop -chan struct{}) error {
s : http.Server{
Addr: addr,
Handler: handler,
}go func() {
-stop // wait for stop signal
s.Shutdown(context.Background())
}()return s.ListenAndServe()
}func serveApp(stop -chan struct{}) error {
mux : http.NewServeMux()
mux.HandleFunc(/, func(resp http.ResponseWriter, req *http.Request) {
fmt.Fprintln(resp, Hello, QCon!)
})
return serve(0.0.0.0:8080, mux, stop)
}func serveDebug(stop -chan struct{}) error {
return serve(127.0.0.1:8001, http.DefaultServeMux, stop)
}func main() {
done : make(chan error, 2)
stop : make(chan struct{})
go func() {
done - serveDebug(stop)
}()
go func() {
done - serveApp(stop)
}()var stopped bool
for i : 0; i cap(done); i {
if err : -done; err ! nil {
fmt.Println(error: %v, err)
}
if !stopped {
stopped true
close(stop)
}
}
}现在每次我们在 done 通道上收到一个值时我们关闭 stop 通道这会导致在该通道上等待的所有 goroutine 关闭其 http.Server。 这反过来将导致其余所有的 ListenAndServe goroutines 返回。 一旦我们开启的所有 goroutine 都停止了main.main 就会返回并且进程会干净地停止。 贴士: 自己编写这种逻辑是重复而微妙的。 参考下这个包: https://github.com/heptio/workgroup它会为你完成大部分工作。 关注下方微信公众号获取更多Go知识
