Go语言圣经
  • 前言
  • Go语言起源
  • Go语言项目
  • 本书的组织
  • 更多的信息
  • 致谢
  • 入门
    • Hello, World
    • 命令行参数
    • 查找重复的行
    • GIF动画
    • 获取URL
    • 并发获取多个URL
    • Web服务
    • 本章要点
  • 程序结构
    • 命名
    • 声明
    • 变量
    • 赋值
    • 类型
    • 包和文件
    • 作用域
  • 基础数据类型
    • 整型
    • 浮点数
    • 复数
    • 布尔型
    • 字符串
    • 常量
  • 复合数据类型
    • 数组
    • Slice
    • Map
    • 结构体
    • JSON
    • 文本和HTML模板
  • 函数
    • 函数声明
    • 递归
    • 多返回值
    • 错误
    • 函数值
    • 匿名函数
    • 可变参数
    • Deferred函数
    • Panic异常
    • Recover捕获异常
  • 方法
    • 方法声明
    • 基于指针对象的方法
    • 通过嵌入结构体来扩展类型
    • 方法值和方法表达式
    • 示例: Bit数组
    • 封装
  • 接口
    • 接口是合约
    • 接口类型
    • 实现接口的条件
    • flag.Value接口
    • 接口值
    • sort.Interface接口
    • http.Handler接口
    • error接口
    • 示例: 表达式求值
    • 类型断言
    • 基于类型断言识别错误类型
    • 通过类型断言查询接口
    • 类型分支
    • 示例: 基于标记的XML解码
    • 补充几点
  • Goroutines和Channels
    • Goroutines
    • 示例: 并发的Clock服务
    • 示例: 并发的Echo服务
    • Channels
    • 并发的循环
    • 示例: 并发的Web爬虫
    • 基于select的多路复用
    • 示例: 并发的字典遍历
    • 并发的退出
    • 示例: 聊天服务
  • 基于共享变量的并发
    • 竞争条件
    • sync.Mutex互斥锁
    • sync.RWMutex读写锁
    • 内存同步
    • sync.Once初始化
    • 竞争条件检测
    • 示例: 并发的非阻塞缓存
    • Goroutines和线程
  • 包和工具
    • 包简介
    • 导入路径
    • 包声明
    • 导入声明
    • 包的匿名导入
    • 包和命名
    • 工具
  • 测试
    • go test
    • 测试函数
    • 测试覆盖率
    • 基准测试
    • 剖析
    • 示例函数
  • 反射
    • 为何需要反射?
    • reflect.Type和reflect.Value
    • Display递归打印
    • 示例: 编码S表达式
    • 通过reflect.Value修改值
    • 示例: 解码S表达式
    • 获取结构体字段标识
    • 显示一个类型的方法集
    • 几点忠告
  • 底层编程
    • unsafe.Sizeof, Alignof 和 Offsetof
    • unsafe.Pointer
    • 示例: 深度相等判断
    • 通过cgo调用C代码
    • 几点忠告
  • 附录
    • 附录A:原文勘误
    • 附录B:作者译者
    • 附录C:译文授权
    • 附录D:其它语言
Powered by GitBook
On this page

Was this helpful?

  1. 底层编程

unsafe.Pointer

大多数指针类型会写成*T,表示是“一个指向T类型变量的指针”。unsafe.Pointer是特别定义的一种指针类型(译注:类似C语言中的void*类型的指针),它可以包含任意类型变量的地址。当然,我们不可以直接通过*p来获取unsafe.Pointer指针指向的真实变量的值,因为我们并不知道变量的具体类型。和普通指针一样,unsafe.Pointer指针也是可以比较的,并且支持和nil常量比较判断是否为空指针。

一个普通的*T类型指针可以被转化为unsafe.Pointer类型指针,并且一个unsafe.Pointer类型指针也可以被转回普通的指针,被转回普通的指针类型并不需要和原始的*T类型相同。通过将*float64类型指针转化为*uint64类型指针,我们可以查看一个浮点数变量的位模式。

package math

func Float64bits(f float64) uint64 { return *(*uint64)(unsafe.Pointer(&f)) }

fmt.Printf("%#016x\n", Float64bits(1.0)) // "0x3ff0000000000000"

通过转为新类型指针,我们可以更新浮点数的位模式。通过位模式操作浮点数是可以的,但是更重要的意义是指针转换语法让我们可以在不破坏类型系统的前提下向内存写入任意的值。

