标签 Unix 下的文章

Go coding in go way

本篇文章是我在2017年第三届GopherChina大会上所作talk:”Go coding in go way“的改编和展开版,全文如下。

一、序

今天我要分享的题目是“Go coding in go way”,中文含义就是用“Go语言编程思维去写Go代码”。看到这个题目大家不禁要问:究竟什么是Go语言编程思维呢?关于什么是Go语言变成思维其实并没有官方说法。这里要和大家交流的内容都是基于Go诞生七年多以来我个人对Go的设计者、Go team以及Go主流社区的观点和代码行为的整理、分析和总结。希望通过我的这次“抛砖引玉”,让在座的Gopher们对“Go语言编程思维”有一个初步的认知,并在日常开发工作中遵循Go语言的编程思维,写出idiomatic的Go代码。

二、编程语言与编程思维

1、大师的观点

在人类自然语言学界有一个很著名的假说:”萨丕尔-沃夫假说“,这个假说的内容是这样的:

语言影响或决定人类的思维方式("Language inuences/determines thought" - Sapir-Whorf hypothesis )

说到这个假说,我们不能不提及在2017年初国内上映了一部口碑不错的美国科幻大片《降临》,这部片子改编自雨果奖获得者华裔科幻小说家Ted姜的《你一生的故事》,片中主线剧情的理论基础就是就是“萨丕尔-沃夫假说”。更夸张的是片中直接将该假说应用到外星人语言上,将其扩展到宇宙范畴^_^。片中的女主作为人类代表与外星人沟通,并学会了外星语言,从此思维大变,拥有了预知未来的“超能力”。由此我们可以看出“选择对一门语言是多么的重要”。

奇妙的是,在编程语言界,有位大师级人物也有着与”萨丕尔-沃夫假说”异曲同工的观点和认知。他就是首届图灵奖得主、著名计算机科学家Alan J. Perlis(艾伦·佩利)。他从另外一个角度提出了:

“不能影响到你的编程思维方式的编程语言不值得去学习和使用”

A language that doesn't aect the way you think about programming is not worth knowing.

2、现实中的“投影”

从上述大师们的理论和观点,我们似乎看到了语言与思维之间存在着某种联系。那么两者间的这种联系在真实编程世界中的投影又是什么样子的呢?我们来看一个简单的编程问题:

【问题: 素数筛】

  问题描述:素数是一个自然数,它具有两个截然不同的自然数除数:1和它本身。 要找到小于或等于给定整数n的素数。针对这个问题,我们可以采用埃拉托斯特尼素数筛算法。
  算法描述:先用最小的素数2去筛,把2的倍数剔除掉;下一个未筛除的数就是素数(这里是3)。再用这个素数3去筛,筛除掉3的倍数... 这样不断重复下去,直到筛完为止。

img{512x368}
算法动图

下面是该素数筛算法的不同编程语言的实现版本。

C语言版本:

【sieve.c】

void sieve() {
        int c, i,j,numbers[LIMIT], primes[PRIMES];

        for (i=0;i<LIMIT;i++){
                numbers[i]=i+2; /*fill the array with natural numbers*/
        }

        for (i=0;i<LIMIT;i++){
                if (numbers[i]!=-1){
                        for (j=2*numbers[i]-2;j<LIMIT;j+=numbers[i])
                                numbers[j]=-1; /*sieve the non-primes*/
                }
        }

        c = j = 0;
        for (i=0;i<LIMIT&&j<PRIMES;i++) {
                if (numbers[i]!=-1) {
                        primes[j++] = numbers[i]; /*transfer the primes to their own array*/
                        c++;
                }
        }

        for (i=0;i<c;i++) printf("%d\n",primes[i]);
}

Haskell版本:

【sieve.hs】

sieve [] = []
sieve (x:xs) = x : sieve (filter (\a -> not $ a `mod` x == 0) xs)

n = 100
main = print $ sieve [2..n]

Go语言版本:

【sieve.go】

func generate(ch chan<- int) {
    for i := 2; ; i++ {
        ch <- i // Send 'i' to channel 'ch'.
    }
}

func filter(src <-chan int, dst chan<- int, prime int) {
    for i := range src { // Loop over values received from 'src'.
        if i%prime != 0 {
            dst <- i // Send 'i' to channel 'dst'.
        }
    }
}

func sieve() {
    ch := make(chan int) // Create a new channel.
    go generate(ch)      // Start generate() as a subprocess.
    for {
        prime := <-ch
        fmt.Print(prime, "\n")
        ch1 := make(chan int)
        go filter(ch, ch1, prime)
        ch = ch1
    }
}

  • C版本的素数筛程序是一个常规实现。它定义了两个数组:numbers和primes,“筛”的过程在numbers这个数组中进行(纯内存修改),非素数的数组元素被设置为-1,便于后续提取;
  • Haskell版本采用了函数递归的思路,通过 “filter操作集合”,用谓词(过滤条件)\a -> not $ a mod x == 0;筛除素数的倍数,将未筛除的数的集合作为参数传递归递给下去;
  • Go版本的素数筛实现采用的是goroutine的并发组合。程序从2开始,依次为每个素数建立一个goroutine,用于作为筛除该素数的倍数。ch指向当前最新输出素数所位于的筛子goroutine的源channel,这段代码来自于Rob Pike的一次关于concurrency的分享slide。

img{512x368}

3、思考

通过上述这个现实中的问题我们可以看到:面对同一个问题,来自不同编程语言的程序员给出了思维方式截然不同的解决方法:C的命令式思维、Haskell的函数式思维和Go的并发思维。这一定程度上印证了前面的假说:编程语言影响编程思维。

Go语言诞生较晚(2007年设计、2009年发布Go1),绝大多数Gopher(包括我在内)第一语言都不是Go,都是“半路出家”从其他语言转过来的,诸如:C、C++、JavaPython等,甚至是Javascript、HaskellLisp等。由于Go语言上手容易,在转Go的初期大家很快就掌握了Go的语法。但写着写着,就是发现自己写的代码总是感觉很别扭,并且总是尝试在Go语言中寻找自己上一门语言中熟悉的语法元素;自己的代码风格似乎和Go stdlib、主流Go开源项目的代码在思考角度和使用方式上存在较大差异。而每每看到Go core team member(比如:rob pike)的一些代码却总有一种醍醐灌顶的赶脚。这就是我们经常说的go coding in c way、in java way、in python way等。出现这种情况的主要原因就是大脑中的原有语言的思维方式在“作祟”。

我们学习和使用一门编程语言,目标就是要用这门语言思维方式去Coding。学习Go,就要用Go的编程思维去写Go代码,而不是用其他语言的思维方式。

4、编程语言思维的形成

人类语言如何影响人类思维这个课题自然要留给人类语言学家去破解。但编程语言如何影响编程思维,每个程序员都有着自己的理解。作为一个有着十几年编程经验的程序员,我认为可以用下面这幅示意图来解释一门编程语言思维的形成机制:

img{512x368}

决定编程语言思维的根本在于这门编程语言的价值观!什么是价值观?个人认为:一门编程语言的价值观就是这门语言的最初设计者对程序世界的认知。不同编程语言的价值观不尽相同,导致不同编程语言采用不同的语法结构,不同语言的使用者拥有着不同的思维方式,表现出针对特定问题的不同的行为(具现为:代码设计上的差异和代码风格上的不同),就像上面素数筛那样。比如:

C的价值观摘录:

- 相信程序员:提供指针和指针运算,让C程序员天马行空的发挥
- 自己动手,丰衣足食:提供一个很小的标准库,其余的让程序员自造
- 保持语言的短小和简单
- 性能优先

C++价值观摘录:

- 支持多范式,不强迫程序员使用某个特定的范式
- 不求完美,但求实用(并且立即可用)

此外,从上述模型图,我们可以看出思维和结构影响语言应用行为,这是语言应用的核心;同时存在一个反馈机制:即语言应用行为会反过来持续影响/优化语言结构。我们常用冰山表示一个事物的表象与内涵。如果说某种语言的惯用法idiomatic tips或者best practice这些具体行为是露出水面上的冰山头部,那么价值观和思维方式就是深藏在水面以下的冰山的基座。

三、Go语言价值观的形成与Go语言价值观

从上述模型来看,编程语言思维形成的主导因素是这门编程语言的价值观,因此我们首先来看一下Go语言价值观的形成以及Go语言价值观的具体内容。

Go语言的价值观的形成我觉得至少有三点因素。

1、语言设计者&Unix文化

Go语言价值观形成是与Go的初期设计者不无关系的,可以说Go最初设计者主导了Go语言价值观的形成!这就好比一个企业的最初创始人缔造企业价值观和文化一样。

img{512x368}

图中是Go的三位最初设计者,从左到右分别是罗伯特·格瑞史莫、罗伯·派克和肯·汤普逊。Go初期的所有features adoption是需要三巨头达成一致才行。三位设计者有一个共同特征,那就是深受Unix文化熏陶。罗伯特·格瑞史莫参与设计了Java的HotSpot虚拟机和Chrome浏览器的JavaScript V8引擎,罗博·派克在大名鼎鼎的bell lab侵淫多年,参与了Plan9操作系统、C编译器以及多种语言编译器的设计和实现,肯·汤普逊更是图灵奖得主、Unix之父。关于Unix设计哲学阐述最好的一本书莫过于埃瑞克.理曼德(Eric S. Raymond)的《UNIX编程艺术》了,该书中列举了很多unix的哲学条目,比如:简单、模块化、正交、组合、pipe、功能短小且聚焦等。三位设计者将Unix设计哲学应用到了Go语言的设计当中,因此你或多或少都能在Go的设计和应用中找到这些哲学的影子。

2、遗传基因

Go并发模型CSP理论的最初提出者Tony Hoare曾提出过这样一个观点:

The task of the programming language designer " is consolidation not innovation ". (Tony Hoare, 1973).
编程语言设计者的任务不是创新,而是巩固。

img{512x368}

和其他语言一样,Go也是站在巨人肩膀上的。这种基因继承,不仅仅是语法结构的继承,还有部分价值观的继承和进一步认知改进。当然不可否认的是Go也有自己的微创新,比如: implicit interface implementation、首字母大小写决定visibility等。虽然不受学院派待见,但把Go的这些微创新组合在一起,你会看到Go迸发出了强大的表现力。

3、面向新的基础设施环境和大规模软件开发的诸多问题

有一种开玩笑的说法:Go诞生于C++程序的漫长compile过程中。如果c++编译很快,那么上面的Go语言三巨头也没有闲暇时间一起喝着咖啡并讨论如何设计一门新语言。

