标签 Array 下的文章

Go语言的“黑暗角落”:盘点学习Go语言时遇到的那些陷阱[译](第一部分)

本文翻译自Rytis Bieliunas的文章《Darker Corners of Go》

译注:若干年前,Kyle Quest曾发过一篇名为“50 Shades of Go: Traps, Gotchas, and Common Mistakes for New Golang Devs”的文章,仿效著名的《C Traps and Pitfalls》编写了50条Go语言的陷阱与缺陷,一时在Go社区广为流传。而本文是又一篇较为系统总结Go陷阱的文章,不同于50 Shades of Go的按初中高级陷阱的分类方式,本文是按类别对Go陷阱做讲解。

0. 简介

这是什么

当初学习Go的时候,我只是看了一些入门书和Go语言规范。当时,我已经掌握了其他几种编程语言,然而感觉自己对Go的了解还不够,无法进行实际工作。我觉得自己对Go世界的运作方式了解地还不够深入,我可能需要趟过一些Go陷阱后才会建立起使用Go的信心。

我是对的

虽然简单是Go语言设计哲学的核心,但当你深入使用Go时,你就会发现Go语言在用它颇具创意的方式啪啪打你的脸。

由于现在我已经用Go进行了几年的生产应用,在趟过很多“坑”之后,我想我应该将这些“遇坑与填坑”的情况整理出来献给那些Go语言的新手同学们。

我的目标是在一篇文章中收集Go中各种可能会让新开发者感到惊讶的东西,也许会对Go中比较特别的功能有所启发。我希望这能为读者节省大量的Google搜索和调试时间,并可能避免一些昂贵的错误。

我认为这篇文章对于那些至少已经知道Go语法的人来说是最有用的。如果你是一个中级或有经验的程序员,已经懂得其他编程语言,并希望学习Go,那就最好不过了。

如果你发现错误或者我没有包含你最喜欢的Go surprise,请告诉我:rytbiel@gmail.com。

非常感谢Vytautas Shaltenis的帮助,让这篇文章变得更好。

1. 代码格式化(Code formatting)

1) gofmt

在Go中,gofmt工具将许多预定好的代码格式“强加”于你的代码。gofmt对源文件进行机械性的更改,例如对包导入声明进行排序和对代码应用缩进等。这是自从切片面包诞生以来最好的事情,因为它可以节省开发人员大量无关紧要的争论所消耗的工作量。例如,它使用制表符来缩进,使用空格来对齐– 对代码风格的争论到此为止。

您可以完全不使用gofmt工具,但如果使用它,你却无法将对其所实施的代码格式化样式进行配置。该工具完全没有提供任何代码格式化选项,这才是重点。提供一种“足够好”的统一代码格式样式,它可能是没人喜欢的样式,但是Go开发人员认为统一胜于完美

共享样式和自动代码格式化的好处包括:

  • 无需花费任何时间在代码审查上来解决格式问题。
  • 它可以使您免于与一起工作的同事争论大括号到底放在哪里,缩进使用制表符还是空格。你所有的激情和精力都可以得到更有效的利用。
  • 代码更易于编写:像代码格式这样的次要工作已经有工具帮你完成。
  • 代码更容易阅读:您无需从心理上解析你不熟悉的别人的代码格式。

大多数流行的IDE都具有Go插件,这些插件会在保存源文件时自动运行gofmt。

诸如goformat之类的第三方工具允许你在Go中使用自定义代码样式格式。但你真的希望那样做么?

2) 长代码行

Gofmt不会尝试为您分解很长的代码。有诸如golines之类的第三方工具可以做到这一点。

3) 大括号

在Go中,必须在行的末尾放置大括号。有趣的是,这不是gofmt强制执行的,而是Go词法分析器实现方式的副作用。有或没有gofmt,都不能将大括号放在新行上。

package main

// missing function body
func main()
// syntax error: unexpected semicolon or newline before {
{
}

// all good!
func main() {
}

4) 多行声明中的逗号

在初始化切片、数组、map或结构体时,Go要求在换行符前加逗号。在多种语言中都允许使用尾部逗号,并且在某些样式指南中鼓励使用逗号。在Go中,它们是强制性的。这样在重新排列行或添加新行时就无需修改不相关的行。这也意味着更少的代码审核差异噪声。

// all of these are OK
a := []int{1, 2}

b := []int{1, 2,}

c := []int{
    1,
    2}

d := []int{
    1,
    2,
}

// syntax error without trailing comma
e := []int{
    1,
    // syntax error: unexpected newline, expecting comma or }
    2
}

结构体也使用相同规则:

type s struct {
    One int
    Two int
}

f := s{
    One: 1,
    // syntax error: unexpected newline, expecting comma or }
    Two: 2
}

2. 包导入(Import)

1) 未使用的导入包

未使用导入包的Go程序无法编译。这是该语言的故意设定,因为导入包会降低编译器的速度。在大型程序中,未使用的导入包可能会对编译时间产生重大影响。

为了使编译器在开发过程中感到happy^_^,您可以通过以下方式引用该软件包:

package main

import (
    "fmt"
    "math"
)

// Reference unused package
var _ = math.Round 

func main() {
    fmt.Println("Hello")
}

2) goimports

更好的解决方案是使用goimports工具。goimports会为您删除未引用的导入包。更好的是,它尝试自动查找并添加缺失的包导入。

package main

import "math" // imported and not used: "math"

func main() {
    fmt.Println("Hello") // undefined: fmt
}

运行goimports之后:

./goimports main.go
package main

import "fmt"

func main() {
    fmt.Println("Hello")
}

