CN109753358B - 任务处理方法及装置 - Google Patents

Abstract

本申请提供的任务处理方法及装置，首先，由第一线程接收客户端发送的任务处理请求；接着，在任务请求所请求处理的任务为CPU密集型任务时，将该CPU密集型任务发送给第二线程；最后，由第二线程处理该CPU密集型任务，并将处理结果反馈给第一线程。在上述方案，第一线程在接收到任务处理请求后，会在请求处理的任务为CPU密集型任务时，将耗时的CPU密集型任务下发给单独的第二线程进行处理，第一线程不会处理耗时任务而是再去接收任务处理请求，提高第一线程任务处理的效率，防止系统卡顿。同时在请求处理的任务场景为CPU密集型任务场景时，本方案能对接收到的每个CPU密集型任务请求进行异步处理，大大提高了任务处理请求的并发量。

Description

任务处理方法及装置

技术领域

本申请涉及数据处理技术领域，具体而言，涉及一种任务处理方法及装置。

背景技术

Node.js是一个由C++语言编写而成，基于Chrome V8引擎的JavaScript运行环境，是一个JavaScript运行在服务端的开发平台。

Node.js使用事件驱动模式而得以轻量和高效，Node.js在处理IO密集型任务时是非常高效的，但是在处理CPU密集型任务时，将会使任务处理的效率降低。原因在于：IO密集型任务的大部分时间是在等待IO操作完成，对CPU资源的占用很少，执行耗时少；而CPU密集型任务的大部分时间用来计算或逻辑判断，对CPU资源的占用很多，执行耗时较多。由于Node.js属于单线程模式，如果处理非常耗时的CPU密集型任务，将会导致整个浏览系统卡顿，严重的时候，甚至会导致浏览系统瘫痪不可用。

发明内容

本申请描述一种任务处理方法及装置，用于解决Node.js在处理CPU密集型任务时存在系统卡顿的技术问题。

第一方面，本申请提供一种任务处理方法，所述方法包括：

通过第一线程接收客户端发送的任务处理请求；

判断所述任务处理请求所请求处理的任务是否为CPU密集型任务；

若所述任务处理请求所请求处理的任务为CPU密集型任务，将该CPU密集型任务发送给第二线程；

通过所述第二线程对所述CPU密集型任务进行处理，并将处理得到的处理结果反馈给所述第一线程。

可选地，在本申请中，在通过第一线程接收客户端发送的任务处理请求之前，所述方法还包括：

将不同的CPU密集型任务通过JavaScript代码写入JavaScript文件中。

可选地，在本申请中，若所述任务处理请求所请求处理的任务为CPU密集型任务，将该CPU密集型任务发送给第二线程，包括：

从所述JavaScript文件中获取该任务处理请求对应的CPU密集型任务，并将获取到的CPU密集型任务发送给所述第二线程。

可选地，在本申请中，若所述任务处理请求所请求处理的任务为CPU密集型任务，将该CPU密集型任务发送给第二线程，还包括：

检测所述第二线程是否启动；

在检测到所述第二线程未启动时，初始化所述第二线程，并将所述第二线程启动；

为所述第二线程创建一隔离的线程执行环境。

可选地，在本申请中，在为所述第二线程创建一隔离的执行环境之后，所述方法包括：

校验发送给第二线程的CPU密集型任务的传入参数是否正确，所述传入参数包括将第二线程处理得到的处理结果反馈给所述第一线程的回调函数；

在校验到所述传入参数正确时，将发送给第二线程的CPU密集型任务封装成能被所述第二线程执行的任务。

可选地，在本申请中，通过所述第二线程对所述CPU密集型任务进行处理，并将对应的处理结果反馈给所述第一线程，包括：

通过所述第二线程执行封装后的CPU密集型任务，得到处理结果，通过回调函数将处理结果反馈给所述第一线程。

第二方面，本申请还提供一种任务处理装置，所述装置包括：

接收模块，用于通过第一线程接收客户端发送的任务处理请求；

判断模块，用于判断所述任务处理请求所请求处理的任务是否为CPU密集型任务；

发送模块，用于若所述任务处理请求所请求处理的任务为CPU密集型任务，将该CPU密集型任务发送给第二线程；

