CN110147269B - 一种事件处理方法、装置、设备及存储介质 - Google Patents

Abstract

本发明涉及一种事件处理方法、装置、设备及存储介质，所述方法包括：获取目标事件；将所述目标事件划分为若干子事件，根据预设规则，将所述若干子事件分类为第一类事件和第二类事件；将当前时间段划分为在时间上不重叠的时间段，其中，所述在时间上不重叠的时间段包括单线程阶段和多线程阶段；在所述单线程阶段处理所述第一类事件，在所述多线程阶段处理所述第二类事件。本发明根据不同线程的处理特性，将不同类型的事件放在不同的线程阶段进行处理，提高了开发效率以及系统性能；同时将单线程与多线程相结合，平衡了开发成本与性能的问题。

Description

一种事件处理方法、装置、设备及存储介质

技术领域

本发明涉及计算机技术领域，尤其涉及一种事件处理方法、装置、设备及存储介质。

背景技术

在计算机技术应用领域，通常会采用单进程单线程模型、单进程多线程模型以及多进程单线程模型进行事件处理。单进程单线程模型开发效率高，但不足以承载过多的用户；单进程多线程模型没有内存冗余的弊端，能够充分利用多核优势，不需要中控服务器同步数据，但是会涉及到加锁以及大量异步回调，开发以及调试成本较高；多进程单线程模型可以进行故障隔离，单个服务器进程宕机不会影响全服玩家，其次是扩展性强，通过分布式部署，可实现多人同时在线，但是数据同步以及异步调用会带来很大的开发以及调试成本。

发明内容

本发明所要解决的技术问题在于，提供一种事件处理方法、装置、设备及存储介质，采用单线程与多线程相结合的方式进行事件处理，从而平衡了性能与开发成本的问题，提高了开发效率。

为了解决上述技术问题，第一方面，本发明提供了一种事件处理方法，所述方法包括：

获取目标事件；

将所述目标事件划分为若干子事件，根据预设规则，将所述若干子事件分类为第一类事件和第二类事件；

将当前时间段划分为在时间上不重叠的时间段，其中，所述在时间上不重叠的时间段包括单线程阶段和多线程阶段；

在所述单线程阶段处理所述第一类事件，在所述多线程阶段处理所述第二类事件。

第二方面，本发明提供了一种事件处理装置，所述装置包括：

目标事件获取模块，用于获取目标事件；

事件分类模块，用于将所述目标事件划分为若干子事件，根据预设规则，将所述若干子事件分类为第一类事件和第二类事件；

时间段划分模块，用于将当前时间段划分为在时间上不重叠的时间段，其中，所述在时间上不重叠的时间段包括单线程阶段和多线程阶段；

事件处理模块，用于在所述单线程阶段处理所述第一类事件，在所述多线程阶段处理所述第二类事件。

第三方面，本发明提供了一种设备，所述设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如第一方面所述的事件处理方法。

第四方面，本发明提供了一种计算机存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行如第一方面所述的事件处理方法。

实施本发明实施例，具有如下有益效果：

本发明通过对获取到的目标事件进行划分，得到若干子事件；根据预设规则，对若干子事件进行分类，得到第一类事件和第二类事件；将当前时间段划分为在时间上不重叠的时间段，包括单线程阶段和多线程阶段；在所述单线程阶段处理所述第一类事件，在所述多线程阶段处理第二类事件；其中，单线程阶段处理计算量小，耦合性大的事件，多线程阶段处理计算量大、耦合性小的事件，这样根据不同线程的处理特性，将不同类型的事件放在不同的线程阶段进行处理，提高了开发效率以及系统性能；同时将单线程与多线程相结合，平衡了开发成本与性能的问题。

附图说明

图1是本发明实施例提供的一种事件处理方法流程图；

图2是本发明实施例提供的时间段分割示意图；

图3是本发明实施例提供的分阶段事件处理过程流程图；

图4是本发明实施例提供的游戏中CPU耗时分布示意图；

图5是本发明实施例提供的有限多线程模型性能示意图；

图6是本发明实施例提供的OpenMP经典的运行模型示意图；