大多数流行的IDE的Go插件在保存源文件时会自动运行goimports。

3) 下划线导入

以下划线方式导入包仅是出于对其副作用的依赖。这意味着它将创建程序包级变量并运行包的init函数

package package1

func package1Function() int {
    fmt.Println("Package 1 side-effect")
    return 1
}

var globalVariable = package1Function()

func init() {
    fmt.Println("Package 1 init side effect")
}

导入package1:

package package2

import _ package1

这将打印消息并初始化globalVariable:

Package 1 side-effect
Package 1 init side effect

多次导入一个包(例如,在主程序包以及在其主要引用的程序包中)只运行一次该包的init函数。

下划线导入在Go运行时库中有使用。例如,导入net/http/pprof调用其init函数,该函数公开HTTP端点,这些端点可以提供有关应用程序的调试信息:

import _ "net/http/pprof"

4) 点导入

点导入允许在不使用限定符的情况下访问导入包中的标识符:

package main

import (
    "fmt"
    . "math"
)

func main() {
    fmt.Println(Sin(3)) // references math.Sin
}

是否应从Go语言中完全删除点导入一直存在公开辩论。Go团队不建议在测试包以外的任何地方使用它们:

因为它使得程序可读性大大下降,我们很难知道一个Quux之类的名称是当前程序包中还是导入程序包中的顶层标识符 – https://golang.org/doc/faq

另外,如果您使用go-lint工具,那么在测试文件之外使用点导入时,它会显示警告,并且您无法轻易将其关闭。

Go团队建议在测试中使用点可以避免包的循环依赖:

// foo_test package tests for foo package
package foo_test

import (
    "bar/testutil" // also imports "foo"
    . "foo"
)

该测试文件不能成为foo包的一部分,因为它引用了bar/testutil,而bar/testutil又引用了foo并导致了循环依赖。

在这种情况下,首先要考虑的是,是否有一种更好的方法来构建可避免循环依赖的软件包。将bar/testutil使用的内容从foo移动到foo和bar/testutil都可以导入的第三个包可能更好,这样就可以将测试以正常方式写在foo包中。

如果重构没有意义,并且使用点导入将测试移至单独的程序包,则foo_test程序包至少可以假装为foo程序包的一部分。注意,它无法访问foo包的未导出类型和函数。

可以说,在域特定语言编程中,点导入是一个很好的用例。例如,Goa框架将其用于配置。如果没有点导入,它看起来不会很好:

package design

import . "goa.design/goa/v3/dsl"

// API describes the global properties of the API server.
var _ = API("calc", func() {
    Title("Calculator Service")
    Description("HTTP service for adding numbers, a goa teaser")
    Server("calc", func() {
        Host("localhost", func() { URI("http://localhost:8088") })
    })
})

3. 变量

1) 未使用的变量

带有未使用变量的Go程序无法编译:

如果存在未使用的变量,则可能表示有bug[…] Go拒绝使用未使用的变量或导入来编译程序,并且不会为了短期的便利性去换取更高的构建速度和程序的清晰性。- https://golang.org/doc/faq

该规则的例外是全局变量和函数参数:

package main

var unusedGlobal int // this is ok

func f1(unusedArg int) { // unused function arguments are also ok
    // error: a declared but not used
    a, b := 1,2
    // b is used here, but a is only assigned to, does not count as “used”
    a = b
}

2) 短变量声明

声明变量的简写形式仅在函数内部起作用:

package main

v1 := 1 // error: non-declaration statement outside function body
var v2 = 2 // this is ok

func main() {
    v3 := 3 // this is ok
    fmt.Println(v3)
}

设置结构体字段值时,它也不起作用:

package main

type myStruct struct {
    Field int
}

func main() {
    var s myStruct

    // error: non-name s.Field on the left side of :=
    s.Field, newVar := 1, 2 

    var newVar int
    s.Field, newVar = 1, 2 // this is actually ok
}

3) 变量遮蔽

令人遗憾的是,Go中允许使用变量遮蔽。您需要经常注意这一点,因为它可能导致难以发现的问题。发生这种情况是因为,为方便起见,如果至少有一个变量是新变量,Go允许使用短变量声明形式:

package main

import "fmt"

func main() {
    v1 := 1
    // v1 is not actually redeclared here, only gets a new value set
    v1, v2 := 2, 3
    fmt.Println(v1, v2) // prints 2, 3
}

但是,如果声明在另一个代码块内部,则它将声明一个新变量,从而可能导致严重的错误:

package main

import "fmt"

func main() {
    v1 := 1
    if v1 == 1 {
        v1, v2 := 2, 3
        fmt.Println(v1, v2) // prints 2, 3
    }
    fmt.Println(v1) // prints 1 !
}

一个更现实的示例,假设您有一个返回错误的函数:

package main

import (
    "errors"
    "fmt"
)

func func1() error {
   return nil
}

func errFunc1() (int, error) {
   return 1, errors.New("important error")
}

func returnsErr() error {
    err := func1()
    if err == nil {
        v1, err := errFunc1()
        if err != nil {
            fmt.Println(v1, err) // prints: 1 important error
        }
    }
    return err // this returns nil!
}

func main() {
    fmt.Println(returnsErr()) // prints nil
}

一种解决方案是不要在嵌套代码块内使用短变量声明:

func returnsErr() error {
    err := func1()
    var v1 int

    if err == nil {
        v1, err = errFunc1()
        if err != nil {
            fmt.Println(v1, err) // prints: 1 important error
        }
    }

    return err // returns "important error"
}