处理模块，用于通过所述第二线程对所述CPU密集型任务进行处理，并将处理得到的处理结果反馈给所述第一线程。

可选地，在本申请中，所述装置还包括：

写入模块，用于将不同的CPU密集型任务通过JavaScript代码写入JavaScript文件中。

可选地，在本申请中，所述发送模块具体用于：

从所述JavaScript文件中获取该任务处理请求对应的CPU密集型任务，并将获取到的CPU密集型任务发送给所述第二线程。

可选地，在本申请中，所述发送模块还具体用于：

检测模块，用于检测所述第二线程是否启动；

启动模块，用于在检测到所述第二线程未启动时，初始化所述第二线程，并将所述第二线程启动；

第二创建模块，为所述第二线程创建一隔离的线程执行环境。

可选地，在本申请中，所述发送模块还具体用于：

检验模块，用于校验发送给第二线程的CPU密集型任务的传入参数是否正确，所述传入参数包括将第二线程处理得到的处理结果反馈给所述第一线程的回调函数；

封装模块，用于在校验到所述传入参数正确时，将发送给第二线程的CPU密集型任务封装成能被所述第二线程执行的任务。

可选地，在本申请中，所述处理模块具体用于：

通过所述第二线程执行封装后的CPU密集型任务，得到处理结果，通过回调函数将处理结果反馈给所述第一线程。

第三方面，本申请还提供一种服务器，所述服务器包括处理器及存储有若干计算机指令的非易失性存储器，所述计算机指令被所述处理器执行时，所述服务器执行第一方面所述的任务处理方法。

第四方面，本申请还提供一种可读存储介质，所述可读存储介质包括计算机程序，所述计算机程序运行时控制所述可读存储介质所在服务器执行第一方面所述的任务处理方法。

相对于现有技术而言，本申请具有以下有益效果：

本申请提供的任务处理方法及装置，首先，由第一线程接收客户端发送的任务处理请求；接着，在任务请求所请求处理的任务为CPU密集型任务时，将该CPU密集型任务发送给第二线程；最后，由第二线程处理该CPU密集型任务，并将处理结果反馈给第一线程。采用上述方案，第一线程在接收到任务处理请求后，会在请求处理的任务为CPU密集型任务时，将耗时的CPU密集型任务下发给单独的第二线程进行处理，第一线程不会处理耗时的CPU密集型任务而是再去接收其它任务处理请求，提高第一线程任务处理的效率，防止系统卡顿。同时在请求处理的任务场景为CPU密集型任务场景时，本方案能对接收到的每个CPU密集型任务请求进行异步处理，大大提高了任务处理请求的并发量。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为采用事件驱动模式处理请求的Node.js的处理模式；

图2为本申请实施例提供的服务器的结构框图；

图3为本申请实施例提供的任务处理的交互示意图；

图4为本申请实施例提供的任务处理方法的一种流程示意图；

图5为图4中步骤S430的子步骤流程示意图；

图6为本申请实施例提供的任务处理装置的一种功能模块框图；

图7为本申请实施例提供的任务处理装置的另一种功能模块框图。

图标：100-服务器；110-任务处理装置；1101-接收模块；1102-判断模块；1103-发送模块；1104-处理模块；1105-写入模块；111-存储器；112-处理器；113-通信单元。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请实施例保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请实施例的描述中，术语"第一"、"第二"等仅用于区分描述，而不能理解为指示或暗示相对重要性。

在本申请实施例的描述中，还需要说明的是，除非另有明确的规定和限定，术语“设置”、“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本申请实施例中的具体含义。

在介绍本申请技术方案之前，先对现有服务器的执行模式进行介绍。现有服务器的执行模式包括：同步模式、进程模式、线程模式及事件驱动模式。

同步模式，属于单进程、单线程、有序的处理请求的一种模式。当一个请求到达服务器的时候，服务器迭代地处理每一个请求，在前一个请求没有完成的时候，后一个请求会一直处在等待状态，完全不会并发处理，请求处理效率非常低。

进程模式，为每一个请求新开一个进程，这样就可以并发的处理多个请求，但是，每一个进程都会消耗CPU、内存、磁盘空间等资源，并且为每个进程分配这些资源也需要耗费大量时间。如果请求的数量过多，系统会消耗掉大量的服务器资源，最终导致处理请求的速度越来越慢。

