GO goroutine死锁

死锁现场1 ：

package main
func main() {
	ch := make(chan int)

	<- ch
}

运行结果：

fatal error: all goroutines are asleep - deadlock!

分析：
只有一个主协程，在<-ch时就阻塞上了，并未检测到其它的活跃并相关的协程

死锁现场2 ：

package main

import (
	"fmt"
	"time"
)

func main() {
	ch := make(chan int)

	ch <- 1
	ch <- 2
	ch <- 3


	go func(ch chan int) {
		//time.Sleep(time.Second)
		fmt.Println(<- ch)
		fmt.Println(<- ch)
		fmt.Println(<- ch)
	}(ch)


	time.Sleep(time.Second*5)
}

运行结果：

fatal error: all goroutines are asleep - deadlock!

分析：
在ch <- 1时主协程被阻塞了，并未执行到启动下面协程的代码。

为什么会有死锁的产生？

经过多次的实验发现，只要主协程没被锁上就不会有问题，上段代码来研究一下：

package main

import (
	"fmt"
	"time"
)

func main() {
	ch := make(chan int)

	go func(ch chan int) {
		//time.Sleep(time.Second)
		for j:=0;j<5 ;j++  {
			fmt.Println(<- ch)
		}
	}(ch)

	time.Sleep(time.Second)
	for i:=0;i<4 ;i++  {

		ch <- i
	}

	time.Sleep(time.Second*5)
}

分析：
1、上面代码中肯定是上面开启的协程被阻塞了，但是并不影响
2、如果把主协程中的输入放到开启线程前面，那先被阻塞的主协程，那这就死锁了
3、如果输入的数量多，输出的数据量，那最后等待被读取的肯定是主线程，那会死锁
4、如果输入的数量少，那是后开启的子协程被阻塞，没影响
5、把输入也给放到新的协程中，那么输入多或是输出多都没关系，因为主协程没被阻塞

结论：
1、保证主协程不被阻塞
2、主协程中尽量不要用chan