一种任务异步执行方法、装置及系统与流程

本申请涉及计算机技术领域，尤其涉及一种任务异步执行方法、装置及系统。

背景技术：

目前，处理器上可以运行多个应用程序，客户端可以向处理器中应用程序发送任务。

为了提高应用程序中任务的处理速率，目前处理器可以构建线程池。线程池为处理器的操作系统中预先建立的多个线程的集合；其中，线程为操作系统能够进行运算调度的最小单位，通俗来讲线程可以看成任务的执行单元。为了处理应用程序中的任务，处理器可以为每个应用程序分配一个线程，由线程来处理应用程序中的任务。由于处理器可以并发处理多个线程，所以处理器可以并发处理多个应用程序中的任务，从而提高应用程序中任务的处理效率。

线程在运行过程中具有三种状态：运行状态、就绪状态和阻塞状态。其中，当线程执行任务的数据没有到位时，则线程为阻塞状态；当线程执行任务的所需数据到位，但是处理器无法向该线程提供cpu资源时，则线程为就绪状态；当线程既有执行任务的所需数据又有处理器提供的cpu资源时，则线程为运行状态。

在线程处理任务的过程中难免会遇到阻塞状态，此时线程无法继续执行任务，这会导致线程无法执行应用程序中其它任务。为此目前线程在执行任务时，首先会预判执行该任务是否有出现阻塞状态的可能；如果有，向线程池应用程序接口(applicationprograminterface，api)发送该任务，线程池api会将该任务发送至线程池的任务队列，线程池中的线程可以在任务队列中获取该任务从而处理该任务。如果无，则线程继续执行该任务。

在线程池调度处理该任务的过程中，线程池首先为该任务分配一个空闲线程，当该空闲线程在执行该任务的过程中遇到阻塞或者处理器为其分配使用时间用完时，会调度到线程池的另一个空闲线程中，直到该任务处理结束。

在处理器的线程池切换线程的过程中，需要cpu陷入操作系统内核来做线程切换，当线程切换较为频繁时会浪费cpu的执行时间并影响处理器性能。并且，在线程池中多个线程之间可以并发进行，在多个线程访问同一变量时，需要采用锁机制来维持变量的数据同步。但是，各个线程在使用锁的过程中会存在激烈的竞争，这也影响处理器性能。

技术实现要素：

本申请提供了一种任务处理方法、装置及系统，不再由线程池来处理可能出现阻塞的任务，从而解决由线程池处理可能出现阻塞的任务而引起的增加cpu的消耗且影响处理器的性能的问题。

为了实现上述目的，本申请提供了以下技术手段：

一种任务异步执行方法，所述方法包括：

在当前线程通过线程池api计划向线程池提交当前任务的情况下，在所述当前线程下为所述当前任务建立对应的当前协程；其中，所述当前任务为所述当前线程确定在执行过程中可能出现阻塞的任务；

利用所述当前协程处理所述当前任务。

优选的，所述利用所述当前协程处理所述当前任务，包括：

在所述当前协程处理所述当前任务的过程中，若所述当前协程未出现阻塞状态，则在所述当前任务结束之后，销毁所述当前协程。

优选的，所述利用所述当前协程处理所述当前任务，包括：

在所述当前协程处理所述当前任务的过程中，若所述当前协程出现阻塞状态，则挂起所述当前协程；

切换至所述当前线程下的一个未阻塞协程；

控制所述当前线程的cpu资源，执行所述未阻塞协程。

优选的，所述切换至所述当前线程下的一个未阻塞协程，包括：

判断所述当前协程的父协程、唤醒协程队列或io协程队列中是否具有非阻塞协程；

若有，切换至所述当前协程的父协程、所述唤醒协程队列或所述io协程队列中一个非阻塞协程；

若无，则判断超时协程队列中是否具有非阻塞协程；

若所述超时协程队列中具有非阻塞协程，则切换至所述超时协程队列中一个非阻塞协程；

若所述超时协程队列中不具有非阻塞协程，则在时间间隔内判断是否监听到io事件或唤醒事件；

若在所述时间间隔内监听到io事件或唤醒事件，则进入判断所述当前协程的父协程、唤醒协程队列或io协程队列中是否具有非阻塞协程的步骤；