图7是本发明实施例提供的一种多线程阶段事件处理方法流程图；

图8是本发明实施例提供的一种事件检测方法流程图；

图9是本发明实施例提供的一种锁处理方法流程图；

图10是本发明实施例提供的一种事件处理装置示意图；

图11是本发明实施例提供的事件处理模块示意图；

图12是本发明实施例提供的第二处理模块示意图；

图13是本发明实施例提供的检测模块示意图；

图14是本发明实施例提供的锁处理模块示意图；

图15是本发明实施例提供的一种设备结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述。显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本发明的描述中，需要理解的是，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。而且，术语“第一”、“第二”等适用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。

本发明提出的单线程与多线程相结合的有限多线程模型，能够将不同的事件放在不同线程进行处理，具体的实现过程可参见图1，其示出了一种事件处理方法，可应用于服务器侧，所述方法包括：

S110.获取目标事件。

这里的目标事件可以是从预先存储的事件队列中拿出的待处理事件，也可以是当前直接获取到的目标事件。

目标事件中可以包括用户终端发来的各种请求消息，以及各系统的心跳逻辑等，服务器需要对接收到的相关事件进行相应的处理。

S120.将所述目标事件划分为若干子事件，根据预设规则，将所述若干子事件分类为第一类事件和第二类事件。

总体上来讲，第一类事件可以是计算量小，且耦合性大的事件；第二类事件可以是计算量大，其耦合性小的事件。

S130.将当前时间段划分为在时间上不重叠的时间段，其中，所述在时间上不重叠的时间段包括单线程阶段和多线程阶段。

可以理解的是，当前时间段的长度不一定是预设的，即对于每一个时间段，都可以有不同的时间长度，其可以根据当前获取到的目标事件来进行确定。对于获取到的每一个目标事件，处理该目标事件的时长可能都是不一样的，处理每个目标事件的时长均是由处理第一类事件的时长加上处理第二类事件的时长来确定的，即对应单线程阶段时长加上多线程阶段的时长。

S140.在所述单线程阶段处理所述第一类事件，在所述多线程阶段处理所述第二类事件。

请参见图2，其示出了时间段分割示意图，将当前时间段分为了单线程阶段和多线程阶段两个阶段，单线程阶段和多线程阶段在时间上是不重叠的，是一个阶段结束之后才会进入到下一个阶段。

具体分阶段进行事件处理过程具体可参见图3，具体可包括：

S310.在当前时间段，控制主线程在所述单线程阶段以单线程模式运行，处理所述第一类事件。

程序开始执行时，启动的线程为主线程，主线程在单线程阶段以单线程模式执行相应的处理操作。

S320.当所述第一类事件处理完成之后，根据所述主线程生成若干子线程，控制所述主线程和所述若干子线程在所述多线程阶段以多线程模式运行，处理所述第二类事件。

进入多线程阶段时，主线程会根据需要生成相应的子线程，以满足处理第二类事件的需求。

S330.当所述第二类事件处理完成之后，回收所述若干子线程，进入下一个时间段。

下面具体分析哪些事件可以放到单线程去执行，哪些事件可以放到多线程去执行。本实施例中，以相关游戏应用场景为例，一般放在单线程执行的事件包括：

(1)对于全局变量(global、static和单件的)有修改的尽量放在单线程阶段，比如发邮件、组队相关、对帮会数据改变；

(2)跨场景有交互的尽量在放在单线程阶段，比如增加队伍成员后同步信息给所有队员，两个可能不在一起的玩家私聊等；

(3)代码逻辑很复杂，未来扩展性很强的功能，比如登录、切场景；

(4)其它尽量多的代码执行放在单线程阶段，除非有较大性能消耗，再去考虑多线程。

本实施例提供的事件处理方法是通过单线程与多线程相结合来实现的，可以看成是一种有限多线程模型。上述第(4)点非常重要，是有限多线程模型的“有限”所在，要尽量保证代码的简单，多线程处理的越多，需要解决的问题越多，在开发成本和性能上就会失衡。

在本实施例中，放在多线程的主要是以下部分，且都是基于压测数据做的决定，而这部分的性能消耗已经大于90％：