面对时代变迁、面对新的基础设施环境、多核多处理器平台的出现,很多传统语言表现出了“不适应”,这直接导致在开发大规模软件过程中出现了各种各样的问题,比如:构建缓慢、依赖失控、代码风格各异、难用且复杂无法自动化的工具、跨语言构建难等。Go的设计初衷就是为了面向新环境、面向解决问题的。虽然这些问题不都是能在语言层面解决的,但这些环境和问题影响了设计者对程序世界的认知,也就影响了Go的价值观。

4、Go语言的价值观

在明确了Go价值观的形成因素后,我认为Go语言的价值观至少包含以下几点:

 - Overall Simplicity 全面的简单
 - Orthogonal Composition 正交组合
 - Preference in Concurrency 偏好并发

用一句话概括Go的价值观(也便于记忆):

Go is about orthogonal composition of simple concepts with preference in concurrency.
Go是在偏好并发的环境下的简单概念/事物的正交组合

无论是Go语言设计还是Go语言使用,都受到上述价值观的影响。接下来我们逐个来看一下Go语言价值观主导下的Go语言编程思维,并看看每种编程思维在语言设计、标准库实现以及主流Go开源项目中的应用体现。我将按“价值观” -> “(价值观下的)语言设计” -> “编程思维” -> “编程思维体现”的顺序展开。

四、Overall Simplicity

Go的第一个价值观就是”全面简单”。

图灵奖获得者迪杰斯特拉说过:”简单和优雅不受欢迎,那是因为人们要想实现它们需要更努力地工作,更多自律以及领会更多的教育。” 而Go的设计者们恰恰在语言设计初期就将复杂性留给了语言自身的设计和实现阶段,留给了Go core team,而将简单留给了gopher们。因此,Simplicity价值观更多地体现在了Go语言设计层面。 这里简单列举一些:

- 简洁、正规的语法:大大降低Go入门门槛,让来自其他语言的初学者可以轻松使用Go语言;
- 仅仅25个keyword:主流编程语言中最简单的,没有之一;
-  “一种”代码写法、尽可能减少程序员付出;
- 垃圾回收GC: 降低程序员在内存管理方面的心智负担;
- goroutine:提供最简洁的并发支持;
- constants:对传统语言中常量定义和使用方法做进一步简化;
- interface:纯方法集合,纯行为定义,隐式实现;
- package:Go程序结构层面的唯一组织形式,它将设计、语法、命名、构建、链接和测试都聚于一包中,导入和使用简单。

如今,Go语言的简单已经从自身设计扩展到Go应用的方方面面,但也正是由于在语言层面已经足够简单了,因此在应用层面,“简单”体现的反倒不是很明显,更加顺其自然。接下来,我总结整理几个在“全面简单”价值观下形成的Go编程思维,我们一起看一下。

1、short naming thought(短命名思维)

在gofmt的帮助下,Go语言一统coding style。在这样的一个情形下,naming成了gopher们为数不多可以“自由发挥”的空间了。但对于naming,Go有着自己的思维:短命名。即在并不影响readablity的前提下,尽可能的用长度短小的标识符,于是我们经常看到用单个字母命名的变量,这与其他一些语言在命名上的建议有不同,比如Java建议遵循“见名知义”的命名原则。

Go一般在上下文环境中用最短的名字携带足够的信息,我们可以对比一下Java和Go:

   java    vs. go

  "index" vs. "i"
  "value" vs. "v"

除了短小,Go还要求尽量在一定上下文中保持命名含义的一致性,比如:在一个上下文中,我们声明了两个变量b,如果第一个b表意为buf,那么后续的b也最好是这个含义。

在命名短小和一致性方面,stdlib和知名开源项目为我们做出表率。我们统计一下Go标准库中标识符使用频率,可以看到大量单字母命名的变量标识符占据top30:

cat $(find $GOROOT -name '*.go') | indents | sort | uniq -c | sort -nr | sed 30q
          60224 v
          42444 err
          38012 t
          33386 x
          33302 i
          33277 b
          27943 p
          25121 s
          21228 n
          20831 r
          20634 _
          19236 c
          17056 y
          12850 f
          12834 a
          ... ...

细致分析了一下stdlib中常见短变量名字所代表的含义(见代码后的注释),stdlib在一致性方面做的还是不错的,当然也有例外。

        [v, k, i]

        // loop varible
        for i, v := range s {
        for k, v := range m {
        for v := range r { // channel

        // if、switch/case clause varible
        if v := mimeTypes[ext]; v != "" {
        switch v := ptr.Elem(); v.Kind() {
        case v := <-c:

        v := reflect.ValueOf(x) // result of reflect.Value()

        [t]

        t := time.Now() // time
        t := &Timer{ // timer
        if t := md.typemap[off]; t != nil { // type

        [b]

        b := make([]byte, n) // bytes slice
        b := new(bytes.Buffer) // bytes.Buffer

2、minimal thought(最小思维)

码农们是苦逼的,每天坐在电脑前一坐就是10多个小时,自己的“业余”时间已经很少了。Go语言的设计者在这方面做的很“贴心”,考虑到为了让男Gopher能有时间撩妹,女Gopher能有时间傍帅哥,Go语言倡导minimal thought,即尽可能的降低gopher们的投入。这种思维体现在语言设计、语言使用、相关工具使用等多个方面。比如:

  • 一种代码风格:程序员们再也无需为coding style的个人喜好而争论不休了,节省下来的时间专心做自己喜欢的事情:)
  • “一种”代码写法(或提供最少的写法、更简单的写法):你会发现,面对一个问题,大多数gopher们给出的go实现方式都类似。这就是Go“一种代码写法”思维的直接体现。Go在语法结构层面没有提供给Gopher很大的灵活性。Go is not a “TMTOWTDI — There’s More Than One Way To Do It”。这点与C++、Ruby有着很大不同。
  • 显式代码(obvious),而不是聪明(clever)代码:Go提倡显而易见、可读性好的代码,而非充满各种技巧或称为“炫技”的所谓“聪明”代码。纵观stdlib、kubernetes等go代码库,都是很obvious(直观)的go code,clever code难觅踪迹。这样一来,别人写的代码,你可以轻松地看懂(为你节省大量时间和精力)。这也是Go代码中clever code比例远远小于其他主流语言的原因,Go不是炫技的舞台。

C++程序员看到这里是不是在“抹眼泪”,这里并非黑C++,C++的复杂和多范式是客观的,C++98标准和C++17标准的差异甚至可以用“两门语言”来形容,用泛型的代码和不用泛型的代码看起来也像是两门完全不同的语言,这种心智负担之沉重可想而知。

接下来,我们看看minimal thought在语言设计和应用中的体现。

1) “一种”循环: for

Go语言仅仅提供了一种用于“循环逻辑”的关键字:for。在其他语言中的各种用于循环逻辑的关键字,比如while, do-while等,在go中都可以通过for模拟实现。

- 常规
  for i := 0; i < count; i++ {}

- "while"
  for condition { }

- "do-while"
  for { // use "for-break" instead
        doSomething()
        if condition { break }
  }

- iterator loop
  for k, v := range f.Value {}

- dead loop
  for {}

2) “一种”constant

前面说过Go设计者是十分体贴的,这种体贴体现在很多不起眼的细节上,比如对传统语言中constant声明和使用的优化。

Go语言中constants只是数字,无论是整型还是浮点型都可以直接写成数字,无需显式地赋给类型:

  const incomingQueueLength = 25

  const (
      http2minMaxFrameSize = 1 << 14
      http2maxFrameSize    = 1<<24 - 1
  )

  const PI = 3.1415928
  const e = 1E6

参与计算的constant无需显式算术转换,而是由编译器自动确定语句中constant的承载类型:

  const a = 10080
  var c int32 = 99
  d := c + a
  fmt.Printf("%T\n", d) //int32
  fmt.Printf("%T\n", a) //int

3) “一种”错误处理方法

C++之父Bjarne Stroustrup说过:“世界上有两类编程语言,一类是总被人抱怨诟病的,而另外一类是无人使用的”。Go语言自其出生那天起,就因错误处理机制看起来似乎有些过时、有些简单而被大家所诟病,直至今天这种声音依旧存在。因为Go仅仅提供了一种基于值比较的简单的错误处理方法。但就是这样的错误处理方法也恰恰是Go设计者simplicity价值观的体现。Go设计者认为如果像其他一些主流语言那样,将exception的try-catch-finally的机制与语言的控制结构耦合在一起,将势必大大增加语言的复杂性,这与simplicity的价值观是背道而驰的。简单的基于值比较的error处理方法可以让使用者更重视每一个error并聚焦于错误本身。显式地去处理每一个error,让gopher对代码更有自信。并且在这种机制下,错误值和其他类型的值地位是一样的,错误处理代码也是普通代码,并无特殊之处,无特殊化处理,无需增加语言复杂性。

这些年来,gopher们也初步探索出了这种错误处理方法的常见处理模式,我们以stdlib中识别出的error handling模式为例:

a) 最常见的

在外部无需区分返回的错误值的情况下,可以在内部通过fmt.Errorf或errors.New构造一个临时错误码并返回。这种错误处理方式可以cover 80%以上情形:

    callee:
    return errors.New("something error")

    or

    return fmt.Errorf("something error: %s", "error reason")

  caller:
    if err != nil {... }

b) 导出的Error变量

当外部需要区分返回的错误值的,比如这里我要进行一个io调用,后续的操作逻辑需要因io调用的返回错误码的不同而异,我们使用导出的error变量:

  // io/io.go
  var ErrShortWrite = errors.New("short write")
  var ErrShortBuffer = errors.New("short buffer")

  if err := doSomeIO(); err == io.ErrShortWrite { ... }

c) 定义新的错误类型实现定制化错误上下文

上面的导出Error变量中包含的error context信息和信息形成机制太过简单,当我们要定制error context时, 我们可以定义一个新的Error type。之后通过针对error interface value的type assertion or type switch得到真实错误类型并访问error context:

  // encoding/json/decode.go
  type UnmarshalTypeError struct {
      Value  string       // description of JSON value - "bool", "array", "number -5"
      Type   reflect.Type // type of Go value it could not be assigned to
      Offset int64        // error occurred after reading Offset bytes
      Struct string       // name of the struct type containing the field
      Field  string       // name of the field holding the Go value
  }

  func (e *UnmarshalTypeError) Error() string {
      ... ...
      return "json: cannot unmarshal " + e.Value + " into Go value of type " + e.Type.String()
  }

  if serr, ok := err.(*UnmarshalTypeError); ok {
     //use serr to access context in UnmarshalTypeError
     ... ...
  }

不过这样的用法并不推荐也并不多见,在stdlib、kubernetes中,虽然都有自定义的exported error type,但是却很少在外部通过type assertion直接访问其内部error context字段,那标准库是怎么判断error差别的呢?

**d) 包含package中error公共行为特征的Error interface type