若在所述时间间隔内未监听到io事件或唤醒事件，则进入判断超时协程队列中是否具有非阻塞协程的步骤。

优选的，所述时间间隔为超时协程队列中最小的剩余时间；其中，所述剩余时间为预设超时时间与存在于所述超时协程队列的时间的差值。

优选的，在所述当前协程出现阻塞状态之后，还包括：

在所述当前协程的阻塞状态置有超时时间的情况下，将所述当前协程的标识信息和当前时间加入至超时协程队列；

在所述当前协程的阻塞状态由io阻塞引起的情况下，将引起所述当前协程出现io阻塞的io事件和当前协程的标识信息，一并注册至io事件监听器。

优选的，所述利用所述当前协程处理所述当前任务，包括：

在所述当前协程处理所述当前任务的过程中，若接收到新任务，则依据所述新任务，并以所述当前协程为父协程新建子协程；

利用所述子协程处理所述新任务。

一种任务异步执行装置，所述装置包括：

建立单元，用于在当前线程通过线程池api计划向线程池提交当前任务的情况下，在所述当前线程下为所述当前任务建立对应的当前协程；其中，所述当前任务为所述当前线程确定在执行过程中可能出现阻塞的任务；

处理单元，用于利用所述当前协程处理所述当前任务。

优选的，所述处理单元，包括：

销毁单元，用于在所述当前协程处理所述当前任务的过程中，若所述当前协程未出现阻塞状态，则在所述当前任务结束之后，销毁所述当前协程。

优选的，所述处理单元，包括：

挂起单元，用于在所述当前协程处理所述当前任务的过程中，若所述当前协程出现阻塞状态，则挂起所述当前协程；

切换单元，用于切换至所述当前线程下的一个未阻塞协程；

执行单元，用于控制所述当前线程的cpu资源，执行所述未阻塞协程。

优选的，所述切换单元，包括：

第一判断单元，用于判断所述当前协程的父协程、唤醒协程队列或io协程队列中是否具有非阻塞协程；

第一切换协程单元，用于在所述第一判断单元为是的情况下，切换至所述当前协程的父协程、唤醒协程队列或io协程队列中一个非阻塞协程；

第二判断单元，用于在所述第一判断单元为否的情况下，判断超时协程队列中是否具有非阻塞协程；

第二切换协程单元，用于在所述第二判断单元为是的情况下，切换若所述超时协程队列中具有非阻塞协程，则切换至所述超时协程队列中一个非阻塞协程；

第三判断单元，用于在所述第二判断单元为否的情况下，在时间间隔内判断是否监听到io事件或唤醒事件；在所述时间间隔内监听到io事件或唤醒事件的情况下，触发所述第一判断单元；在所述时间间隔内未监听到io事件或唤醒事件的情况下，则触发第二判断单元。

优选的，所述时间间隔为超时协程队列中最小的剩余时间；其中，所述剩余时间为预设超时时间与存在于所述超时协程队列的时间的差值。

优选的，还包括：

加入单元，用于在所述当前协程的阻塞状态置有超时时间的情况下，将所述当前协程的标识信息和当前时间加入至超时协程队列；

注册单元，用于在所述当前协程的阻塞状态由io阻塞引起的情况下，将引起所述当前协程出现io阻塞的io事件和当前协程的标识信息，一并注册至io事件监听器。

优选的，所述处理单元，包括：

新建单元，用于在所述当前协程处理所述当前任务的过程中，若接收到新任务，则依据所述新任务，并以所述当前协程为父协程新建子协程；

处理新任务单元，用于利用所述子协程处理所述新任务。

一种任务异步执行系统，包括：

客户端和服务器；其中，所述服务器运行有多个应用程序；

所述客户端，用于向服务器中应用程序发送任务；

所述服务器，用于在当前线程通过线程池api计划向线程池提交当前任务的情况下，在所述当前线程下为所述当前任务建立对应的当前协程；其中，所述当前任务为所述当前线程确定在执行过程中可能出现阻塞的任务；利用所述当前协程处理所述当前任务。

通过以技术手段，可以看出本申请具有以下有益效果：

