go语言线程等待与唤醒 go语言线程等待与唤醒不同

Golang的调度模型

Go有四大核心模块，基本全部体现在runtime，有调度系统、GC、goroutine、channel，那么深入理解其中的精髓可以帮助我们理解Go这一门语言！

创新互联主要业务有网站营销策划、成都网站设计、网站制作、微信公众号开发、微信小程序定制开发、H5响应式网站、程序开发等业务。一次合作终身朋友，是我们奉行的宗旨；我们不仅仅把客户当客户，还把客户视为我们的合作伙伴，在开展业务的过程中，公司还积累了丰富的行业经验、全网整合营销推广资源和合作伙伴关系资源，并逐渐建立起规范的客户服务和保障体系。 

参考: 调度系统设计精要

下面是我用Go语言简单写的一个调度器，大家可以看看设计思路，以及存在的问题！

1、测试条件，调度器只启动两个线程，然后一个线程主要是负责循环的添加任务，一个线程循环的去执行任务

2、测试条件，调度器启动三个线程，然后两个线程去执行任务，一个添加任务

3、继续测试，启动十个线程，一个添加任务，九个执行任务

4、我们添加一些阻塞的任务

执行可以看到完全不可用

1、 可以看到随着M的不断的增加，可以发现执行任务的数量也不断的减少，原因是什么呢？有兴趣的同学可以加一个pprof可以看看，其实大量的在等待锁的过程！

2、如果我的M运行了类似于Sleep操作的方法如何解决了，我的调度器还能支撑这个量级的调度吗？

关于pprof如何使用：在代码头部加一个这个代码：

我们查看一下 go tool pprof main/prof.pporf

可以看到真正执行代码的时间只有 0.17s + 0.02s 其他时间都被阻塞掉了！

1、GM模型中的所有G都是放入到一个queue，那么导致所有的M取执行任务时都会去竞争锁，我们插入G也会去竞争锁，所以解决这种问题一般就是减少对单一资源的竞争，那就是桶化，其实就是每个线程都分配一个队列

2、GM模型中没有任务状态，只有runnable，假如任务遇到阻塞，完全可以把任务挂起再唤醒

这里其实会遇到一个问题，假如要分配很多个线程，那么此时随着线程的增加，也会造成队列的增加，其实也会造成调度器的压力，因为它需要遍历全部线程的队列去分配任务以及后续会讲到的窃取任务！

因为我们知道CPU的最大并行度其实取决于CPU的核数，也就是我们没必要为每个线程都去分配一个队列，因为就算是给他们分配了，他们自己去那执行调度，其实也会出现大量阻塞，原因就是CPU调度不过来这些线程！

Go里面是只分配了CPU个数的队列，这里就是P这个概念，你可以理解为P其实是真正的资源分配器，M很轻只是执行程序，所有的资源内存都维护在P上！M只有绑定P才能执行任务（强制的）！

这样做的好处：

1、首先调度程序其实就是调度不同状态的任务，go里面为Go标记了不同的状态，其实大概就是分为：runnable，running，block等，所以如何充分调度不同状态的G成了问题，那么关于阻塞的G如何解决，其实可以很好的解决G调度的问题！

上面这些情况其实就分为：

2、用户态阻塞，一般Go里面依靠 gopark 函数去实现，大体的代码逻辑基本上和go的调度绑定死了

源码在：

3、其实对于netpool 这种nio模型，其实内核调用是非阻塞的，所以go开辟了一个网络轮训器队列，来存放这些被阻塞的g，等待内核被唤醒！那么什么时候会被唤醒了，其实就是需要等待调度器去调度了！

4、如果是内核态阻塞了（内核态阻塞一般都会将线程挂起，线程需要等待被唤醒），我们此时P只能放弃此线程的权利，然后再找一个新的线程去运行P！

关于着新线程：找有没有idle的线程，没有就会创建一个新的线程！

关于当内核被唤醒后的操作：因为GPM模型所以需要找到个P绑定，所以G会去尝试找一个可用的P，如果没有可用的P，G会标记为runnable放到全局队列中！