或者在上述示例的情况下,更好的方法是尽早退出:

func returnsErr() error {
    err := func1()
    if err != nil {
        return err
    }

    v1, err := errFunc1()
    if err != nil {
        fmt.Println(v1, err) // prints: 1 important error
        return err
    }

    return nil
}

也有可以提供帮助的工具。在go vet工具中曾有一个实验性的变量遮蔽检测,后来将其删除。在撰写本文时,这是您可以安装和运行该工具的方式:

go get -u golang.org/x/tools/go/analysis/passes/shadow/cmd/shadow
go vet -vettool=$(which shadow)

打印:

.\main.go:20:7: declaration of "err" shadows declaration at line 17

4. 运算符

1) 运算符优先级

Go运算符的优先级与其他语言不同:

Precedence   Operator
5            * / % << >> & &^
4            + - | ^
3            == != < <= > >=
2            &&
1            ||

将其与基于C的语言进行比较:

Precedence   Operator
10           *, /, %
9            +, -
8            <<, >>
7            <, <=, >, >=
6            ==, !=
5            &
4            ^
3            |
2            &&
1            ||

对于相同的表达式,这可能导致不同的结果:

In Go: 1 << 1 + 1 // (1<<1)+1 = 3
In C: 1 << 1 + 1 // 1<<(1+1) = 4

2) 自增和自减

与许多其他语言不同,Go没有前缀自增或自减运算符:

var i int
++i // syntax error: unexpected ++, expecting }
--i // syntax error: unexpected --, expecting }

尽管Go确实具有这些运算符的后缀版本,但Go不允许在表达式中使用它们:

slice := []int{1,2,3}
i := 1
slice[i++] = 0 // syntax error: unexpected ++, expecting :

3) 三元运算符

Go语言不支持三元运算符,像下面这样的代码:

result := a ? b : c

在Go中没有,你也不要费力寻找。您必须使用if-else代替。Go语言设计人员认为此运算符经常导致难看的代码,最好不要使用它。

4) 按位非

在Go中,XOR运算符\^被用作一元NOT运算符,而不是像许多其他语言使用〜符号。

In Go: ^1 // -2
In C: ~1 // -2

用于二元计算是,XOR运算符仍用作XOR(异或)运算符。

3^1 // 2

5.常量

1) iota

iota开始在Go中进行常量编号。但它并不非期望的“从零开始”,它是当前const块中常量的索引:

const (
    myconst = "c"
    myconst2 = "c2"
    two = iota // 2
)

两次使用iota不会重置编号:

const (
    zero = iota // 0
    one // 1
    two = iota // 2
)

6. 切片和数组

1) 切片和数组

在Go中,切片和数组的用途相似。它们的声明方式几乎相同:

package main

import "fmt"

func main() {
    slice := []int{1, 2, 3}
    array := [3]int{1, 2, 3}
    // let the compiler work out array length
    // this will be an equivalent of [3]int
    array2 := [...]int{1, 2, 3}
    fmt.Println(slice, array, array2)
}
[1 2 3] [1 2 3] [1 2 3]

切片感觉像是在顶部具有有用功能的数组。他们在实现的内部使用指向数组的指针。但是,切片要方便得多,以至于我们很少在Go中直接使用数组。

2) 数组

数组是有着固定大小内存的一组同类型元素的集合。不同长度的数组被认为是不同的不兼容类型。

与C语言不同,创建数组时,Go会将数组元素初始化为零值,因此我们无需再显式地执行此初始化操作。另外,与C不同的是,Go数组是值类型,它不是指向内存块第一个元素的指针。如果将数组传递给函数,则将复制整个数组。您仍然可以传递指向数组的指针以使其不被复制。

3) 切片

切片是数组段的描述符。这是一个非常有用的数据结构,但可能有点不寻常。有几种可以让你掉入坑中的场景,但如果您知道切片的内部工作原理,则可以避免这些“坑”。这是Go源代码中切片的实际定义:

type slice struct {
    array unsafe.Pointer
    len   int
    cap   int
}

Slice本身是一个值类型,但它使用指针引用它使用的数组。与数组不同,如果将切片传递给函数,则会获得数组指针,len和cap属性的副本(上图中的第一个块),但是数组本身的数据不会被复制,切片的两个副本都指向同一数组。当您“切片”一个切片时,也会发生同样的事情。Go会创建一个新的切片,该切片仍指向相同的数组:

package main

import "fmt"

func f1(s []int) {
    // slicing the slice creates a new slice
    // but does not copy the array data
    s = s[2:4]
    // modifying the sub-slice
    // changes the array of slice in main function as well
    for i := range s {
        s[i] += 10
    }
    fmt.Println("f1", s, len(s), cap(s))
}

func main() {
    s := []int{1, 2, 3, 4, 5}
    // passing a slice as an argument
    // makes a copy of the slice properties (pointer, len and cap)
    // but the copy shares the same array
    f1(s)
    fmt.Println("main", s, len(s), cap(s))
}

f1 [13 14] 2 3
main [1 2 13 14 5] 5 5

如果您不知道哪个分片,则可以假设它是一个值类型,并且感到惊讶的是f1“破坏了”main中切片中的数据。

4) 获取包括其数据的切片的副本

要获取切片及其数据的副本,您需要做一些工作。您可以将元素手动复制到新切片或使用复制(copy)或追加(append):

package main

import "fmt"

func f1(s []int) {
    s = s[2:4]
    s2 := make([]int, len(s))
    copy(s2, s)

    // or if you prefer less efficient, but more concise version:
    // s2 := append([]int{}, s[2:4]...)

    for i := range s2 {
        s2[i] += 10
    }

    fmt.Println("f1", s2, len(s2), cap(s2))
}

