《2019年进程通信和线程间通信 1.doc》由会员分享，可在线阅读，更多相关《2019年进程通信和线程间通信 1.doc（15页珍藏版）》请在三一文库上搜索。
1、进程通信和线程间通信 1进程通信和线程间通信(1)2010-04-09 15：32进程间通信与线程间通信Linux下进程间通信(IPC)的方式数不胜数，光UNPv2列出的就有：pipe、FIFO、POSIX消息队列、共享内存、信号(signals)等等，更不必说Sockets了。同步原语(synchronization primitives)也很多，互斥器(mutex)、条件变量(condition variable)、读写锁(reader-writer lock)、文件锁(Record locking)、信号量(Semaphore)等等。如何选择呢?根据我的个人经验，贵精不贵多，认真挑选三四
2、样东西就能完全满足我的工作需要，而且每样我都能用得很熟,，不容易犯错。5进程间通信进程间通信我首选Sockets(主要指TCP，我没有用过UDP，也不考虑Unix domain协议)，其最大的好处在于：可以跨主机，具有伸缩性。反正都是多进程了，如果一台机器处理能力不够，很自然地就能用多台机器来处理。把进程分散到同一局域网的多台机器上，程序改改host：port配置就能继续用。相反，前面列出的其他IPC都不能跨机器(比如共享内存效率最高，但再怎么着也不能高效地共享两台机器的内存)，限制了scalability。在编程上，TCP sockets和pipe都是一个文件描述符，用来收发字节流，都可以r
3、ead/write/fcntl/select/poll等。不同的是，TCP是双向的，pipe是单向的(Linux)，进程间双向通讯还得开两个文件描述符，不方便；而且进程要有父子关系才能用pipe，这些都限制了pipe的使用。在收发字节流这一通讯模型下，没有比sockets/TCP更自然的IPC了。当然，pipe也有一个经典应用场景，那就是写Reactor/Selector时用来异步唤醒select(或等价的poll/epoll)调用(Sun JVM在Linux就是这么做的)。TCP port是由一个进程独占，且操作系统会自动回收(listening port和已建立连接的TCP socket都
4、是文件描述符，在进程结束时操作系统会关闭所有文件描述符)。这说明，即使程序意外退出，也不会给系统留下垃圾，程序重启之后能比较容易地恢复，而不需要重启操作系统(用跨进程的mutex就有这个风险)。还有一个好处，既然port是独占的，那么可以防止程序重复启动(后面那个进程抢不到port，自然就没法工作了)，造成意料之外的结果。两个进程通过TCP通信，如果一个崩溃了，操作系统会关闭连接，这样另一个进程几乎立刻就能感知，可以快速failover。当然，应用层的心跳也是必不可少的，我以后在讲服务端的日期与时间处理的时候还会谈到心跳协议的设计。与其他IPC相比，TCP协议的一个自然好处是可记录可重现，tc
5、pdump/Wireshark是解决两个进程间协议/状态争端的好帮手。另外，如果网络库带连接重试功能的话，我们可以不要求系统里的进程以特定的顺序启动，任何一个进程都能单独重启，这对开发牢靠的分布式系统意义重大。使用TCP这种字节流(byte stream)方式通信，会有marshal/unmarshal的开销，这要求我们选用合适的消息格式，准确地说是wire format。这将是我下一篇blog的主题，目前我推荐Google Protocol Buffers。有人或许会说，具体问题具体分析，如果两个进程在同一台机器，就用共享内存，否则就用TCP，比如MS SQL Server就同时支持这两种通
6、信方式。我问，是否值得为那么一点性能提升而让代码的复杂度大大增加呢?TCP是字节流协议，只能顺序读取，有写缓冲；共享内存是消息协议，a进程填好一块内存让b进程来读，基本是停等方式。要把这两种方式揉到一个程序里，需要建一个抽象层，封装两种IPC。这会带来不透明性，并且增加测试的复杂度，而且万一通信的某一方崩溃，状态reconcile也会比sockets麻烦。为我所不取。再说了，你舍得让几万块买来的SQL Server和你的程序分享机器资源吗?产品里的数据库服务器往往是独立的高配置服务器，一般不会同时运行其他占资源的程序。TCP本身是个数据流协议，除了直接使用它来通信，还可以在此之上构建RPC/R
7、EST/SOAP之类的上层通信协议，这超过了本文的范围。另外，除了点对点的通信之外，应用级的广播协议也是非常有用的，可以方便地构建可观可控的分布式系统。本文不具体讲Reactor方式下的网络编程，其实这里边有很多值得注意的地方，比如带back off的retry connecting，用优先队列来组织timer等等，留作以后分析吧。6线程间同步线程同步的四项原则，按重要性排列：1.首要原则是尽量最低限度地共享对象，减少需要同步的场合。一个对象能不暴露给别的线程就不要暴露；如果要暴露，优先考虑immutable对象；实在不行才暴露可修改的对象，并用同步措施来充分保护它。2.其次是使用高级的并发编
8、程构件，如TaskQueue、Producer-Consumer Queue、CountDownLatch等等；3.最后不得已必须使用底层同步原语(primitives)时，只用非递归的互斥器和条件变量，偶尔用一用读写锁；4.不自己编写lock-free代码，不去凭空猜测哪种做法性能会更好，比如spin lock vs.mutex。前面两条很容易理解，这里着重讲一下第3条：底层同步原语的使用。互斥器(mutex)互斥器(mutex)恐怕是使用得最多的同步原语，粗略地说，它保护了临界区，一个时刻最多只能有一个线程在临界区内活动。(请注意，我谈的是pthreads里的mutex，不是Windows
9、里的重量级跨进程Mutex。)单独使用mutex时，我们主要为了保护共享数据。我个人的原则是：l用RAII手法封装mutex的创建、销毁、加锁、解锁这四个操作。l只用非递归的mutex(即不可重入的mutex)。l不手工调用lock()和unlock()函数，一切交给栈上的Guard对象的构造和析构函数负责，Guard对象的生命期正好等于临界区(分析对象在什么时候析构是C+程序员的基本功)。这样我们保证在同一个函数里加锁和解锁，避免在foo()里加锁，然后跑到bar()里解锁。l在每次构造Guard对象的时候，思考一路上(调用栈上)已经持有的锁，防止因加锁顺序不同而导致死锁(deadlock)
10、。由于Guard对象是栈上对象，看函数调用栈就能分析用锁的情况，非常便利。次要原则有：l不使用跨进程的mutex，进程间通信只用TCP sockets。l加锁解锁在同一个线程，线程a不能去unlock线程b已经锁住的mutex。(RAII自动保证)l别忘了解锁。(RAII自动保证)l不重复解锁。(RAII自动保证)l必要的时候可以考虑用PTHREAD_MUTEX_ERRORCHECK来排错用RAII封装这几个操作是通行的做法，这几乎是C+的标准实践，后面我会给出具体的代码示例，相信大家都已经写过或用过类似的代码了。Java里的synchronized语句和C#的using语句也有类似的效果，即
11、保证锁的生效期间等于一个作用域，不会因异常而忘记解锁。Mutex恐怕是最简单的同步原语，安照上面的几条原则，几乎不可能用错。我自己从来没有违背过这些原则，编码时出现问题都很快能招到并修复。跑题：非递归的mutex谈谈我坚持使用非递归的互斥器的个人想法。Mutex分为递归(recursive)和非递归(non-recursive)两种，这是POSIX的叫法，另外的名字是可重入(Reentrant)与非可重入。这两种mutex作为线程间(inter-thread)的同步工具时没有区别，它们的惟一区别在于：同一个线程可以重复对recursive mutex加锁，但是不能重复对non-recursiv
12、e mutex加锁。首选非递归mutex，绝对不是为了性能，而是为了体现设计意图。non-recursive和recursive的性能差别其实不大，因为少用一个计数器，前者略快一点点而已。在同一个线程里多次对non-recursive mutex加锁会立刻导致死锁，我认为这是它的优点，能帮助我们思考代码对锁的期求，并且及早(在编码阶段)发现问题。毫无疑问recursive mutex使用起来要方便一些，因为不用考虑一个线程会自己把自己给锁死了，我猜这也是Java和Windows默认提供recursive mutex的原因。(Java语言自带的intrinsic lock是可重入的，它的conc
13、urrent库里提供ReentrantLock，Windows的CRITICAL_SECTION也是可重入的。似乎它们都不提供轻量级的non-recursive mutex。)正因为它方便，recursive mutex可能会隐藏代码里的一些问题。典型情况是你以为拿到一个锁就能修改对象了，没想到外层代码已经拿到了锁，正在修改(或读取)同一个对象呢。具体的例子：std：vector foos；MutexLock mutex；void post(const Foo&f)MutexLockGuard lock(mutex)；foos.push_back(f)；void traverse()Mutex
14、LockGuard lock(mutex)；for(auto it=foos.begin()；it！=foos.end()；+it)/用了0x新写法it-doit()；post()加锁，然后修改foos对象；traverse()加锁，然后遍历foos数组。将来有一天，Foo：doit()间接调用了post()(这在逻辑上是错误的)，那么会很有戏剧性的：1.Mutex是非递归的，于是死锁了。2.Mutex是递归的，由于push_back可能(但不总是)导致vector迭代器失效，程序偶尔会crash。这时候就能体现non-recursive的优越性：把程序的逻辑错误暴露出来。死锁比较容易debu
15、g，把各个线程的调用栈打出来(gdb)thread apply all bt)，只要每个函数不是特别长，很容易看出来是怎么死的。(另一方面支持了函数不要写过长。)或者可以用PTHREAD_MUTEX_ERRORCHECK一下子就能找到错误(前提是MutexLock带debug选项。)程序反正要死，不如死得有意义一点，让验尸官的日子好过些。如果一个函数既可能在已加锁的情况下调用，又可能在未加锁的情况下调用，那么就拆成两个函数：1.跟原来的函数同名，函数加锁，转而调用第2个函数。2.给函数名加上后缀WithLockHold，不加锁，把原来的函数体搬过来。就像这样：void post(const F
16、oo&f)MutexLockGuard lock(mutex)；postWithLockHold(f)；/不用担心开销，编译器会自动内联的/引入这个函数是为了体现代码作者的意图，尽管push_back通常可以手动内联void postWithLockHold(const Foo&f)foos.push_back(f)；这有可能出现两个问题(感谢水木网友ilovecpp提出)：a)误用了加锁版本，死锁了。b)误用了不加锁版本，数据损坏了。对于a)，仿造前面的办法能比较容易地排错。对于b)，如果pthreads提供isLocked()就好办，可以写成：void postWithLockHold(c
17、onst Foo&f)assert(mutex.isLocked()；/目前只是一个愿望/.另外，WithLockHold这个显眼的后缀也让程序中的误用容易暴露出来。C+没有annotation，不能像Java那样给method或field标上GuardedBy注解，需要程序员自己小心在意。虽然这里的办法不能一劳永逸地解决全部多线程错误，但能帮上一点是一点了。我还没有遇到过需要使用recursive mutex的情况，我想将来遇到了都可以借助wrapper改用non-recursive mutex，代码只会更清晰。=回到正题=本文这里只谈了mutex本身的正确使用，在C+里多线程编程还会遇到其
18、他很多race condition，请参考拙作当析构函数遇到多线程-C+中线程安全的对象回调。请注意这里的class命名与那篇文章有所不同。我现在认为MutexLock和MutexLockGuard是更好的名称。性能注脚：Linux的pthreads mutex采用futex实现，不必每次加锁解锁都陷入系统调用，效率不错。Windows的CRITICAL_SECTION也是类似。条件变量条件变量(condition variable)顾名思义是一个或多个线程等待某个布尔表达式为真，即等待别的线程唤醒它。条件变量的学名叫管程(monitor)。Java Object内置的wait(),notif
19、y(),notifyAll()即是条件变量(它们以容易用错著称)。条件变量只有一种正确使用的方式，对于wait()端：1.必须与mutex一起使用，该布尔表达式的读写需受此mutex保护2.在mutex已上锁的时候才能调用wait()3.把判断布尔条件和wait()放到while循环中写成代码是：MutexLock mutex；Condition cond(mutex)；std：deque queue；int dequeue()MutexLockGuard lock(mutex)；while(queue.empty()/必须用循环；必须在判断之后再wait()cond.wait()；/这一步会
20、原子地unlock mutex并进入blocking，不会与enqueue死锁assert(！queue.empty()；int top=queue.front()；queue.pop_front()；return top；对于signal/broadcast端：1.不一定要在mutex已上锁的情况下调用signal(理论上)2.在signal之前一般要修改布尔表达式3.修改布尔表达式通常要用mutex保护(至少用作full memory barrier)写成代码是：void enqueue(int x)MutexLockGuard lock(mutex)；queue.push_back(x)
21、；cond.notify()；上面的dequeue/enqueue实际上实现了一个简单的unbounded BlockingQueue。条件变量是非常底层的同步原语，很少直接使用，一般都是用它来实现高层的同步措施，如BlockingQueue或CountDownLatch。读写锁与其他读写锁(Reader-Writer lock)，读写锁是个优秀的抽象，它明确区分了read和write两种行为。需要注意的是，reader lock是可重入的，writer lock是不可重入(包括不可提升reader lock)的。这正是我说它优秀的主要原因。遇到并发读写，如果条件合适，我会用借shared_p
22、tr实现线程安全的copy-on-write介绍的办法，而不用读写锁。当然这不是绝对的。信号量(Semaphore)，我没有遇到过需要使用信号量的情况，无从谈及个人经验。说一句大逆不道的话，如果程序里需要解决如哲学家就餐之类的复杂IPC问题，我认为应该首先考察几个设计，为什么线程之间会有如此复杂的资源争抢(一个线程要同时抢到两个资源，一个资源可以被两个线程争夺)?能不能把想吃饭这个事情专门交给一个为各位哲学家分派餐具的线程来做，然后每个哲学家等在一个简单的condition variable上，到时间了有人通知他去吃饭?从哲学上说，教科书上的解决方案是平权，每个哲学家有自己的线程，自己去拿筷子
23、；我宁愿用集权的方式，用一个线程专门管餐具的分配，让其他哲学家线程拿个号等在食堂门口好了。这样不损失多少效率，却让程序简单很多。虽然Windows的WaitForMultipleObjects让这个问题trivial化，在Linux下正确模拟WaitForMultipleObjects不是普通程序员该干的。封装MutexLock、MutexLockGuard和Condition本节把前面用到的MutexLock、MutexLockGuard、Condition classes的代码列出来，前面两个classes没多大难度，后面那个有点意思。MutexLock封装临界区(Critical sec
24、ion)，这是一个简单的资源类，用RAII手法CCS：13封装互斥器的创建与销毁。临界区在Windows上是CRITICAL_SECTION，是可重入的；在Linux下是pthread_mutex_t，默认是不可重入的。MutexLock一般是别的class的数据成员。MutexLockGuard封装临界区的进入和退出，即加锁和解锁。MutexLockGuard一般是个栈上对象，它的作用域刚好等于临界区域。这两个classes应该能在纸上默写出来，没有太多需要解释的：#include#include class MutexLock：boost：noncopyable public：MutexL
25、ock()/为了节省版面，单行函数都没有正确缩进pthread_mutex_init(&mutex_,NULL)；MutexLock()pthread_mutex_destroy(&mutex_)；void lock()/程序一般不主动调用pthread_mutex_lock(&mutex_)；void unlock()/程序一般不主动调用pthread_mutex_unlock(&mutex_)；pthread_mutex_t*getPthreadMutex()/仅供Condition调用，严禁自己调用return&mutex_；private：pthread_mutex_t mutex_；
26、class MutexLockGuard：boost：noncopyable public：explicit MutexLockGuard(MutexLock&mutex)：mutex_(mutex)mutex_.lock()；MutexLockGuard()mutex_.unlock()；private：MutexLock&mutex_；#define MutexLockGuard(x)static_assert(false,missing mutex guard var name)注意代码的最后一行定义了一个宏，这个宏的作用是防止程序里出现如下错误：void doit()MutexLock
27、Guard(mutex)；/没有变量名，产生一个临时对象又马上销毁了，没有锁住临界区/正确写法是MutexLockGuard lock(mutex)；/临界区这里MutexLock没有提供trylock()函数，因为我没有用过它，我想不出什么时候程序需要试着去锁一锁，或许我写过的代码太简单了。我见过有人把MutexLockGuard写成template，我没有这么做是因为它的模板类型参数只有MutexLock一种可能，没有必要随意增加灵活性，于是我人肉把模板具现化(instantiate)了。此外一种更激进的写法是，把lock/unlock放到private区，然后把Guard设为MutexL
28、ock的friend，我认为在注释里告知程序员即可，另外check-in之前的code review也很容易发现误用的情况(grep getPthreadMutex)。这段代码没有达到工业强度：a)Mutex创建为PTHREAD_MUTEX_DEFAULT类型，而不是我们预想的PTHREAD_MUTEX_NORMAL类型(实际上这二者很可能是等同的)，严格的做法是用mutexattr来显示指定mutex的类型。b)没有检查返回值。这里不能用assert检查返回值，因为assert在release build里是空语句。我们检查返回值的意义在于防止ENOMEM之类的资源不足情况，这一般只可能在负
29、载很重的产品程序中出现。一旦出现这种错误，程序必须立刻清理现场并主动退出，否则会莫名其妙地崩溃，给事后调查造成困难。这里我们需要non-debug的assert，或许google-glog的CHECK()是个不错的思路。以上两点改进留作练习。Condition class的实现有点意思。Pthreads condition variable允许在wait()的时候指定mutex，但是我想不出什么理由一个condition variable会和不同的mutex配合使用。Java的intrinsic condition和Conditon class都不支持这么做，因此我觉得可以放弃这一灵活性，老老
30、实实一对一好了。相反boost：thread的condition_varianle是在wait的时候指定mutex，请参观其同步原语的庞杂设计：l Concept有四种Lockable,TimedLockable,SharedLockable,UpgradeLockable.l Lock有五六种：lock_guard,unique_lock,shared_lock,upgrade_lock,upgrade_to_unique_lock,scoped_try_lock.l Mutex有七种：mutex,try_mutex,timed_mutex,recursive_mutex,recursive
31、_try_mutex,recursive_timed_mutex,shared_mutex.恕我愚钝，见到boost：thread这样如Rube Goldberg Machine一样灵活的库我只得三揖绕道而行。这些class名字也很无厘头，为什么不老老实实用reader_writer_lock这样的通俗名字呢?非得增加精神负担，自己发明新名字。我不愿为这样的灵活性付出代价，宁愿自己做几个简简单单的一看就明白的classes来用，这种简单的几行代码的轮子造造也无妨。提供灵活性固然是本事，然而在不需要灵活性的地方把代码写死，更需要大智慧。下面这个Condition简单地封装了pthread con
32、d var，用起来也容易，见本节前面的例子。这里我用notify/notifyAll作为函数名，因为signal有别的含义，C+里的signal/slot，C里的signal handler等等。就别overload这个术语了。class Condition：boost：noncopyable public：Condition(MutexLock&mutex)：mutex_(mutex)pthread_cond_init(&pcond_,NULL)；Condition()pthread_cond_destroy(&pcond_)；void wait()pthread_cond_wait(&pc
33、ond_,mutex_.getPthreadMutex()；void notify()pthread_cond_signal(&pcond_)；void notifyAll()pthread_cond_broadcast(&pcond_)；private：MutexLock&mutex_；pthread_cond_t pcond_；如果一个class要包含MutexLock和Condition，请注意它们的声明顺序和初始化顺序，mutex_应先于condition_构造，并作为后者的构造参数：class CountDownLatch public：CountDownLatch(int coun
34、t)：count_(count),mutex_(),condition_(mutex_)private：int count_；MutexLock mutex_；/顺序很重要Condition condition_；请允许我再次强调，虽然本节花了大量篇幅介绍如何正确使用mutex和condition variable，但并不代表我鼓励到处使用它们。这两者都是非常底层的同步原语，主要用来实现更高级的并发编程工具，一个多线程程序里如果大量使用mutex和condition variable来同步，基本跟用铅笔刀锯大树(孟岩语)没啥区别。线程安全的Singleton实现研究Signleton的线程安全
35、实现的历史你会发现很多有意思的事情，一度人们认为Double checked locking是王道，兼顾了效率与正确性。后来有神牛指出由于乱序执行的影响，DCL是靠不住的。(这个又让我想起了SQL注入，十年前用字符串拼接出SQL语句是Web开发的通行做法，直到有一天有人利用这个漏洞越权获得并修改网站数据，人们才幡然醒悟，赶紧修补。)Java开发者还算幸运，可以借助内部静态类的装载来实现。C+就比较惨，要么次次锁，要么eager initialize、或者动用memory barrier这样的大杀器。接下来Java 5修订了内存模型，并增强了volatile的语义，这下DCL(with vola
36、tile)又是安全的了。然而C+的内存模型还在修订中，C+的volatile目前还不能(将来也难说)保证DCL的正确性(只在VS2005+上有效)。其实没那么麻烦，在实践中用pthread once就行：#include template class Singleton：boost：noncopyable public：static T&instance()pthread_once(&ponce_,&Singleton：init)；return*value_；static void init()value_=new T()；private：static pthread_once_t ponce
37、_；static T*value_；template pthread_once_t Singleton：ponce_=PTHREAD_ONCE_INIT；template T*Singleton：value_=NULL；上面这个Singleton没有任何花哨的技巧，用pthread_once_t来保证lazy-initialization的线程安全。使用方法也很简单：Foo&foo=Singleton：instance()；当然，这个Singleton没有考虑对象的销毁，在服务器程序里，这不是一个问题，因为当程序退出的时候自然就释放所有资源了(前提是程序里不使用不能由操作系统自动关闭的资源，比
38、如跨进程的Mutex)。另外，这个Singleton只能调用默认构造函数，如果用户想要指定T的构造方式，我们可以用模板特化(template specialization)技术来提供一个定制点，这需要引入另一层间接。归纳l进程间通信首选TCP sockets l线程同步的四项原则l使用互斥器的条件变量的惯用手法(idiom)，关键是RAII用好这几样东西，基本上能应付多线程服务端开发的各种场合，只是或许有人会觉得性能没有发挥到极致。我认为，先把程序写正确了，再考虑性能优化，这在多线程下任然成立。让一个正确的程序变快，远比让一个快的程序变正确容易得多。7总结在现代的多核计算背景下，线程是不可避免
39、的。多线程编程是一项重要的个人技能，不能因为它难就本能地排斥，现在的软件开发比起10年20年前已经难了不知道多少倍。掌握多线程编程，才能更理智地选择用还是不用多线程，因为你能预估多线程实现的难度与收益，在一开始做出正确的选择。要知道把一个单线程程序改成多线程的，往往比重头实现一个多线程的程序更难。掌握同步原语和它们的适用场合时多线程编程的基本功。以我的经验，熟练使用文中提到的同步原语，就能比较容易地编写线程安全的程序。本文没有考虑signal对多线程编程的影响，Unix的signal在多线程下的行为比较复杂，一般要靠底层的网络库(如Reactor)加以屏蔽，避免干扰上层应用程序的开发。通篇来看
40、，效率并不是我的主要考虑点，a)TCP不是效率最高的IPC，b)我提倡正确加锁而不是自己编写lock-free算法(使用原子操作除外)。在程序的复杂度和性能之前取得平衡，并经考虑未来两三年扩容的可能(无论是CPU变快、核数变多，还是机器数量增加，网络升级)。下一篇多线程编程的反模式会考察伸缩性方面的常见错误，我认为在分布式系统中，伸缩性(scalability)比单机的性能优化更值得投入精力。这篇文章记录了我目前对多线程编程的理解，用文中介绍的手法，我能解决自己面临的全部多线程编程任务。如果文章的观点与您不合，比如您使用了我没有推荐使用的技术或手法(共享内存、信号量等等)，只要您理由充分，但行
41、无妨。这篇文章本来还有两节多线程编程的反模式与多线程的应用场景，考虑到字数已经超过一万了，且听下回分解吧后文预览：Sleep反模式我认为sleep只能出现在测试代码中，比如写单元测试的时候。(涉及时间的单元测试不那么好写，短的如一两秒钟可以用sleep，长的如一小时一天得想其他办法，比如把算法提出来并把时间注入进去。)产品代码中线程的等待可分为两种：一种是无所事事的时候(要么等在select/poll/epoll上。要么等在condition variable上，等待BlockingQueue/CountDownLatch亦可归入此类)，一种是等着进入临界区(等在mutex上)以便继续处理。在程序的正常执行中，如果需要等待一段时间，应该往event loop里注册一个timer，然后在timer的回调函数里接着干活，因为线程是个珍贵的共享资源，不能轻易浪费。如果多线程的安全性和效率要靠代码主动调用sleep来保证，这是设计出了问题。等待一个事件发生，正确的做法是用select或condition variable或(更理想地)高层同步工具。当然，在GUI编程中会有主动让出CPU的做法，比如调用sleep(0)来实现yield。特别声明：1：资料来源于互联网，版权归属原作者2：资料内容属于网络意见，与本账号立场无关3：如有侵权，请告知，立即删除。105103105822