Skip to main content

Go Race Detector Observations

· 3 min read

Go has a built-in race detector, succinctly described in this Go article. I’ve found it to be a useful tool—often the first thing I reach for when debugging flaky Go tests and suspecting a race condition. I thought I’d write down some lessons I’ve learned from using this tool.

1. Go Race Detector is Your Friend​

Running tests in Go with the -race flag enables race detection and can give you an immediate first-pass indication of whether the test has a race condition. Since the race detector works by "instrumenting/monitoring" the code during execution, the slower runtime compared to running the same test without the flag can actually be beneficial.

The cost of race detection varies by program, but for a typical program, memory usage may increase by 5-10x and execution time by 2-20x.

This slowdown can make elusive race conditions more reproducible. Once you learn how to interpret the race detector’s logs, you’ll have a direct way to identify which code paths need further scrutiny. An example of how to interpret race detector logs can be found in my other post.

  • In essence: find the concurrent read and write that are causing the race.

Using the race detector can give you a quick indicator of potential race conditions.

2. No Race Condition Detected != No Race Condition​

The race detector only finds races that happen at runtime, so it can't find races in code paths that are not executed.

Because the race detector works at runtime, it can only detect race conditions that are actually triggered during execution. This is important to acknowledge, as some race conditions are highly timing-sensitive—they may only occur when certain operations are unusually fast or slow.

3. Race Detected != Production Code is Impacted by Race Condition​

Again, since the race detector works at runtime, detecting a race condition doesn’t necessarily mean your production code is affected. Sometimes, the test code itself introduces the race.

For example, tests often try to hit edge scenarios, which can unintentionally induce race conditions. This is common in tests that use multiple goroutines to test concurrent functions, especially when results are not communicated through channels. Another pattern I’ve seen is tests that intentionally misuse the function under test—such as skipping synchronization or blocking on a done channel—to simulate concurrent processes.

One telltale sign is tweaking sleep durations across goroutines to simulate the handling of many incoming requests.

Lastly, test code is often less strict with shared variables (e.g., using a map or counter without a lock) and then making assertions across goroutines. This can introduce race conditions that the race detector rightly reports—but in such cases, it's more a sign of poorly written tests than a serious concern about the production code.

4. AI Can't Reliably Help You Detect Race Conditions​

On the topic of race detection, I want to share a quick note: after experimenting with AI tools (specifically GitHub Copilot) to analyze and detect race conditions, I’ve concluded that while they can be helpful, they aren’t 100% reliable. AI can sometimes spot issues and suggest fixes, but it may also miss certain race conditions or propose solutions that aren’t suitable.

That said, this is just my observation as of April 2025—AI is improving fast, and I hope it proves me wrong soon...