线程式模式，是比较流行的服务器处理模式，比如，Apache服务器就采用该线程式模式。在服务器中维护一个线程池，当每一个请求到达服务器，服务器都会从线程池中获取一个线程来处理该请求，当请求处理完之后，再将线程返还给线程池，这样既能避免单线程模式中无法实现多并发的问题，同时也能解决多进程中资源消耗及开启进程消耗时间较大的问题。

事件驱动模式，在通过事件驱动的方式处理请求时无需为每一个请求创建额外的线程，每一个IO操作都会被添加到事件队列中，某个特定的线程循环地处理队列中的任务，当执行过程中遇到堵塞(比如，读取文件、查询数据库)时，线程不会停下来等待结果，而是留下一个处理结果的回调函数，转而继续执行队列中的下一个任务。这个传递到队列中的回调函数在堵塞任务运行结束后才被线程调用。

Node.js采用事件驱动模式处理请求，当服务器接收到请求时，将异步的操作放到任务队列中并立即返回结果，然后去服务下一个请求。当这个请求真正的处理完成，通过回调函数返回给用户，因服务器一直接收请求而不用等待任何读写操作，在采用该模式下，Node.js具有高效的特点。

请参照图1，图1示出了采用事件驱动模式处理请求的Node.js的处理模式。在该Node.js的处理模式中处理请求的流程如下所示。

S1，客户端向服务器发送请求。该请求可以是合法的任何请求，例如Http请求。

S2，Node.js主线程接收客户端发送的请求，将接收的请求加入任务队列。

S3，Node.js主线程通过事件循环(Event loop)的方式处理任务队列中的任务或事件。其中，Event loop在主线程开启时启动，并在主线程接收到任务请求时处理接收的任务。

具体地，在Node.js主线程循环地处理任务队列中的任务时，当要处理的任务为调用有异步API(Application Programming Interface，应用程序编程接口)接口的任务(以下称为异步任务)时，执行S4。当要处理的任务为调用非异步API接口(例如同步API接口)的任务(以下称为非异步任务)时，则在主线程中处理。

S4，将异步任务交由后台的C++线程池中的空闲线程处理，通过空闲线程对任务进行无阻塞的处理。其中，该空闲线程的执行流程与主线程的执行流程为异步过程，彼此之间不受影响。

S5，通过回调函数将处理结果返回给Node.js主线程。

S6，Node.js主线程再将处理结果返回给客户端。

通过对上述Node.js的处理模式的处理流程的介绍可知，Node.js是一种单进程、单线程基于事件驱动模式的服务器处理模式。Node.js在处理不耗时的IO密集型任务场景时，处理任务的效率很高；在CPU密集型任务场景中，CPU密集型任务为非异步任务，主线程会直接处理耗时的CPU密集型任务，会导致整个系统卡顿，甚至可能使系统瘫痪不可用，处理任务的处理效率就会变得很低。

为了解决上述技术问题，本申请的申请人经过研究后提出以下解决方案。

请参照图2，图2为本申请实施例提供的一种服务器100的结构示意图。服务器100包括运行在Node.js环境下的浏览器引擎(比如，Chrome V8，图未示)，服务器100可以包括任务处理装置110、存储器111、处理器112及通信单元113。

存储器111、处理器112及通信单元113的各元件相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。

其中，存储器111可以是，但不限于，随机存取存储器(Random Access Memory，RAM)，只读存储器(Read Only Memory，ROM)，可编程只读存储器(Programmable Read-OnlyMemory，PROM)，可擦除只读存储器(Erasable Programmable Read-Only Memory，EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory，EEPROM)等。其中，存储器111用于存储程序，处理器112在接收到执行指令后，执行所述程序。通信单元113用于通过网络建立服务器100与用户终端之间的通信连接，并可以用于通过网络接收或发送数据信息。

任务处理装置110包括至少一个可以软件或固件(firmware)的形式存储于所述存储器111中或固化在所述服务器100的操作系统(英文：Operating System，简称：OS)中的软件功能模块。处理器112用于执行存储器111中存储的可执行模块，例如任务处理装置110所包括的软件功能模块及计算机程序等。

