go-concurrent-programming.md

最近在看《Programming in Go》, 其中关于并发编程写得很不错, 受益非浅, 其中有一些例子是需要多思考才能想明白的, 所以我打算记录下来, 强化一下思路

《Programming in Go》在 Chapter 7. Concurrent Programming 里面一共用3个例子来讲述并发编程的3个模式, 第一个是 filter , 筛选出后缀名和文件大小文件列表, 还算简单就不说, 然后第二个是升级版, 正则版 filter , 不同的是他是根据正则搜索出文件的文本并且列出来. 这个例子我起初看是有点蒙的, 这样写是没错, 但是为什么要这样写, 他的设计思路是什么, 和其他方法相比他有什么优势, 这些都不清楚, 于是决定好好分析一下. 实际上这个例子实现的功能并不复杂, 所以我的文章实际上是在讨论怎么产生出和作者相似的思路.

如果不考虑用 goroutine 的话, 思路其实很简单:

1. 列出文件列表, 编译正则.

2. 遍历文件, 打开并遍历每行, 如果正则能匹配, 记录下来.

3. 列出来.

如果用 goroutine , 就会有以下思路:

1. 在得到文件路径数组之后, 分发任务给N个核.

2. 每个核负责打开文件, 将符合条件的那行文本写入到 `channel`

3. 主线程等待并接收`channel`的结果. 显示出来, 完毕

** 然后下文才是重点 **

1. channel关闭的时机

在go中, channel 是不会自动关闭的, 所以需要在我们使用完之后手动去关闭, 而且如果使用for语法来遍历channel每次得到的数据, 如果channel没有关闭的话会陷入死循环. 在 goruntine 中会造成 deadlock

for job := range jobs {

fmt.Println(job)

}

如果没close, 会触发dead lock. 因为for...range...会自动阻塞直到读取到数据或者channel关闭, 没close的话就会导致整个channel处于睡眠状态. channel关闭后, 就不允许写入(缓冲的数据还在, 还可以读取), 所以, channel 关闭的时机很重要.

2. 分发任务

我所知道任务分发方法有两种:

第一种是固定分配, 如果说我想计算1+2+3+...+100, 然后分成4份, 也就是 1+2+..+25, ..., ..., 86+87+...+100, 然后再将结果累加起来.

还有一种是抢占式的, 这里需要使用一个队列, 将所有任务写入队列, 然后开N个goroutine, 每个goroutine从队列读取任务(要确保线程安全), 处理, 完成后再继续读取任务. 不再是固定分配, 自己那份做完了就休息了, 所以看来第二种要好一点.

采用第二种方式的话, 对应go的做法, 那就是使用一个channel, 命名为 jobs, 将所有的任务写入进去, 写入完毕之后关闭这个 channel, 当然, 因为是N核, 系统能同时处理的任务我们设置为N个(也就是我们使用了N个goruntine), 那么声明 jobs 是缓冲区长度为N的 channel.

Buffered channel 和普通的 channel 的差别是他可以同时容纳多个单位数据, 当缓存的数据单位数量等于 channel 容量的时候, 再执行写入将会阻塞, 否则都是及时处理的.

3. 结果集

当我们将数据处理后, 就需要将结果收集起来. 需要注意的是, 这些操作不是在主 goruntine 执行, 所以我们需要通过 channel 传递给主 goruntine . 所以只需要在外部声明一个名为 results 的 channel . 然后在主 goruntine 通过 for 来显示, 这时候就会发现一个问题, 这个 results 关闭的时机问题. 正确的关闭时机是写入所有的 Result 之后. 但是别忘了我们同时开了多个 goruntine , 所以 results 应该在 执行任务的 goruntine 完成信号累计到N个 这个时机关闭. 所以我们再引入一个名叫 done 的 channel 来解决. 每个 goruntine 发送完 result 后会写入一次done, 然后我们就可以遍历 done , 遍历之后说明全部完成了, 再执行显示.

Result 的数据结构

type Result struct {
    filename string
    lino int
    line string
}

书中的 cgrep1 就是这样的

func awaitCompletion(done <-chan struct{}, results chan Result) {
    for i := 0; i < workers; i++ {
        <-done
    }
    close(results)
}

但是这样有可能造成死锁, 因为书中 results 缓冲区长度限定为最大1000个, 也就是超过1000个 result 的时候再打算写入 result 会等待取出 result 后才执行, done 也不会写入, 而 awaitCompletion 是等到所有 goruntine 都完成了才会取出 results, 而且当 result 非常大的时候因为内存的缘故也是不可能一次性取出的. 所以就需要在读取 results 的同时读取 done, 当读取 done 次数大于 N 后关闭 results, 所以, 因为要在多个 channel 中同时读取, 所以需要使用 select.

下面是书中的 cgrep3 , 改进版:

func waitAndProcessResults(timeout int64, done <-chan struct{}, results <-chan Result) {
    finish := time.After(time.Duration(timeout))
    for working := workers; working > 0; {
        select { // Blocking
            case result := <-results:
                fmt.Printf("%s:%d:%s\n", result.filename, result.lino,
                result.line)
            case <-finish:
                fmt.Println("timed out")
                return // Time's up so finish with what results there were
            case <-done: 
                working--
        } 
    }
    for {
        select { // Nonblocking
            case result := <-results:
                fmt.Printf("%s:%d:%s\n", result.filename, result.lino,
                result.line)
            case <-finish:
                fmt.Println("timed out")
                return // Time's up so finish with what results there were
            default: 
                return
        } 
    }
}
看到这里, 我就有个疑问, 为什么在全部完成之后(done都接收到N个了), 还要再遍历出 results, 直到读取不到才算读取完成呢(我反应一向比较慢^_^)? 于是我做了个实验, 去掉了后面再次循环的部分, 发现有时会遗漏掉数据(我用4个测试文件...), 证明这段代码是有用的!!!
我的想法是, 他是在处理完 result, 然后写入 results, 写完了才发送 done, 也就是在收到所有的 done 之后, 所有的数据应该是已经处理完成的. 为了验证这个想法, 我写了一下代码:
for working := workers; working > 0; {
    select { // Blocking
        case result := <-results:
            // received result
        case <-done: 
            working--
            if working <= 0 {
                println(len(results))
            }
    } 
}