在标准库中,我们可以发现这样一种错误处理方式:将某个包中的Error Type归类,统一提取出一些公共行为特征,并且将这些公共行为特征(behaviour)放入一个公开的interface type中。以stdlib中的net package为例。net package将包内的所有错误类型的公共特征抽象放入”Error”这个error type中。外部使用时,通过这个公共interface获取具体错误的特征:

//net/net.go
  type Error interface {
      error
      Timeout() bool   // Is the error a timeout?
      Temporary() bool // Is the error temporary?
  }

net/http/server.go中的使用举例:

  rw, e := l.Accept()
  if e != nil {
      if ne, ok := e.(net.Error); ok && ne.Temporary() {
         ... ..
      }
      ... ...
  }

OpError是net packge中的一个自定义error type , 它实现了Temporary interface, 可以被外部统一用Error的method判断是否是Temporary或timeout error特征:

  //net/net.go
  type OpError struct {
      ... ...
      // Err is the error that occurred during the operation.
      Err error
  }

  type temporary interface {
      Temporary() bool
  }

  func (e *OpError) Temporary() bool {
    if ne, ok := e.Err.(*os.SyscallError); ok {
        t, ok := ne.Err.(temporary)
        return ok && t.Temporary()
    }
    t, ok := e.Err.(temporary)
    return ok && t.Temporary()
  }

**e) 通过一些公开的error behaviour function对error behaviour进行判断

我们在标准库中还能看到一种判断error behavior的方法,那就是通过一些公开的error behaviour function。比如:os包暴露的IsExist等函数:

  //os/error.go

  func IsExist(err error) bool {
      return isExist(err)
  }
  func IsNotExist(err error) bool { ... }
  func IsPermission(err error) bool { ... }

  例子:

    f, err := ioutil.TempFile("", "_Go_ErrIsExist")
    f2, err := os.OpenFile(f.Name(), os.O_RDWR|os.O_CREATE|os.O_EXCL, 0600)
    if os.IsExist(err) {
        fmt.Println("file exist")
        return
    }

顺便在这里提一下Go关于error type和variable的命名方式:

 错误类型: xxxError

  //net/net.go
  type OpError struct { ... }
  type ParseError struct { ... }
  type timeoutError struct{}

导出的错误变量: ErrXxx

  //io/io.go
  var ErrShortWrite = errors.New("short write")
  var ErrNoProgress = errors.New("multiple Read calls return no data or error")

很多人抱怨,当前Go提供的error handling方案让gopher可以很容易地写出如下面所示的不优雅代码:

  var err error
  err = doSomethingA()
  if err != nil {
      return err
  }

  err = doSomethingB()
  if err = nil {
      return err
  }

  err = doSomethingC()
  if err = nil {
      return err
  }
  ... ...

代码中大量重复着if err!= nil { return err} 这段snippet。但是如果你全面浏览过Go标准库中的代码,你会发现像上面这样的代码并不多见。Rob Pike曾经在《errors are values》一文中针对这个问题做过解释,并给了stdlib中的一些消除重复的方法:那就是将error作为一个内部状态:

  //bufio/bufio.go
  type Writer struct {
      err error
      buf []byte
      n   int
      wr  io.Writer
  }
  func (b *Writer) Write(p []byte) (nn int, err error) {
      if b.err != nil {
          return nn, b.err
      }
      ... ...
  }

  //writer_demo.go
  buf := bufio.NewWriter(fd)
  buf.WriteString("hello, ")
  buf.WriteString("gopherchina ")
  buf.WriteString("2017")
  if err := buf.Flush() ; err != nil {
      return err
  }

error handling的具体策略要根据实际情况而定。stdlib面向的”业务域”相对”狭窄”,像bufio.Write可以采用上面的方法解决,但是对于做业务应用的gopher来讲,业务复杂多变,错误处理没有绝对的模式,需根据上下文不同而具体设计。但如果一个函数中上述snippet过多,很可能是这个函数或方法的职责过多导致,重构是唯一出路。

五、Orthogonal Composition

正交组合是我总结出来的第二个Go语言的价值观。如果说上一个价值观聚焦的是Go程序提供的各种小概念实体或者说”零件”的话,那么Composition就是在考虑如何将这些”零件”联系到一起,搭建程序的静态骨架。

在Go语言设计层面,Go设计者为gopher提供了正交的语法元素,供后续组合使用,包括:

  • Go语言无类型体系(type hierarchy),类型定义正交独立;
  • 方法和类型的正交性: 每种类型都可以拥有自己的method set;
  • interface与其实现之间无”显式关联”;

正交性为”组合”策略的实施奠定了基础,提供了前提。Rob Pike曾说过: “If C++ and Java are about type hierarchies and the taxonomy(分类)of types, Go is about composition.”。组合是搭建Go程序静态结构的主要方式。“组合”的价值观贯穿整个语言设计和语言应用:

  • 类型间的耦合方式直接影响到程序的结构;
  • Go语言通过“组合”构架程序静态结构;
  • 垂直组合(类型组合):Go通过 type embedding机制提供;
  • 水平组合:Go通过interface语法进行“连接”。

interface是水平组合的关键,好比程序肌体上的“关节”,给予连接“关节”的两个部分各自“自由活动”的能力,而整体上又实现了某种功能。

1、vertical composition thought(垂直组合思维)

传统OO语言都是通过继承的方式建构出自己的类型体系的,但Go语言中并没有类型体系的概念。Go语言通过类型的垂直组合而不是继承让单一类型承载更多的功能。由于不是继承,那么也就没有了所谓“父子类型”的概念,也没有向上、向下转型(type casting);被嵌入的类型也不知道将其嵌入的外部类型的存在。调用Method时,method的匹配取决于方法名字,而不是类型。

Go语言通过type embedding实现垂直组合。组合方式莫过于以下这么几种:

a) construct interface by embedding interface

  type ReadWriter interface {
      Reader
      Writer
  }

通过在interface中嵌入interface type name,实现接口行为聚合,组成大接口。这种方式在stdlib中尤为常用。

b) construct struct by embedding interface

  type MyReader struct {
      io.Reader // underlying reader
      N int64   // max bytes remaining
  }

c) construct struct by embedding struct

  // sync/pool.go
  type poolLocal struct {
      private interface{}   // Can be used only by the respective P.
      shared  []interface{} // Can be used by any P.
      Mutex                 // Protects shared.
      pad     [128]byte     // Prevents false sharing.
  }

在struct中嵌入interface type name和在struct嵌入struct,都是“委派模式(delegate)”的一种应用。在struct中嵌入interface方便快速构建满足某一个interface的dummy struct,方便快速进行unit testing,仅需实现少数需要的接口方法即可,尤其是针对Big interface时。

struct中嵌入struct,被嵌入的struct的method会被提升到外面的类型中,比如上述的poolLocal struct,对于外部来说它拥有了Lock和Unlock方法,但是实际调用时,method调用实际被传给poolLocal中的Mutex实例。

2、small interface thought(小接口思维)

interface是Go语言真正的魔法。前面提到过,interface好比程序肌体的骨架关节,上下连接着骨架部件。interface决定了Go语言中类型的水平组合方式。interface与其实现者之间的关系是隐式的,无需显式的”implements”声明(但编译器会做静态检查);interface仅仅是method集合,而method和普通function一样声明,无需在特定位置。

在Go语言中,你会发现小接口(方法数量在1~3)定义占据主流。

  // builtin/builtin.go
  type error interface {
      Error() string
  }

  // io/io.go
  type Reader interface {
      Read(p []byte) (n int, err error)
  }

  // net/http/server.go
  type Handler interface {
      ServeHTTP(ResponseWriter, *Request)
  }

  type ResponseWriter interface {
      Header() Header
      Write([]byte) (int, error)
      WriteHeader(int)
  }

我统计了一下stdlib、k8s和docker里面的interface定义,画出了下面这幅接口个数与接口中method个数关系的折线图:

img{512x368}

小接口方法少,职责单一;易于实现和测试,通用性强(如:io.Reader和Writer),易于组合(如:io.Reader)。不过要想在业务领域定义出合适的小接口,还是需要对问题域有着透彻的理解的。往往无法定义出小接口,都是由于对领域的理解还不到位,没法抽象到很高的程度所致。

3、horizontal composition thought(水平组合思维)

有了小接口,后续主要关注如何通过接口进行“连接”的方式实现水平组合,以解决大问题、复杂的问题。通过interface进行组合的一种常见方法就是:通过接受interface类型参数的普通function进行组合。

以下几种具体形式:

a) 基本形式

接受interface value作为参数是水平组合的基本形式:

形式:someFunc(interface value parameter)

隐式的interface实现会不经意间满足:依赖抽象、里氏替换原则、接口隔离等原则,这在其他语言中是需要很”刻意”的设计谋划的,但在Go interface来看,一切却是自然而然的。

  func ReadAll(r io.Reader) ([]byte, error)
  func Copy(dst Writer, src Reader) (written int64, err error)

b) wrapper function

形式:接受interface类型参数,并返回与其参数类型相同的返回值

  // Wrapper function:
  func LimitReader(r Reader, n int64) Reader { return &LimitedReader{r, n} }

  type LimitedReader struct {
      R Reader // underlying reader
      N int64  // max bytes remaining
  }
  func (l *LimitedReader) Read(p []byte) (n int, err error) {}

  // Usage:
  r := strings.NewReader("some io.Reader stream to be read\n")
  lr := io.LimitReader(r, 4)
  if _, err := io.Copy(os.Stdout, lr); err != nil {
      log.Fatal(err)
  }
  // Output: some

LimitReader是一个wrapper function,它在r的外面再包裹上LimitedReader。通过wrapper function将NewReader和LimitedReader 的两者巧妙的组合在了一起。这样当我们采用包装后的reader去Read时,返回的是受到Limitedreader限制的内容了:即只读取了前面的4个字节:”some”。

c) wrapper function chain

由于wrapper function返回值类型与parameter类型相同,因此wrapper function可以组合一个chain,形式如下:

形式:wrapperFunc(wrapperFunc(wrapperFunc(...)))

我们定义一个wrapper function:CapReader,用于将从reader读取的数据变为大写:

  func CapReader(r io.Reader) io.Reader {
      return &capitalizedReader{r: r}
  }

  type capitalizedReader struct {
      r io.Reader
  }

  func (r *capitalizedReader) Read(p []byte) (int, error) {
      n, err := r.r.Read(p)
      if err != nil {
          return 0, err
      }

      q := bytes.ToUpper(p)
      for i, v := range q {
          p[i] = v
      }
      return n, err
  }

将多个wrapper function串在一起:

  s := strings.NewReader("some io.Reader stream to be read\n")
  r := io.TeeReader(CapReader(io.LimitReader(s, 4)), os.Stdout)
  b, _ := ioutil.ReadAll(r) //SOME
  fmt.Println(len(b))       //4