应当理解的是，图2所示的结构仅为示意，所述服务器100还可包括比图2中所示更多或者更少的组件，或者具有与图2所示不同的配置。图2中所示的各组件可以采用硬件、软件或其组合实现。

请参照图3，图3示出了本申请实施例提供的进行任务处理的交互示意图。详细地，服务器100可创建第一线程(主线程)和第二线程(后台线程)，第一线程将CPU密集型任务发送给第二线程，第二线程将该任务处理后，通过回调函数将处理结果反馈给第一线程。

接下来对具体如何实现CPU密集型任务的过程进行详细介绍，请参照图4，图4为本申请实施例提供的应用于图2中的服务器100的任务处理方法的流程图，结合图4，下面对所述方法包括的各个步骤进行详尽的阐述。

步骤S410，通过第一线程接收客户端发送的任务处理请求。

服务器100通过第一线程(主线程)接收与服务器100通信的客户端发送的任务处理请求。

在步骤S410之前，本申请实施例提供的方法还包括：

将不同的CPU密集型任务通过JavaScript代码写入JavaScript文件中。

具体地，可以通过Node.js中的require方式引入JavaScript文件，并将不同的CPU密集型任务以JavaScript代码的形式写入到该引入的JavaScript文件中。将不同的CPU密集型任务预先写入到JavaScript文件中，可以便于在接收的任务处理请求为CPU密集型任务时，从JavaScript文件中获取对应的JavaScript代码。

步骤S420，判断任务处理请求所请求处理的任务是否为CPU密集型任务。

具体地，若请求处理的任务为消耗CPU资源的任务，例如计算类任务(比如，计算圆周率、求解数学方程)或图像处理类任务(比如，视频编解码、图像修复)等，则判定任务处理请求所请求处理的任务为CPU密集型任务；若请求处理的任务为读/写类操作，比如，对I/O、硬盘、内存等的读/写操作，则判定所请求处理的任务为IO密集型任务。

第一线程在判断请求处理的任务为CPU密集型任务时，执行步骤S430。

第一线程在判断请求处理的任务为IO密集型任务时，采用传统的方式处理该任务即可，在此不再赘述。

步骤S430，将该CPU密集型任务发送给第二线程。

在本申请实施例中，第一线程在判断请求处理的任务为CPU密集型任务后，从预先创建的JavaScript文件中获取该任务处理请求的CPU密集型任务的JavaScript代码。第一线程调用扩展C++模块将该CPU密集型任务的JavaScript代码和回调函数进行封装，第一线程将封装后的CPU密集型任务发送给第二线程。

扩展C++模块可通过Chrome V8提供的C++的应用程序编程接口API引用文件名为node.h的C++库文件，并通过该C++库文件中函数创建得到。扩展C++模块是开发人员为了自身的需求开发出来的，这种类型C++模块的C++库文件为扩展库，是采用C++语言编写的动态链接库，扩展C++模块主要的作用是用于在Node.js的JavaScript和C++库直接建立起桥梁作用。具体地，扩展C++模块将CPU密集型任务(JavaScript格式)封装成一个第二线程能够识别的任务(C++格式)，第一线程将封装后的任务发送第二线程，第一线程在接收到第二线程收到任务的确认信息后继续处理任务请求。CPU密集型任务在第二线程中执行处理，第二线程在将该CPU密集型任务处理完成后，将处理结果返回第一线程。通过第一线程与第二线程在同一进程内通信传递处理结果，相比通过不同进程之间的通信传递处理结果的效率会更高。

在采用事件驱动模式处理请求的Node.js的处理模式中，主线程处理非异步任务，而在非异步任务为CPU密集型任务时，主线程会因处理该CPU密集型任务而使处理任务请求的处理效率变低。而本申请上述提供的技术方案中将耗时的CPU密集型任务发送给单独的第二线程处理，第一线程不会处理耗时的CPU密集型任务，而在将CPU密集型任务发送给第二线程后，继续处理任务请求，如此，可以提高第一线程处理任务请求的并发量。

请参照图5，在本申请实施例中，第一线程调用扩展C++模块实现将CPU密集型任务封装后发送给第二线程的过程可以包括以下步骤：

子步骤S431，检测第二线程是否启动。