本申请在应用程序的当前线程确定执行当前任务可能出现阻塞时，不再将当前任务发送至线程池的任务队列，即不再由线程池调度处理当前任务；而是在当前线程下新建协程，由协程来处理当前任务。所以，本申请可以解决由线程池来处理可能出现阻塞的任务而引起的增加cpu的消耗且影响处理器的性能的问题。

此外，由于协程是一种用户级的轻量级线程，即协程存在于用户空间。因此，协程的切换不需要深入处理器的内核空间，仅在处理器的用户空间便可以切换；因此协程的切换消耗较少的cpu资源，从而提高处理器性能。

并且，多个协程之间采用协作式多任务的方式。协作式多任务的方式在同一时刻仅有一个协程在执行，不会出现多个协程同时执行的情况。因此，在使用协程时无需采用锁机制来维持变量的数据同步，这可以进一步提高处理器性能。

并且，本申请中执行应用程序中任务的当前线程，仍然会调用线程池api计划向线程池的任务队列发送当前任务。不同的是，处理器改变了线程池api逻辑，使得线程池api不再将当前任务发送至任务队列，而是在当前线程下新建协程。因此，处理器上的应用程序不必进行任何改变，本申请的执行过程相对于应用程序而言是透明的。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例公开的任务异步执行方法的流程图；

图2为本申请实施例公开的又一任务异步执行方法的流程图；

图3为本申请实施例公开的又一任务异步执行方法的流程图；

图4为本申请实施例公开的又一任务异步执行方法的流程图；

图5为本申请实施例公开的任务异步执行装置的结构示意图；

图6为本申请实施例公开的又一任务异步执行装置的结构示意图；

图7为本申请实施例公开的又一任务异步执行装置的结构示意图；

图8为本申请实施例公开的又一任务异步执行装置的结构示意图；

图9为本申请实施例公开的任务异步执行系统的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请发明人在研究背景技术的过程中发现：

针对本申请所示的背景技术而言，影响处理器性能的根本原因在于：线程将可能阻塞的任务发送至线程池，由线程池来调度处理该任务。这导致线程池需要频繁进行线程切换，以及频繁用锁机制来保证数据同步，进而增加cpu的消耗，影响处理器的性能。

因此，申请人设想在线程确定执行任务有出现阻塞的可能时，不再将该任务发送至线程池、由线程池来处理任务，而是采用其它方式来处理该任务，从而解决由线程池处理可能出现阻塞的任务而引起的增加cpu的消耗且影响处理器的性能的问题。

下面详细介绍本申请如何采用其它方式来处理可能出现阻塞的任务。

可以理解的是，当前线程在一段时间内可能确定多个可能出现阻塞的任务，由于针对每个可能出现阻塞的任务的处理过程均是一致的，所以本申请仅以当前任务为例对任务异步执行方法进行详细描述，其它任务的执行过程与当前任务类似，因此不再赘述。

本申请提供的任务异步执行方法，应用于处理器。本申请所指的处理器可以是pc机的处理器，指服务器，还可以是移动设备的处理器。

在详细介绍具体执行过程之前，首先说明一下处理器的软件栈，以便本领域技术人员更加清楚了解本申请的执行过程。

处理器的软件栈从底层至上层包括：操作系统、语言runtime、程序框架和业务代码。其中，语言runtime可以为libc、jvm或clr等语言；程序框架可以为spring或netty等；业务代码通俗而言即为应用程序，例如，社交程序、电商程序等。

本申请主要涉及语言runtime和业务代码这两个层面。应用程序均运行在业务代码这个层面，在语言runtime这个层面上具有线程池。处理器可以在线程池中为每个应用程序分配一个线程，用以处理应用程序中的任务。

下面介绍本申请提供的一种任务异步执行方法，应用于处理器的语言runtime这个层面。本申请以多个线程中的一个当前线程为例，对当前线程处理的一个当前任务进行详细介绍。可以理解的是，对于其它线程的其它任务而言，其处理过程是一致的，在此不再赘述。如图1所示，所述方法具体包括以下步骤：