(1)数据驱动逻辑只包含移动和技能；

(2)移动和技能的心跳逻辑、AI(Artificial Intelligence，人工智能)逻辑；

(3)Obj对象属性的属性计算和更新；

(4)为了解决登录tps，部分登录做的事情押后到了多线程，比如战力计算，阵营计算；

(5)为了解决切场景的消耗，切场景后的视野更新押后到了多线程；

(6)其它以性能压测为基础，出现在排序靠前的模块且和跨场景、修改全局数据无关的内容，其它不建议放在多线程。

以mmorpg(Massive Multiplayer Online Role-PlayingGame，多人在线角色扮演游戏)游戏场景为例，请参见图4，其示出了mmorpg游戏中的CPU耗时分布示意图。

mmorpg后台主要有两大驱动力，其一是消息驱动，包含玩家上行协议的驱动和其它服务器Server的消息驱动，这部分的主要耗时来源是战斗请求包和移动请求包，移动和战斗占整个CPU耗时处理的15％左右性能消耗。其二是定时器，包含各大系统的心跳逻辑以及各个Obj的心跳逻辑，在承载5000玩家在线的时候，怪物和NPC(Non-Player Character，非玩家角色)往往要达到十万之多，因此定时器的主要耗时来源是场景心跳(AI、技能冷却时间检查、扫敌等)，这部分占整个CPU耗时处理的75％左右。这两部分组成了蓝色区域累计占比高达90％，它们的共同点是有很少的跨场景操作，以及少量的公共模块数据访问(比如邮件、帮会)。而另外的10％是UI(User Interface，用户界面)上的各种请求操作，以及防外挂、帮会自己的心跳逻辑等，代码量极大，耦合度很高。

基于本实施例的上述事件处理方法，可以将场景心跳、战斗请求和移动请求的相关事件并行起来，运行在多线程模式，也不会影响到其他区域的代码复杂度。

以下从理论上进行分析，有限多线程模型在理想情况下对性能的影响，按照原来单线程设计性能消耗，假设能抽离给多线程并行计算的时间占比为mt，单线程执行的时间占比为st，在8核下无锁运行，性能随着st的缩短而提升，那么按照公式：e＝1/((1-st)/8+st)，如果st＝20％，性能可以提升至原来的333％，如果st＝10％，性能可以提升至原来的470％，后续从实际运行效果上看，在性能高峰时刻，st占比平均远小于20％，甚至可以弱化到5％以内，mmorpg的这种特殊性给有限多线程很多提升空间。具体的性能分析图可参见图5。

基于以上对本实施例提供的有限多线程事件处理方法的描述，可通过相关代码来实现相应的功能，也可以采用现有的实现框架来进行实现，本实施例主要以基于现有的OpenMP框架为例，来具体说明实现有限多线程的实施过程。

OpenMP使用一种可移植、可伸缩的模型，给予编程者一个简单和灵活的接口来开发并行应用，支持多平台共享内存的C/C++/Fortran多处理器编程，可以运行在绝大多数处理器架构和操作系统上，包括Solaris，AIX，HP-UX，GNU/Linux，Mac OS X和Windows平台。它由编译器指令集、库函数和环境变量组成，影响运行时行为。

请参见图6，其示出了一个OpenMP经典的运行模型，一般从一个主线程(masterthread)开始运行在单线程模式下，遇到一个可以并行的模块，便进入到多线程模式，分界线(barriers)是等待所有多线程任务都完成，才能再次进入单线程阶段。这个设计思路和本实施例的有限多线程模型高度匹配，因此可以基于该OpenMP模型构建有限多线程模型。

本实施例以mmorpg游戏服务器架构为例，选择了OpenMP中的task模式，简单的理解，task就是定义一个任务，线程组内的某一个线程来执行此任务。任务构造定义一个显式的任务，可能会被遇到的线程马上执行，也可能被延迟给线程组内其他线程来执行。任务的执行，依赖于OpenMP的任务调度。