一个unsafe.Pointer指针也可以被转化为uintptr类型,然后保存到指针型数值变量中(译注:这只是和当前指针相同的一个数字值,并不是一个指针),然后用以做必要的指针数值运算。(第三章内容,uintptr是一个无符号的整型数,足以保存一个地址)这种转换虽然也是可逆的,但是将uintptr转为unsafe.Pointer指针可能会破坏类型系统,因为并不是所有的数字都是有效的内存地址。

许多将unsafe.Pointer指针转为原生数字,然后再转回为unsafe.Pointer类型指针的操作也是不安全的。比如下面的例子需要将变量x的地址加上b字段地址偏移量转化为*int16类型指针,然后通过该指针更新x.b:

gopl.io/ch13/unsafeptr

var x struct {
    a bool
    b int16
    c []int
}

// 和 pb := &x.b 等价
pb := (*int16)(unsafe.Pointer(
    uintptr(unsafe.Pointer(&x)) + unsafe.Offsetof(x.b)))
*pb = 42
fmt.Println(x.b) // "42"

上面的写法尽管很繁琐,但在这里并不是一件坏事,因为这些功能应该很谨慎地使用。不要试图引入一个uintptr类型的临时变量,因为它可能会破坏代码的安全性(译注:这是真正可以体会unsafe包为何不安全的例子)。下面段代码是错误的:

// NOTE: subtly incorrect!
tmp := uintptr(unsafe.Pointer(&x)) + unsafe.Offsetof(x.b)
pb := (*int16)(unsafe.Pointer(tmp))
*pb = 42

产生错误的原因很微妙。有时候垃圾回收器会移动一些变量以降低内存碎片等问题。这类垃圾回收器被称为移动GC。当一个变量被移动,所有的保存改变量旧地址的指针必须同时被更新为变量移动后的新地址。从垃圾收集器的视角来看,一个unsafe.Pointer是一个指向变量的指针,因此当变量被移动是对应的指针也必须被更新;但是uintptr类型的临时变量只是一个普通的数字,所以其值不应该被改变。上面错误的代码因为引入一个非指针的临时变量tmp,导致垃圾收集器无法正确识别这个是一个指向变量x的指针。当第二个语句执行时,变量x可能已经被转移,这时候临时变量tmp也就不再是现在的&x.b地址。第三个向之前无效地址空间的赋值语句将彻底摧毁整个程序!

还有很多类似原因导致的错误。例如这条语句:

pT := uintptr(unsafe.Pointer(new(T))) // 提示: 错误!

这里并没有指针引用new新创建的变量,因此该语句执行完成之后,垃圾收集器有权马上回收其内存空间,所以返回的pT将是无效的地址。

虽然目前的Go语言实现还没有使用移动GC(译注:未来可能实现),但这不该是编写错误代码侥幸的理由:当前的Go语言实现已经有移动变量的场景。在5.2节我们提到goroutine的栈是根据需要动态增长的。当发送栈动态增长的时候,原来栈中的所以变量可能需要被移动到新的更大的栈中,所以我们并不能确保变量的地址在整个使用周期内是不变的。

当调用一个库函数,并且返回的是uintptr类型地址时(译注:普通方法实现的函数不尽量不要返回该类型。下面例子是reflect包的函数,reflect包和unsafe包一样都是采用特殊技术实现的,编译器可能给它们开了后门),比如下面反射包中的相关函数,返回的结果应该立即转换为unsafe.Pointer以确保指针指向的是相同的变量。

package reflect

func (Value) Pointer() uintptr
func (Value) UnsafeAddr() uintptr
func (Value) InterfaceData() [2]uintptr // (index 1)
Previousunsafe.Sizeof, Alignof 和 OffsetofNext示例: 深度相等判断

Last updated 4 years ago

Was this helpful?

在编写本文时,还没有清晰的原则来指引Go程序员,什么样的unsafe.Pointer和uintptr的转换是不安全的(参考 ). 译注: 该问题已经关闭),因此我们强烈建议按照最坏的方式处理。将所有包含变量地址的uintptr类型变量当作BUG处理,同时减少不必要的unsafe.Pointer类型到uintptr类型的转换。在第一个例子中,有三个转换——字段偏移量到uintptr的转换和转回unsafe.Pointer类型的操作——所有的转换全在一个表达式完成。

Issue7192