步骤s101：在当前线程通过线程池api计划向线程池提交当前任务的情况下，在所述当前线程下为所述当前任务建立对应的当前协程；其中，所述当前任务为所述当前线程确定在执行过程中可能出现阻塞的任务。

技术人员会预判当前任务在执行过程中，是否有出现阻塞的可能。若有，则向当前线程发送一个指令告知当前任务有出现阻塞的可能；若无，则向当前线程发送一个指令，告知当前任务无出现阻塞的可能。在当前线程获取当前任务之后，首先确定一下在执行当前任务过程中是否有出现阻塞的可能；若无，则说明执行当前任务不会出现阻塞，因此当前线程可以继续执行当前任务。若有，则说明执行当前任务有可能出现阻塞，为了防止当前线程在执行当前任务时被阻塞，应用程序会控制当前线程向线程池api发送当前任务。

在现有技术中线程池api会将当前任务发送至线程池的任务队列中，由线程池中的线程在任务队列中获取并处理当前任务。而本申请中为了避免线程池获取并处理当前任务，本申请改变了线程池api实现逻辑，使得线程池 api不再向任务队列发送当前任务，而是在当前线程下新建一个与当前任务对应的当前协程。协程与线程类似，均可以用于处理任务。

当前线程步骤s102：利用所述当前协程处理所述当前任务。

在步骤s101新建当前协程之后，可以利用新建的当前协程处理当前任务。

图1所示的实施例仅描述了一个当前任务，可以理解的是，在当前线程确定多个可能会出现阻塞的任务时，针对每个可能出现阻塞的任务，执行过程中是类似的。因此，可以在当前线程下建立与可能出现阻塞任务一一对应的多个协程，这样可以使得当前线程中运行有很多协程。

在当前协程处理当前任务的过程中可能会不同情况，下面对各个情况进行一一描述。

第一种情况：当前协程未出现阻塞状态。

由于当前线程未执行当前任务，仅仅是预判一下当前任务是否会出现阻塞。在确定当前任务有出现阻塞的可能时，在实际执行过程当前任务不一定出现阻塞。因此，当前协程在实际执行当前任务过程中，当前协程可能未出现阻塞状态。在此情况下，当前协程可以持续执行当前任务，并在任务结束之后销毁当前协程。然后，释放当前协程所占用的cpu资源。

第二种情况：当前协程处理过程中接收到新任务。

在所述当前协程处理所述当前任务的过程中，若接收到当前线程发送的新任务，则依据所述新任务并以所述当前协程为父协程新建子协程；并利用所述子协程处理所述新任务。

第三种情况：当前协程出现阻塞状态。

在当前线程确定当前任务有出现阻塞的可能时，在当前协程实际执行当前任务的过程中，当前协程很有可能上会出现阻塞状态。

下面详细介绍在当前协程出现阻塞状态之后的处理过程，如图2所示，具体包括以下步骤：

步骤s201：在所述当前协程处理所述当前任务的过程中，若所述当前协程出现阻塞状态，则挂起所述当前协程。

由于当前协程已出现阻塞状态，则说明当前协程目前暂时无法继续处理当前任务，因此暂时挂起当前协程。

为了使当前协程可以继续执行，可以将对当前协程执行以下处理过程。如图3所示，具体包括以下步骤：

步骤s301：判断当前协程的阻塞状态是否由io阻塞引起，若是则进入步骤s302，否则进入步骤s303。

io阻塞(输入输出阻塞)为当前协程需要等待输入或输出操作之后才能够得到执行当前任务的所需数据。若io事件未反馈所需数据，则当前协程会处于io阻塞状态。若当前协程处于io阻塞状态，则进入步骤s302。

若当前协程不是由io阻塞所引起的，则当前协程为由主动阻塞引起的。主动阻塞可以为技术人员根据需要主动阻塞当前协程，控制当前协程处于阻塞状态，技术人员的主动阻塞手段可以为：休眠操作sleep()、暂停操作pause()，等待操作wait()等。

若当前协程的阻塞状态由主动阻塞引起的情况下，采用唤醒api来对当前协程执行唤醒操作，详细执行过程已超出本申请的论述范围，在此不再详细描述。可以理解的是，若当前协程被唤醒api唤醒之后，可以将当前协程的标识信息存储至唤醒协程队列中；若当前协程未被唤醒，则不将当前协程的标识信息存储至唤醒协程队列中。

