inasayang's blog

Go | First Response Pattern

xiayangzzw@gmail.com (inasayang) — Thu, 07 Aug 2025 00:00:00 Z

// Avoid timeout - Replicate servers and use first response
type Result string
type Search func(query string) Result

func fakeSearch(kind string) Search {
	return func(query string) Result {
		time.Sleep(time.Duration(rand.Intn(100)) * time.Millisecond)
		return Result(fmt.Sprintf("%s result for %q", kind, query))
	}
}

func First(query string, replicas ...Search) Result {
	c := make(chan Result)
	searchReplica := func(i int) { c <- replicas[i](query) }
	for i := range replicas {
		go searchReplica(i)
	}
	return <-c
}

func main() {
	start := time.Now()
	result := First("golang",
		fakeSearch("replica1"), 
		fakeSearch("replica2"),
		fakeSearch("replica3"))
	elapsed := time.Since(start)
	fmt.Println(result)
	fmt.Printf("%.3fms\n", float64(elapsed.Nanoseconds())/1e6)
}

这是 Go 并发经典实践之一：“用副本竞速的方式避免超时，返回最早的可用结果”——常见于高可用分布式系统的请求快速返回（比如多个搜索副本、微服务副本集请谁先响应）。

# 主要思想

业务背景：你有好几个“备用服务器/副本/搜索实现”，哪个响应最快用哪个，“慢的都不用等”，避免整个请求因单点慢或偶发延迟变慢。
这是现实世界中 Google、Amazon 等公司搜索引擎“边缘副本”、“异地容灾高可用”大量使用的技术方案。

# 现实应用场景

微服务多活：多个服务副本响应同一请求，优先拿到第一个并快速返回，极大降低99.99延迟。
CDN/边缘计算：拉取数据时向多节点并发请求，客户端只拿第一个响应的内容。
多家供应商比价/辅助搜索聚合：哪个接口快就显示谁的内容。

# 使用context控制goroutine leak

这个简单写法确实会导致 goroutine 泄露（goroutine leak）的问题。

你发起了多个副本 goroutine，每个都会做完自己的“搜索”然后把结果写入同一个 channel c。
但 First 只从 channel 取第一个结果：return <-c
其它 goroutine 后续写入 channel 时，如果没人读，它们会永远阻塞在 c <- ... 这一行上——此时这些 goroutine 无法退出，即内存泄露。

func First(query string, replicas ...Search) Result {
	ctx, cancel := context.WithCancel(context.Background())
	defer cancel()
	c := make(chan Result)
	searchReplica := func(i int) {
		select {
		case c <- replicas[i](query):
		case <-ctx.Done():
			return
		}
	}
	for i := range replicas {
		go searchReplica(i)
	}
	result := <-c
	cancel() // 让其他 goroutine 自动退出
	return result
}

主流程一旦拿到第一个结果，cancel() 会通知其他所有 goroutine 退出。

复杂情况下可配合 context、WaitGroup 做到无资源泄露。

https://www.concurrency.rocks/

Go | 跨包访问非导出符号

xiayangzzw@gmail.com (inasayang) — Mon, 21 Apr 2025 00:00:00 Z

//go:linkname 是 Go 语言中的一个编译指令（compiler directive），用于在编译期间将一个符号（函数或变量）的名称重命名成另一个符号，达到在不同包之间绕过封装直接访问非导出（unexported）标识符的效果。

需要导入 unsafe 包
函数或变量必须声明

# 使用未导出函数（示例1）：

package mypkg

import _ "unsafe"

//go:linkname privateFunc runtime.internalFunc
func privateFunc()

这里 mypkg 包里的 privateFunc 会被链接为 runtime 包中的非导出函数 internalFunc，调用privateFunc() 就是调用的 runtime.internalFunc()。

# 使用未导出函数（示例2）：

package main

import (
    _ "unsafe"
    _ "github.com/xxx/yyy/zzz"  // 确保包被导入
)

//go:linkname newUUID github.com/xxx/yyy/zzz.newUUID
func newUUID() string

func main() {
    s := newUUID()
    fmt.Println(s)
}

# 使用未导出变量：

package yourpkg

import _ "unsafe"

//go:linkname someValue github.com/xxx/yyy/zzz.someValue
var someValue int

Go | 使用PGO优化编译示例

xiayangzzw@gmail.com (inasayang) — Tue, 15 Apr 2025 00:00:00 Z

