Go 语言中下划线的用法分析总结

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

...
func (littleEndian) Uint64(b []byte) uint64 {
    _ = b[7] // bounds check hint to compiler; see golang.org/issue/14808
    return uint64(b[0]) | uint64(b[1])<<8 | uint64(b[2])<<16 | uint64(b[3])<<24 |
        uint64(b[4])<<32 | uint64(b[5])<<40 | uint64(b[6])<<48 | uint64(b[7])<<56
}

func (littleEndian) PutUint64(b []byte, v uint64) {
	_ = b[7] // early bounds check to guarantee safety of writes below

	b[0] = byte(v)
	b[1] = byte(v >> 8)
	b[2] = byte(v >> 16)
	b[3] = byte(v >> 24)
	b[4] = byte(v >> 32)
	b[5] = byte(v >> 40)
	b[6] = byte(v >> 48)
	b[7] = byte(v >> 56) // panic: runtime error: index out of range
}
...

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

package main

import "fmt"

func main() {
    b := []byte{0, 1, 2, 3, 4, 5, 6}
    var v uint64 = 0x0807060504030201

    b[0] = byte(v)
    b[1] = byte(v >> 8)
    b[2] = byte(v >> 16)
    b[3] = byte(v >> 24)
    b[4] = byte(v >> 32)
    b[5] = byte(v >> 40)
    b[6] = byte(v >> 48)
    b[7] = byte(v >> 56) // panic: runtime error: index out of range

    fmt.Println(b)
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

package main

import "fmt"

func main() {
    b := []byte{0, 1, 2, 3, 4, 5, 6}
    var v uint64 = 0x0807060504030201

    b[7] = byte(v >> 56) // panic: runtime error: index out of range
    b[6] = byte(v >> 48)
    b[5] = byte(v >> 40)
    b[4] = byte(v >> 32)
    b[3] = byte(v >> 24)
    b[2] = byte(v >> 16)
    b[1] = byte(v >> 8)
    b[0] = byte(v)

    fmt.Println(b)
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

package main

import "fmt"

func main() {
    b := []byte{0, 1, 2, 3, 4, 5, 6}
    var v uint64 = 0x0807060504030201

    _ = b[7] // early bounds check to guarantee safety of writes below

    b[0] = byte(v)
    b[1] = byte(v >> 8)
    b[2] = byte(v >> 16)
    b[3] = byte(v >> 24)
    b[4] = byte(v >> 32)
    b[5] = byte(v >> 40)
    b[6] = byte(v >> 48)
    b[7] = byte(v >> 56)

    fmt.Println(b)
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

问题1：在 Golang 中是否有必要进行早期检查以保证书写的安全性？

A1：这里的答案是“是和否”。一般来说，“否”，你通常不必在Go中插入边界检查，因为编译器会为你插入它们（这就是为什么当你尝试访问片段长度之外的内存位置时，你的示例会 panic）。但是，如果你正在执行多个写入操作（“是”），则需要插入像提供的示例一样的早期边界检查，以确保你不会只有一些写入成功，从而使你处于不良状态（或重构，如你在示例B中所做的那样，以便首次写入最大阵列，确保在任何写入操作成功之前发生恐慌）。

然而，这不是一个“Go 问题”，因为它是一个通用的错误类。在任何语言中如果你不进行边界检查（或者如果它是一种强制执行像 Go 一样的边界的语言的最高索引），写入操作就不安全。这也很大程度上取决于解决方案;在你发布的标准库的示例中，用户进行边界检查是有必要的。但是，在你发布的第二个示例中，用户边界检查不是必需的，因为代码可以像 B 一样写，其中编译器会在第一行插入边界检查。

问题2：为了保证书写的安全性进行早期检查的话，哪一个样本代码更简洁和性能优化（速度）好些呢？样本代码A，B，C或...？

A2：我认为是 B: 因为它简洁并做了早期检查，不是吗？

你是对的。在 B 中，编译器会在第一次写入时插入边界检查，保护其余的写入。因为你正在使用常量（7，6，... 0）对切片进行索引，编译器可以将边界检查从其余的写入中删除，因为它可以保证它们是安全的。

1
2
3
4
5

关于“写入安全性”的评论在这里有误导性。在开始时放置最高边界检查只是一个优化。如果你忽略它，行为将不会改变（或变成“不安全”），但是你可能会遭受多重边界检查而不是仅仅一次的性能损失，因为每个后续较高索引所需的最小限度增量。

如果评论中提到“保证写入安全”，这只是意味着它将保证编译器后续的写入操作是安全的，无需插入更多的边界检查。把它写出来不会使写入不安全，只会让编译器插入更多的边界检查。在任何情况下，编译器都不会产生不安全的内存访问。

在代码中插入这个假的早期边界检查是一个好主意，而不是不使用它或者重写代码来合法使用最高索引（如代码B中的代码），这是值得商榷的。只要它清楚为什么它在那里（例如，一个明智的和没有误导性的评论）我会说如果你想使用它，并找到它的好处。一般情况下，通过手动优化，未来的编译器优化可能会使其成为冗余或以其他方式改变其有效性。

1
2
3
4
5
6
7

import (
	"database/sql"
	"fmt"
	_ "github.com/go-sql-driver/mysql"
	_ "net/http/pprof"
)
...

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

type ResponseWriter interface {
	http.ResponseWriter
	http.Hijacker
	http.Flusher
	http.CloseNotifier

	// Returns the HTTP response status code of the current request.
	Status() int

	// Returns the number of bytes already written into the response http body.
	// See Written()
	Size() int

	// Writes the string into the response body.
	WriteString(string) (int, error)

	// Returns true if the response body was already written.
	Written() bool

	// Forces to write the http header (status code + headers).
	WriteHeaderNow()
}

type responseWriter struct {
	http.ResponseWriter
	size   int
	status int
}

var _ ResponseWriter = &responseWriter{}