协程、进程和线程

一、进程和线程，协程简单对比

1.1 进程和线程

进程是Windows系统中的概念，包含着运行一个程序所需要的基本资源。一个正在运行的应用程序在操作系统中被视为一个进程（是系统进行资源分配和调度的单位），进程可以包括一个或多个线程（通过CPU调度和分派线程，这些线程共享进程资源）。

1.2 线程和协程

Unity是单线程（没用多线程概念，可以写成多线程thread，但是只有主线程才能访问Unity3D的对象、组件、方法）所以增加了一种”伪线程“，协程。

协程（coroutine），一系列互相依赖的协程间依次使用CPU，每次只有一个协程工作，而其他协成处于休眠状态。协程实际上是在一个线程中，只不过每个协程对CPU进行分时，协程可以访问和使用unity的所有方法和component。

　　　　同一时间只能执行某个协程，协程适合对某个任务进行分时处理。

　　　　控制代码在特定的时间执行。

　　　　协程不是线程，也不是异步执行，跟Update一样，在主线程中执行。

　　　　不用考虑同步和锁的问题。

　　　　协程是一个分部组件，遇到条件（yield return）会挂起,直到条件满足才会被唤起执行后面的语句。

优势：

①协程极高的执行效率。因为子程序切换不是线程切换，而是由程序自身控制，因此，没有线程切换的开销，和多线程比，线程数量越多，协程的性能优势就越明显。

协程最开始占用2k，线程是几兆

协程切换为几十纳秒（ns）线程是几微秒，性能快几十倍左右

线程切换由最高权限内核处理，协程程序自己随便玩

参考：https://blog.csdn.net/zhangyanfei01/article/details/100106207

https://www.zhihu.com/question/308641794/answer/572499202

②不需要多线程的锁机制，因为只有一个线程，也不存在同时写变量冲突，在协程中控制共享资源不加锁，只需要判断状态就好了，所以执行效率比多线程高很多

注意：C#中有lock这个关键字,以确保只有一个线程可以在特定时间内访问特定的对象

1.3 堆栈比较

进程拥有自己独立的堆和栈，既不共享堆，亦不共享栈，进程由操作系统调度。

线程拥有自己独立的栈和共享的堆，共享堆，不共享栈，线程亦由操作系统调度(标准线程是的)。

协程和线程一样共享堆，不共享栈，协程由程序员在协程的代码里显示调度。

二、协程详细

2.1 什么是协同程序？

在主线程运行时同时开启另一段逻辑处理，来协助当前程序的执行。换句话说，开启协程就是开启一个线程。可以用来控制运动、序列以及对象的行为。

协程很像多线程，但是不是多线程，实际运行在主线程，没有共享内存加锁，可能会发生堵塞.

Unity的协程实在每帧结束之后去检测yield的条件是否满足。

2.2 协同程序的开启与终止

       在Unity3D中，使用MonoBehaviour.StartCoroutine方法即可开启一个协同程序，也就是说该方法必须在MonoBehaviour或继承于MonoBehaviour的类中调用。

       在Unity3D中，使用StartCoroutine(string  methodName)和StartCoroutine(IEnumerator  routine)都可以开启一个线程。区别在于使用字符串作为参数可以开启线程并在线程结束前终止线程，相反使用IEnumerator 作为参数只能等待线程的结束而不能随时终止(除非使用StopAllCoroutines()方法)；另外使用字符串作为参数时，开启线程时最多只能传递 一个参数，并且性能消耗会更大一点，而使用IEnumerator 作为参数则没有这个限制。

        在Unity3D中，使用StopCoroutine(string  methodName)来终止一个协同程序，使用StopAllCoroutines()来终止所有可以终止的协同程序，但这两个方法都只能终止该MonoBehaviour中的协同程序。

        还有一种方法可以终止协同程序，即将协同程序所在gameobject的active属性设置为false，当再次设置active为ture时，协同程 序并不会再开启；如是将协同程序所在脚本的enabled设置为false则不会生效。这是因为协同程序被开启后作为一个线程在运行，而MonoBehaviour也是一个线程，他们成为互不干扰的模块，除非代码中用调用，他们共同作用于同一个对象，只有当对象不可见才能同时终止这两个线 程。然而，为了管理我们额外开启的线程，Unity3D将协同程序的调用放在了MonoBehaviour中，这样我们在编程时就可以方便的调用指定脚本 中的协同程序，而不是无法去管理，特别是对于只根据方法名来判断线程的方式在多人开发中很容易出错，这样的设计保证了对象、脚本的条理化管理，并防止了重 名。