func main() {
    s := []int{1, 2, 3, 4, 5}
    f1(s)
    fmt.Println("main", s, len(s), cap(s))
}

f1 [13 14] 2 3
main [1 2 3 4 5] 5 5

5) 使用append扩充切片

切片的所有副本都共享同一数组,直到他们不这样做。切片最有用的属性是它可以为您自动管理数组的增长。当它需要超过现有数组容量时,它会分配一个全新的数组。如果您希望切片的两个副本共享数组,那么这也可能是陷阱:

package main

import "fmt"

func main() {
    // make a slice with length 3 and capacity 4
    s := make([]int, 3, 4)

    // initialize to 1,2,3
    s[0] = 1
    s[1] = 2
    s[2] = 3

    // capacity of the array is 4
    // adding one more number fits in the initial array
    s2 := append(s, 4)

    // modify the elements of the array
    // s and s2 still share the same array
    for i := range s2 {
        s2[i] += 10
    }

    fmt.Println(s, len(s), cap(s))    // [11 12 13] 3 4
    fmt.Println(s2, len(s2), cap(s2)) // [11 12 13 14] 4 4

    // this append grows the array past its capacity
    // new array must be allocated for s3
    s3 := append(s2, 5)

    // modify the elements of the array to see the result
    for i := range s3 {
        s3[i] += 10
    }

    fmt.Println(s, len(s), cap(s)) // still the old array [11 12 13] 3 4
    fmt.Println(s2, len(s2), cap(s2)) // the old array [11 12 13 14] 4 4

    // array was copied on last append [21 22 23 24 15] 5 8
    fmt.Println(s3, len(s3), cap(s3))
}

6) nil切片

无需检查切片是否为nil值,也不必对其初始化。len,cap和append等功能在nil slice上同样可以正常工作:

package main

import "fmt"

func main() {
    var s []int // nil slice
    fmt.Println(s, len(s), cap(s)) // [] 0 0
    s = append(s, 1)
    fmt.Println(s, len(s), cap(s)) // [1] 1 1
}

空切片(empty slice)与nil切片不是同一回事:

package main

import "fmt"

func main() {
    var s []int // this is a nil slice
    s2 := []int{} // this is an empty slice

    // looks like the same thing here:
    fmt.Println(s, len(s), cap(s)) // [] 0 0
    fmt.Println(s2, len(s2), cap(s2)) // [] 0 0

    // but s2 is actually allocated somewhere
    fmt.Printf("%p %p", s, s2) // 0x0 0x65ca90
}

如果您非常在意性能和内存使用情况,那么初始化一个空切片可能不如使用nil切片理想。

7) make陷阱

要创建一个新的切片,可以将make与切片类型以及切片的初始长度和容量一起使用。容量参数是可选的:

func make([]T, len, cap) []T

这样做太简单了:

package main

import (
    "fmt"
)

func main() {
    s := make([]int, 3)
    s = append(s, 1)
    s = append(s, 2)
    s = append(s, 3)
    fmt.Println(s)
}

[0 0 0 1 2 3]

不,这永远不会发生在我身上,我知道make创建切片的第二个参数是长度,而不是容量,我听到你说……

8) 未使用的切片的数组数据

由于对数组进行切片会创建一个新的切片,但会共享底层数组,因此有可能在内存中保留比你预期更多的数据。这是一个愚蠢的例子:

package main

import (
    "bytes"
    "fmt"
    "io/ioutil"
    "os"
)

func getExecutableFormat() []byte {
    // read our own executable file into memory
    bytes, err := ioutil.ReadFile(os.Args[0])
    if err != nil {
        panic(err)
    }
    return bytes[:4]
}

func main() {
    format := getExecutableFormat()
    if bytes.HasPrefix(format, []byte("ELF")) {
        fmt.Println("linux executable")
    } else if bytes.HasPrefix(format, []byte("MZ")) {
        fmt.Println("windows executable")
    }
}

在上面的代码中,只要该format变量在范围内并且不能被垃圾回收,则整个可执行文件(可能几兆字节的数据)将必须保留在内存中。要修复它,请复制实际需要的字节。

9) 多维切片

目前,Go中没有这样的东西。可能某天会有,但是此时此刻您需要自己计算元素索引来手动将一维切片用作多维切片,或者使用“锯齿状”切片(锯齿状切片是切片的切片):

package main

import "fmt"

func main() {
    x := 2
    y := 3
    s := make([][]int, y)
    for i := range s {
        s[i] = make([]int, x)
    }
    fmt.Println(s)
}

[[0 0] [0 0] [0 0]]

第二部分见下面链接:


“Gopher部落”知识星球正式转正(从试运营星球变成了正式星球)!“gopher部落”旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,>每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需>求!部落目前虽小,但持续力很强。在2021年上半年,部落将策划两个专题系列分享,并且是部落独享哦:

  • Go技术书籍的书摘和读书体会系列
  • Go与eBPF系列

欢迎大家加入!

Go技术专栏“改善Go语⾔编程质量的50个有效实践”正在慕课网火热热销中!本专栏主要满足>广大gopher关于Go语言进阶的需求,围绕如何写出地道且高质量Go代码给出50条有效实践建议,上线后收到一致好评!欢迎大家订
阅!

img{512x368}

我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网热卖>中,欢迎小伙伴们订阅学习!

