Go race 为什么不报告跨进程的数据竞争

如果两个 Go 进程同时改同一份文件、同一个 Unix Socket 背后的服务状态，或者同时更新一条数据库记录，执行 go test -race 可能完全没有报告。这不是 race 检测器失效，而是问题已经越过了它能观察的内存边界。

结论：-race 主要检测“同一个进程内，多个 goroutine 对同一内存位置的并发冲突”。两个独立进程各自拥有独立的地址空间和 race 运行时；它们通过文件、管道、Socket 或数据库交换的是外部资源，不会自动被视为同一个 Go 变量。

官方文档：https://go.dev/doc/articles/race_detector

• 进程内共享变量：用 -race 找访问冲突。
• 跨进程共享资源：检查协议、锁、事务和服务端并发语义。
• 没有报告：只表示观测范围内没有捕获到冲突，不等于系统整体没有并发问题。

先看清 -race 到底在检测什么

Go 官方把 data race 定义为：两个 goroutine 并发访问同一个变量，并且至少有一次访问是写入。使用 go test -race 时，编译和运行阶段会为相关内存访问建立检测信息；只有测试真正走到那条路径，检测器才有机会发现冲突。

package counter

import "testing"

func TestCounter(t *testing.T) {
	var total int
	done := make(chan struct{})

	go func() {
		// 这个写入与下面 goroutine 的写入共享同一个进程内变量。
		total++
		close(done)
	}()

	// 没有锁或同步关系时，两个 goroutine 可能同时修改 total。
	total++
	

这类代码即使偶尔得到“看起来正确”的结果，也可能被 -race 报告。检测器关心的是并发访问关系，不是某一次打印出来的数值是否碰巧正确。加互斥锁、使用合适的原子操作，或者改成通过 channel 传递所有权，才是在修复这条进程内边界。

为什么两个进程不会自动形成一条 race 报告

启动两个进程后，即使它们都执行了相同的 Go 代码，进程 A 的 counter 和进程 B 的 counter 也不是同一个 Go 地址。每个进程的 race 运行时只能记录自己看到的访问；另一个进程的调用栈、线程和内存访问不会直接出现在这份报告里。

跨进程真正共享的通常是另一种媒介。比如两个进程都打开同一个文件，它们争用的是文件系统中的对象；使用管道或 Socket 时，争用的是字节流和协议状态；使用数据库时，最终由数据库的锁、隔离级别和约束决定并发结果。这些都不能仅凭 -race 判断。

import "os"

func appendRecord(path string, data []byte) error {
	// 两个进程各自持有文件描述符，-race 不会把它们合并成一个 Go 变量。
	f, err := os.OpenFile(path, os.O_WRONLY|os.O_CREATE|os.O_APPEND, 0o600)
	if err != nil {
		return err
	}
	defer f.Close() // 当前进程使用完描述符后释放资源。

	// O_APPEND 只表达写入位置语义，记录完整性仍要由协议或文件锁设计保证。
	_, err = f.Write(data)
	return err
}

上面的示例可以说明检测边界，但不能把 O_APPEND 当成跨进程业务事务。若一条记录必须完整写入，应补充明确的记录格式、锁或单写者协议；若数据需要条件更新，应优先让数据库事务或一个拥有状态的服务来裁决。

排查时先按共享媒介分层

遇到“两个服务同时写，但 -race 没有输出”的情况，可以先回答一个问题：冲突对象究竟在哪里？下面的分层比继续反复加 -race 更有效。

如果问题同时包含两层，例如进程内缓存和数据库更新，那么两层都要测：先让 -race 覆盖缓存的 goroutine 竞争，再用并发测试或故障注入检查数据库事务。不要因为第一层没有报告，就把第二层当成已经安全。

怎样使用 -race 才不会误读结果

# 让当前测试进程带上 race 检测，并扩大日志可读性。
GORACE="strip_path_prefix=$(pwd)" go test -race ./...

# 真实工作负载需要覆盖测试没有走到的代码路径。
go build -race -o service-race ./cmd/service
./service-race

官方文档明确提醒，race detector 只发现运行时实际发生的竞争；测试覆盖不足时，应让带 -race 的程序接受更接近真实的负载。同时它会带来明显开销，官方给出的典型范围是内存增加约 5–10 倍、执行时间增加约 2–20 倍。因此它适合测试、预发布和受控压测，不应被误解为线上所有并发错误的统一探针。

实战中可以保留两份检查清单：一份记录哪些进程内共享对象已经被 -race 覆盖；另一份记录跨进程资源的协议、锁、事务和失败重试。只有两份都回答清楚，才能说“这条并发路径被检查过”。

相关问题

没有 race 报告，是不是代码一定没有数据竞争？

不是。它可能没有执行到冲突路径，也可能冲突发生在另一个进程、外部服务或未被检测器覆盖的资源上。

两个 goroutine 访问同一个文件，-race 能发现吗？

如果它们只是各自调用文件 API，-race 不会替你判断文件系统层面的写入顺序和记录完整性；仍应设计文件锁、单写者或可恢复的写入协议。

跨进程问题应该用什么测试？

按资源类型做并发测试：IPC 检查消息协议和重试，文件检查锁与恢复，数据库检查事务和约束，再把每个进程内部的共享内存交给 -race。