可以看到例子中,我们将TeeReader、CapReader、LimitedReader、strings Reader等组合到了一起,实现了读取前四个字节,将读取数据转换为大写并输出到标准输出的功能。

**d) adapter function type **

adapter function type是一个辅助水平组合实现的“工具”。adapter function type将一个普通function转换为自己的类型,同时辅助快速实现了某个“one-method” interface。 adapter function type的行为模式有些像电影中的“僵尸” – 咬别人一口就可以将别人转化为自己的同类。最著名的僵尸类型莫过于http.HandlerFunc了:

  type Handler interface {
      ServeHTTP(ResponseWriter, *Request)
  }

  type HandlerFunc func(ResponseWriter, *Request)

  func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) {
      f(w, r)
  }

  // Usage: use HandlerFunc adapts index function to an implemenation type of Handler interface.
  func index(w http.ResponseWriter, r *http.Request) {
      fmt.Fprintf(w, "Welcome!")
  }

  http.ListenAndServe(":8080", http.HandlerFunc(index))

可以看到通过HandlerFunc,我们可以将普通function index快速转化为满足Handler interface的type。一旦转化ok,便可以通过interface进行组合了。

**e) middleware composition **

middleware这个词的含义可大可小,在Go Web编程中,常常指的是一个满足Handler interface的HandlerFunc类型实例。实质上:

middleware =  wrapper function + adapter function type

我们可以看一个例子:

  func logHandler(h http.Handler) http.Handler {
      return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
          t := time.Now()
          log.Printf("[%s] %q %v\n", r.Method, r.URL.String(), t)
          h.ServeHTTP(w, r)
      })
  }

  func authHandler(h http.Handler) http.Handler {
      return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
          err := validateAuth(r.URL.Query().Get("auth"))
          if err != nil {
              http.Error(w, "bad auth param", http.StatusUnauthorized)
              return
          }
          h.ServeHTTP(w, r)
      })
  }

  func main() {
      http.ListenAndServe(":8080", logHandler(authHandler(http.HandlerFunc(index))))
  }

wrapper function(如:logHandler、authHandler)内部利用 adapter function type转化了一个普通function,并返回实现了Handler interface的HandlerFunc类型实例。

六、Preference in Concurrency

Go语言的第三个价值观是偏好并发。如果说interface和组合决定了程序的静态结构组成的话,那么concurrency则影响着程序在执行阶段的动态运行结构。从某种意义上说,Go语言就是关于concurrency和interface的设计!

并发不是并行(paralell),并发是关于程序结构的,而不是关于性能的。并发让并行更easy,并且通常性能更好;对于程序结构来说,concurrency是一个比interface组合更大的概念。并发是一种在程序执行层面上的组合:goroutines各自执行特定的工作,通过channels+select将goroutines连接起来。原生对并发的支持,让Go语言更适应现代计算环境。并发的存在鼓励程序员在程序设计时进行独立计算的分解。

在语言层面,Go提供了三种并发原语:

  • goroutines提供并发执行, 它是Go runtime调度的基本单元;goroutine实现了异步编程模型的高效,但却允许你使用同步范式编写代码,降低心智负担;goroutines被动态地多路复用到系统核心线程上以保证所有goroutines的正常运行。

  • channels用于goroutines之间的通信和同步;channel是goroutines间建立联系的主要途径或者说goroutine通过channel耦合/组合在一起,这一点channel的功用有点像Unix pipe。

  • select可以让goroutine同时协调处理多个channel操作。

1、concurrency thought(并发思维)

我将“偏好并发”价值观下的思维统称为“并发思维”。并发思维的核心依旧是组合!

采用并发思维进行程序动态结构设计,需要识别和分解出独立的计算单元放入Goroutines执行,并使用channel/select建立Goroutines之间的联系。计算单元的拆解是并发程序设计的重点,拆解没有统一规则,因业务域不同而异,例如:素数筛实现为每个素数建立一个goroutine以筛除素数的倍数。

不过我们可以从建立Goroutines间的“联系”的角度来看一些常见的goroutines间的“关系”模式。我们可以从“退出机制”和“通信联系”两大方面出发考虑。

a) “detached” goroutine

所谓分离的goroutine,即不需要关心它的退出,相当于与父goroutine间“无关系”。这类goroutines启动后与其创建者彻底分离(detached),生命周期与程序生命周期相同。通常,这类goroutine在后台执行一些特定任务,如:monitor、watcher等。其实现通常采用for-select代码段形式;以timer或event驱动。

Go应用中内置的GC goroutine就是这种类型的:

// runtime/mgc.go
  go gcBgMarkWorker(p) // each P has a background GC G.

  func gcBgMarkWorker(_p_ *p) {
      gp := getg()

      for {
        ... ...
      }
  }

b) “parent-child” goroutine

这类goroutine与detached goroutine正相反,parent需要通知并等待child退出。如果仅通知并等待一个child,我们可以这样做:

parent:

  quit := make(chan string)
  go child(quit)

child:

  select {
    case c := <-workCh:
    // do something
    case <-quit:
    // do some cleanup
    quit<-"done"
  }

parent:

  quit<-"quit"
  <-quit

当需要同时通知多个child goroutine quit时,我们可以通过channel close来实现:

parent:

  quit := make(chan struct{})
  for ... {
    go child(quit) // several child goroutines
  }

child:

  select {
    case c := <-workCh: // do something
    case <-quit: // do some cleanup
    return
  }

parent:

  close(quit)
  time.Sleep(time.Second * 30)

如果parent要获得child的退出状态值,可以自定义quit channel中的元素类型:

  type ExitStatus interface {
      Status() int
  }

  type IntStatus int // an adapter
  func (n IntStatus)Status() int {
    return int(n)
  }

  quit := make(chan ExitStatus) // for each child goroutine

child:

  quit <- IntStatus(2017)

parent:

  s := <-quit
  fmt.Println(s.Status()) //2017

c) service handle

一些goroutine在程序内部提供特定service,这些goroutine使用channel作为service handle,其他goroutine通过service handle与其通信。

比如:我们经常使用的time.After返回一个service handle:

  //time/sleep.go
  func After(d Duration) <-chan Time {
      return NewTimer(d).C
  }

对应的service goroutine就是runtime中的timer service goroutine:

  // runtime/time.go
  func timerproc() {
    timers.gp = getg()
    for {
      ... ...
    }
  }

编写此类service goroutine时,需要考虑对于“慢消费者”service goroutine应该如何处置:阻塞还是丢弃。timer service goroutine使用的是buffered channel(size=1),并在向channel发送消息时通过select做了一个判断。如果channel buffer满了,则丢弃这次timer事件。

如果我们要同时处理来自不同service goroutine的handle,那么可以使用service handles aggregation,见下面例子:

比如:我们从wechat、weibo、短信渠道获取msg:

  type msg struct {
      content string
      source  string
  }

  func wechatReceiver() <-chan *msg {
      c := make(chan *msg)
      go func() {
          c <- &msg{"wechat1", sourceWechat}
          c <- &msg{"wechat2", sourceWechat}
          c <- &msg{"wechat3", sourceWechat}
      }()

      return c
  }

  func weiboReceiver() <-chan *msg {...}
  func textmessiageReceiver() <-chan *msg {...}

我们需要把这些handle聚合起来统一处理,我们通过一个aggregation function来做。对于不固定数量handles的聚合,用goroutine来聚合(非常类似于unix pipe chain):

  func serviceAggregation(ins ...<-chan *msg) <-chan *msg {
      out := make(chan *msg)
      for _, c := range ins {
          go func(c <-chan *msg) {
              for v := range c {
                  out <- v
              }
          }(c)
      }
      return out
  }

  c := serviceAggregation(weiboReceiver(), wechatReceiver(), textmessageReceiver())
  m := <-c // 获取message并处理

对于固定数量handles聚合,用select就可以实现:

  func serviceAggregation(weibo, wechat, textmessage <-chan *msg) <-chan *msg {
      out := make(chan *msg)

      go func(out chan<- *msg) {
          for {
              select {
              case m := <-weibo:
                  out <- m
              case m := <-wechat:
                  out <- m
              case m := <-textmessage:
                  out <- m
              }
          }
      }(out)
      return out
  }
  c := serviceAggregation(weiboReceiver(), wechatReceiver(), textmessageReceiver())
  m := <-c // 获取message并处理

d) dispatch-and-mix goroutines

在“微服务”时代,我们在处理一个请求时经常调用多个外部微服务并综合处理返回结果:

  func handleRequestClassic() {
    r1 := invokeService1()
    //handle result1
    r2 := invokeService2()
    //handle result2
    r3 := invokeService3()
    //handle result3
  }

上述例子中的问题是显而易见的:顺序调用、慢、一旦某个service出现异常,返回时间不可预知,可能会导致调用阻塞。

一个优化的方法就是讲将处理请求时对外部的服务调用分发到goroutine中,再汇总返回结果。并且通过设置一个总体超时时间,让调用返回的时间可预知。:

  func handleRequestByDAM() {
    c1, c2, c3 := make(chan Result1), make(chan Result2), make(chan Result3)
    go func() { c1 <- invokeService1() } ()
    go func() { c2 <- invokeService2() } ()
    go func() { c3 <- invokeService3() } ()
    timeout := time.After(200 * time.Millisecond)
    for i := 0; i < 3; i++ {
        select {
        case r := <-c1: //handle result1
            c1 = nil
        case r := <-c2: //handle result2
            c2 = nil
        case r := <-c3: //handle result3
            c3 = nil
        case <-timeout:
            fmt.Println("timed out")
            return
        }
    }
    return
  }

不过这次优化后的程序依旧存在一个问题,那就是一旦timeout,调用返回,但一些在途的请求资源可能没有回收,request无法显式撤回,久而久之,可能导致资源的泄露。于是我们做进一步改进:通过Context显式cancel掉已经向外发起的在途请求,释放占用资源:

  type service func() result
  func invokeService(ctx context.Context, s service) chan result {
    c := make(chan result)
    go func() {
      c1 := make(chan result)
      go func() {
        c1 <-s()
      }
      select {
        case v := <-c1:
             c <-v
        case <-ctx.Done():
        // cancel this in-flight request by closing its connection.
      }
    }()
    return c
  }

  func handleRequestByDAM() {
    ctx, cf := context.WithCancel(context.Background())
    c1, c2, c3 := invokeService(ctx, service1), invokeService(ctx, service2),
                   invokeService(ctx, service3)
    timeout := time.After(200 * time.Millisecond)
    for i := 0; i < 3; i++ {
        select {
        case r := <-c1: //handle result1
        case r := <-c2: //handle result2
        case r := <-c3: //handle result3
        case <-timeout:
            cf() // cancel all service invoke requests
            return
        }
    }
    return
  }