5、其实了解上面大致其实就了解了Go的基本调度模型

答案文章里慢慢品味！

如果某个 G 执行时间过长，其他的 G 如何才能被正常的调度？ 这便涉及到有关调度的两个理念：协作式调度与抢占式调度。协作式和抢占式这两个理念解释起来很简单： 协作式调度依靠被调度方主动弃权；抢占式调度则依靠调度器强制将被调度方被动中断。

例如下面的代码，我本地的版本是 go1.13.5

执行: GOMAXPROCS=1 配置全局只能有一个P

可以看到main函数无法执行!也就是那个go 空转抢占了整个程序

备注：

但是假如我换为用 1.14+版本执行，有兴趣的话可以使用我的docker镜像，直接可以拉取： fanhaodong/golang:1.15.11 和 fanhaodong/golang:1.13.5

首先我们知道G/M/P，G可能和M也可能和P解除绑定，那么关于数据变量放在哪哇！其实这个就是逃逸分析！

输出可以看到其实没有发生逃逸，那是因为 demo被拷贝它自己的栈空间内

备注：

-gcflags"-N -l -m" 其中 -N禁用优化-l禁止内联优化，-m打印逃逸信息

那么继续改成这个

可以看到发现 demo对象其实被逃逸到了堆上！这就是不会出现类似于G如果被别的M执行，其实不会出现内存分配位置的问题！

所以可以看到demo其实是copy到了堆上！这就是g逃逸的问题，和for循环一样的

执行可以发现，其实x已经逃逸到了堆上，所以你所有的g都引用的一个对象，如何解决了

如何解决了，其实很简单

也谈goroutine调度器

图解Go运行时调度器

Go语言回顾：从Go 1.0到Go 1.13

Go语言原本

调度系统设计精要

Scalable Go Scheduler Design Doc

图解Go中select语句的底层原理

Go 的select语句是一种仅能用于channl发送和接收消息的专用语句，此语句运行期间是阻塞的；当select中没有case语句的时候，会阻塞当前的groutine。所以，有人也会说select是用来阻塞监听goroutine的。

还有人说：select是Golang在语言层面提供的I/O多路复用的机制，其专门用来检测多个channel是否准备完毕：可读或可写。

以上说法都正确。

我们来回顾一下是什么是 I/O多路复用 。

每来一个进程，都会建立连接，然后阻塞，直到接收到数据返回响应。

普通这种方式的缺点其实很明显：系统需要创建和维护额外的线程或进程。因为大多数时候，大部分阻塞的线程或进程是处于等待状态，只有少部分会接收并处理响应，而其余的都在等待。系统为此还需要多做很多额外的线程或者进程的管理工作。

为了解决图中这些多余的线程或者进程，于是有了"I/O多路复用"

每个线程或者进程都先到图中”装置“中注册，然后阻塞，然后只有一个线程在”运输“，当注册的线程或者进程准备好数据后，”装置“会根据注册的信息得到相应的数据。从始至终kernel只会使用图中这个黄黄的线程，无需再对额外的线程或者进程进行管理，提升了效率。

select的实现经历了多个版本的修改，当前版本为：1.11

select这个语句底层实现实际上主要由两部分组成： case语句 和 执行函数 。

源码地址为：/go/src/runtime/select.go

每个case语句，单独抽象出以下结构体：

结构体可以用下图表示：

然后执行select语句实际上就是调用 func selectgo(cas0 *scase, order0 *uint16, ncases int) (int, bool) 函数。

func selectgo(cas0 *scase, order0 *uint16, ncases int) (int, bool) 函数参数：

selectgo 返回所选scase的索引(该索引与其各自的select {recv，send，default}调用的序号位置相匹配)。此外，如果选择的scase是接收操作(recv)，则返回是否接收到值。

谁负责调用 func selectgo(cas0 *scase, order0 *uint16, ncases int) (int, bool) 函数呢？

在 /reflect/value.go 中有个 func rselect([]runtimeSelect) (chosen int, recvOK bool) 函数，此函数的实现在 /runtime/select.go 文件中的 func reflect_rselect(cases []runtimeSelect) (int, bool) 函数中:

那谁调用的 func rselect([]runtimeSelect) (chosen int, recvOK bool) 呢？

在 /refect/value.go 中，有一个 func Select(cases []SelectCase) (chosen int, recv Value, recvOK bool) 的函数，其调用了 rselect 函数，并将最终Go中select语句的返回值的返回。

以上这三个函数的调用栈按顺序如下：

这仨函数中无论是返回值还是参数都大同小异，可以简单粗暴的认为：函数参数传入的是case语句，返回值返回被选中的case语句。

那谁调用了 func Select(cases []SelectCase) (chosen int, recv Value, recvOK bool) 呢？

可以简单的认为是系统了。

来个简单的图：

前两个函数 Select 和 rselect 都是做了简单的初始化参数，调用下一个函数的操作。select真正的核心功能，是在最后一个函数 func selectgo(cas0 *scase, order0 *uint16, ncases int) (int, bool) 中实现的。

打乱传入的case结构体顺序

锁住其中的所有的channel

遍历所有的channel，查看其是否可读或者可写

如果其中的channel可读或者可写，则解锁所有channel，并返回对应的channel数据

假如没有channel可读或者可写，但是有default语句，则同上:返回default语句对应的scase并解锁所有的channel。

假如既没有channel可读或者可写，也没有default语句，则将当前运行的groutine阻塞，并加入到当前所有channel的等待队列中去。

然后解锁所有channel，等待被唤醒。

此时如果有个channel可读或者可写ready了，则唤醒，并再次加锁所有channel，

遍历所有channel找到那个对应的channel和G，唤醒G，并将没有成功的G从所有channel的等待队列中移除。

如果对应的scase值不为空，则返回需要的值，并解锁所有channel

如果对应的scase为空，则循环此过程。

在想想select和channel做了什么事儿，我觉得和多路复用是一回事儿

如何唤醒指定的一个线程

java使用单纯的wait/notify是无法唤醒指定线程的

一般的做法是修改一个特定标识，然后notifyAll，被唤醒的线程查看该标识是否指定自己处理，是就运行下去，不是就继续wait

还有一种做法是针对每一个线程做一个wait object，要唤醒哪一个就notify哪一个object就行了，但是能不能这样做去取决于你的业务需求

线程sleep和wait的区别

sleep()和wait()的区别

Java中的多线程是一种抢占式的机制而不是分时机制。线程主要有以下几种状态：可运行，运行，阻塞，死亡。抢占式机制指的是有多个线程处于可运行状态，但是只有一个线程在运行。

当有多个线程访问共享数据的时候，就需要对线程进行同步。线程中的几个主要方法的比较：

Thread类的方法：sleep(),yield()等

Object的方法：wait()和notify()等

每个对象都有一个机锁来控制同步访问。Synchronized关键字可以和对象的机锁交互，来实现线程的同步。

由于sleep()方法是Thread类的方法，因此它不能改变对象的机锁。所以当在一个Synchronized方法中调用sleep（）时，线程虽然休眠了，但是对象的机锁没有被释放，其他线程仍然无法访问这个对象。而wait()方法则会在线程休眠的同时释放掉机锁，其他线程可以访问该对象。

Yield()方法是停止当前线程，让同等优先权的线程运行。如果没有同等优先权的线程，那么Yield()方法将不会起作用。

一个线程结束的标志是：run()方法结束。

一个机锁被释放的标志是：synchronized块或方法结束。

Wait()方法和notify()方法：当一个线程执行到wait()方法时(线程休眠且释放机锁)，它就进入到一个和该对象相关的等待池中，同时失去了对象的机锁。当它被一个notify()方法唤醒时，等待池中的线程就被放到了锁池中。该线程从锁池中获得机锁，然后回到wait()前的中断现场。

join()方法使当前线程停下来等待，直至另一个调用join方法的线程终止。

值得注意的是：线程的在被激活后不一定马上就运行，而是进入到可运行线程的队列中。

共同点： 他们都是在多线程的环境下，都可以在程序的调用处阻塞指定的毫秒数，并返回。