以游戏的场景心跳逻辑为例，可以把一次场景的心跳分成两部分，一部分运行在单线程模式下，命名为TickSingle；一部分运行在多线程模式下，命名为TickMulti。一旦运行在多线程阶段，就把一个场景的TickMulti函数当作一个完整的task，交给OpenMP进行多线程并行计算，相关实现代码如下：

对于上述代码中的相关指令，做以下解释：

parallel指令：定义并行区域，#pragma omp parallel[clauses]，支持零个或多个子句；

num_threads子句：parallel指令的子句，定义线程数目；

master指令：指定只有主线程应执行的程序部分；

task指令：定义任务，线程组内的某一个线程来执行接下来的每一个任务；

taskwait：设置barrier，这个指令会保证前面的task都已经处理完成，然后才会继续往下走。

基于以上代码，所有可以多线程执行的逻辑都写在Scene::TickMulti()函数内即可，以场景TickMulti函数为task切分是最适合mmorpg的，OpenMP能保证一个task只在一个线程同时执行，而不会再次被切分。对各个编译器有良好的内置集成，编译的时候，需要添加选项-fopenmp，不需要引入任何库文件即可编译成功，在有些虚拟机上，在非繁忙的时候可能会出现CPU飙升，需要在启动之前设定一下环境变量，让单线程阶段其它CPU的策略是“被动休息”状态即可：export OMP_WAIT_POLICY＝PASSIVE。

在多线程阶段，控制所述主线程和所述若干子线程在所述多线程阶段以多线程模式运行，处理所述第二类事件，但由于第二类事件中包含若干子事件，且处理每个子事件的耗时可能不同，有的子事件可能耗时很长，此时为了防止在多线程末期多个子事件等待一个耗时较长的时间完成，可以在进入多线程阶段，首先处理该耗时较长的子事件，相应的具体实施过程可参见图7，其示出了一种多线程阶段事件处理方法，所述方法包括：

S710.在当前时间段对所述第二类事件进行处理之前，获取上一时间段对所述第二类事件中的每个子事件的处理时长，并对所述处理时长进行排序。

S720.在所述多线程阶段，根据排序结果，按照所述处理时长从大到小的顺序，依次处理相应的子事件。

具体以场景的心跳为一个task，每个task的耗时并不平均，在多线程阶段会出现多线程负载不均衡的情况，理想目标是线程平均分担，这会让多线程阶段时间整体缩短。task的调度在GCC的模式下基本是先来先服务(FIFO)，调度方式比较难改变，但可以决定哪个task先给OpenMP，在给多线程之前，给task按照上一帧的执行时间给个倒序排列，这样就能保证耗时操作先做，以尽大的可能不让多个线程末期等待一个大task完成，阻塞进入单线程阶段的时间，从而提高帧率。

基于本实施例上述的事件处理方法，所述方法还可以包括：

S150.当所述第二类事件中存在需要进行预设操作的子事件时，对所述子事件进行封装，将封装好的子事件留到下一时间段的单线程阶段进行处理。

一个多线程进程的数据同步和安全本身就是一个课题，有限多线程模型也有多线程阶段，这个问题就不能完全规避，复杂问题尽量给单线程阶段接管是简化处理的好主意。代码耦合度太高，无法保证多线程阶段的函数不间接调用到“不安全”函数，举个容易能碰到的例子：技能的伤害函数可能触发角色死亡，角色死亡会调用OnDie()接口，这个接口是开放性的，任何系统里都可能在这里新增或者修改函数调用，比如可能会让单件实例的邮件系统触发一封邮件，造成邮件存储数据全局变量的改变(假设邮件系统没有抽象成独立的服务)，而这种情况都试图在多线程程序改变全局变量，是不安全的。

为了避免加锁有阻塞逻辑，多线程程序往往会采用消息队列异步化，把处理交给一个指定的线程去改变共享数据。但有限多线程不是时刻运行的，当前场景这次心跳在A线程，下次可能在B线程，不能简单的发消息给对应线程，但是可以押后到下次单线程处理阶段去执行，这个通过一个良好的消息封装，结合C++11的lamda表达式，非常容易实现，以下示例代码展示了，如果在多线程阶段收到发邮件请求，押后到单线程去执行的过程，值得注意的是，这个处理不能过于频繁，防止性能消耗在消息处理上，在性能占比上也应该是很小的部分。

