单锁场景下Go程序报死锁是否符合死锁定义？

First, let's take a look at your code and the output you got:

Your Code #

package main
import (
	"fmt"
	"sync"
	"time"
)
var mu = new(sync.Mutex)
func f2() {
	mu.Lock()
	fmt.Println("call f2...")
}
func main() {
	go f2()
	time.Sleep(time.Second * 2)
	mu.Lock()
	fmt.Println("get lock in main")
}

Output #

call f2... fatal error: all goroutines are asleep - deadlock!

This absolutely counts as a deadlock. Let's break this down and clear up the misunderstanding you had about the deadlock conditions.

First, let's unpack the code's behavior:
The f2() goroutine acquires the mutex lock but never calls mu.Unlock()—it holds onto the lock permanently. After sleeping for 2 seconds, the main goroutine tries to grab the same mutex, but gets blocked because f2 still has it. At this point, both goroutines are stuck: one holds the lock and does nothing else, the other waits endlessly for the lock. No part of the program can proceed, which is the core of a deadlock.

Now let's address your question about the "hold and wait" condition:
You thought this condition requires at least two types of resources, but that's not accurate. The core of "hold and wait" is that an execution unit (goroutine/process) holds at least one resource while waiting for another resource held by a different execution unit. In this scenario:

• The f2 goroutine holds the only mutex resource and never releases it.
• The main goroutine waits for that same mutex, with no way to get it.

Let's verify all four deadlock necessary conditions to confirm:

• Mutual Exclusion: The mutex can only be held by one goroutine at a time—this is exactly how mutexes work, so this condition is met.
• Hold and Wait: f2 holds the lock indefinitely, while main waits for that lock. This fits the definition perfectly, even with a single resource.
• No Preemption: Go's mutex can't be forcibly taken from a goroutine; it has to be released voluntarily with Unlock(). This condition is satisfied.
• Circular Wait: While it looks like a one-way wait, we have a de facto circular dependency: main can't proceed until f2 releases the lock, and f2 will never release the lock (since it has no code to do so). Go's runtime detects when all goroutines are stuck in blocked/sleeping states and throws the deadlock error you saw.

Go's deadlock detection logic is straightforward: if the runtime finds there are no runnable goroutines left (all are stuck on blocking operations like lock waits or channel operations), it declares a deadlock.

To sum up: This scenario is a textbook deadlock. Single resources can absolutely cause deadlocks—all it takes is one execution unit hoarding the resource permanently while others wait for it with no way to proceed.

内容的提问来源于stack exchange，提问作者pete lin