PGO (Profile-Guided Optimization) 是一种编译优化技术，通过收集程序的实际运行时数据来指导编译器进行更有针对性的优化。

-pgo file
        specify the file path of a profile for profile-guided optimization (PGO).
        When the special name "auto" is specified, for each main package in the
        build, the go command selects a file named "default.pgo" in the package's
        directory if that file exists, and applies it to the (transitive)
        dependencies of the main package (other packages are not affected).
        Special name "off" turns off PGO. The default is "auto".

这段说明解释了 -pgo 参数的几种用法：

pgo=文件路径 - 指定一个具体的性能分析文件路径用于PGO优化
pgo=auto - 自动模式(默认)，会在每个main包的目录中查找名为"default.pgo"的文件
pgo=off - 明确关闭PGO优化

当使用自动模式时，PGO优化只会应用到main包及其依赖项，而不会影响其他不相关的包。

# 收集性能分析数据

// main.go
package main

import (
    "os"
    "runtime/pprof"
)

func computeIntensive() int {
    result := 0
    for i := 0; i < 10000000; i++ {
        result += i % 10
    }
    return result
}

func main() {
    // 第一次运行时开启性能分析
    if len(os.Args) > 1 && os.Args[1] == "profile" {
        f, _ := os.Create("profile.pprof")
        defer f.Close()
        pprof.StartCPUProfile(f)
        defer pprof.StopCPUProfile()
    }
    
    // 执行计算密集型操作
    result := computeIntensive()
    println("Result:", result)
}

go build -o myapp.exe .
./myapp.exe profile

# 使用收集的分析数据进行优化编译

go build -pgo profile.pprof -o myapp_optimized.exe .

如果有多个pprof文件

# 使用pprof工具合并多个分析文件
go tool pprof -proto cpu1.pprof cpu2.pprof cpu3.pprof > combined.pprof
# 使用合并后的分析文件进行构建
go build -pgo combined.pprof -o myapp_optimized.exe .

# 测试

time ./myapp.exe
time ./myapp_optimized.exe

PGO 优化通常在较大、复杂的应用中效果更显著，特别是有明显热点路径的程序。对于简单程序，优化效果可能不明显，甚至因为优化开销而略微变慢。
PGO 主要适用于计算密集型应用。

Go | 检测当前系统位数

xiayangzzw@gmail.com (inasayang) — Sat, 09 Mar 2024 00:00:00 Z

# 声明一个常量来表示当前操作系统的位数

const NativeWordBits = 32 << (^uint(0) >> 63) // 64 or 32

^uint(0)：对于无符号整型 uint(0)（其所有位都是0），按位取反操作会产生一个所有位都是1的数字。这个结果的数值上等同于 uint 能表示的最大值。
>> 63：这个操作的结果依赖于 uint 的大小：
- 在64位平台上，uint 类型为64位，^uint(0) 产生一个所有位都为1的64位数字。向右移动63位后，最左边的一位（最高位）会移动到最右边，结果为1（二进制的000…001）
- 在32位平台上，尽管仍然执行相同的操作，但是由于 uint 的大小只有32位，所以这个操作实际上产生的结果是 0，因为32位无法表示一个向右移动了63位的值
32 << (... >> 63)：最终这个表达式将32左移上一步的结果。在32位平台上，由于上一步的结果是 0，32 << 0 保持不变，仍然是 32。这反映了32位系统的字长。在64位平台上，上一步的结果是 1，因此 32 << 1 相当于将32乘以2，结果是 64。这反映了64位系统的字长。

# 检查当前操作系统是32位的还是64位的

const Is64bitOS = ^uint(0) >> 63 != 0 
const Is32bitOS = ^uint(0) >> 32 == 0

Go101

Go | 使一个结构体类型不可比较

xiayangzzw@gmail.com (inasayang) — Tue, 08 Aug 2023 00:00:00 Z

可以放置一个非导出的零尺寸的不可比较类型的字段在结构体类型中以使此结构体类型不可比较

结构体

type T struct {
	dummy [0]func()
	AnotherField int
}

使用

var x map[T]int // 编译错误：非法的键值类型

var a, b T
_ = a == b // 编译错误：非法的比较

Go | 0尺寸结构体

xiayangzzw@gmail.com (inasayang) — Mon, 07 Aug 2023 00:00:00 Z

下面四个结构体的尺寸大小各是多少？

type A struct {
	x int64
	y int64
}
type A1 struct {
	x int64
	y int64
	z struct{}
}
type A2 struct {
	z struct{}
	x int64
	y int64
}
type A3 struct {
	x int64
	z struct{}
	y int64
}

