英文:
Go channel buffering and deadlocks
问题
考虑以下代码块，由于达到缓冲区限制，预计会引发错误：
package main
import (
"fmt"
"time"
)
func main() {
burstyLimiter := make(chan time.Time, 4)
for i := 0; i < 5; i++ {
burstyLimiter <- time.Now()
fmt.Println("adding to burstyLimiter")
}
}
但是，当我尝试使用以下完全相同的代码块时，它会阻塞而不是抛出错误。我正在尝试理解这种行为。谢谢你的时间。
package main
import (
"fmt"
"time"
)
func main() {
requests := make(chan int, 5)
close(requests)
limiter := time.Tick(time.Millisecond * 200)
for req := range requests {
<-limiter
fmt.Println("request", req, time.Now())
}
burstyLimiter := make(chan time.Time, 4)
for i := 0; i < 5; i++ {
burstyLimiter <- time.Now()
fmt.Println("adding to burstyLimiter")
}
}
英文:
Considering the following code block, it's expected to throw an error due to reaching a the buffer limit:
package main
import (
"fmt"
"time"
)
func main() {
burstyLimiter := make(chan time.Time, 4)
for i := 0; i < 5; i++ {
burstyLimiter <- time.Now()
fmt.Println("adding to burstyLimiter")
}
}
But when I try the exact block with the following, it blocks instead of throwing an error. I am tying to understand this behavior. Thanks for your time.
package main
import (
"fmt"
"time"
)
func main() {
requests := make(chan int, 5)
close(requests)
limiter := time.Tick(time.Millisecond * 200)
for req := range requests {
<-limiter
fmt.Println("request", req, time.Now())
}
burstyLimiter := make(chan time.Time, 4)
for i := 0; i < 5; i++ {
burstyLimiter <- time.Now()
fmt.Println("adding to burstyLimiter")
}
}
答案1
得分: 1
当Go运行时发现所有的goroutine都处于死锁状态时，你会遇到一种恐慌：等待某个“内部”事件，这里的“内部”指的是另一个goroutine应该触发它。
这就是你在第一个程序中遇到的情况。
在第二个程序中，你有一个“隐藏”的goroutine，由对time.Tick的调用创建。这个goroutine在一个通道上发送滴答声，但不会在其上阻塞（“通过丢弃滴答声来弥补接收者的慢速”来自文档）。因此，在第二个示例中至少有一个正在运行的goroutine，它偶尔会在外部事件（定时器滴答声）上阻塞，因此从Go运行时死锁检测的角度来看，整个系统并没有死锁。
英文:
You get a panic, when the Go runtime discovers that all goroutines are in a deadlock: waiting for some "internal" event, internal in the sense another goroutine is expected to trigger it.
This is what you get in the first program.
In the second program, you have a "hidden" goroutine, created by the call to time.Tick. This goroutine sends ticks on a channel, but does not block on it ("drops ticks to make up for slow receivers" form the docs). So you have at least one running goroutine in the second example, which occasionally blocks on external event (timer tick), thus the whole system is not deadlocked form the point of view of the Go runtime deadlock detection.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论