然后看到输出的数是大于0的, 也就是说在接收到全部 done 之后, results 还有数据在缓冲区中, 然后在看看发送 result 的代码, 突然就明白了

func doJobs(done chan<- struct{}, lineRx *regexp.Regexp, jobs <-chan Job) {
    for job := range jobs {
        job.Do(lineRx)
    }
    done <- struct{}{}
}

我把写入和读取想当然认为一起发生了, 因为有缓冲区的缘故, doJobs在发送进 results 的缓冲区之后就立刻发送 done 了, 但是写入的数据有没有被处理, 是不知道的, 所以在接收到所有 done 之后, results 缓冲区还有数据, 需要再循环一遍.

附我的代码一份:

package main
import (
    "fmt"
    "os"
    "runtime"
    "regexp"
    "log"
    "bufio"
)
type Job struct {
    filename string
    results chan<- Result
}
type Result struct {
    filename string
    line string
    lino int
}
var worker = runtime.NumCPU()
func main() {
    // config cpu number
    runtime.GOMAXPROCS(worker)
    files := os.Args[2:]
    regex, err := regexp.Compile(os.Args[1])
    if err != nil {
        log.Fatal(err)
        return
    }
    // 任务列表, 并发数目为CPU个数
    jobs := make(chan Job, worker)
    // 结果
    results := make(chan Result, minimum(1000, len(files)))
    // 标记完成
    dones := make(chan struct{}, worker)
    go addJob(files, jobs, results)
    for i:=0; i<worker; i++ {
        go doJob(jobs, regex, dones)
    }
    awaitForCloseResult(dones, results)
}
func addJob(files []string, jobs chan<- Job, results chan<- Result) {
    for _, filename := range files {
        jobs <- Job {filename, results}
    }
    close(jobs)
}
func doJob(jobs <-chan Job, regex *regexp.Regexp, dones chan<- struct{}) {
    for job := range jobs {
        job.Do(regex)
    }
    dones <- struct{}{}
}
func awaitForCloseResult(dones <-chan struct{}, results chan Result) {
    working := worker
    done := false
    for {
        select {
            case result := <-results:
                println(result)
            case <-dones:
                working -= 1
                if working <= 0 {
                    done = true
                }
            default:
                if done {
                    return
                }
        }
    }
}
func (j *Job) Do(re *regexp.Regexp) {
    f, err := os.Open(j.filename)
    if err != nil {
        println(err)
        return
    }
    defer f.Close()
    b := bufio.NewReader(f)
    lino := 0
    for {
        line, _, err := b.ReadLine()
        if re.Match(line) {
            j.results <- Result {j.filename, string(line), lino}
        }
        if err != nil {
            break
        }
        lino += 1
    }
}
func minimum(a, b int) int {
    if a > b {
        return b
    }
    return a
}
func println(o ...interface{}) {
    fmt.Println(o...)
}

原文发布于微信公众号 - Golang语言社区(Golangweb)

原文发表时间:2017-01-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏小狼的世界

CoffeeScript学习笔记

CoffeeScript编程语言构建于Javascript之上,它可编译成高效JavaScript。可以在Web浏览器上,或者结合Node.js一类的技术构建服...

1201
来自专栏较真的前端

[译] 调试 RxJS 第1部分: 工具篇

1774
来自专栏Python小屋

使用Python读写文本文件内容

本文主要演示如何读写文本文件的内容,以及上下文管理语句with的用法。使用上下文管理语句with时,即使在操作文件内容时引发异常也能保证文件被正确关闭。 #'w...

2675
来自专栏Linux驱动

22.Linux-块设备驱动之框架详细分析(详解)

本节目的:     通过分析块设备驱动的框架,知道如何来写驱动 1.之前我们学的都是字符设备驱动,先来回忆一下 字符设备驱动: 当我们的应用层读写(read()...

4525
来自专栏北京马哥教育

大神带你 20 分钟学会 Ansible !

5532
来自专栏高性能服务器开发

(一)Redis结构解析

从今天起,本人将会展开对Redis源码的学习,Redis的代码规模比较小,非常适合学习,是一份非常不错的学习资料,数了一下大概100个文件左右的样子,用的是C...

3085
来自专栏王纯的专栏

Valgrind 使用入门

Valgrind 是一套类似于 gprof 的动态检测的工具集,由于使用方便,不需修改目标程序源码,输出清晰图文并茂等优势,常被用作后台(特别是linux后台)...

2.4K0
来自专栏IT可乐

Nginx(三)------nginx 反向代理

  Nginx 服务器的反向代理服务是其最常用的重要功能,由反向代理服务也可以衍生出很多与此相关的 Nginx 服务器重要功能,比如后面会介绍的负载均衡。本篇博...

1883
来自专栏你不就像风一样

Java中用final修饰参数的方法当传入i++时异常

我的项目是这样写项目运行不起来,具体原因我参考的 https://www.cnblogs.com/xiohao/p/4861500.html, 解决方法...

1083
来自专栏mySoul

微信小程序自定义组件(二)

两个<custom-ul>以及<custom-li>两个组件都为自定义组件,如果进行通信会非常的难以操作,至此通过relations完成子父组件的定义,简化通信...

2833

扫码关注云+社区

领取腾讯云代金券