不同点： Thread.sleep(long)可以不在synchronized的块下调用，而且使用Thread.sleep()不会丢失当前线程对任何对象的同步锁(monitor);

object.wait(long)必须在synchronized的块下来使用，调用了之后失去对object的monitor, 这样做的好处是它不影响其它的线程对object进行操作。

wait()与解锁

如果一个线程在同步中使用了wait()方法,那么它就会释放该对象的锁.同时同步方法就被解开.但是如果不立即使用notify()或notifyAll()方法去唤醒其他正在等待的线程的话,那么该线程就会一直等待下去.而正在等待的其他线程也会一直等待下去.造成程序无法正常运行.

所以wait()和notify()方法始终都是配合起来用,比如两根线程,一个线程调用wait()方法后接着调用nitify()方法唤醒另一个线程,而另一个线程执行完了再调用notify()方法去唤醒第一个线程,然后又调用wait()方法让自己再进入等待.

也就是如此交替下去.

线程中sleep和wait的区别

线程中sleep和wait的区别：

sleep与wait最主要的区别在于，sleep与wait都可以使线程等待，但sleep不会释放资源而wait会释放资源。

代码明示：

public class ThreadTest {

public static void main(String[] args) throws InterruptedException {

new Thread(new Thread1()).start();

synchronized (ThreadTest.class) {

System.out.println("Main Thread go to sleep  : currenttime--"+System.currentTimeMillis());

//sleep过程不会释放资源

Thread.sleep(10000);

}

System.out.println("Main Thread get up : currenttime--"+System.currentTimeMillis());

new Thread(new Thread2()).start();

System.out.println("Main Thread over");

}

static class Thread1 implements Runnable{

@Override

public void run() {

System.out.println("Thread1 is ready :currenttime--"+System.currentTimeMillis());

//因为sleep不会释放资源，所以在主线程sleep结束前，是不能取得资源的锁，而是在等待

synchronized (ThreadTest.class) {

System.out.println("Thread1 is running :currenttime--"+System.currentTimeMillis());

System.out.println("Thread1 wait :currenttime--"+System.currentTimeMillis());

try {

ThreadTest.class.wait();

} catch (InterruptedException e) {

e.printStackTrace();

}              

System.out.println("Thread1 is over ");

}

}

}

static class Thread2 implements Runnable{

@Override

public void run() {

System.out.println("Thread2 is ready :currenttime--"+System.currentTimeMillis());

synchronized (ThreadTest.class){

System.out.println("Thread2 is running :currenttime--"+System.currentTimeMillis());

System.out.println("Thread2 notify :currenttime--"+System.currentTimeMillis());

ThreadTest.class.notify();

System.out.println("Thread2 is over");

}

}

}

}

输出结果：

Main Thread go to sleep  : currenttime--1400232812969

Thread1 is ready :currenttime--1400232812969

Main Thread get up : currenttime--1400232822970

Thread1 is running :currenttime--1400232822970

Thread1 wait :currenttime--1400232822970

Main Thread over

Thread2 is ready :currenttime--1400232822972

Thread2 is running :currenttime--1400232822972

Thread2 notify :currenttime--1400232822972

Thread2 is over

Thread1 is over

由结果可以看出，当主线程sleep10s中的过程，Thread1仅仅处于ready状态，而一直没有获取到ThreadTest.class的锁，原因在于，主线程在sleep的之前已经获取了该资源的锁，这也验证了在用sleep（）的时候不会释放资源。

当主线程sleep完之后，Thread1获取到了ThreadTest.class的锁，然后调用了wait方法(wait方法是Object的静态方法)。在调用该方法后，Thread2启动，且顺利获取到ThreadTest.class的锁，这也验证了在用wait（）方法的时候会释放资源。

最后，在Thread2中调用notify方法（notify方法也是Object的静态方法，作用是唤醒在同步监视器上等待的一个线程），然后看到 "Thread1 is over"。wait 方法与 notify 方法或notifyAll方法 搭配使用，来协调线程运行。如果把Thread2中的notify方法去掉，会发现最后Thread1并没有再次运行，也就不会打印"Thread1 is over"。