优化后的程序的优点:并发、快、返回结果可预知。

七、总结

通过这篇文章,我总结了主导Go语言编程思维的三个价值观:

  • Overall Simplicity
  • Orthogonal Composition
  • Preference in Concurrency

阐述了每种价值观主导下的编程思维,并给出了每种编程思维在语言设计、语言应用方面的一些模式和实际例子。

Go最初的设计初衷还有一点,那就是将编程时的fun重新带给Gopher们。但个人觉得只有当你使用Go编程思维去写Go code时,你才能体会到Go设计者的用意,才能让你没有别扭的赶脚,发现自己走在正确的way上,才能真正感到go coding时的fun。

另外,虽然总结出的三个价值观数量不多,但如果能在实际运用中认真践行,却能迸发巨大能量。它会让你应对各种复杂情况、代码设计变得游刃有余、顺利解决各种业务问题。

最后再说说Go 2.0。回到前面的 “编程语言思维的形成”模型,行为总是对结构有反馈的,这将导致结构的持续改变和优化。Go team将于今年8月份发布Go1.9版本,这是一个关键的时间节点。恰好今年的denver的Gophercon大会上,Russ Cox将做”the future of go”的演讲,后续是继续1.10还是Go 2.0,让我们拭目以待!不过个人觉得,无论对语言结构改动的需求有多大,Go的价值观都是不会发生改变的。

本文的slide文件可以在这里下载。


微博:@tonybai_cn
微信公众号:iamtonybai
github.com: https://github.com/bigwhite

Go语言TCP Socket编程

Golang的主要 设计目标之一就是面向大规模后端服务程序,网络通信这块是服务端 程序必不可少也是至关重要的一部分。在日常应用中,我们也可以看到Go中的net以及其subdirectories下的包均是“高频+刚需”,而TCP socket则是网络编程的主流,即便您没有直接使用到net中有关TCP Socket方面的接口,但net/http总是用到了吧,http底层依旧是用tcp socket实现的。

网络编程方面,我们最常用的就是tcp socket编程了,在posix标准出来后,socket在各大主流OS平台上都得到了很好的支持。关于tcp programming,最好的资料莫过于W. Richard Stevens 的网络编程圣经《UNIX网络 编程 卷1:套接字联网API》 了,书中关于tcp socket接口的各种使用、行为模式、异常处理讲解的十分细致。Go是自带runtime的跨平台编程语言,Go中暴露给语言使用者的tcp socket api是建立OS原生tcp socket接口之上的。由于Go runtime调度的需要,golang tcp socket接口在行为特点与异常处理方面与OS原生接口有着一些差别。这篇博文的目标就是整理出关于Go tcp socket在各个场景下的使用方法、行为特点以及注意事项。

一、模型

从tcp socket诞生后,网络编程架构模型也几经演化,大致是:“每进程一个连接” –> “每线程一个连接” –> “Non-Block + I/O多路复用(linux epoll/windows iocp/freebsd darwin kqueue/solaris Event Port)”。伴随着模型的演化,服务程序愈加强大,可以支持更多的连接,获得更好的处理性能。

目前主流web server一般均采用的都是”Non-Block + I/O多路复用”(有的也结合了多线程、多进程)。不过I/O多路复用也给使用者带来了不小的复杂度,以至于后续出现了许多高性能的I/O多路复用框架, 比如libeventlibevlibuv等,以帮助开发者简化开发复杂性,降低心智负担。不过Go的设计者似乎认为I/O多路复用的这种通过回调机制割裂控制流 的方式依旧复杂,且有悖于“一般逻辑”设计,为此Go语言将该“复杂性”隐藏在Runtime中了:Go开发者无需关注socket是否是 non-block的,也无需亲自注册文件描述符的回调,只需在每个连接对应的goroutine中以“block I/O”的方式对待socket处理即可,这可以说大大降低了开发人员的心智负担。一个典型的Go server端程序大致如下:

//go-tcpsock/server.go
func handleConn(c net.Conn) {
    defer c.Close()
    for {
        // read from the connection
        // ... ...
        // write to the connection
        //... ...
    }
}

func main() {
    l, err := net.Listen("tcp", ":8888")
    if err != nil {
        fmt.Println("listen error:", err)
        return
    }

    for {
        c, err := l.Accept()
        if err != nil {
            fmt.Println("accept error:", err)
            break
        }
        // start a new goroutine to handle
        // the new connection.
        go handleConn(c)
    }
}

用户层眼中看到的goroutine中的“block socket”,实际上是通过Go runtime中的netpoller通过Non-block socket + I/O多路复用机制“模拟”出来的,真实的underlying socket实际上是non-block的,只是runtime拦截了底层socket系统调用的错误码,并通过netpoller和goroutine 调度让goroutine“阻塞”在用户层得到的Socket fd上。比如:当用户层针对某个socket fd发起read操作时,如果该socket fd中尚无数据,那么runtime会将该socket fd加入到netpoller中监听,同时对应的goroutine被挂起,直到runtime收到socket fd 数据ready的通知,runtime才会重新唤醒等待在该socket fd上准备read的那个Goroutine。而这个过程从Goroutine的视角来看,就像是read操作一直block在那个socket fd上似的。具体实现细节在后续场景中会有补充描述。

二、TCP连接的建立

众所周知,TCP Socket的连接的建立需要经历客户端和服务端的三次握手的过程。连接建立过程中,服务端是一个标准的Listen + Accept的结构(可参考上面的代码),而在客户端Go语言使用net.Dial或DialTimeout进行连接建立:

阻塞Dial:

conn, err := net.Dial("tcp", "google.com:80")
if err != nil {
    //handle error
}
// read or write on conn

或是带上超时机制的Dial:

conn, err := net.DialTimeout("tcp", ":8080", 2 * time.Second)
if err != nil {
    //handle error
}
// read or write on conn

对于客户端而言,连接的建立会遇到如下几种情形:


1、网络不可达或对方服务未启动

如果传给Dial的Addr是可以立即判断出网络不可达,或者Addr中端口对应的服务没有启动,端口未被监听,Dial会几乎立即返回错误,比如:

//go-tcpsock/conn_establish/client1.go
... ...
func main() {
    log.Println("begin dial...")
    conn, err := net.Dial("tcp", ":8888")
    if err != nil {
        log.Println("dial error:", err)
        return
    }
    defer conn.Close()
    log.Println("dial ok")
}

如果本机8888端口未有服务程序监听,那么执行上面程序,Dial会很快返回错误:

$go run client1.go
2015/11/16 14:37:41 begin dial...
2015/11/16 14:37:41 dial error: dial tcp :8888: getsockopt: connection refused

2、对方服务的listen backlog满