img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。2020年4月8日,中国三大电信运营商联合发布《5G消息白皮书》,51短信平台也会全新升级到“51商用消息平台”,全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博:https://weibo.com/bigwhite20xx
  • 微信公众号:iamtonybai
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • “Gopher部落”知识星球:https://public.zsxq.com/groups/51284458844544

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

写Go代码时遇到的那些问题[第3期]

我有一个习惯,那就是随时记录下编程过程中遇到的问题(包括问题现场、问题起因以及对问题的分析),并喜欢阶段性的对一段时间内的编码过程的得与失进行回顾和总结。内容可以包括:对编程语法的新认知、遇坑填坑的经历、一些让自己豁然开朗的小tip/小实践等。记录和总结的多了,感觉有价值的,就成文发在博客上的;一些小的点,或是还没有想清楚的事情,或思路没法结构化统一的,就放在资料库里备用。“写Go代码时遇到的那些问题”这个系列也是基于这个思路做的。

在这一篇中,我把“所遇到的问题”划分为三类:语言类、库与工具类、实践类,这样应该更便于大家分类阅读和理解。另外借这篇文章,我们先来看一下Go语言当前的State,资料来自于twitter、redditgolang-dev forum、github上golang项目的issue/cl以及各种gophercon的talk资料。

零. Go语言当前状态

1. vgo

Go 1.10在中国农历春节期间正式发布。随后Go team进入了Go 1.11的开发周期

在2017年的Go语言用户调查报告结果中,缺少良好的包管理工具以及Generics依然是Gopher面临的最为棘手的挑战和难题的Top2,Go team也终于开始认真对待这两个问题了,尤其是包依赖管理的问题。在今年2月末,Russ Cox在自己的博客上连续发表了七篇博文,详细阐述了vgo – 带版本感知和支持的Go命令行工具的设计思路和实现方案,并在3月末正式提交了”versioned-go proposal“。

目前相对成熟的包管理方案是:

"语义化版本"
+manifest文件(手工维护的依赖约束描述文件)
+lock文件(工具自动生成的传递依赖描述文件)
+版本选择引擎工具(比如dep中的gps - Go Packaging Solver)

与之相比,vgo既有继承,更有创新。继承的是对语义化版本的支持,创新的则是semantic import versioning最小版本选择minimal version selection等新机制,不变的则是对Go1语法的兼容。按照Russ Cox的计划,Go 1.11很可能会提供一个试验性的vgo实现(当然vgo所呈现的形式估计是merge到go tools中),让广大gopher试用和反馈,然后会像vendor机制那样,在后续Go版本中逐渐成为默认选项。

2. wasm porting

知名开源项目gopherjs的作者Richard Musiol上个月提交了一个proposal: WebAssembly architecture for Go,主旨在于让Gopher也可以用Go编写前端代码,让Go编写的代码可以在浏览器中运行。当然这并不是真的让Go能像js那样直接运行于浏览器或nodejs上,而是将Go编译为WebAssembly,wasm中间字节码,再在浏览器或nodejs初始化的运行环境中运行。这里根据自己的理解粗略画了一幅二进制机器码的go app与中间码的wasm的运行层次对比图,希望对大家有用:

img{512x368}

wasm porting已经完成了第一次commit ,很大可能会随着go1.11一并发布第一个版本。

3. 非协作式的goroutine抢占式调度

当前goroutine“抢占式”调度依靠的是compiler在函数中自动插入的“cooperative preemption point”来实现的,但这种方式在使用过程中依然有各种各样的问题,比如:检查点的性能损耗、诡异的全面延迟问题以及调试上的困难。近期负责go runtime gc设计与实现的Austin Clements提出了一个proposal:non-cooperative goroutine preemption ,该proposal将去除cooperative preemption point,而改为利用构建和记录每条指令的stack和register map的方式实现goroutine的抢占, 该proposal预计将在go 1.12中实现。

4. Go的历史与未来

GopherConRu 2018大会上,来自Go team的核心成员Brad Fitzpatrick做了“Go的历史与未来”的主题演讲 ,Bradfitz“爆料”了关于Go2的几个可能,考虑到Bradfitz在Go team中的位置,这些可能性还是具有很大可信度的:

1). 绝不像Perl6和Python3那样分裂社区
2). Go1的包可以import Go2的package
3). Go2很可能加入Generics,Ian Lance Taylor应该在主导该Proposal
4). Go2在error handling方面会有改进,但不会是try--catch那种形式
5). 相比于Go1,Go2仅会在1-3个方面做出重大变化
6). Go2可能会有一个新的标准库,并且该标准库会比现有的标准库更小,很多功能放到标准库外面
7). 但Go2会在标准库外面给出最流行、推荐的、可能认证的常用包列表,这些在标准库外面的包可以持续更新,而不像那些在标准库中的包,只能半年更新一次。

一. 语言篇

1. len(channel)的使用

len是Go语言的一个built-in函数,它支持接受array、slice、map、string、channel类型的参数,并返回对应类型的”长度” – 一个整型值:

len(s)   

如果s是string,len(s)返回字符串中的字节个数
如何s是[n]T, *[n]T的数组类型,len(s)返回数组的长度n
如果s是[]T的Slice类型,len(s)返回slice的当前长度
如果s是map[K]T的map类型,len(s)返回map中的已定义的key的个数
如果s是chan T类型,那么len(s)返回当前在buffered channel中排队(尚未读取)的元素个数

不过我们在代码经常见到的是len函数针对数组、slice、string类型的调用,而len与channel的联合使用却很少。那是不是说len(channel)就不可用了呢?我们先来看看len(channel)的语义。

  • 当channel为unbuffered channel时,len(channel)总是返回0;
  • 当channel为buffered channel时,len(channel)返回当前channel中尚未被读取的元素个数。

