一种任务处理方法及装置与流程
本申请涉及并发处理控制领域，尤其涉及一种任务处理方法及装置。
背景技术：
目前，针对多任务同时处理可采用线程池技术，在同一时刻利用不同线程处理不同任务，达到同时处理多个任务的目的。采用线程池技术，在初始化时可在线程池中创建多个线程和一个任务队列，当有多个任务需要执行时，会将多个任务推入到任务队列中，并从线程池中选择多个空闲的线程分别执行多个任务，当该多个任务执行完毕后，将执行该多个任务的多个线程的状态置为空闲，并将该多个线程再放入线程池中，以使其可以被派发执行新的任务。
现有技术中，线程池中的线程数量是固定值，当任务请求数量过多时，后续请求将直接由任务的调用者直接执行，导致实际并发数会随着请求数增多而加大，导致资源被大量占用，出现资源不足的问题。
因此，亟需一种任务处理方法，实现严格控制任务处理请求的量，避免出现资源出现不足的问题。
技术实现要素：
本申请实施例提供一种任务处理方法及装置，用以动态控制任务请求进入线程池的数量，避免任务并发数太大，资源被大量占用的问题。
第一方面，本申请实施例提供一种任务处理方法，该方法包括：
客户端在第一时段内从下游任务处理节点获取第一参考任务并发数，接着确定出该时间段内的cpu的使用率和内存的使用率，进一步地确定第二参考任务并发数。客户端根据第一参考任务并发数和第二参考任务并发数将令牌的数量调整为第一数值。当客户端在第一时段后的第一时刻接收第一任务处理请求，当判断第一时刻的已用令牌的数量小于上述第一数值时，为第一任务处理请求分配第一令牌并将该任务提交至线程池中处理。
在上述实施例中，利用过去时段内下游任务处理节点上报的第一参考任务并发数，以及根据过去时段内cpu和内存的使用率情况，确定出未来时段内令牌的合适的数量，从而实现动态控制任务并发量，避免因并发数量太大造成资源大量占用，系统卡顿的问题。
在一种可能的实施例中，客户端在第二时刻内接收第二任务处理请求，第二时刻发生在第一时刻之后；当第二时刻已用令牌的数量不小于第一数值时，将第二任务处理请求所在线程休眠，并提交到等待队列中等待处理。
上述实施例中，客户端在第一时刻之后的第二时刻接收第二任务处理请求之后，通过比较当前已使用令牌的数量与当前的第一数值，若不小于第一数值，作为第二任务处理请求线程休眠并被提交至等待队列中等待唤醒。实现了根据过去时段内cpu和内存的使用率情况确定出未来时段内令牌的数量，再根据令牌数量控制任务的处理数量，达到动态且合理地控制任务并发量的效果，避免系统资源使用过度造成系统宕机的问题。
在一种可能的实施例中，客户端在第一任务处理请求提交至线程池被处理完成后，将第一令牌从已用状态更新为可用状态，并将当前已用令牌的数量自减1；当第三时刻已用令牌的数量小于第一数值时，唤醒等待队列中的第三任务处理请求所在的线程，第三时刻发生在第二时刻之后；为第三任务处理请求所在的线程分配令牌，并将第三任务处理请求提交至线程池中处理。
上述实施例中，第一任务处理请求被处理完成之后，客户端释放对应的第一令牌并将当前已用令牌的数量减去1，通过为执行的任务处理请求分配令牌，并在每个任务处理请求完成后释放令牌，实现根据令牌数量调整任务处理请求的处理数量，达到动态控制任务并发量的效果，避免系统资源使用过度造成系统宕机的问题。
在一种可能的实施例中，客户端从第一参考任务并发数和第二参考任务并发数中确定最小参考任务并发数；根据最小参考任务并发数，调整用于控制任务并发数的令牌的数量为第一数值。
上述实施例中，客户端根据第一参考任务并发数和第二参考任务并发数确定出最小参考任务并发数，并进一步地确定出对应的令牌数量，也就是第一数值，实现根据下游任务处理节点、系统当前cpu的使用率、系统的当前内存的使用率确定出当前系统的最佳并发处理数量，实现了根据系统的各项指标灵活调整任务的并发量，提前规避系统或下游任务处理节点资源使用过度的风险，保证系统在正常处理任务请求的情况下，不浪费处理资源，实现高效的任务处理。
在一种可能的实施例中，客户端确定在第一时段内的cpu的使用率，包括：获取到不同任务实例类型的时间片占用次数；任务实例至少包括空闲类型的任务实例，进一步地将第一时段内各任务实例类型的时间片占用次数相加得出第一时段内的总时间片次数。再根据空闲类型的任务实例的时间片占用次数和总时间片次数，计算得到第一时段内的cpu的使用率，cpu的使用率满足公式一；
其中，a为cpu的使用率，b为空闲类型的任务实例的时间片占用次数，c为总时间片次数。
上述实施例中，客户端首先获取系统在第一时段内的不同任务实例类型的时间片占用次数，确定出该时段内的总时间片次数，进一步地根据空闲类型的任务实例对应的时间片占用次数确定出该时段内的cpu的使用率，实现根据系统当前时段的状态调整当前令牌总数，从而控制任务并发处理量，实现了根据系统的各项指标灵活调整任务的并发量，提前规避系统或下游任务处理节点资源使用过度的风险。
在一种可能的实施例中，客户端根据cpu的使用率和内存使用率中的至少一个，确定第二参考任务并发数，包括：当cpu的使用率大于第一阈值时，确定第二参考任务并发数为原有任务并发数量的n1倍，其中n1大于0小于或等于1；当cpu的使用率不大于第一阈值时，确定第二参考任务并发数为原有任务并发数量的m1倍，其中m1大于1。
上述实施例中，客户端实现根据系统当前时段的状态调整当前令牌总数，从而控制任务并发处理量，实现了根据系统当前时段的状态灵活调整任务的并发量，提前规避系统资源使用过度的风险。
在一种可能的实施例中，客户端确定在第一时段内的内存的使用率，包括：获取总java虚拟机jvm内存和当前空闲内存；根据总jvm内存和当前空闲内存，计算得到第一时段内的内存的使用率，内存的使用率满足公式二；
其中，d为内存的使用率，e为当前空闲内存，f为总jvm内存。
上述实施例中，客户端通过公式二确定出第一时段内的内存使用率，帮助后续步骤中确定出令牌的第一数值，也就是帮助实现根据系统当前时段的状态调整当前令牌总数，从而控制任务并发处理量，实现了根据系统当前时段的状态灵活调整任务的并发量，提前规避系统资源使用过度的风险。
在一种可能的实施例中，客户端根据cpu的使用率和内存的使用率中的至少一个，确定第二参考任务并发数，包括：当内存使用率大于第三阈值时，确定第二参考任务并发数为原有任务并发数量的n2倍，其中n2大于0小于或等于1；当内存使用率不大于第四阈值时，确定第二参考任务并发数为原有任务并发数量的m2倍，其中m2大于1。
上述实施例中，客户端根据实现根据系统当前时段的状态调整当前令牌总数，从而控制任务并发处理量，实现了根据系统当前时段的状态灵活调整任务的并发量，提前规避系统资源使用过度的风险。
第二方面，本申请实施例提供一种任务处理装置，包括用于执行以上第一方面各个步骤的单元或手段(means)，具体包括：
接收单元，用于在第一时段内从下游任务处理节点获取第一参考任务并发数；
处理单元，用于确定在第一时段内的cpu的使用率和内存的使用率中的至少一个；
处理单元，还用于根据cpu的使用率和内存使用率中的至少一个，确定第二参考任务并发数；
处理单元，还用于根据第一参考任务并发数和第二参考任务并发数，调整用于控制任务并发数的令牌的数量为第一数值；
接收单元，还用于在第一时刻接收第一任务处理请求，第一时刻发生在第一时段之后；
处理单元，还用于当第一时刻已用令牌的数量小于第一数值时，为第一任务处理请求分配第一令牌，并将第一任务处理请求提交至线程池中处理。
在一种可能的实施例中，接收单元，还用于在第二时刻内接收第二任务处理请求，第二时刻发生在第一时刻之后；
处理单元，还用于当第二时刻已用令牌的数量不小于第一数值时，将第二任务处理请求所在线程休眠，并提交到等待队列中等待处理。
在一种可能的实施例中，处理单元，还用于在第一任务处理请求提交至线程池被处理完成后，将第一令牌从已用状态更新为可用状态，并将当前已用令牌的数量自减1；
当第三时刻已用令牌的数量小于第一数值时，唤醒等待队列中的第三任务处理请求所在的线程，第三时刻发生在第二时刻之后；
为第三任务处理请求所在的线程分配令牌，并将第三任务处理请求提交至线程池中处理。
在一种可能的实施例中，处理单元，具体用于：
从第一参考任务并发数和第二参考任务并发数中确定最小参考任务并发数；
根据最小参考任务并发数，调整用于控制任务并发数的令牌的数量为第一数值。
在一种可能的实施例中，处理单元，具体用于：
获取到不同任务实例类型的时间片占用次数；任务实例至少包括空闲类型的任务实例；
将第一时段内各任务实例类型的时间片占用次数相加，得出第一时段内的总时间片次数。进一步地，根据空闲类型的任务实例的时间片占用次数和总时间片次数，计算得到第一时段内的cpu的使用率，cpu的使用率满足公式一；
其中，a为cpu的使用率，b为空闲类型的任务实例的时间片占用次数，c为总时间片次数。
在一种可能的实施例中，处理单元，具体用于：
当cpu的使用率大于第一阈值时，确定第二参考任务并发数为原有任务并发数量的n1倍，其中n1大于0小于或等于1；
当cpu的使用率不大于第一阈值时，确定第二参考任务并发数为原有任务并发数量的m1倍，其中m1大于1。
在一种可能的实施例中，接收单元，还用于获取总java虚拟机jvm内存和当前空闲内存；
处理单元，具体用于：
根据总jvm内存和当前空闲内存，计算得到第一时段内的内存的使用率，内存的使用率满足公式二；
其中，d为内存的使用率，e为当前空闲内存，f为总jvm内存。
在一种可能的实施例中，处理单元，具体用于：
当内存使用率大于第三阈值时，确定第二参考任务并发数为原有任务并发数量的n2倍，其中n2大于0小于或等于1；
当内存使用率不大于第四阈值时，确定第二参考任务并发数为原有任务并发数量的m2倍，其中m2大于1。
第四方面提供一种计算机可读存储介质，其上存储有一些程序，这些程序被计算机调用执行时，可以使得计算机完成上述第一方面的任意一种可能的实施例中所涉及的方法。
第五方面提供一种计算机程序产品，该计算机程序产品在被计算机调用执行时可以完成第一方面任意可能的设计中所涉及的方法。
附图说明
图1为本申请实施例提供的一种线程池任务处理技术示意图；
图2为本申请实施例提供的一种控制任务请求处理量的系统架构示意图；
图3为本申请实施例提供的一种任务处理方法流程示意图；
图4为本申请实施例提供的一种任务处理方法的流程示意图；
图5为本申请实施例提供的一种令牌工具的工作方法的流程示意图；
图6为本申请实施例提供的一种指标收集方法的流程示意图；
图7为本申请实施例提供的一种并发控制流程示意图；
图8为本申请实施例提供的一种任务处理装置的结构示意图；
图9为本申请实施例提供的一种计算装置的结构示意图。
具体实施方式
为了使本申请实施例的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施例作进一步地详细描述。
以下，对本申请实施例中的部分用语进行解释说明，以便于本领域技术人员理解。
(1)线程池技术，是指在同一时刻可利用不同线程处理不同任务的技术。参阅图1所示，其为一种线程池实现方案，采用线程池技术，在初始化时可在线程池中创建n个线程和一个任务队列，其中n为用户根据实际应用设置的固定值，图1中的n为大于或等于6的整数。当有多个任务需要执行时，会将多个任务推入到任务队列中，图1中以将任务1、任务2以及任务3推入到任务队列为例，当有3个任务需要执行时，可从线程池中选择3个空闲的线程，例如线程1、线程2以及线程3来分别执行该3个任务，当该3个任务执行完毕后，将线程1、线程2以及线程3的状态置为空闲，并将线程1、线程2以及线程3再次放入线程池中，以使其可以被派发执行新的任务。需要说明的是，图1中以一个线程处理一个任务为例说明，实际应用中一个线程也可处理多个任务，例如，一个线程也可以处理两个或三个任务等。
(2)线程，是程序执行的最小单元，是被系统独立调度的基本单位。线程池中的线程可包括两种状态，分别为空闲状态和工作状态。空闲状态是指线程具备处理任务的条件，逻辑上可以处理任务，但当前不处理任务的状态。工作状态是指线程正在处理任务的状态。
(3)“多个”是指两个或两个以上，其它量词与之类似。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。“第一”，“第二”，“第三”，及“第四”等词汇，仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。
随着计算机技术的发展，对多任务同时处理提出更高的需求。目前，针对多任务同时处理可采用线程池技术。但是采用现有的线程池技术，在线程池初始化之后创建的线程数量是固定值。
现有技术中，示例性地，当上述图1中的任务队列中的待执行任务处理请求已达到线程池的承载阈值时，来自线程池的上游节点的任务处理请求仍源源不断地进入线程池，此时线程池可承载的任务处理请求数量超过线程池的承载阈值，那么超过该承载阈值的任务处理请求将直接被执行，所以现有技术中的实际并发数会随着实际任务处理请求的数量增多而加大，最终会造成资源被大量占用，对系统及下游任务处理节点造成影响。
为了解决上述问题，本申请实施例还提供一种控制任务请求处理量的系统架构示意图，如图2所示，该系统架构包括客户端10、服务器20，其中服务器20与客户端10连接，客户端10向服务器20发送任务处理请求(例如交易请求)，服务器20接收到来自客户端10的任务处理请求后，服务器20中的线程池对任务处理请求进行并发处理，具体地处理方法可以参见图3所述的方法流程。
图3为本申请实施例提供的任务处理方法流程示意图，该方法用以根据任务请求处理系统自身参数(包括内存使用率、cpu使用率等)、下游任务处理节点上报的任务处理数量的建议，对任务请求处理量进行动态调整，具体包括如下步骤。
步骤301，服务器20在第一时段内从下游任务处理节点获取第一参考任务并发数。
示例性地，服务器20在2020年5月20日1：00到2020年5月20日2：00，获取任务请求处理系统的下游任务处理节点的第一参考任务并发数，比如为20，上述技术方案通过周期性地根据下游任务处理节点的第一参考任务并发数进行周期调节，避免下游任务处理节点出现资源使用过度的风险。
步骤302，服务器20确定在第一时段内的cpu的使用率和内存的使用率中的至少一个。
示例性地，服务器20在2020年5月20日1：00到2020年5月20日2：00获取任务请求处理系统的内存使用率，cpu使用率等。上述步骤中，通过周期性的获取任务请求处理系统的自身的参数，实现根据系统自身的情况来调整控制任务处理请求的数量，严格控制任务的并发量，避免造成系统或下游任务处理节点的资源使用过度的风险。
步骤303，服务器20根据cpu的使用率和内存使用率中的至少一个，确定第二参考任务并发数。
示例性地。服务器20根据上述获取的cpu的使用率和内存使用率确定出对应的第二参考任务并发数，比如为10。通过上述步骤确定出第二参考任务并发数，进一步地实现根据系统自身的情况来调整控制任务处理请求的数量，严格控制任务的并发量，避免了系统资源被过度使用的风险。
步骤304，服务器20根据第一参考任务并发数和第二参考任务并发数，调整用于控制任务并发数的令牌的数量为第一数值。
在一种可能的实施例中，服务器20从第一参考任务并发数和第二参考任务并发数中确定最小参考任务并发数，进一步地，根据该最小参考任务并发数调整用于控制任务并发数的令牌的数量为第一数值。
示例性地，服务器20确定出最小参考任务并发数为10，进一步地，确定对应的令牌的数量，第一数值可以为10。通过上述步骤，实现根据预设规则周期性地调整令牌的数量，再通过令牌的数量实现对任务的并发数的有效控制，避免了资源使用过度的风险。
步骤305，服务器20在第一时刻接收第一任务处理请求，第一时刻发生在第一时段之后。
示例性地，服务器20在第一时段之后的第一时刻2020年5月20日2：01，接收到第一任务处理请求。
步骤306，当第一时刻已用令牌的数量小于第一数值时，服务器20为第一任务处理请求分配第一令牌，并将第一任务处理请求提交至线程池中处理。
示例性地，服务器20将第一时段确定出的第一数值、当前已使用令牌的数量进行比较，当已用令牌的数量小于第一数值时，为该第一任务处理请求分配一个令牌并将该任务处理请求提交至线程池中处理。实现了根据令牌数控制进入线程池的任务处理请求的数量，严格控制任务的并发量，避免了系统资源被过度使用的风险。
上述步骤中，实现了动态收集任务请求处理系统的指标数据并根据预设规则灵活调整任务处理的并发量，避免造成任务请求处理系统及其下游处理节点的系统资源使用过度的风险，提高了任务请求处理的效率。
进一步地，上述步骤306之后，也就是服务器20在第一任务处理请求提交至线程池被处理完成后，将第一令牌从已用状态更新为可用状态，并将当前已用令牌的数量自减1。进一步地，当第二时刻之后的第三时刻的已用令牌的数量小于第一数值时，唤醒等待队列中的第三任务处理请求所在的线程并为该第三任务处理请求所在的线程分配令牌，并将第三任务处理请求提交至线程池中处理。
示例性地，服务器20在每次任务处理请求被处理完成之后，都将对应的令牌释放归还并将当前已使用令牌的数量减1。进一步地，当在第二时刻之后的第三时刻，服务器20可以比较当前的已用令牌的数量、第一数值，若已用令牌的数量小于第一数值，则可以唤醒等待队列中的第三任务处理请求，为其分配令牌并提交至线程池进行处理；否则不唤醒等待队列中的任务处理请求。通过上述步骤，实现对任务的并发量的严格控制，避免了系统资源被大量占用的风险。
进一步地，上述步骤306之后，服务器20在第一时刻之后的第二时刻接收第二任务处理请求，当第二时刻已用令牌的数量不小于第一数值时，将第二任务处理请求所在线程休眠，并提交到等待队列中等待处理。
示例性地，服务器20在第一时刻后的第二时刻接收第二任务处理请求，比较当前的已使用令牌的数量、第一数值，当已使用令牌的数量不小于第一数值时，将第二任务处理请求的线程休眠并放入等待队列中，等待唤醒。实现根据当前时刻的令牌的已使用数量和上一周期确定的第一数值，灵活调节任务处理请求进入线程池的数量，严格控制任务的并发量，避免造成该系统的资源使用过度的风险。
在一种可能的实施例中，上述步骤302中，服务器20确定在第一时段内的cpu的使用率，包括：
获取任务处理系统中不同类型的任务实例在第一时段内的时间片占用次数，并相加得出第一时段内的总时间片次数。进一步地，根据其中空闲类型的任务实例的时间片占用次数和总时间片次数，计算得到第一时段内的cpu的使用率，cpu的使用率满足公式一；
其中a为cpu的使用率，b为空闲类型的任务实例的时间片占用次数，c为总时间片次数。
示例性地，使用跨平台服务器信息查询工具osh查看服务器20的cpu使用率，其中，首先获取到不同类型，比如用户user、内核sys、空闲idle、等待iowait等类型的任务实例的时间片占用次数。进一步地，服务器20将上述不同类型的任务实例的时间片占用次数相加得到总时间片次数。
比如在服务器20中任务处理系统在第一时段2020年5月20日1：00到2020年5月20日2：00，用户类型的任务实例的时间片占用次数为5，内核类型的任务实例的时间片占用次数为10，空闲类型的任务实例的时间片占用次数b为15，等待类型的任务实例的时间片占用次数为20。进一步地，得出第一时段内的总时间片次数c为5+10+15+20＝50。
再进一步地，服务器20根据公式：
在一种可能的实施例中，上述步骤303，还包括：
当cpu的使用率大于第一阈值时，服务器20确定第二参考任务并发数为原有任务并发数量的n1倍，其中n1大于0小于或等于1；当cpu的使用率和内存使用率不大于第二阈值时，确定第二参考任务并发数为原有任务并发数量的m1倍，其中m1大于1。
示例性地，服务器20判断上述cpu使用率超过了预设第一阈值60％，则确定原有任务并发数20的1/2为新的第二参考并发数10。为后续步骤中确定出第一数值做好准备，帮助实现根据令牌的第一数值控制任务的并发量，避免了系统资源被大量占用的问题。
在一种可能的实施例中，上述步骤302中，服务器20确定在第一时段内的内存的使用率，包括：
获取总java虚拟机jvm内存和当前空闲内存，进一步地，服务器20根据总jvm内存和当前空闲内存，计算得到第一时段内的内存的使用率，内存的使用率满足公式二；
其中，d为内存的使用率，e为当前空闲内存，f为总jvm内存。
示例性地，服务器20通过jdk(javadevelopmenttoolkit，java语言开发工具包)提供的runtime对象，确定出总jvm内存50和当前空闲内存10。再根据公式计算出内存使用率
进一步地，上述步骤303中，服务器20根据cpu的使用率和内存的使用率中的至少一个，确定第二参考任务并发数，还包括：
当内存的使用率大于第三阈值时，确定第二参考任务并发数为原有任务并发数量的n2倍，其中n2大于0小于或等于1；当内存的使用率不大于第四阈值时，确定第二参考任务并发数为原有任务并发数量的m2倍，其中m2大于1。
示例性地，内存使用率80％大于第三阈值60％，确定出原有任务并发数量20的4/5的第二参考任务并发数16。
可选地，确定出上述两个第二参考任务并发数10、16中的较小的值为最终的第二参考任务并发数，示例性地，最终的第二参考任务并发数为10。
在一种可能的实施例中，服务器20可以将令牌总数设置为线程池中的核心线程数、非核心线程数和定长队列的长度之和，实现通过令牌的数量来严格控制任务处理的并发数。比如，每一个任务处理请求都必须获取一个令牌之后，才能进入线程池；如果一个任务处理请求未获取到令牌，此时该任务处理请求将被放入等待队列，该任务处理请求对应的线程进行休眠并等待被唤醒。
基于上述描述，本发明实施例还提供如图4所示的一种任务处理方法的流程示意图，包括：
步骤401，服务器20接收任务处理请求，可选地，服务器20为该任务处理请求申请获取令牌。
步骤402，服务器20判断当前已用令牌的数量是否小于第一数值，当小于时，进入步骤403；否则进入步骤404。
步骤404，服务器20将任务请求对应的线程休眠，并将该请求提交至等待队列。
步骤403，服务器20为任务处理请求分配令牌并将该请求提交至线程池处理。
步骤405，当该任务处理请求处理完后，服务器20归还令牌，也就是将令牌从已用状态更新为可用状态，并将当前已用令牌的数量自减1。
步骤406，进一步地，服务器20判断当前已用令牌的数量是否小于第一数值，当小于时，进入步骤408，否则进入步骤407。
步骤407，服务器20不唤醒等待队列中的任务处理请求的线程。
步骤408，服务器20唤醒等待队列中的任务处理请求的线程，具体地，服务器20根据底层线程调度将404中的等待队列中的一个线程唤醒，并进入步骤409。
步骤409，服务器20为上述被唤醒的任务处理请求申请获取令牌并返回步骤后403。
可选地，当等待队列中的所有任务处理请求都被处理完之后，返回步骤401。
基于上述描述，本发明实施例还提供一种令牌工具的工作方法，如图5所示，其中令牌工具至少包括获取令牌模块50、归还令牌模块51、重置令牌总数模块52。
第一部分，获取令牌模块50的工作方法包括：
步骤501，获取锁，其中锁用于控制同时只有一个任务处理请求的线程能进入到令牌维护和校验的逻辑，保证后续步骤中无并发问题。
步骤502，判断已用令牌的数量，是否小于第一数值，该第一数值为当前的令牌总数。若是，进入步骤503并将已用令牌的数量加1，并进入步骤505释放锁，步骤506，返回成功；否则，表明当前令牌已全部被使用，已达到最大并发数，进入步骤504。
步骤504，将任务处理请求对应线程休眠。
步骤507，将任务处理请求提交至等待队列。
可选地，当等待队列中的一个线程被唤醒，则进入步骤508，将该线程从等待队列中取出。
第二部分，归还令牌模块51的工作方法包括：
步骤511，获取锁，其中锁用于控制同时只有一个任务处理请求的线程能进入到令牌维护和校验的逻辑，保证后续步骤中无并发问题。
步骤512，将已用令牌的数量减1。
步骤513，判断已用令牌的数量是否小于第一数值。若是，进入步骤514；否则，表明最近一段时间内令牌总数对应的第一数值被调减，进入步骤515。
步骤514，唤醒等待队列中的一个任务处理请求的休眠的线程。
步骤515，释放锁，不唤醒等待队列中的线程，以实现逐步减小并发数的效果(适用于令牌总数调减的场景)。
步骤517，将唤醒的线程对应的任务处理请求从等待队列中移出，可选地，为该任务处理请求分配令牌并提交至线程池进行处理。
第三部分，调整令牌模块52的工作方法包括：
步骤521，获取锁，锁用于控制同一时刻只有一个任务处理请求的线程进入到令牌维护和校验的逻辑，保证后续步骤中无并发问题。
步骤522，修改令牌总数的第一数值，再进入步骤523判断以下两种情况：
情况一，对第一数值调增：唤醒对应调增的数量的等待队列中的休眠线程，此时获取到令牌的任务处理请求的线程的数量同步增加，此时进入步骤525，发出唤醒信号；进一步地，进入步骤509，唤醒线程；进一步地，可以进入步骤524释，放锁。
情况二，对第一数值调减：通过在上述归还令牌模块的逻辑中的步骤513及相关步骤，实现使获取令牌的任务处理请求的线程的数量持续减小的效果，此时进入步骤524，释放锁。
基于上述描述，本发明实施例还提供如图6所示的指标收集方法，用于根据任务处理系统下游节点的第一参考任务并发数、任务请求处理系统的cpu使用率、内存使用率确定出令牌总数对应的第一数值。其中包括：
步骤601，参数初始化，其中服务器20配置系统起始参数，包括配置任务并发数、设定的内存使用率阈值、设定的cpu使用率阈值。比如任务并发数为20，设定的内存使用率阈值为60％、设定的cpu使用率阈值为60％。
步骤602，服务器20获取下游任务处理节点上报的指标，其中，任务处理系统根据http接口，获取下游任务处理节点上报的第一参考任务并发数。进一步地，记录第一参考任务并发数。比如，第一参考任务并发数为10。
步骤603，服务器20通过跨平台服务器信息查询工具oshi，采集cpu使用率；进一步地，根据设定的cpu使用率阈值确定出cpu建议并发数。
示例性地，服务器20采集第一时段内的不同类型的任务实例的时间片占用次数，进一步地，将各个类型的时间占用次数相加确定出总时间片次数c。再进一步地，根据公式
比如，服务器20采集第一时段内空闲类型的任务实例的时间片占用次数为15，用户类型的任务实例的时间片占用次数为10，系统类型的任务实例的时间片占用次数为20，等待类型的任务实例的时间片占用次数为5。上述各个类型的任务实例的时间片占用次数相加得到总时间片占用次数totalcpu，为50。再根据公式
步骤604，服务器20通过jdk提供的runtime对象采集内存的使用率；进一步地，根据内存使用率阈值确定出内存建议并发数。
示例性地，服务器20通过jdk提供的runtime对象，获取总内存totalmemory、空闲内存freememory。进一步地，服务器20根据公式
比如，服务器20确定出第一时段内的内存的使用率为30％，不超过设定的内存使用率阈值60％，则不设置内存建议并发数。
步骤605，服务器20比较第一参考任务并发数、内存建议并发数、cpu建议并发数，取其中的最小值为第一数值。示例性地，服务器20比较第一参考任务并发数10、cpu建议并发数15，确定出第一数值为10。
步骤606，服务器20根据第一数值重置令牌总数。示例性地，将令牌总数重置为10。
步骤607，服务器20重置线程池参数，示例性地，重置线程池的任务并发数为10。
可选地，周期执行上述方法，实现实时根据系统及下游任务处理节点的参数动态调整令牌数，实现严格控制任务并发数，避免资源使用过度。
在一种可能的实施例中，针对上述令牌工具，还可以使用samepore作为令牌工具，其中并发控制流程如图7所示，包括：
步骤701，服务器20获取任务处理请求。
步骤702，服务器20判断当前剩余的令牌数是否大于0，若是，进入步骤703；否则进入步骤704。
步骤704，服务器20将该任务处理请求的线程休眠并放入等待队列中。
步骤703，服务器20为该任务处理请求分配令牌并将该任务处理请求提交至线程池进行处理。
步骤705，服务器20释放令牌，将剩余令牌数加1。
步骤706，服务器20判断剩余令牌数是否大于0，若是，进入步骤707；否则进入步骤708。
步骤707，服务器20通过底层线程调度唤醒等待队列中的休眠的一个任务处理请求的线程，并进入步骤709，为该任务处理申请分配令牌，再进入步骤703，获取令牌并将该请求提交至线程池进行处理。
可选地，当等待队列中的休眠的任务处理请求全部处理完成后，返回步骤701，获取新的任务处理请求。
可选地，步骤708，不唤醒等待队列中的任务处理请求。
基于与方法实施例的同一发明构思，本申请实施例还提供一种任务处理装置。可以理解的是，该任务处理装置为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
图8示出了本申请实施例涉及的任务处理装置的一种可能的结构示意图。如图8所示，任务处理装置800包括接收单元801、处理单元802。
接收单元，用于在第一时段内从下游任务处理节点获取第一参考任务并发数。
处理单元，用于确定在第一时段内的cpu的使用率和内存的使用率中的至少一个。进一步地，还用于根据cpu的使用率和内存使用率中的至少一个，确定第二参考任务并发数。
处理单元，还用于根据第一参考任务并发数和第二参考任务并发数，调整用于控制任务并发数的令牌的数量为第一数值。
接收单元，还用于在第一时刻接收第一任务处理请求，第一时刻发生在第一时段之后。
处理单元，还用于当第一时刻已用令牌的数量小于第一数值时，为第一任务处理请求分配第一令牌，并将第一任务处理请求提交至线程池中处理。
在一种可能的实施例中，接收单元，还用于在第二时刻内接收第二任务处理请求，第二时刻发生在第一时刻之后。
处理单元，还用于当第二时刻已用令牌的数量不小于第一数值时，将第二任务处理请求所在线程休眠，并提交到等待队列中等待处理。
在一种可能的实施例中，处理单元，还用于在第一任务处理请求提交至线程池被处理完成后，将第一令牌从已用状态更新为可用状态，并将当前已用令牌的数量自减1。
当第三时刻已用令牌的数量小于第一数值时，唤醒等待队列中的第三任务处理请求所在的线程，第三时刻发生在第二时刻之后。
为第三任务处理请求所在的线程分配令牌，并将第三任务处理请求提交至线程池中处理。
在一种可能的实施例中，处理单元，具体用于：
从第一参考任务并发数和第二参考任务并发数中确定最小参考任务并发数。再根据最小参考任务并发数，调整用于控制任务并发数的令牌的数量为第一数值。
在一种可能的实施例中，处理单元，具体用于：
获取到不同任务实例类型的时间片占用次数；任务实例至少包括空闲类型的任务实例。将第一时段内各任务实例类型的时间片占用次数相加，得出第一时段内的总时间片次数；
根据空闲类型的任务实例的时间片占用次数和总时间片次数，计算得到第一时段内的cpu的使用率，cpu的使用率满足公式一；
其中，a为cpu的使用率，b为空闲类型的任务实例的时间片占用次数，c为总时间片次数。
在一种可能的实施例中，处理单元，具体用于：
当cpu的使用率大于第一阈值时，确定第二参考任务并发数为原有任务并发数量的n1倍，其中n1大于0小于或等于1；
当cpu的使用率不大于第一阈值时，确定第二参考任务并发数为原有任务并发数量的m1倍，其中m1大于1。
在一种可能的实施例中，接收单元，还用于获取总java虚拟机jvm内存和当前空闲内存；
处理单元，具体用于：
根据总jvm内存和当前空闲内存，计算得到第一时段内的内存的使用率，内存的使用率满足公式二；
其中，d为内存的使用率，e为当前空闲内存，f为总jvm内存。
在一种可能的实施例中，处理单元，具体用于：
当内存使用率大于第三阈值时，确定第二参考任务并发数为原有任务并发数量的n2倍，其中n2大于0小于或等于1；
当内存使用率不大于第四阈值时，确定第二参考任务并发数为原有任务并发数量的m2倍，其中m2大于1。
图8中示出的设备结构并不构成对任务处理装置的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。
基于相同的技术构思，本发明实施例提供了一种计算设备，如图9所示，包括至少一个处理器901，以及与至少一个处理器连接的存储器902，本发明实施例中不限定处理器901与存储器902之间的具体连接介质，图9中处理器901和存储器902之间通过总线连接为例。总线可以分为地址总线、数据总线、控制总线等。
在本发明实施例中，存储器902存储有可被至少一个处理器901执行的指令，至少一个处理器901通过执行存储器902存储的指令，可以执行前述的漏洞检测方法中所包括的步骤。
其中，处理器901是终端设备的控制中心，可以利用各种接口和线路连接终端设备的各个部分，通过运行或执行存储在存储器902内的指令以及调用存储在存储器902内的数据，从而处理数据。可选的，处理器901可包括一个或多个处理单元，处理器901可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器901中。在一些实施例中，处理器901和存储器902可以在同一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。
处理器901可以是通用处理器，例如中央处理器(cpu)、数字信号处理器、专用集成电路(applicationspecificintegratedcircuit，asic)、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本发明实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
存储器902作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器902可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(randomaccessmemory，ram)、静态随机访问存储器(staticrandomaccessmemory，sram)、可编程只读存储器(programmablereadonlymemory，prom)、只读存储器(readonlymemory，rom)、带电可擦除可编程只读存储器(electricallyerasableprogrammableread-onlymemory，eeprom)、磁性存储器、磁盘、光盘等等。存储器902是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本发明实施例中的存储器902还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。
基于同一发明构思，本发明实施例还提供了一种计算机可读非易失性存储介质，包括计算机可读程序，当计算机读取并执行计算机可读程序时，使得计算机执行上述实施例中的漏洞检测的方法。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的程序产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的程序产生包括程序装置的制造品，该程序装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的程序提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
显然，本领域的技术人员可以对本申请实施例进行各种改动和变型而不脱离本申请实施例的精神和范围。这样，倘若本申请实施例的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。
- 还没有人留言评论。精彩留言会获得点赞！