也就是说，若当前协程的标识信息出现在唤醒协程队列中，则表示当前协程已经不是阻塞状态而是非阻塞状态。

步骤s302：将引起所述当前协程出现io阻塞的io事件和当前协程的标识信息，注册至io事件监听器。

当io阻塞由io事件引起时，将引起io阻塞的io事件和当前协程的标识信息，注册到io事件监听器中，由io事件监听器来判断io事件是否已经反馈所需数据。若已经引起当前协程出现io阻塞的io事件，已经向当前协程反馈所需数据，那么，将当前协程的标识信息存储至io协程队列中。若已经引起当前协程出现io阻塞的io事件，仍然未向当前协程反馈所需数据，则不将当前协程的标识信息存储至io协程队列中。

也就是说，若当前协程的标识信息出现在io协程队列中，则表示当前协程已经不是阻塞状态而是非阻塞状态。

步骤s303：在所述当前协程的阻塞状态置有超时时间的情况下，将所述当前协程的标识信息和当前时间加入至超时协程队列。

处理器会进一步判断当前协程的阻塞状态是否设置有超时时间，若设置有超时时间，则将当前协程的标识信息以及当前时间加入至超时协程队列中。

若当前协程存在于超时协程队列中的时间大于预设超时时间，则说明当前协程已经超过了该协程调用带有全异步特性的阻塞api所设定的超时时间。，所以将当前协程由阻塞状态改为非阻塞状态。若当前协程存在于超时协程队列中的时间不大于预设超时时间，则说明当前协程仍然处于阻塞状态。

在按图3所示的实施例对当前协程处理完毕之后，继续执行图2所示的实施例。

接着返回图2，进入步骤s202：切换至所述当前线程中的一个未阻塞协程。

为了提高当前线程占用cpu资源的利用率，在当前协程被挂起之后，可以切换至所述当前线程中的一个未阻塞协程。如图4所示，下面详细介绍本步骤的具体执行过程。

步骤s401：判断所述当前协程的父协程、唤醒协程队列或io协程队列中是否具有非阻塞协程。若有，则进入步骤s401，否则进入步骤s402。

在当前协程被阻塞时，可以判断当前协程的父协程、唤醒协程队列或io协程队列中是否有非阻塞协程，关于唤醒协程队列以及io协程队列已经在图3所示的实施例进行描述，本步骤不再赘述。

下面说明一下当前协程的父协程，由于协程处理过程中在父协程下建立当前协程之后，便会立即执行当前协程，而未将父协程加入唤醒协程队列或io协程队列中，所以需要单独判断一下父协程是否为非阻塞协程。

步骤s402：若有，切换至所述当前协程的父协程、唤醒协程队列或io协程队列中一个非阻塞协程。

若在当前协程的父协程、唤醒协程队列或io协程队列中具有非阻塞协程，则可以切换至其中一个非阻塞协程中。具体的，处理器可以逐个判断父协程、唤醒协程队列和io协程队列中是否具有非阻塞协程，若判定出一个非阻塞协程，则可以不再执行步骤s401的判断过程，从而节约cpu资源。

步骤s403：若无，则判断超时协程队列中是否具有非阻塞协程。若有进入步骤s404，否则进入步骤s405。

由于一个协程处于非阻塞状态之后，首先出现在唤醒协程队列或io协程队列中，父协程由于没有处于唤醒协程队列或io协程队列中所以需要单独判断，因此，首先对父协程、唤醒协程队列或io协程队列进行判断。

若在当前协程的父协程、唤醒协程队列和io协程队列中均没有非阻塞协程，则继续在超时协程队列中判断是否具有存在于超时协程队列的时间大于预设超时时间的协程，若有，则说明该协程处于非阻塞状态；若无，则说明超时协程队列中也不具有处于非阻塞状态的协程。

步骤s404：若所述超时协程队列中具有非阻塞协程，则切换至所述超时协程队列中一个非阻塞协程。

步骤s405：若所述超时协程队列中不具有非阻塞协程，则在时间间隔内判断是否监听到io事件或唤醒事件。若是，则进入步骤s401，否则进入步骤s403。