这样一来,所谓len(channel)中的channel就是针对buffered channel。len(channel)从语义上来说一般会被用来做“判满”、”判有”和”判空”逻辑:

// 判空

if len(channel) == 0 {
    // 这时:channel 空了 ?
}

// 判有

if len(channel) > 0 {
    // 这时:channel 有数据了 ?
}

// 判满
if len(channel) == cap(channel) {
    // 这时:   channel 满了 ?
}

大家看到了,我在上面代码中注释:“空了”、“有数据了”和“满了”的后面打上了问号!channel多用于多个goroutine间的通讯,一旦多个goroutine共同读写channel,len(channel)就会在多个goroutine间形成”竞态条件”,单存的依靠len(channel)来判断队列状态,不能保证在后续真正读写channel的时候channel状态是不变的。以判空为例:

img{512x368}

从上图可以看到,当goroutine1使用len(channel)判空后,便尝试从channel中读取数据。但在真正从Channel读数据前,另外一个goroutine2已经将数据读了出去,goroutine1后面的读取将阻塞在channel上,导致后面逻辑的失效。因此,为了不阻塞在channel上,常见的方法是将“判空与读取”放在一起做、将”判满与写入”一起做,通过select实现操作的“事务性”:

//writing-go-code-issues/3rd-issue/channel_len.go/channel_len.go.go
func readFromChan(ch <-chan int) (int, bool) {
    select {
    case i := <-ch:
        return i, true
    default:
        return 0, false // channel is empty
    }
}

func writeToChan(ch chan<- int, i int) bool {
    select {
    case ch <- i:
        return true
    default:
        return false // channel is full
    }
}

我们看到由于用到了Select-default的trick,当channel空的时候,readFromChan不会阻塞;当channel满的时候,writeToChan也不会阻塞。这种方法也许适合大多数的场合,但是这种方法有一个“问题”,那就是“改变了channel的状态”:读出了一个元素或写入了一个元素。有些时候,我们不想这么做,我们想在不改变channel状态下单纯地侦测channel状态!很遗憾,目前没有哪种方法可以适用于所有场合。但是在特定的场景下,我们可以用len(channel)实现。比如下面这个场景:

img{512x368}

这是一个“多producer + 1 consumer”的场景。controller是一个总控协程,初始情况下,它来判断channel中是否有消息。如果有消息,它本身不消费“消息”,而是创建一个consumer来消费消息,直到consumer因某种情况退出,控制权再回到controller,controller不会立即创建new consumer,而是等待channel下一次有消息时才创建。在这样一个场景中,我们就可以使用len(channel)来判断是否有消息。

2. 时间的格式化输出

时间的格式化输出是日常编程中经常遇到的“题目”。以前使用C语言编程时,用的是strftime。我们来回忆一下c的代码:

// writing-go-code-issues/3rd-issue/time-format/strftime_in_c.c
#include <stdio.h>
#include <time.h>

int main() {
        time_t now = time(NULL);

        struct tm *localTm;
        localTm = localtime(&now);

        char strTime[100];
        strftime(strTime, sizeof(strTime),  "%Y-%m-%d %H:%M:%S", localTm);
        printf("%s\n", strTime);

        return 0;
}

这段c代码输出结果是:

2018-04-04 16:07:00

我们看到strftime采用“字符化”的占位符(诸如:%Y、%m等)“拼”出时间的目标输出格式布局(如:”%Y-%m-%d %H:%M:%S”),这种方式不仅在C中采用,很多其他主流编程语言也采用了该方案,比如:shell、pythonrubyjava等,这似乎已经成为了各种编程语言在时间格式化输出的标准。这些占位符对应的字符(比如Y、M、H)是对应英文单词的头母,因此相对来说较为容易记忆。

但是如果你在Go中使用strftime的这套“标准”,看到输出结果的那一刻,你肯定要“骂娘”!

// writing-go-code-issues/3rd-issue/time-format/timeformat_in_c_way.go
package main

import (
    "fmt"
    "time"
)

func main() {
    fmt.Println(time.Now().Format("%Y-%m-%d %H:%M:%S"))
}

上述go代码输出结果如下:

%Y-%m-%d %H:%M:%S

Go居然将“时间格式占位符字符串”原封不动的输出了!

这是因为Go另辟了蹊径,采用了不同于strftime的时间格式化输出的方案。Go的设计者主要出于这样的考虑:虽然strftime的单个占位符使用了对应单词的首字母的形式,但是但真正写起代码来,不打开strftime函数的manual或查看网页版的strftime助记符说明,很难真的拼出一个复杂的时间格式。并且对于一个”%Y-%m-%d %H:%M:%S”的格式串,不对照文档,很难在大脑中准确给出格式化后的时间结果,比如%Y和%y有何不同、%M和%m又有何差别呢?

Go语言采用了更为直观的“参考时间(reference time)”替代strftime的各种标准占位符,使用“参考时间”构造出来的“时间格式串”与最终输出串是“一模一样”的,这就省去了程序员再次在大脑中对格式串进行解析的过程:

格式串:"2006年01月02日 15时04分05秒"

=>

输出结果:2018年04月04日 18时13分08秒

标准的参考时间如下:

2006-01-02 15:04:05 PM -07:00 Jan Mon MST

这个绝对时间本身并没有什么实际意义,仅是出于“好记”的考虑,我们将这个参考时间换为另外一种时间输出格式:

01/02 03:04:05PM '06 -0700