另外，本实施例中，也可以将单线程阶段的部分消息延后给多线程阶段，这部分消息要求两点：一个是逻辑简单，没有跨场景和全局变量写操作，另一个要求是能接受时序打乱，这个消息包和其它没有过多的依赖关系。按照之前的数据，可以选取移动包和技能包延后到多线程处理。

基于本实施例上述的事件处理方法，请参见图8，所述方法还可以包括：

S810.对单线程阶段的事件处理过程进行检测，当检测到调用多线程预设处理函数时，发出告警信息。

S820.对多线程阶段的事件处理过程进行检测，当检测到调用单线程预设处理函数时，发出告警信息。

具体可以理解为：如果某些函数不是线程安全，但是改造起来又有较大成本，应该明确拒绝它运行在多线程阶段，让它抛出异常。以玩家加入队伍为例，这个操作的后续处理很复杂，就要明确让加入队伍的处理只能运行在单线程，为了确保在单线程运行的函数不被多线程调用，需要有个防范和检查机制，处理方式是提供一个名字叫CheckSingleThread函数进行检查，一旦发现在多线程阶段调用，后台会受到告警信息，开发人员就能收到短信或者微信提醒，很快可以根据栈信息把它异步化即可。以下伪码演示捕获的过程。

同样，有些函数运行在多线程，但是不希望它们会被其它线程调用过来，比如是场景内Obj上的函数，这样可能引起数据冲突。同理也可以添加一个对多线程防范和检查的函数CheckMutilThread，标识它只能运行在指定的线程上。以玩家身上的属性设置底层接口为例，这个接口可能改变血、速度等各种角色身上的变量，不希望它有跨场景的访问，就可以明确指出来。

CheckSingleThread和CheckMutilThread会对实现不安全访问的帮助很大，适当的注入能够非常快捷的找到了那些应该修改的地方，并且通过SingleDo延后到单线程阶段，避免访问冲突，以告警来驱动修改，效率很高，控制多线程的代码量越少，需要处理的内容越少。

请参见图9，其示出了一种锁处理方法，所述方法包括：

S910.对事件处理过程中需要访问的资源进行加锁。

涉及到多线程调用，很可能有少量的加锁处理，本实施例中的有限多线程不是全量多线程，只有少量代码执行在多线程阶段，比较容易控制。

S920.记录事件处理过程中的冲突日志和冲突时间。

通过锁进行统计，记录相关的冲突日志和冲突时间。

S930.根据所述冲突日志和所述冲突时间，确定冲突的优先级。

S940.根据所述优先级，依次对相应的资源进行去锁化处理。

具体的锁处理的实现过程如下：

先写一把大锁(虽然看上去是不够成熟的行为)，所有的加锁逻辑都用它，先不要考虑效率，优先考虑快速让代码跑起来，并且至少它不会死锁。这把锁要具有内建统计，记录冲突日志和冲突时间，后续根据冲突的统计优先级，逐个把锁去掉或者分解，这样至少能保证版本在改造期间是稳定的，不会因为锁导致停工抢修。大锁的代码很简单，先尝试上锁，如果有冲突记录冲突时间，CPU时间函数实现参考，以下伪码简单演示了记录锁冲突的过程。

后面就是根据实际数据按照优先级来去锁化，目标应该是每一帧都不会因为锁冲突有明显(多线程阶段耗时占比千分之一以内)实际的损耗，后面分析几个锁处理的例子。

利用线程局部变量避免加锁，这种方式修改起来往往最简单，比如之前一个返回函数内static变量的函数，只需要简单的把这个变量声明为thread_local变量。对于C++11以下的版本，如果没有这个标识符，OpenMP本身也提供了强大的private字句可以把变量进行线程私有化，并且还能提供诸如初始化时机，退出并行区域是否恢复等操作，这里不再赘述。