详细地，扩展C++模块可通过检测第二线程中的启动标志，判断第二线程是否启动，比如，在启动标志为0时，判定第二线程未启动；在启动标志为1时，判定第二线程启动；并在判定第二线程未启动时进入子步骤S432。

子步骤S432，在检测到第二线程未启动时，初始化第二线程，并将第二线程启动。

在检测到第二线程未启动时，将扩展C++模块初始化。具体地，在初始化过程中调用扩展C++模块所需的驱动及引用的其他C++模块等，使得初始化后的扩展C++模块可以被直接调用。

扩展C++模块通过调用系统的API初始化第二线程，并设置启动参数将第二线程启动，第二线程在启动后会一直存在，第二线程的生命周期和Node.js进程相同。其中，启动参数包括I/O接口参数和/或将第二线程运行结果反馈回第一线程的回调函数。

子步骤S433，为第二线程创建一隔离的线程执行环境。

详细地，可在Chrome V8所运行的Node.js环境下，为第二线程创建一隔离的线程执行环境。

在多线程调用的时候，需要使每个线程运行在一个单独的Chrome V8虚拟机(Virtual Machine，VM)上，因此需要在线程初始化的时候为线程创建一个隔离的ChromeV8环境。具体地，隔离环境的创建方式可以采用Isolate::New()实现，其中，Isolate为Chrome V8引擎实例。线程结束前可以取消隔离的Chrome V8环境，具体地，隔离环境的取消方式可以采用Isolate::Dispose()实现。

具体地，可通过获取ChromeV8引擎的上下文，为第二线程创建一个隔离的ChromeV8环境，使得运行第二线程的Chrome V8虚拟机，和运行第一线程的Chrome V8虚拟机并行执行，提高任务处理效率。其中，上下文描述了ChromeV8引擎的环境信息。

可以理解的是，上述扩展C++模块检测第二线程是否启动，并为第二线程创建隔离执行环境的步骤，只需在第二线程首次启动时进行，不需要每次都重复执行。

请再次参照图5，在为第二线程创建一隔离的线程执行环境之后，步骤S430还可以包括：

子步骤S434，校验发送给第二线程的CPU密集型任务的传入参数是否正确。

详细地，在该步骤中，可通过扩展C++模块校验发送给第二线程的CPU密集型任务的传入参数是否正确，其中传入参数包括将第二线程处理得到的处理结果反馈给第一线程的回调函数。

子步骤S435，在校验到传入参数正确时，将发送给第二线程的CPU密集型任务封装成能被第二线程执行的任务。

具体地，可首先将CPU密集型任务封装成第二线程能够识别的任务，然后再将封装后的任务发送给第二线程。

步骤S440，通过第二线程对CPU密集型任务进行处理，并将处理得到的处理结果反馈给第一线程。

本实施例中，首先通过第二线程执行封装后的CPU密集型任务，得到处理结果，然后再通过回调函数将处理结果反馈给第一线程。

在本申请实施例中，第二线程执行封装后的CPU密集型任务。具体地，第二线程通过API接口调用Node.js底层的C++线程池中的空闲C++线程执行封装后的CPU密集型任务，在完成CPU密集型任务的执行后得到该空闲C++线程返回的处理结果，第二线程通过回调函数将处理结果反馈给第一线程，之后，循环执行下一个封装后的CPU密集型任务。若直接采用第二线程执行封装后的CPU密集型任务，需要第二线程调用其他的C++模块或C++库实现，由于不同CPU密集型任务所需要用到的C++模块或C++库不同，在进行开发时，需要为第二线程创建一包括大量C++模块的C++文件库，程序开发任务量大。因此，第二线程调用本就存在的底层C++线程执行封装后的CPU密集型任务相比直接采用第二线程执行封装后的CPU密集型任务具有程序开发量少，节约资源的特点。另外，若使用第二线程执行CPU密集型任务会占用线程资源，影响将处理结果返回第一线程的效率，因此第二线程将各CPU密集型任务分配并调用底层C++线程执行处理，第二线程能够调用更多资源来识别任务、返回任务处理结果，效率更高；而第二线程调用的用于处理各CPU密集型任务的C++线程之间是异步的，互相不受影响，从而能够提高任务处理的效率。