答案

A： 16
A1： 24
A2： 16
A3： 16

为什么A1的结构体会不同呢？

一个可寻址的结构值的所有字段都可以被取地址，A1可以被取地址，则z也可以被取地址
如果非零尺寸的结构体值的最后一个字段的尺寸是零，那么取此最后一个字段的地址将会返回一个越出了结构体值分配的内存块的地址（可能指向另一个被分配的内存块）
标准的Go编译器会确保取一个非零尺寸的结构体值的最后一个字段的地址时，绝对不会返回越出分配给此结构体值的内存块的地址
Go标准编译器通过在需要时在结构体最后的零尺寸字段之后填充一些字节来实现这一点
- 具体补多少，需要达到内存对齐即可
如果一个结构体的全部字段的类型都是零尺寸的(因此整个结构体也是零尺寸的)，那么就不需要再填充字节，因为标准编译器会专门处理零尺寸的内存块

Golang101

Go | Build Constraints 构建约束

xiayangzzw@gmail.com (inasayang) — Mon, 02 Jan 2023 00:00:00 Z

一个构建约束(构建标签)是文件应包含在包中的条件。构建约束由开始的行注释给出。

//go:build

约束可以出现在任何类型的源文件中（不仅仅是 Go），但它们必须出现在文件顶部附近，前面只有空行和其他行注释。这些规则意味着在 Go 文件中，构建约束必须出现在 package 子句之前。

为了区分构建约束和包文档，构建约束后面应该跟一个空行。

构建约束注释被评估为包含由 ||、&& 和 ! 组合的构建标记的表达式,运算符和括号。

例如，当满足linux和386约束时，或者满足darwin而cgo不满足时，以下构建约束约束文件构建：

//go:build (linux && 386) || (darwin && !cgo)

一个文件有多个 //go:build 行是错误的。

在特定构建期间，满足以下构建标签：

目标操作系统，由 runtime.GOOS 拼写，使用 GOOS 环境变量设置。
目标体系结构，由 runtime.GOARCH 拼写，使用 GOARCH 环境变量设置。
unix，如果 GOOS 是 Unix 或类 Unix 系统。
正在使用的编译器，gc或gccgo
cgo，如果支持 cgo 命令（请参阅go help environment中的 CGO_ENABLED）。
每个 Go 主要版本的术语，通过当前版本：从 Go 1.1 版开始的“go1.1”，从 Go 1.12 开始的“go1.12”，等等。
-tags 标志给出的任何附加标签（参见go help build）。

如果文件名在去除扩展名和可能的 _test 后缀后匹配以下任何模式：

*_GOOS
*_GOARCH
*_GOOS_GOARCH

（示例：source_windows_amd64.go）其中 GOOS 和 GOARCH 分别代表任何已知的操作系统和体系结构值，然后该文件被认为具有需要这些术语的隐式构建约束（除了文件中的任何显式约束之外）。

除了 android 标签和文件之外，使用 GOOS=android 匹配构建标签和文件，就像 GOOS=linux 一样。
除了 illumos 标签和文件之外，使用 GOOS=illumos 匹配构建标签和文件，就像 GOOS=solaris 一样。
除了 ios 标签和文件之外，使用 GOOS=ios 匹配构建标签和文件，就像 GOOS=darwin 一样。

要阻止文件被考虑用于构建：

//go:build ignore

仅在使用 cgo 时构建文件，并且仅在 Linux 和 OS X 上：

//go:build cgo && (linux || darwin)

这样的文件通常与另一个实现其他系统默认功能的文件配对，在这种情况下会带有约束：

//go:build !(cgo && (linux || darwin))

将文件命名为 dns_windows.go 将导致它仅在为 Windows 构建包时被包含；同样，只有在为 32 位 x86 构建包时才会包含 math_386.s。

Go 版本 1.16 及更早版本使用不同的语法来构建约束，带有// +build前缀。 gofmt 命令将在遇到旧语法时添加等效的 //go:build 约束。

例外，下列使用空格，逗号，多行在新版本中已失效：

用空格分隔的构建标记在逻辑上是或
```
  // +build linux darwin
```
用逗号分隔的构建标记在逻辑上是和
```
// +build windows,386
```
在多行上构建约束是逻辑和
```
// +build windows
// +build 386
```

完整的约束标签可以在这里找到

Build constraints