以下伪码可能是程序原来存在的一个函数，之所以有static变量，估计是为了效率考虑避免频繁构造和析构，也可能是在单线程先为了调用方便，但是这个函数如果运行在多线程下就会出问题，可能会被多个线程同时读写，改成thread_local staticMyStruct s_mydata后，就不会存在多线程冲突的问题了。

另外一种更常见的情况是，希望在多线程的读操作是安全的，那么就要尽量把写操作放在单线程阶段，比如队伍和帮会，在多线程阶段可以无限制的读，在有限多线程的情况下，确实能保证绝大部分操作本身就在单线程，但仍旧会有风险。此时就要尽量把写操作都加上CheckSingleThread检查。这里举个更典型的例子，来说明要根据具体情况去分，当两个帮会宣战后，需求要记录他们的伤害统计，因为帮会的战斗同时发生在多个场景，因此有跨线程访问的可能，因此最初的代码可能先加锁保证安全，伪码如下：

但是，这是一个高频事件，通过锁的统计发现这里冲突时间较长，针对map和set的红黑树的实现，知道如果写不安全，读也不安全，写如果加锁，多线程读也需要同样锁。而整个函数的延后到单线程阶段是可行的，但是高频操作的异步化本身也有不小的开销，看似很难平衡。如果只把有树的新增操作押后在单线程阶段，在不改变树结构的情况下，多线程阶段是可以安全读写的，改造成如下代码后，既没有锁操作，又把异步化将为了低频操作。

以上两个简单的例子是想说明针对于锁，如果有数据证明它可能影响效率，要通过具体分析尽量做到去锁化或者缩小加锁范围，另外一些如果能确定和业务逻辑关联不大，就考虑拆分成小锁。

本发明通过对获取到的目标事件进行划分，得到若干子事件；根据预设规则，对若干子事件进行分类，得到第一类事件和第二类事件；将当前时间段划分为在时间上不重叠的时间段，包括单线程阶段和多线程阶段；在所述单线程阶段处理所述第一类事件，在所述多线程阶段处理第二类事件；其中，单线程阶段处理计算量小，耦合性大的事件，多线程阶段处理计算量大、耦合性小的事件，这样根据不同线程的处理特性，将不同类型的事件放在不同的线程阶段进行处理，提高了开发效率以及系统性能；同时将单线程与多线程相结合，平衡了开发成本与性能的问题。

本实施例还提供了一种事件处理装置，请参见图10，所述装置包括：

目标事件获取模块1010，用于获取目标事件。

事件分类模块1020，用于将所述目标事件划分为若干子事件，根据预设规则，将所述若干子事件分类为第一类事件和第二类事件。

时间段划分模块1030，用于将当前时间段划分为在时间上不重叠的时间段，其中，所述在时间上不重叠的时间段包括单线程阶段和多线程阶段。

事件处理模块1040，用于在所述单线程阶段处理所述第一类事件，在所述多线程阶段处理所述第二类事件。

请参见图11，所述事件处理模块1040包括：

第一处理模块1110，用于在当前时间段，控制主线程在所述单线程阶段以单线程模式运行，处理所述第一类事件。

第二处理模块1120，用于当所述第一类事件处理完成之后，根据所述主线程生成若干子线程，控制所述主线程和所述若干子线程在所述多线程阶段以多线程模式运行，处理所述第二类事件。

处理完成模块1130，用于当所述第二类事件处理完成之后，回收所述若干子线程，进入下一个时间段。

请参见图12，所述第二处理模块1120包括：

排序模块1210，用于在当前时间段对所述第二类事件进行处理之前，获取上一时间段对所述第二类事件中的每个子事件的处理时长，并对所述处理时长进行排序。

第三处理模块1220，用于在所述多线程阶段，根据排序结果，按照所述处理时长从大到小的顺序，依次处理相应的子事件。

本实施例中的事件处理装置还可以包括：

延后模块1050，用于当所述第二类事件中存在需要进行预设操作的子事件时，对所述子事件进行封装，将封装好的子事件留到下一时间段的单线程阶段进行处理。

请参见图13，本实施例中的事件处理装置还可以包括检测模块，具体包括：