还有一种场景就是对方服务器很忙,瞬间有大量client端连接尝试向server建立,server端的listen backlog队列满,server accept不及时((即便不accept,那么在backlog数量范畴里面,connect都会是成功的,因为new conn已经加入到server side的listen queue中了,accept只是从queue中取出一个conn而已),这将导致client端Dial阻塞。我们还是通过例子感受Dial的行为特点:

服务端代码:

//go-tcpsock/conn_establish/server2.go
... ...
func main() {
    l, err := net.Listen("tcp", ":8888")
    if err != nil {
        log.Println("error listen:", err)
        return
    }
    defer l.Close()
    log.Println("listen ok")

    var i int
    for {
        time.Sleep(time.Second * 10)
        if _, err := l.Accept(); err != nil {
            log.Println("accept error:", err)
            break
        }
        i++
        log.Printf("%d: accept a new connection\n", i)
    }
}

客户端代码:

//go-tcpsock/conn_establish/client2.go
... ...
func establishConn(i int) net.Conn {
    conn, err := net.Dial("tcp", ":8888")
    if err != nil {
        log.Printf("%d: dial error: %s", i, err)
        return nil
    }
    log.Println(i, ":connect to server ok")
    return conn
}

func main() {
    var sl []net.Conn
    for i := 1; i < 1000; i++ {
        conn := establishConn(i)
        if conn != nil {
            sl = append(sl, conn)
        }
    }

    time.Sleep(time.Second * 10000)
}

从程序可以看出,服务端在listen成功后,每隔10s钟accept一次。客户端则是串行的尝试建立连接。这两个程序在Darwin下的执行 结果:

$go run server2.go
2015/11/16 21:55:41 listen ok
2015/11/16 21:55:51 1: accept a new connection
2015/11/16 21:56:01 2: accept a new connection
... ...

$go run client2.go
2015/11/16 21:55:44 1 :connect to server ok
2015/11/16 21:55:44 2 :connect to server ok
2015/11/16 21:55:44 3 :connect to server ok
... ...

2015/11/16 21:55:44 126 :connect to server ok
2015/11/16 21:55:44 127 :connect to server ok
2015/11/16 21:55:44 128 :connect to server ok

2015/11/16 21:55:52 129 :connect to server ok
2015/11/16 21:56:03 130 :connect to server ok
2015/11/16 21:56:14 131 :connect to server ok
... ...

可以看出Client初始时成功地一次性建立了128个连接,然后后续每阻塞近10s才能成功建立一条连接。也就是说在server端 backlog满时(未及时accept),客户端将阻塞在Dial上,直到server端进行一次accept。至于为什么是128,这与darwin 下的默认设置有关:

$sysctl -a|grep kern.ipc.somaxconn
kern.ipc.somaxconn: 128

如果我在ubuntu 14.04上运行上述server程序,我们的client端初始可以成功建立499条连接。

如果server一直不accept,client端会一直阻塞么?我们去掉accept后的结果是:在Darwin下,client端会阻塞大 约1分多钟才会返回timeout:

2015/11/16 22:03:31 128 :connect to server ok
2015/11/16 22:04:48 129: dial error: dial tcp :8888: getsockopt: operation timed out

而如果server运行在ubuntu 14.04上,client似乎一直阻塞,我等了10多分钟依旧没有返回。 阻塞与否看来与server端的网络实现和设置有关。

3、网络延迟较大,Dial阻塞并超时

如果网络延迟较大,TCP握手过程将更加艰难坎坷(各种丢包),时间消耗的自然也会更长。Dial这时会阻塞,如果长时间依旧无法建立连接,则Dial也会返回“ getsockopt: operation timed out”错误。


在连接建立阶段,多数情况下,Dial是可以满足需求的,即便阻塞一小会儿。但对于某些程序而言,需要有严格的连接时间限定,如果一定时间内没能成功建立连接,程序可能会需要执行一段“异常”处理逻辑,为此我们就需要DialTimeout了。下面的例子将Dial的最长阻塞时间限制在2s内,超出这个时长,Dial将返回timeout error:

//go-tcpsock/conn_establish/client3.go
... ...
func main() {
    log.Println("begin dial...")
    conn, err := net.DialTimeout("tcp", "104.236.176.96:80", 2*time.Second)
    if err != nil {
        log.Println("dial error:", err)
        return
    }
    defer conn.Close()
    log.Println("dial ok")
}

执行结果如下(需要模拟一个延迟较大的网络环境):

$go run client3.go
2015/11/17 09:28:34 begin dial...
2015/11/17 09:28:36 dial error: dial tcp 104.236.176.96:80: i/o timeout

三、Socket读写

连接建立起来后,我们就要在conn上进行读写,以完成业务逻辑。前面说过Go runtime隐藏了I/O多路复用的复杂性。语言使用者只需采用goroutine+Block I/O的模式即可满足大部分场景需求。Dial成功后,方法返回一个net.Conn接口类型变量值,这个接口变量的动态类型为一个*TCPConn:

//$GOROOT/src/net/tcpsock_posix.go
type TCPConn struct {
    conn
}

TCPConn内嵌了一个unexported类型:conn,因此TCPConn”继承”了conn的Read和Write方法,后续通过Dial返回值调用的Write和Read方法均是net.conn的方法:

//$GOROOT/src/net/net.go
type conn struct {
    fd *netFD
}

func (c *conn) ok() bool { return c != nil && c.fd != nil }

// Implementation of the Conn interface.

// Read implements the Conn Read method.
func (c *conn) Read(b []byte) (int, error) {
    if !c.ok() {
        return 0, syscall.EINVAL
    }
    n, err := c.fd.Read(b)
    if err != nil && err != io.EOF {
        err = &OpError{Op: "read", Net: c.fd.net, Source: c.fd.laddr, Addr: c.fd.raddr, Err: err}
    }
    return n, err
}

// Write implements the Conn Write method.
func (c *conn) Write(b []byte) (int, error) {
    if !c.ok() {
        return 0, syscall.EINVAL
    }
    n, err := c.fd.Write(b)
    if err != nil {
        err = &OpError{Op: "write", Net: c.fd.net, Source: c.fd.laddr, Addr: c.fd.raddr, Err: err}
    }
    return n, err
}

下面我们先来通过几个场景来总结一下conn.Read的行为特点。


1、Socket中无数据

连接建立后,如果对方未发送数据到socket,接收方(Server)会阻塞在Read操作上,这和前面提到的“模型”原理是一致的。执行该Read操作的goroutine也会被挂起。runtime会监视该socket,直到其有数据才会重新
调度该socket对应的Goroutine完成read。由于篇幅原因,这里就不列代码了,例子对应的代码文件:go-tcpsock/read_write下的client1.go和server1.go。

2、Socket中有部分数据

如果socket中有部分数据,且长度小于一次Read操作所期望读出的数据长度,那么Read将会成功读出这部分数据并返回,而不是等待所有期望数据全部读取后再返回。

Client端:

//go-tcpsock/read_write/client2.go
... ...
func main() {
    if len(os.Args) <= 1 {
        fmt.Println("usage: go run client2.go YOUR_CONTENT")
        return
    }
    log.Println("begin dial...")
    conn, err := net.Dial("tcp", ":8888")
    if err != nil {
        log.Println("dial error:", err)
        return
    }
    defer conn.Close()
    log.Println("dial ok")

    time.Sleep(time.Second * 2)
    data := os.Args[1]
    conn.Write([]byte(data))

    time.Sleep(time.Second * 10000)
}

Server端:

//go-tcpsock/read_write/server2.go
... ...
func handleConn(c net.Conn) {
    defer c.Close()
    for {
        // read from the connection
        var buf = make([]byte, 10)
        log.Println("start to read from conn")
        n, err := c.Read(buf)
        if err != nil {
            log.Println("conn read error:", err)
            return
        }
        log.Printf("read %d bytes, content is %s\n", n, string(buf[:n]))
    }
}
... ...

我们通过client2.go发送”hi”到Server端:
运行结果:

$go run client2.go hi
2015/11/17 13:30:53 begin dial...
2015/11/17 13:30:53 dial ok

$go run server2.go
2015/11/17 13:33:45 accept a new connection
2015/11/17 13:33:45 start to read from conn
2015/11/17 13:33:47 read 2 bytes, content is hi
...

Client向socket中写入两个字节数据(“hi”),Server端创建一个len = 10的slice,等待Read将读取的数据放入slice;Server随后读取到那两个字节:”hi”。Read成功返回,n =2 ,err = nil。

3、Socket中有足够数据

如果socket中有数据,且长度大于等于一次Read操作所期望读出的数据长度,那么Read将会成功读出这部分数据并返回。这个情景是最符合我们对Read的期待的了:Read将用Socket中的数据将我们传入的slice填满后返回:n = 10, err = nil。

我们通过client2.go向Server2发送如下内容:abcdefghij12345,执行结果如下:

$go run client2.go abcdefghij12345
2015/11/17 13:38:00 begin dial...
2015/11/17 13:38:00 dial ok

$go run server2.go
2015/11/17 13:38:00 accept a new connection
2015/11/17 13:38:00 start to read from conn
2015/11/17 13:38:02 read 10 bytes, content is abcdefghij
2015/11/17 13:38:02 start to read from conn
2015/11/17 13:38:02 read 5 bytes, content is 12345

client端发送的内容长度为15个字节,Server端Read buffer的长度为10,因此Server Read第一次返回时只会读取10个字节;Socket中还剩余5个字节数据,Server再次Read时会把剩余数据读出(如:情形2)。

4、Socket关闭

如果client端主动关闭了socket,那么Server的Read将会读到什么呢?这里分为“有数据关闭”和“无数据关闭”。

“有数据关闭”是指在client关闭时,socket中还有server端未读取的数据,我们在go-tcpsock/read_write/client3.go和server3.go中模拟这种情况:

$go run client3.go hello
2015/11/17 13:50:57 begin dial...
2015/11/17 13:50:57 dial ok

$go run server3.go
2015/11/17 13:50:57 accept a new connection
2015/11/17 13:51:07 start to read from conn
2015/11/17 13:51:07 read 5 bytes, content is hello
2015/11/17 13:51:17 start to read from conn
2015/11/17 13:51:17 conn read error: EOF

从输出结果来看,当client端close socket退出后,server3依旧没有开始Read,10s后第一次Read成功读出了5个字节的数据,当第二次Read时,由于client端 socket关闭,Read返回EOF error。

通过上面这个例子,我们也可以猜测出“无数据关闭”情形下的结果,那就是Read直接返回EOF error。

5、读取操作超时

有些场合对Read的阻塞时间有严格限制,在这种情况下,Read的行为到底是什么样的呢?在返回超时错误时,是否也同时Read了一部分数据了呢?这个实验比较难于模拟,下面的测试结果也未必能反映出所有可能结果。我们编写了client4.go和server4.go来模拟这一情形。

//go-tcpsock/read_write/client4.go
... ...
func main() {
    log.Println("begin dial...")
    conn, err := net.Dial("tcp", ":8888")
    if err != nil {
        log.Println("dial error:", err)
        return
    }
    defer conn.Close()
    log.Println("dial ok")

    data := make([]byte, 65536)
    conn.Write(data)

    time.Sleep(time.Second * 10000)
}

//go-tcpsock/read_write/server4.go
... ...
func handleConn(c net.Conn) {
    defer c.Close()
    for {
        // read from the connection
        time.Sleep(10 * time.Second)
        var buf = make([]byte, 65536)
        log.Println("start to read from conn")
        c.SetReadDeadline(time.Now().Add(time.Microsecond * 10))
        n, err := c.Read(buf)
        if err != nil {
            log.Printf("conn read %d bytes,  error: %s", n, err)
            if nerr, ok := err.(net.Error); ok && nerr.Timeout() {
                continue
            }
            return
        }
        log.Printf("read %d bytes, content is %s\n", n, string(buf[:n]))
    }
}

在Server端我们通过Conn的SetReadDeadline方法设置了10微秒的读超时时间,Server的执行结果如下:

$go run server4.go

2015/11/17 14:21:17 accept a new connection
2015/11/17 14:21:27 start to read from conn
2015/11/17 14:21:27 conn read 0 bytes,  error: read tcp 127.0.0.1:8888->127.0.0.1:60970: i/o timeout
2015/11/17 14:21:37 start to read from conn
2015/11/17 14:21:37 read 65536 bytes, content is

虽然每次都是10微秒超时,但结果不同,第一次Read超时,读出数据长度为0;第二次读取所有数据成功,没有超时。反复执行了多次,没能出现“读出部分数据且返回超时错误”的情况。


和读相比,Write遇到的情形一样不少,我们也逐一看一下。


1、成功写

前面例子着重于Read,client端在Write时并未判断Write的返回值。所谓“成功写”指的就是Write调用返回的n与预期要写入的数据长度相等,且error = nil。这是我们在调用Write时遇到的最常见的情形,这里不再举例了。

2、写阻塞

TCP连接通信两端的OS都会为该连接保留数据缓冲,一端调用Write后,实际上数据是写入到OS的协议栈的数据缓冲的。TCP是全双工通信,因此每个方向都有独立的数据缓冲。当发送方将对方的接收缓冲区以及自身的发送缓冲区写满后,Write就会阻塞。我们来看一个例子:client5.go和server.go。

//go-tcpsock/read_write/client5.go
... ...
func main() {
    log.Println("begin dial...")
    conn, err := net.Dial("tcp", ":8888")
    if err != nil {
        log.Println("dial error:", err)
        return
    }
    defer conn.Close()
    log.Println("dial ok")

    data := make([]byte, 65536)
    var total int
    for {
        n, err := conn.Write(data)
        if err != nil {
            total += n
            log.Printf("write %d bytes, error:%s\n", n, err)
            break
        }
        total += n
        log.Printf("write %d bytes this time, %d bytes in total\n", n, total)
    }

    log.Printf("write %d bytes in total\n", total)
    time.Sleep(time.Second * 10000)
}

//go-tcpsock/read_write/server5.go
... ...
func handleConn(c net.Conn) {
    defer c.Close()
    time.Sleep(time.Second * 10)
    for {
        // read from the connection
        time.Sleep(5 * time.Second)
        var buf = make([]byte, 60000)
        log.Println("start to read from conn")
        n, err := c.Read(buf)
        if err != nil {
            log.Printf("conn read %d bytes,  error: %s", n, err)
            if nerr, ok := err.(net.Error); ok && nerr.Timeout() {
                continue
            }
        }

        log.Printf("read %d bytes, content is %s\n", n, string(buf[:n]))
    }
}
... ...

Server5在前10s中并不Read数据,因此当client5一直尝试写入时,写到一定量后就会发生阻塞:

$go run client5.go

2015/11/17 14:57:33 begin dial...
2015/11/17 14:57:33 dial ok
2015/11/17 14:57:33 write 65536 bytes this time, 65536 bytes in total
2015/11/17 14:57:33 write 65536 bytes this time, 131072 bytes in total
2015/11/17 14:57:33 write 65536 bytes this time, 196608 bytes in total
2015/11/17 14:57:33 write 65536 bytes this time, 262144 bytes in total
2015/11/17 14:57:33 write 65536 bytes this time, 327680 bytes in total
2015/11/17 14:57:33 write 65536 bytes this time, 393216 bytes in total
2015/11/17 14:57:33 write 65536 bytes this time, 458752 bytes in total
2015/11/17 14:57:33 write 65536 bytes this time, 524288 bytes in total
2015/11/17 14:57:33 write 65536 bytes this time, 589824 bytes in total
2015/11/17 14:57:33 write 65536 bytes this time, 655360 bytes in total

在Darwin上,这个size大约在679468bytes。后续当server5每隔5s进行Read时,OS socket缓冲区腾出了空间,client5就又可以写入了:

$go run server5.go
2015/11/17 15:07:01 accept a new connection
2015/11/17 15:07:16 start to read from conn
2015/11/17 15:07:16 read 60000 bytes, content is
2015/11/17 15:07:21 start to read from conn
2015/11/17 15:07:21 read 60000 bytes, content is
2015/11/17 15:07:26 start to read from conn
2015/11/17 15:07:26 read 60000 bytes, content is
....

client端:

2015/11/17 15:07:01 write 65536 bytes this time, 720896 bytes in total
2015/11/17 15:07:06 write 65536 bytes this time, 786432 bytes in total
2015/11/17 15:07:16 write 65536 bytes this time, 851968 bytes in total
2015/11/17 15:07:16 write 65536 bytes this time, 917504 bytes in total
2015/11/17 15:07:27 write 65536 bytes this time, 983040 bytes in total
2015/11/17 15:07:27 write 65536 bytes this time, 1048576 bytes in total
.... ...

3、写入部分数据

Write操作存在写入部分数据的情况,比如上面例子中,当client端输出日志停留在“write 65536 bytes this time, 655360 bytes in total”时,我们杀掉server5,这时我们会看到client5输出以下日志:

...
2015/11/17 15:19:14 write 65536 bytes this time, 655360 bytes in total
2015/11/17 15:19:16 write 24108 bytes, error:write tcp 127.0.0.1:62245->127.0.0.1:8888: write: broken pipe
2015/11/17 15:19:16 write 679468 bytes in total

显然Write并非在655360这个地方阻塞的,而是后续又写入24108后发生了阻塞,server端socket关闭后,我们看到Wrote返回er != nil且n = 24108,程序需要对这部分写入的24108字节做特定处理。

4、写入超时

如果非要给Write增加一个期限,那我们可以调用SetWriteDeadline方法。我们copy一份client5.go,形成client6.go,在client6.go的Write之前增加一行timeout设置代码:

conn.SetWriteDeadline(time.Now().Add(time.Microsecond * 10))

启动server6.go,启动client6.go,我们可以看到写入超时的情况下,Write的返回结果:

$go run client6.go
2015/11/17 15:26:34 begin dial...
2015/11/17 15:26:34 dial ok
2015/11/17 15:26:34 write 65536 bytes this time, 65536 bytes in total
... ...
2015/11/17 15:26:34 write 65536 bytes this time, 655360 bytes in total
2015/11/17 15:26:34 write 24108 bytes, error:write tcp 127.0.0.1:62325->127.0.0.1:8888: i/o timeout
2015/11/17 15:26:34 write 679468 bytes in total

可以看到在写入超时时,依旧存在部分数据写入的情况。


综上例子,虽然Go给我们提供了阻塞I/O的便利,但在调用Read和Write时依旧要综合需要方法返回的n和err的结果,以做出正确处理。net.conn实现了io.Reader和io.Writer接口,因此可以试用一些wrapper包进行socket读写,比如bufio包下面的Writer和Reader、io/ioutil下的函数等。

Goroutine safe

基于goroutine的网络架构模型,存在在不同goroutine间共享conn的情况,那么conn的读写是否是goroutine safe的呢?在深入这个问题之前,我们先从应用意义上来看read操作和write操作的goroutine-safe必要性。

对于read操作而言,由于TCP是面向字节流,conn.Read无法正确区分数据的业务边界,因此多个goroutine对同一个conn进行read的意义不大,goroutine读到不完整的业务包反倒是增加了业务处理的难度。对与Write操作而言,倒是有多个goroutine并发写的情况。不过conn读写是否goroutine-safe的测试不是很好做,我们先深入一下runtime代码,先从理论上给这个问题定个性:

net.conn只是*netFD的wrapper结构,最终Write和Read都会落在其中的fd上:

type conn struct {
    fd *netFD
}

netFD在不同平台上有着不同的实现,我们以net/fd_unix.go中的netFD为例:

// Network file descriptor.
type netFD struct {
    // locking/lifetime of sysfd + serialize access to Read and Write methods
    fdmu fdMutex

    // immutable until Close
    sysfd       int
    family      int
    sotype      int
    isConnected bool
    net         string
    laddr       Addr
    raddr       Addr

    // wait server
    pd pollDesc
}

我们看到netFD中包含了一个runtime实现的fdMutex类型字段,从注释上来看,该fdMutex用来串行化对该netFD对应的sysfd的Write和Read操作。从这个注释上来看,所有对conn的Read和Write操作都是有fdMutex互斥的,从netFD的Read和Write方法的实现也证实了这一点:

func (fd *netFD) Read(p []byte) (n int, err error) {
    if err := fd.readLock(); err != nil {
        return 0, err
    }
    defer fd.readUnlock()
    if err := fd.pd.PrepareRead(); err != nil {
        return 0, err
    }
    for {
        n, err = syscall.Read(fd.sysfd, p)
        if err != nil {
            n = 0
            if err == syscall.EAGAIN {
                if err = fd.pd.WaitRead(); err == nil {
                    continue
                }
            }
        }
        err = fd.eofError(n, err)
        break
    }
    if _, ok := err.(syscall.Errno); ok {
        err = os.NewSyscallError("read", err)
    }
    return
}

func (fd *netFD) Write(p []byte) (nn int, err error) {
    if err := fd.writeLock(); err != nil {
        return 0, err
    }
    defer fd.writeUnlock()
    if err := fd.pd.PrepareWrite(); err != nil {
        return 0, err
    }
    for {
        var n int
        n, err = syscall.Write(fd.sysfd, p[nn:])
        if n > 0 {
            nn += n
        }
        if nn == len(p) {
            break
        }
        if err == syscall.EAGAIN {
            if err = fd.pd.WaitWrite(); err == nil {
                continue
            }
        }
        if err != nil {
            break
        }
        if n == 0 {
            err = io.ErrUnexpectedEOF
            break
        }
    }
    if _, ok := err.(syscall.Errno); ok {
        err = os.NewSyscallError("write", err)
    }
    return nn, err
}

每次Write操作都是受lock保护,直到此次数据全部write完。因此在应用层面,要想保证多个goroutine在一个conn上write操作的Safe,需要一次write完整写入一个“业务包”;一旦将业务包的写入拆分为多次write,那就无法保证某个Goroutine的某“业务包”数据在conn发送的连续性。

同时也可以看出即便是Read操作,也是lock保护的。多个Goroutine对同一conn的并发读不会出现读出内容重叠的情况,但内容断点是依 runtime调度来随机确定的。存在一个业务包数据,1/3内容被goroutine-1读走,另外2/3被另外一个goroutine-2读 走的情况。比如一个完整包:world,当goroutine的read slice size < 5时,存在可能:一个goroutine读到 “worl”,另外一个goroutine读出”d”。

四、Socket属性

原生Socket API提供了丰富的sockopt设置接口,但Golang有自己的网络架构模型,golang提供的socket options接口也是基于上述模型的必要的属性设置。包括

  • SetKeepAlive
  • SetKeepAlivePeriod
  • SetLinger
  • SetNoDelay (默认no delay)
  • SetWriteBuffer
  • SetReadBuffer

不过上面的Method是TCPConn的,而不是Conn的,要使用上面的Method的,需要type assertion:

tcpConn, ok := c.(*TCPConn)
if !ok {
    //error handle
}

tcpConn.SetNoDelay(true)

对于listener socket, golang默认采用了 SO_REUSEADDR,这样当你重启 listener程序时,不会因为address in use的错误而启动失败。而listen backlog的默认值是通过获取系统的设置值得到的。不同系统不同:mac 128, linux 512等。

五、关闭连接

和前面的方法相比,关闭连接算是最简单的操作了。由于socket是全双工的,client和server端在己方已关闭的socket和对方关闭的socket上操作的结果有不同。看下面例子:

//go-tcpsock/conn_close/client1.go
... ...
func main() {
    log.Println("begin dial...")
    conn, err := net.Dial("tcp", ":8888")
    if err != nil {
        log.Println("dial error:", err)
        return
    }
    conn.Close()
    log.Println("close ok")

    var buf = make([]byte, 32)
    n, err := conn.Read(buf)
    if err != nil {
        log.Println("read error:", err)
    } else {
        log.Printf("read % bytes, content is %s\n", n, string(buf[:n]))
    }

    n, err = conn.Write(buf)
    if err != nil {
        log.Println("write error:", err)
    } else {
        log.Printf("write % bytes, content is %s\n", n, string(buf[:n]))
    }

    time.Sleep(time.Second * 1000)
}

//go-tcpsock/conn_close/server1.go
... ...
func handleConn(c net.Conn) {
    defer c.Close()

    // read from the connection
    var buf = make([]byte, 10)
    log.Println("start to read from conn")
    n, err := c.Read(buf)
    if err != nil {
        log.Println("conn read error:", err)
    } else {
        log.Printf("read %d bytes, content is %s\n", n, string(buf[:n]))
    }

    n, err = c.Write(buf)
    if err != nil {
        log.Println("conn write error:", err)
    } else {
        log.Printf("write %d bytes, content is %s\n", n, string(buf[:n]))
    }
}
... ...

上述例子的执行结果如下:

$go run server1.go
2015/11/17 17:00:51 accept a new connection
2015/11/17 17:00:51 start to read from conn
2015/11/17 17:00:51 conn read error: EOF
2015/11/17 17:00:51 write 10 bytes, content is

$go run client1.go
2015/11/17 17:00:51 begin dial...
2015/11/17 17:00:51 close ok
2015/11/17 17:00:51 read error: read tcp 127.0.0.1:64195->127.0.0.1:8888: use of closed network connection
2015/11/17 17:00:51 write error: write tcp 127.0.0.1:64195->127.0.0.1:8888: use of closed network connection

从client1的结果来看,在己方已经关闭的socket上再进行read和write操作,会得到”use of closed network connection” error;
从server1的执行结果来看,在对方关闭的socket上执行read操作会得到EOF error,但write操作会成功,因为数据会成功写入己方的内核socket缓冲区中,即便最终发不到对方socket缓冲区了,因为己方socket并未关闭。因此当发现对方socket关闭后,己方应该正确合理处理自己的socket,再继续write已经无任何意义了。

六、小结

本文比较基础,但却很重要,毕竟golang是面向大规模服务后端的,对通信环节的细节的深入理解会大有裨益。另外Go的goroutine+阻塞通信的网络通信模型降低了开发者心智负担,简化了通信的复杂性,这点尤为重要。

本文代码实验环境:go 1.5.1 on Darwin amd64以及部分在ubuntu 14.04 amd64。

本文demo代码在这里可以找到。

为阻塞型函数调用添加超时机制

我们产品中的一个子模块在进行Oracle实时数据库查询时,常常因数据库性能波动或异常而被阻塞在OCI API的调用上,为此我们付出了“惨痛”的代价。说来说去还是我们的程序设计的不够完善,在此类阻塞型函数调用方面缺少微小粒度的超时机制。

调用阻塞多发生在I/O操作(磁盘、网络、低速设备)、第三方API调用等方面。对于文件/网络I/O操作,我们可利用在非阻塞文件描述符上select /poll的超时机制来替代针对阻塞型文件描述符的系统调用;但在第三方API方面,多数时候是无法用select/poll来进行超时的,我们可以选择 另外一种方法:利用setjmp和longjmp的非局部跳转机制来为特定阻塞调用添加超时机制。其原理大致是:利用定时器(alarm、setitimer)设置超时时间,在SIGALRM的handler中利用longjmp跳到阻塞型调用之前,达到超时跳出阻塞型函数调用的效果。同时这种方法通用性更好些。

这个机制实现起来并不难,但有些细节还是要考虑周全,否则很容易出错。我们的产品是需要运行在LinuxSolaris两个平台下的,因此机制的实现还要考虑移植性的问题。下面简要说说在实现这一机制过程中出现的一些问题与解决方法。

一、第一版

考虑到阻塞型函数的原型各不相同,且我们的产品中对阻塞调用有重试次数的要求,因此打算将这个机制包装成一个,大致是这个模样:

#define add_timeout_to_func(func, n, interval, ret, …) \…

其中func是函数名;n是重试的次数;interval是超时的时间,单位是秒;ret是函数成功调用后的返回值,若失败,也是这个宏的返回值。

我们可以像下面这样使用这个宏:

/* example.c */
int
main()
{
    #define MAXLINE 1024
    char line[MAXLINE];

    int ret = 0;
    int try_times = 3;
    int interval = 1000;
    add_timeout_to_func(read, try_times, interval, ret, STDIN_FILENO, line, MAXLINE);
    if (ret == E_CALL_TIMEOUT) {
        printf("invoke read timeouts for 3 times\n");
        return -1;
    } else if (ret == 0) {
        printf("invoke read ok\n");
        return 0;
    } else {
        printf("add_timeout_to_func error = %d\n", ret);
    }
}

add_timeout_to_func中为阻塞型函数添加的超时机制是利用setjmp/longjmp与信号的处理函数合作完成的。

/* timeout_wrapper.h */
 

#include <setjmp.h>
#include <stdarg.h>
#include <unistd.h>
#include <stdio.h>
#include <signal.h>
#include <string.h>
#include <errno.h>

extern volatile int invoke_count;
extern jmp_buf invoke_env;

void timeout_signal_handler(int sig);
typedef void (*sighandler_t)(int);
#define E_CALL_TIMEOUT (-9)

#define add_timeout_to_func(func, n, interval, ret, ...) \
    { \
        invoke_count = 0; \
        sighandler_t h = signal(SIGALRM, timeout_signal_handler); \
        if (h == SIG_ERR) { \
            ret = errno; \
            goto end; \
        }  \
\
        if (sigjmp(invoke_env) != 0) { \
            if (invoke_count >= n) { \
                ret = E_CALL_TIMEOUT; \
                goto err; \
            } \
        } \
\
        alarm(interval);\
        ret = func(__VA_ARGS__);\
        alarm(0); \
err:\
        signal(SIGALRM, h);\
end:\
        ;\
    }

/* timeout_wrapper.c */
#include "timeout_wrapper.h"

volatile int invoke_count = 0;
jmp_buf invoke_env;

void
timeout_signal_handler(int sig)
{
    invoke_count++;
    longjmp(invoke_env, 1);
}

编译运行这个程序,分别在Solaris、Linux下运行,遗憾的是两个平台下都以失败告终。

先说一下在Linux下的情况。在Linux下,程序居然不响应第二次SIGALRM信号了。通过strace也可以看出,当alarm被第二次调用后, 系统便阻塞在了read上,没有实现为read增加超时机制的目的。原因何在呢?我在《The Linux Programming Interface》一书中找到了原因。原因大致是这样的,我们按照代码的执行流程来分析:

* add_timeout_to_func宏首先设置了信号的handler,保存了env信息(setjmp),调用alarm设置定时器,然后阻塞在read调用上;
* 1s后,定时器信号SIGALRM产生,中断发生,代码进入信号处理程序,即timeout_signal_handler; Linux上的实现是当进入处理程序时,内核会自动屏蔽对应的信号(SIGALRM)以及此时act.sa_mask字段中的所有信号;在离开 handler后,内核取消这些信号的屏蔽。
* 问题在于我们是通过longjmp调用离开handler的,longjmp对应的invoke_env是否在setjmp时保存了这些被屏蔽的信号呢? 答案是:在Linux上没有。这样longjmp跳到setjmp后也就无法恢复对SIGALRM的屏蔽;当再次产生SIGALRM信号时,程序将无法处 理,也就一直阻塞在read调用上了。

解决方法:将setjmp/longjmp替换为sigsetjmp和siglongjmp,后面这组调用在sigsetjmp时保存了屏蔽信号,这样在 siglongjmp返回时可以恢复到handler之前的信号屏蔽集合,也就是说SIGALRM恢复自由了。在Solaris 下,setjmp/longjmp是可以恢复被屏蔽的信号的。

再说说在Solaris下的情况。在Solaris下,程序在第二次SIGALRM到来之际,居然退出了,终端上显示:“闹钟信号”。这是因为在 Solaris下,通过signal函数设置信号的处理handler仅是一次性的。在应对完一次信号处理后,信号的handler被自动恢复到之前的处 理策略设置,对于SIGALRM来说,也就是程序退出。解决办法:通过多次调用signal设置handler或通过sigaction来长效设置 handler。考虑到移植性和简单性,我们选择了sigaction。在Linux平台下,signal函数底层就是用sigaction实现的,是简洁版的sigaction,因此它的设置不是一次性的,而是长效的。

二、第二版

综上问题的修改,我们有了第二版代码。

/* timeout_wrapper.h */

extern volatile int invoke_count;
extern sigjmp_buf invoke_env;

void timeout_signal_handler(int sig);
typedef void sigfunc(int sig);
sigfunc *my_signal(int signo, sigfunc* func);
#define E_CALL_TIMEOUT (-9)

#define add_timeout_to_func(func, n, interval, ret, …) \
    { \
        invoke_count = 0; \
        sigfunc *sf = my_signal(SIGALRM, timeout_signal_handler); \
        if (sf == SIG_ERR) { \
            ret = errno; \
            goto end; \
        }  \
\
        if (sigsetjmp(invoke_env, SIGALRM) != 0) { \
            if (invoke_count >= n) { \
                ret = E_CALL_TIMEOUT; \
                goto err; \
            } \
        } \
\
        alarm(interval); \
        ret = func(__VA_ARGS__);\
        alarm(0); \
err:\
        my_signal(SIGALRM, sf); \
end:\
        ;\
    }

/* timeout_wrapper.c */

volatile int invoke_count = 0;
sigjmp_buf invoke_env;

void
timeout_signal_handler(int sig)
{
    invoke_count++;
    siglongjmp(invoke_env, 1);
}

sigfunc *
my_signal(int signo, sigfunc *func)
{
    struct sigaction act, oact;

    act.sa_handler = func;
    sigemptyset(&act.sa_mask);
    act.sa_flags = 0;
    if (signo == SIGALRM) {
#ifdef SA_INTERRUPT
        act.sa_flags |= SA_INTERRUPT;
#endif
    } else {
#ifdef SA_RESTART
        act.sa_flags |= SA_RESTART;
#endif
    }
    if (sigaction(signo, &act, &oact) < 0)
        return SIG_ERR;
    return oact.sa_handler;
}

这里从《Unix高级环境编程》中借了一段代码,就是那段my_signal的实现。这样修改后,程序在Linux和Solaris下工作都蛮好的。但目前唯一的缺点就是超时时间粒度太大,alarm仅支持秒级定时器,我们至少要支持毫秒级,接下来我们要换掉alarm。

三、第三版

setitimer与alarm是同出一门,共享一个定时器的。不同的是setitimer可以支持到微秒级的粒度,因此我们就用setitimer替换alarm,第三版仅改动了add_timeout_to_func这个宏:

#define add_timeout_to_func(func, n, interval, ret, …) \
    { \
        invoke_count = 0; \
        sigfunc *sf = my_signal(SIGALRM, timeout_signal_handler); \
        if (sf == SIG_ERR) { \
            ret = errno; \
            goto end; \
        }  \
\
        if (sigsetjmp(invoke_env, SIGALRM) != 0) { \
            if (invoke_count >= n) { \
                ret = E_CALL_TIMEOUT; \
                goto err; \
            } \
        } \
\
        struct itimerval tick;  \
        struct itimerval oldtick;  \
        tick.it_value.tv_sec = interval/1000; \
        tick.it_value.tv_usec = (interval%1000) * 1000; \
        tick.it_interval.tv_sec = interval/1000; \
        tick.it_interval.tv_usec = (interval%1000) * 1000; \
\
        if (setitimer(ITIMER_REAL, &tick, &oldtick) < 0) { \
            ret = errno; \
            goto err; \
        } \
\
        ret = func(__VA_ARGS__);\
        setitimer(ITIMER_REAL, &oldtick, NULL); \
err:\
        my_signal(SIGALRM, sf); \
end:\
        ;\
    }

至此,一个为阻塞型函数调用添加的超时机制的雏形基本实现完毕了,但要放在产品代码里还需要更细致的打磨。至少目前只是在单进程单线程中跑过,而且要求每个函数中只能调用add_timeout_to_func一次,否则就会有编译错误。

以上完整代码我都放到github上的experiments repository中了,有兴趣的朋友可以下载细看。




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:


以太币:


如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多