在经过上述判断之后仍未发现非阻塞协程，则说明当前线程中暂时没有非阻塞协程。因此等待一个时间间隔，时间间隔至少为超时协程队列中最小的剩余时间；其中，所述剩余时间为预设超时时间与存在于所述超时协程队列的时间的差值。因此，在等待时间间隔之后，肯定有一个阻塞线程因为存在于超时协程队列中的时间大于预设超时时间，而由阻塞线程变成非阻塞协程。

但是，在等待时间间隔的过程中，可能产生io事件或唤醒事件，从而使得io协程队列或唤醒协程队列中具有非阻塞协程。因此，在等待时间间隔的过程中监听io事件唤醒事件。若监听到io事件或者唤醒事件，则等待提前返回，进入步骤s401，从io协程队列或唤醒协程队列查找非阻塞协程。

若在所述时间间隔内未监听到io事件或唤醒事件，则说明io协程队列或唤醒协程队列中不具有非阻塞协程。由于此时等待了一个时间间隔，所以，在超时协程队列中已经具有非阻塞协程，因此，进入步骤s403，则在超时协程队列中查找非阻塞协程。

在按图4所示的实施例切换到非阻塞协程之后，继续执行图2所示的实施例。

接着返回图2，进入步骤s203：控制所述当前线程的cpu资源，执行所述未阻塞协程。

从图2所示的实施例可以看出，当其中一个协程在执行任务过程中出现阻塞状态时可以挂起协程，并切换到当前线程中的其它未阻塞协程，即无需等待该任务执行完毕之后再切换到其它协程，而是在该任务遇到阻塞时，便切换到其它非阻塞协程即可，也即实现任务的异步执行。本申请在当前线程执行任务的过程中遇到阻塞时可以无需挂起当前线程并执行线程切换，而是挂起当前协程即可，这样可以尽量减少线程之间的切换，以减少cpu的消耗且提高处理器性能。

通过以技术手段，可以看出本申请具有以下有益效果：

本申请在应用程序的当前线程确定执行当前任务可能出现阻塞时，不再将当前任务发送至线程池的任务队列，即不再由线程池调度处理当前任务；而是在当前线程下新建协程，由协程来处理当前任务。所以，本申请可以解决由线程池来处理可能出现阻塞的任务而引起的增加cpu的消耗且影响处理器的性能的问题。

此外，由于协程是一种用户级的轻量级线程，即协程存在于用户空间。因此，协程的切换不需要深入处理器的内核空间，仅在处理器的用户空间便可以切换；因此协程的切换消耗较少的cpu资源，从而提高处理器性能。

并且，多个协程之间采用协作式多任务的方式。协作式多任务的方式在同一时刻仅有一个协程在执行，不会出现多个协程同时执行的情况。因此，在使用协程时无需采用锁机制来维持变量的数据同步，这可以进一步提高处理器性能。

并且，本申请中执行应用程序中任务的当前线程，仍然会调用线程池api计划向线程池的任务队列发送当前任务。不同的是，处理器改变了线程池api逻辑，使得线程池api不再将当前任务发送至任务队列，而是在当前线程下新建协程。因此，处理器上的应用程序不必进行任何改变，本申请的执行过程相对于应用程序而言是透明的。

本申请还提供一种任务异步执行装置，集成于处理器。如图5所示，所述装置包括：

建立单元51，用于在当前线程通过线程池api计划向线程池提交当前任务的情况下，在所述当前线程下为所述当前任务建立对应的当前协程；其中，所述当前任务为所述当前线程确定在执行过程中可能出现阻塞的任务；

处理单元52，用于利用所述当前协程处理所述当前任务。

其中，在当前协程未出现阻塞状态情况下，所述处理单元52，包括：

销毁单元，用于在所述当前协程处理所述当前任务的过程中，若所述当前协程未出现阻塞状态，则在所述当前任务结束之后，销毁所述当前协程。

其中，在当前协程出现阻塞状态情况下，如图6所示，所述处理单元52，具体包括：

挂起单元61，用于在所述当前协程处理所述当前任务的过程中，若所述当前协程出现阻塞状态，则挂起所述当前协程；