本申请实施例提供的任务处理方法，第一线程在接收到任务处理请求后，会在请求处理的任务为CPU密集型任务时，将耗时的CPU密集型任务下发给单独的第二线程进行处理，第一线程再去接收任务处理请求，提高第一线程任务处理的效率，防止系统卡顿。采用单独的第二线程处理CPU密集型任务，只需在进程内新开一线程，新开线程所需的CPU、内存、磁盘空间等资源可有由新开线程所在进程提供；而新开进程，需要为新开进程配置CPU、内存、磁盘空间等资源，会消耗大量服务器资源。此外，进程之间是通过IPC消息通信的，该通信方式不如线程与线程之间的通信效率高。在接收到CPU密集型任务请求后，将CPU密集型任务下发给单独的第二线程处理，可以提高第一线程处理任务请求的并发量。

本申请实施例还提供一种任务处理装置110，与上面实施例不同的是，本任务处理装置110是从虚拟装置的角度描述本申请方案的。请参照图6，任务处理装置110可以包括以下模块。

接收模块1101，用于通过第一线程接收客户端发送的任务处理请求。

请参照图7，在本申请实施例中，任务处理装置110还可以包括：

写入模块1105，用于将不同的CPU密集型任务通过JavaScript代码写入JavaScript文件中。

判断模块1102，用于判断任务处理请求所请求处理的任务是否为CPU密集型任务。

发送模块1103，用于若任务处理请求所请求处理的任务为CPU密集型任务，将该CPU密集型任务发送给第二线程。

在本申请实施例中，发送模块1103具体用于：

从JavaScript文件中获取该任务处理请求对应的CPU密集型任务，并将获取到的CPU密集型任务发送给第二线程。

在本申请实施例中，发送模块1103可以通过扩展C++模块实现，扩展C++模块将CPU密集型任务(JavaScript格式)封装成一个第二线程能够识别的任务(C++格式)，第一线程将封装后的任务发送第二线程，第一线程在接收到第二线程收到任务的确认信息后继续处理任务请求。CPU密集型任务在第二线程中执行处理，第二线程在将该CPU密集型任务处理完成后，将处理结果返回第一线程。

发送模块1103具体用于：

检测第二线程是否启动；

在检测到第二线程未启动时，初始化第二线程，并将第二线程启动；

在Chrome V8所运行的Node.js环境下，为第二线程创建一隔离的线程执行环境。

在本申请实施例中，发送模块1103还用于：

校验发送给第二线程的CPU密集型任务的传入参数是否正确，传入参数包括将第二线程处理得到的处理结果反馈给第一线程的回调函数；

在校验到传入参数正确时，将发送给第二线程的CPU密集型任务封装成能被第二线程执行的任务。

处理模块1104，用于通过第二线程对CPU密集型任务进行处理，并将处理得到的处理结果反馈给第一线程。

在本申请实施例中，处理模块1104通过第二线程执行封装后的CPU密集型任务对应的JavaScript代码，在JavaScript代码执行完成后，得到处理结果，通过回调函数将处理结果反馈给第一线程。