第一检测模块1310，用于对单线程阶段的事件处理过程进行检测，当检测到调用多线程预设处理函数时，发出告警信息。

第二检测模块1320，用于对多线程阶段的事件处理过程进行检测，当检测到调用单线程预设处理函数时，发出告警信息。

请参见图14，所述装置还包括锁处理模块，具体可以包括：

加锁模块1410，用于对事件处理过程中需要访问的资源进行加锁。

记录模块1420，用于记录事件处理过程中的冲突日志和冲突时间。

优先级确定模块1430，用于根据所述冲突日志和所述冲突时间，确定冲突的优先级。

去锁化模块1440，用于根据所述优先级，依次对相应的资源进行去锁化处理。可采用线程局部变量，将有冲突的变量进行线程私有化。

上述实施例中提供的装置可执行本发明任意实施例所提供方法，具备执行该方法相应的功能模块和有益效果。未在上述实施例中详尽描述的技术细节，可参见本发明任意实施例所提供的方法。

本实施例还提供了一种设备，请参见图15，该设备1500可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，CPU)1522(例如，一个或一个以上处理器)和存储器1532，一个或一个以上存储应用程序1542或数据1544的存储介质1530(例如一个或一个以上海量存储设备)。其中，存储器1532和存储介质1530可以是短暂存储或持久存储。存储在存储介质1530的程序可以包括一个或一个以上模块(图示未示出)，每个模块可以包括对设备中的一系列指令操作。更进一步地，中央处理器1522可以设置为与存储介质1530通信，在设备1500上执行存储介质1530中的一系列指令操作。设备1500还可以包括一个或一个以上电源1526，一个或一个以上有线或无线网络接口1550，一个或一个以上输入输出接口1558，和/或，一个或一个以上操作系统1541，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。本实施例上述的任一方法均可基于图15所示的设备进行实施。

本实施例还提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行如本实施例上述的任一方法。

基于本实施例的事件处理方法的开发流程简单、调试简单，开发效率高，降低了人力成本；同时运行效率高，节约了服务器成本。

本说明书提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤和顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或中断产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

本实施例中所示出的结构，仅仅是与本申请方案相关的部分结构，并不构成对本申请方案所应用于其上的设备的限定，具体的设备可以包括比示出的更多或更少的部件，或者组合某些部件，或者具有不同的部件的布置。应当理解到，本实施例中所揭露的方法、装置等，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分仅仅为一种逻辑功能的划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元模块的间接耦合或通信连接。

基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，RandomAccess Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域技术人员还可以进一步意识到，结合本说明书所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但这种实现不应认为超出本发明的范围。

以上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (16)

1.一种事件处理方法，其特征在于，包括：

获取目标事件；

将所述目标事件划分为若干子事件，根据预设规则，将所述若干子事件分类为第一类事件和第二类事件；所述第一类事件是计算量小且耦合性大的事件，所述第二类事件是计算量大且耦合性小的事件；

将当前时间段划分为在时间上不重叠的时间段，其中，所述在时间上不重叠的时间段包括单线程阶段和多线程阶段；

在所述单线程阶段处理所述第一类事件，在所述多线程阶段处理所述第二类事件。

2.根据权利要求1所述的一种事件处理方法，其特征在于，所述在所述单线程阶段处理所述第一类事件，在所述多线程阶段处理所述第二类事件包括：

在当前时间段，控制主线程在所述单线程阶段以单线程模式运行，处理所述第一类事件；

当所述第一类事件处理完成之后，根据所述主线程生成若干子线程，控制所述主线程和所述若干子线程在所述多线程阶段以多线程模式运行，处理所述第二类事件；

当所述第二类事件处理完成之后，回收所述若干子线程，进入下一个时间段。

3.根据权利要求2所述的一种事件处理方法，其特征在于，所述控制所述主线程和所述若干子线程在所述多线程阶段以多线程模式运行，处理所述第二类事件包括：

在当前时间段对所述第二类事件进行处理之前，获取上一时间段对所述第二类事件中的每个子事件的处理时长，并对所述处理时长进行排序；

在所述多线程阶段，根据排序结果，按照所述处理时长从大到小的顺序，依次处理相应的子事件。