切换单元62，用于切换至所述当前线程下的一个未阻塞协程；

执行单元63，用于控制所述当前线程的cpu资源，执行所述未阻塞协程。

其中，如图7所示，所述切换单元62，包括：

第一判断单元71，用于判断所述当前协程的父协程、唤醒协程队列或io协程队列中是否具有非阻塞协程；

第一切换协程单元72，用于在所述第一判断单元71为是的情况下，切换至所述当前协程的父协程、唤醒协程队列或io协程队列中一个非阻塞协程；

第二判断单元73，用于在所述第一判断单元71为否的情况下，判断超时协程队列中是否具有非阻塞协程；

第二切换协程单元74，用于在所述第二判断单元73为是的情况下，切换若所述超时协程队列中具有非阻塞协程，则切换至所述超时协程队列中一个非阻塞协程；

第三判断单元75，用于在所述第二判断单元73为否的情况下，在时间间隔内判断是否监听到io事件或唤醒事件；在所述时间间隔内监听到io事件或唤醒事件的情况下，触发所述第一判断单元71；在所述时间间隔内未监听到io事件或唤醒事件的情况下，则触发第二判断单元73。

其中，所述时间间隔为超时协程队列中最小的剩余时间；其中，所述剩余时间为预设超时时间与存在于所述超时协程队列的时间的差值。

在处理单元执行过程中，如有遇到新任务则所述处理单元，如图8所示，还包括：

新建单元81，用于在所述当前协程处理所述当前任务的过程中，若接收到新任务，则依据所述新任务，并以所述当前协程为父协程新建子协程；

处理新任务单元82，用于利用所述子协程处理所述新任务。

其中，在当前协程出现阻塞状态情况下，如图9所示，本申请提供的一种任务异步执行装置还包括：

加入单元91，用于在所述当前协程的阻塞状态置有超时时间的情况下，将所述当前协程的标识信息和当前时间加入至超时协程队列。

注册单元92，用于在所述当前协程的阻塞状态由io阻塞引起的情况下，将引起所述当前协程出现io阻塞的io事件和当前协程的标识信息，一并注册至io事件监听器。

如图10所示，本申请还提供一种任务异步执行系统，包括：

客户端100和服务器200；其中，所述服务器200运行有多个应用程序；

所述客户端100，用于向服务器200中应用程序发送任务；

所述服务器200，用于在当前线程通过线程池api计划向线程池提交当前任务的情况下，在所述当前线程下为所述当前任务建立对应的当前协程；其中，所述当前任务为所述当前线程确定在执行过程中可能出现阻塞的任务；利用所述当前协程处理所述当前任务。

通过以技术手段，可以看出本申请具有以下有益效果：

本申请在应用程序的当前线程确定执行当前任务可能出现阻塞时，不再将当前任务发送至线程池的任务队列，即不再由线程池调度处理当前任务；而是在当前线程下新建协程，由协程来处理当前任务。所以，本申请可以解决由线程池来处理可能出现阻塞的任务而引起的增加cpu的消耗且影响处理器的性能的问题。

此外，由于协程是一种用户级的轻量级线程，即协程存在于用户空间。因此，协程的切换不需要深入处理器的内核空间，仅在处理器的用户空间便可以切换；因此协程的切换消耗较少的cpu资源，从而提高处理器性能。

并且，多个协程之间采用协作式多任务的方式。协作式多任务的方式在同一时刻仅有一个协程在执行，不会出现多个协程同时执行的情况。因此，在使用协程时无需采用锁机制来维持变量的数据同步，这可以进一步提高处理器性能。

并且，本申请中执行应用程序中任务的当前线程，仍然会调用线程池api计划向线程池的任务队列发送当前任务。不同的是，处理器改变了线程池api逻辑，使得线程池api不再将当前任务发送至任务队列，而是在当前线程下新建协程。因此，处理器上的应用程序不必进行任何改变，本申请的执行过程相对于应用程序而言是透明的。

本实施例方法所述的功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算设备可读取存储介质中。基于这样的理解，本申请实施例对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一台计算设备(可以是个人计算机，处理器，移动计算设备或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。