初级会员
  • 第 57601 位会员
  • Atticus
  • 2020-10-28 13:43:48
  • Offline
  • 20 49

最近发布的文章

    暂无

最近分享的资源

    暂无

最近发布的项目

    暂无

最近的评论

  • 问题一楼已经说了,可以这么改进 ```golang package main import ( "fmt" "io/ioutil" ) type Page struct { Title string Body []byte } func (p *Page) load(title string) { p.Title = title body, err := ioutil.ReadFile(title) if err != nil { fmt.Println("load file err:", err) } p.Body = body } ```
  • 个人理解,你在对通道元素的发送、接收外部封装了锁,确实保证了同一时间要么在向通道写元素,要么在从通道里面读元素,但是由于发送/接收操作都在go routine中实现,因此两种情况会出现死锁: * 接收操作先获取到锁:此时由于通道中没有元素,接收的routine会一直阻塞,且由于锁的原因,发送routine始终无法竞争到锁,更别提向通道发送元素 * 发送routine连续5次竞争到锁或者接收routine连续5次竞争到锁的情况:由于通道容量只有5,连续接收5个或者连续发送5个元素后均无法再继续操作,此时也会阻塞
  • 看了郝林老师的解释,理解了,原文: > 因为条件变量的Wait方法在阻塞当前的 goroutine 之前,会解锁它基于的互斥锁,所以在调用该Wait方法之前,我们必须先锁定那个互斥锁,否则在调用这个Wait方法时,就会引发一个不可恢复的 panic。 > > 为什么条件变量的Wait方法要这么做呢?你可以想象一下,如果Wait方法在互斥锁已经锁定的情况下,阻塞了当前的 goroutine,那么又由谁来解锁呢?别的 goroutine 吗? > > 先不说这违背了互斥锁的重要使用原则,即:成对的锁定和解锁,就算别的 goroutine 可以来解锁,那万一解锁重复了怎么办?由此引发的 panic 可是无法恢复的。 > > 如果当前的 goroutine 无法解锁,别的 goroutine 也都不来解锁,那么又由谁来进入临界区,并改变共享资源的状态呢?只要共享资源的状态不变,即使当前的 goroutine 因收到通知而被唤醒,也依然会再次执行这个Wait方法,并再次被阻塞。 > > 所以说,如果条件变量的Wait方法不先解锁互斥锁的话,那么就只会造成两种后果:不是当前的程序因 panic 而崩溃,就是相关的 goroutine 全面阻塞。
  • 引用了三方的包么,看看是不是没有下载到你gopath下面吧