如果上述功能以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得服务器100执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(英文：Read-Only Memory，简称：ROM)、随机存取存储器(英文：Random Access Memory，简称：RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

综上所述，本申请提供的任务处理方法及装置，首先，由第一线程接收客户端发送的任务处理请求；接着，在任务请求所请求处理的任务为CPU密集型任务时，将该CPU密集型任务发送给第二线程；最后，由第二线程处理该CPU密集型任务，并将处理结果反馈给第一线程。第一线程在接收到任务处理请求后，会在请求处理的任务为CPU密集型任务时，将耗时的CPU密集型任务下发给单独的第二线程进行处理，第一线程再去接收任务处理请求，提高第一线程任务处理的效率，防止系统卡顿。采用单独的第二线程处理CPU密集型任务，只需在进程内新开一线程，新开线程所需的CPU、内存、磁盘空间等资源可有由新开线程所在进程提供；而新开进程，需要为新开进程配置CPU、内存、磁盘空间等资源，会消耗大量服务器资源。此外，进程之间是通过IPC消息通信的，该通信方式不如线程与线程之间的通信效率高。在接收到CPU密集型任务请求后，将CPU密集型任务下发给单独的第二线程处理，可以提高第一线程处理任务请求的并发量。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

Claims (12)

1.一种任务处理方法，其特征在于，所述方法包括：

通过第一线程接收客户端发送的任务处理请求；

判断所述任务处理请求所请求处理的任务是否为CPU密集型任务；

若所述任务处理请求所请求处理的任务为CPU密集型任务，将该CPU密集型任务发送给第二线程；

通过所述第二线程对所述CPU密集型任务进行处理，并将处理得到的处理结果反馈给所述第一线程，其中，所述第二线程具有隔离的线程执行环境，所述处理结果为所述第二线程通过API接口调用Node.js底层的C++线程池中的空闲C++线程执行CPU密集型任务，在完成CPU密集型任务的执行后得到。

2.如权利要求1所述的方法，其特征在于，在通过第一线程接收客户端发送的任务处理请求之前，所述方法还包括：

将不同的CPU密集型任务通过JavaScript代码写入JavaScript文件中。

3.如权利要求2所述的方法，其特征在于，若所述任务处理请求所请求处理的任务为CPU密集型任务，将该CPU密集型任务发送给第二线程，包括：

从所述JavaScript文件中获取该任务处理请求对应的CPU密集型任务，并将获取到的CPU密集型任务发送给所述第二线程。

4.如权利要求1-3任一所述的方法，其特征在于，若所述任务处理请求所请求处理的任务为CPU密集型任务，将该CPU密集型任务发送给第二线程，还包括：

检测所述第二线程是否启动；

在检测到所述第二线程未启动时，初始化所述第二线程，并将所述第二线程启动；

为所述第二线程创建一隔离的线程执行环境。

5.如权利要求4所述的方法，其特征在于，在为所述第二线程创建一隔离的执行环境之后，所述方法还包括：

校验发送给第二线程的CPU密集型任务的传入参数是否正确，所述传入参数包括将第二线程处理得到的处理结果反馈给所述第一线程的回调函数；

在校验到所述传入参数正确时，将发送给第二线程的CPU密集型任务封装成能被所述第二线程执行的任务。

6.如权利要求5所述的方法，其特征在于，通过所述第二线程对所述CPU密集型任务进行处理，并将对应的处理结果反馈给所述第一线程，包括：

通过所述第二线程执行封装后的CPU密集型任务，得到处理结果，通过回调函数将处理结果反馈给所述第一线程。

7.一种任务处理装置，其特征在于，所述装置包括：

接收模块，用于通过第一线程接收客户端发送的任务处理请求；

判断模块，用于判断所述任务处理请求所请求处理的任务是否为CPU密集型任务；

发送模块，用于若所述任务处理请求所请求处理的任务为CPU密集型任务，将该CPU密集型任务发送给第二线程；

处理模块，用于通过所述第二线程对所述CPU密集型任务进行处理，并将处理得到的处理结果反馈给所述第一线程，其中，所述第二线程具有隔离的线程执行环境，所述处理结果为所述第二线程通过API接口调用Node.js底层的C++线程池中的空闲C++线程执行CPU密集型任务，在完成CPU密集型任务的执行后得到。

8.如权利要求7所述的装置，其特征在于，所述装置还包括：

写入模块，用于将不同的CPU密集型任务通过JavaScript代码写入JavaScript文件中。

9.如权利要求8所述的装置，其特征在于，所述发送模块具体用于：

从所述JavaScript文件中获取该任务处理请求对应的CPU密集型任务，并将获取到的CPU密集型任务发送给所述第二线程。

10.如权利要求7-9任一所述的装置，其特征在于，所述发送模块还具体用于：

检测所述第二线程是否启动；

在检测到所述第二线程未启动时，初始化所述第二线程，并将所述第二线程启动；

为所述第二线程创建一隔离的线程执行环境。

11.如权利要求10所述的装置，其特征在于，所述发送模块还具体用于：

校验发送给第二线程的CPU密集型任务的传入参数是否正确，所述传入参数包括将第二线程处理得到的处理结果反馈给所述第一线程的回调函数；

在校验到所述传入参数正确时，将发送给第二线程的CPU密集型任务封装成能被所述第二线程执行的任务。

12.如权利要求11所述的装置，其特征在于，所述处理模块具体用于：

通过所述第二线程执行封装后的CPU密集型任务，得到处理结果，通过回调函数将处理结果反馈给所述第一线程。

Images