我们看出Go设计者的“用心良苦”,这个时间其实恰好是将助记符从小到大排序(从01到07)的结果,可以理解为:01对应的是%M, 02对应的是%d等等。下面这幅图形象地展示了“参考时间”、“格式串”与最终格式化的输出结果之间的关系:

img{512x368}

就我个人使用go的经历来看,我在做时间格式化输出时,尤其是构建略微复杂的时间格式输出时,也还是要go doc time包或打开time包的web手册的。从社区的反馈来看,很多Gopher也都有类似经历,尤其是那些已经用惯了strftime格式的gopher。甚至有人专门做了“Fucking Go Date Format”页面,来帮助自动将strftime使用的格式转换为go time的格式。

下面这幅cheatsheet也能提供一些帮助(由writing-go-code-issues/3rd-issue/time-format/timeformat_cheatsheet.go输出生成):

img{512x368}

二. 库与工具篇

1. golang.org/x/text/encoding/unicode遇坑一则

gocmpp这个项目中,我用到了unicode字符集转换:将utf8转换为ucs2(utf16)、ucs2转换为utf8、utf8转为GB18030等。这些转换功能,我是借助golang.org/x/text这个项目下的encoding/unicode和transform实现的。x/text是golang官方维护的text处理的工具包,其中包含了对unicode字符集的相关操作。

要实现一个utf8到ucs2(utf16)的字符集转换,只需像如下这样实现即可(这也是我的最初实现):

func Utf8ToUcs2(in string) (string, error) {
    if !utf8.ValidString(in) {
        return "", ErrInvalidUtf8Rune
    }

    r := bytes.NewReader([]byte(in))

    //UTF-16 bigendian, no-bom
    t := transform.NewReader(r, unicode.All[1].NewEncoder())
    out, err := ioutil.ReadAll(t)
    if err != nil {
        return "", err
    }
    return string(out), nil
}

这里要注意是unicode.All这个切片保存着UTF-16的所有格式:

var All = []encoding.Encoding{
    UTF16(BigEndian, UseBOM),
    UTF16(BigEndian, IgnoreBOM),
    UTF16(LittleEndian, IgnoreBOM),
}

这里我最初我用的是All[1],即UTF16(BigEndian, IgnoreBOM),一切都是正常的。

但就在年前,我将text项目更新到最新版本,然后发现单元测试无法通过:

--- FAIL: TestUtf8ToUcs2 (0.00s)
    utils_test.go:58: The first char is fe, not equal to expected 6c
FAIL
FAIL    github.com/bigwhite/gocmpp/utils    0.008s

经查找发现:text项目的golang.org/x/text/encoding/unicode包做了不兼容的修改,上面那个unicode.All切片变成了下面这个样子:

// All lists a configuration for each IANA-defined UTF-16 variant.
var All = []encoding.Encoding{
    UTF8,
    UTF16(BigEndian, UseBOM),
    UTF16(BigEndian, IgnoreBOM),
    UTF16(LittleEndian, IgnoreBOM),
}

All切片在最前面插入了一个UTF8元素,这样导致我的代码中原本使用的 UTF16(BigEndian, IgnoreBOM)变成了UTF16(BigEndian, UseBOM),test不过也就情有可原了。

如何改呢?这回儿我直接使用UTF16(BigEndian, IgnoreBOM),而不再使用All切片了:

func Utf8ToUcs2(in string) (string, error) {
    if !utf8.ValidString(in) {
        return "", ErrInvalidUtf8Rune
    }

    r := bytes.NewReader([]byte(in))
    //UTF-16 bigendian, no-bom
    t := transform.NewReader(r,
            unicode.UTF16(unicode.BigEndian, unicode.IgnoreBOM).NewEncoder())
    out, err := ioutil.ReadAll(t)
    if err != nil {
        return "", err
    }
    return string(out), nil
}

这样即便All切片再有什么变动,我的代码也不会受到什么影响了。

2. logrus的非结构化日志定制输出

在该系列的第一篇文章中,我提到过使用logrus+lumberjack来实现支持rotate的logging。

默认情况下日志的输出格式是这样的(writing-go-code-issues/3rd-issue/logrus/logrus2lumberjack_default.go):

time="2018-04-05T06:08:53+08:00" level=info msg="logrus log to lumberjack in normal text formatter"

这样相对结构化的日志比较适合后续的集中日志分析。但是日志携带的“元信息(time、level、msg)”过多,并不是所有场合都倾向于这种日志,于是我们期望以普通的非结构化的日志输出,我们定制formatter:

// writing-go-code-issues/3rd-issue/logrus/logrus2lumberjack.go
func main() {
    customFormatter := &logrus.TextFormatter{
        FullTimestamp:   true,
        TimestampFormat: "2006-01-02 15:04:05",
    }
    logger := logrus.New()
    logger.Formatter = customFormatter

    rotateLogger := &lumberjack.Logger{
        Filename: "./foo.log",
    }
    logger.Out = rotateLogger
    logger.Info("logrus log to lumberjack in normal text formatter")
}

我们使用textformatter,并定制了时间戳的格式,输出结果如下:

time="2018-04-05 06:22:57" level=info msg="logrus log to lumberjack in normal text formatter"

日志仍然不是我们想要的那种。但同样的customFormatter如果输出到terminal,结果却是我们想要的:

//writing-go-code-issues/3rd-issue/logrus/logrus2tty.go

INFO[2018-04-05 06:26:16] logrus log to tty in normal text formatter

到底如何设置TextFormatter的属性才能让我们输出到lumberjack中的日志格式是我们想要的这种呢?无奈下只能挖logrus的源码了,我们找到了这段代码:

