func ListDirectory(dir string) ([]string, error)
func ListDirectory(dir string) chan string
上述两个API有什么区别?
- 第一个,是同步请求,如果目录较大,需要分配大量内存,也需要需要很长时间
- 第二个,返回一个string类型的chan,通过chan传递目录,通道关闭时,表示不再有目录。由于在返回后发生通道的填充,函数内部启动goroutine来填充通道
针对第二个,还有两个问题:
- 把关闭通道视为结束的信号,无法区分空目录,亦或是中途遇到了其他错误导致通道关闭
- 调用者必须持续从通道读取数据,直到它关闭,这是调用者感知chan唯一的方法。调用者必须花时间从chan读取数据,它使用了较少的内存,但是并不会比第一种方法更快。
func ListDirectory(dir string, fn func(string))
如果函数启动goroutine,那么必须向调用方提供显示停止该goroutine的方法。通常,将异步执行函数的决定交给该函数的调用方更容易。
永远不要在不知道如何关闭goroutine的时候启动它。
每当想启动一个goroutine的时候,都需要扪心自问:
- 这个goroutine如何结束?
- 有什么办法可以使得这个goroutine不结束么?
下面这个例子,启动两个http服务,一个是正常业务,一个是debug服务。需求是当任意一个挂了的时候,停止服务,并打印日志。
首先如果收到了stop信号,两个服务都会推出。
其次,当任意一个服务挂掉,chan stop会被关闭,从而导致另外一个服务受到stop信息,也关闭。
func serve(addr string, handler http.Handler, stop <-chan struct{}) error {
s := http.Server{
Addr : addr,
Handler : handler
}
go func() {
<-stop
s.ShutDown(Context.Background())
}()
return s.ListenAndServe()
}
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)
}
}
}