4.根据权利要求1所述的一种事件处理方法，其特征在于，所述方法还包括：

当所述第二类事件中存在需要进行预设操作的子事件时，对所述子事件进行封装，将封装好的子事件留到下一时间段的单线程阶段进行处理。

5.根据权利要求1所述的一种事件处理方法，其特征在于，所述方法还包括：

对单线程阶段的事件处理过程进行检测，当检测到调用多线程预设处理函数时，发出告警信息；

对多线程阶段的事件处理过程进行检测，当检测到调用单线程预设处理函数时，发出告警信息。

6.根据权利要求1所述的一种事件处理方法，其特征在于，所述方法还包括：

对事件处理过程中需要访问的资源进行加锁；

记录事件处理过程中的冲突日志和冲突时间；

根据所述冲突日志和所述冲突时间，确定冲突的优先级；

根据所述优先级，依次对相应的资源进行去锁化处理。

7.根据权利要求6所述的一种事件处理方法，其特征在于，所述根据所述优先级，依次对相应的资源进行去锁化处理包括：

采用线程局部变量，将有冲突的变量进行线程私有化。

8.一种事件处理装置，其特征在于，包括：

目标事件获取模块，用于获取目标事件；

事件分类模块，用于将所述目标事件划分为若干子事件，根据预设规则，将所述若干子事件分类为第一类事件和第二类事件；所述第一类事件是计算量小且耦合性大的事件，所述第二类事件是计算量大且耦合性小的事件；

时间段划分模块，用于将当前时间段划分为在时间上不重叠的时间段，其中，所述在时间上不重叠的时间段包括单线程阶段和多线程阶段；

事件处理模块，用于在所述单线程阶段处理所述第一类事件，在所述多线程阶段处理所述第二类事件。

9.根据权利要求8所述的装置，其特征在于，所述事件处理模块包括：

第一处理模块，用于在当前时间段，控制主线程在所述单线程阶段以单线程模式运行，处理所述第一类事件；

第二处理模块，用于当所述第一类事件处理完成之后，根据所述主线程生成若干子线程，控制所述主线程和所述若干子线程在所述多线程阶段以多线程模式运行，处理所述第二类事件；

处理完成模块，用于当所述第二类事件处理完成之后，回收所述若干子线程，进入下一个时间段。

10.根据权利要求9所述的装置，其特征在于，所述第二处理模块包括：

排序模块，用于在当前时间段对所述第二类事件进行处理之前，获取上一时间段对所述第二类事件中的每个子事件的处理时长，并对所述处理时长进行排序；

第三处理模块，用于在所述多线程阶段，根据排序结果，按照所述处理时长从大到小的顺序，依次处理相应的子事件。

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

延后模块，用于当所述第二类事件中存在需要进行预设操作的子事件时，对所述子事件进行封装，将封装好的子事件留到下一时间段的单线程阶段进行处理。

12.根据权利要求8所述的装置，其特征在于，所述装置还包括检测模块，所述检测模块包括：

第一检测模块，用于对单线程阶段的事件处理过程进行检测，当检测到调用多线程预设处理函数时，发出告警信息；

第二检测模块，用于对多线程阶段的事件处理过程进行检测，当检测到调用单线程预设处理函数时，发出告警信息。

13.根据权利要求8所述的装置，其特征在于，所述装置还包括锁处理模块，所述锁处理模块包括：

加锁模块，用于对事件处理过程中需要访问的资源进行加锁；

记录模块，用于记录事件处理过程中的冲突日志和冲突时间；

优先级确定模块，用于根据所述冲突日志和所述冲突时间，确定冲突的优先级；

去锁化模块，用于根据所述优先级，依次对相应的资源进行去锁化处理。

14.根据权利要求13所述的装置，其特征在于，所述去锁化模块包括：

私有化模块，用于采用线程局部变量，将有冲突的变量进行线程私有化。

15.一种电子设备，其特征在于，所述设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如权利要求1至7任一项所述的事件处理方法。

16.一种计算机存储介质，其特征在于，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行如权利要求1-7任一项所述的事件处理方法。

Images