//github.com/sirupsen/logrus/text_formatter.go

// Format renders a single log entry
func (f *TextFormatter) Format(entry *Entry) ([]byte, error) {
    ... ...
    isColored := (f.ForceColors || f.isTerminal) && !f.DisableColors

    timestampFormat := f.TimestampFormat
    if timestampFormat == "" {
        timestampFormat = defaultTimestampFormat
    }
    if isColored {
        f.printColored(b, entry, keys, timestampFormat)
    } else {
        if !f.DisableTimestamp {
            f.appendKeyValue(b, "time", entry.Time.Format(timestampFormat))
        }
        f.appendKeyValue(b, "level", entry.Level.String())
        if entry.Message != "" {
            f.appendKeyValue(b, "msg", entry.Message)
        }
        for _, key := range keys {
            f.appendKeyValue(b, key, entry.Data[key])
        }
    }

    b.WriteByte('\n')
    return b.Bytes(), nil
}

我们看到如果isColored为false,输出的就是带有time, msg, level的结构化日志;只有isColored为true才能输出我们想要的普通日志。isColored的值与三个属性有关:ForceColors 、isTerminal和DisableColors。我们按照让isColored为true的条件组合重新设置一下这三个属性,因为输出到file,因此isTerminal自动为false。

//writing-go-code-issues/3rd-issue/logrus/logrus2lumberjack_normal.go
func main() {
    //    isColored := (f.ForceColors || f.isTerminal) && !f.DisableColors
    customFormatter := &logrus.TextFormatter{
        FullTimestamp:   true,
        TimestampFormat: "2006-01-02 15:04:05",
        ForceColors:     true,
    }
    logger := logrus.New()
    logger.Formatter = customFormatter

    rotateLogger := &lumberjack.Logger{
        Filename: "./foo.log",
    }
    logger.Out = rotateLogger
    logger.Info("logrus log to lumberjack in normal text formatter")
}

我们设置ForceColors为true后,在foo.log中得到了我们期望的输出结果:

INFO[2018-04-05 06:33:22] logrus log to lumberjack in normal text formatter

三. 实践篇

1. 说说网络数据读取timeout的处理 – 以SetReadDeadline为例

Go天生适合于网络编程,但网络编程的复杂性也是有目共睹的、要写出稳定、高效的网络端程序,需要的考虑的因素有很多。比如其中之一的:从socket读取数据超时的问题。

Go语言标准网络库并没有实现epoll实现的那样的“idle timeout”,而是提供了Deadline机制,我们用一副图来对比一下两个机制的不同:

img{512x368}

看上图a)和b)展示了”idle timeout”机制,所谓idle timeout就是指这个timeout是真正在没有data ready的情况的timeout(如图中a),如果有数据ready可读(如图中b),那么timeout机制暂停,直到数据读完后,再次进入数据等待的时候,idle timeout再次启动。

而deadline(以read deadline为例)机制,则是无论是否有数据ready以及数据读取活动,都会在到达时间(deadline)后的再次read时返回timeout error,并且后续的所有network read operation也都会返回timeout(如图中d),除非重新调用SetReadDeadline(time.Time{})取消Deadline或在再次读取动作前重新重新设定deadline实现续时的目的。Go网络编程一般是“阻塞模型”,那为什么还要有SetReadDeadline呢,这是因为有时候,我们要给调用者“感知”其他“异常情况”的机会,比如是否收到了main goroutine发送过来的退出通知信息

Deadline机制在使用起来很容易出错,这里列举两个曾经遇到的出错状况:

a) 以为SetReadDeadline后,后续每次Read都可能实现idle timeout

img{512x368}

在上图中,我们看到这个流程是读取一个完整业务包的过程,业务包的读取使用了三次Read调用,但是只在第一次Read前调用了SetReadDeadline。这种使用方式仅仅在Read A时实现了足额的“idle timeout”,且仅当A数据始终未ready时会timeout;一旦A数据ready并已经被Read,当Read B和Read C时,如果还期望足额的“idle timeout”那就误解了SetReadDeadline的真正含义了。因此要想在每次Read时都实现“足额的idle timeout”,需要在每次Read前都重新设定deadline。

b) 一个完整“业务包”分多次读取的异常情况的处理

img{512x368}

在这幅图中,每个Read前都重新设定了deadline,那么这样就一定ok了么?对于在一个过程中读取一个“完整业务包”的业务逻辑来说,我们还要考虑对每次读取异常情况的处理,尤其是timeout发生。在该例子中,有三个Read位置需要考虑异常处理。

如果Read A始终没有读到数据,deadline到期,返回timeout,这里是最容易处理的,因为此时前一个完整数据包已经被读完,新的完整数据包还没有到来,外层控制逻辑收到timeout后,重启再次启动该读流程即可。

如果Read B或Read C处没有读到数据,deadline到期,这时异常处理就棘手一些,因为一个完整数据包的部分数据(A)已经从流中被读出,剩余的数据并不是一个完整的业务数据包,不能简单地再在外层控制逻辑中重新启动该过程。我们要么在Read B或Read C处尝试多次重读,直到将完整数据包读取完整后返回;要么认为在B或C处出现timeout是不合理的,返回区别于A处的错误码给外层控制逻辑,让外层逻辑决定是否是连接存在异常。

注:本文所涉及的示例代码,请到这里下载。


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

微信赞赏:
img{512x368}

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 AI原生开发工作流实战 从 0 开始构建 Agent Harness Go语言精进之路1 Go语言精进之路2 Go语言第一课 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com
这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

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

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

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

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats