补贴明细生成方法、装置和电子设备

技术领域

本申请涉及生成薪资明细的技术领域，尤其是涉及一种补贴明细生成方法、装置和电子设备。

背景技术

在当前快递业迅猛发展的前提下，快递业务激增，与此同时，运输司机从业人数快速增加，司机补贴也越来越普及，所以司机补贴明细线上化处理已成为必然趋势。一般的，在司机薪酬补贴明细线上化处理过程中，需要使用算法将司机薪酬补贴明细计算出来，司机薪酬补贴明细包括路补和油补两个计算场景，其中路补包括路程补贴和困难线路补贴，油补包括油耗补贴。现有计算司机薪酬补贴明细算法中的计算代码一般是一个整体，且匹配规则很多，每次匹配只通过一个匹配条件进行匹配，导致匹配过程层层嵌套，每次匹配都需要遍历所有层级的匹配条件才能得到目标计算规则。

由于每次获得目标计算规则都要经历很多次匹配过程，导致运行时需要进行大量匹配后才能得到目标计算规则，在此过程中匹配过程时间过长，会延长计算时间，导致算法计算效率不高。

故，现如今计算司机薪酬补贴明细算法存在计算效率低的问题。

发明内容

为了提高计算效率，本申请提供一种补贴明细生成方法、装置和电子设备，其具体方案如下：

第一方面，本申请提供一种补贴明细生成方法，采用如下的技术方案：

一种补贴明细生成方法，包括：

获取多个任务单各自对应的任务单数据和司机在每一任务单运输过程中产生的相关数据；任务单数据至少包括：特定类型数据、司机信息、车辆信息，特定类型数据包括车牌号、挂车号、车型、线路、站点中的若干个；

针对每一任务单，通过每一任务单对应的唯一线程，根据所述特定类型数据、所述司机信息、所述车辆信息，获取若干补贴计算规则，其中，每一所述补贴计算规则至少包括费率，用以计算油补与路补；

针对每一任务单，根据若干所述补贴计算规则的优先级，将优先级最高的补贴计算规则作为最终补贴计算规则；

针对每一任务单，基于所述最终补贴计算规则对司机在每一任务单运输过程中产生的相关数据进行计算，得到第一计算结果；

根据多个任务单各自对应的第一计算结果，生成多个任务单各自对应的补贴明细。

通过采用上述技术方案，获取多个任务单各自对应的任务单数据和司机在每一任务单运输过程中产生的相关数据，将匹配规则落在任务单维度上，为获取以任务单为单位的补贴明细奠定数据基础；在每一个线程中，根据任务单数据中的特定类型数据、司机信息、车辆信息，匹配得到若干条补贴计算规则，能够极大提高匹配的效率；为保证计算结果的唯一性，最终计算只需要一条最终补贴计算规则，因而，根据若干补贴计算规则的优先级，从匹配得到的若干条补贴计算规则中选择一条最合适的补贴计算规则，作为最终补贴计算规则；根据获取到的最终补贴计算规则，基于最终补贴计算规则对司机在每一任务单运输过程中产生的相关数据，计算得到每一任务单的第一计算结果；最终根据多个任务单的第一计算结果，生成所有任务单的补贴明细，直接获取以任务单为单位的补贴明细，得到的补贴明细信息清晰易见，为后续工作节省时间。由此可见，本申请技术方案能够提升计算效率。

本申请在一较佳示例中可以进一步配置为：

在根据所述特定类型数据、所述司机信息、所述车辆信息，获取若干补贴计算规则之前，还包括：

针对每一任务单，根据司机信息和车辆信息，获取每一任务单中对应的若干大范围补贴计算规则；

相应的，针对每一任务单，通过每一任务单对应的唯一线程，根据特定类型数据、司机信息、车辆信息，获取若干补贴计算规则的进一步配置，包括：

针对每一任务单，通过每一任务单对应的唯一线程，根据特定类型数据、司机信息、车辆信息和若干大范围补贴计算规则，获取若干补贴计算规则。

通过采用上述技术方案，先从数据库中的规则信息中筛取大范围补贴计算规则，再从大范围补贴计算规则中筛取适用于当前任务单的若干补贴计算规则，避免直接从数据库中成千上万的规则信息中直接获取最终补贴计算规则，这一匹配过程中耗费过长时间，本方案能够提升获取最终补贴计算规则的效率。

本申请在一较佳示例中可以进一步配置为：司机在每一任务单运输过程中产生的相关数据包括：任务实际里程或任务实际次数或任务实际用时，任务实际用油数据，OA申请补油数据，司机人数，

所述基于最终补贴计算规则对司机在每一任务单运输过程中产生的相关数据进行计算，得到第一计算结果，包括：

基于最终补贴计算规则对任务实际里程或任务实际次数或任务实际用时进行计算，得到第一计算结果。

相应的，本申请在一较佳示例中可以进一步配置为：

根据多个任务单的第一计算结果，生成多个任务单补贴明细，包括：

根据线路的数据、每一任务单的第一计算结果、任务实际用油数据和OA申请补油数据，得到每一任务单的第二计算结果,其中，线路的数据包括线路名称和线路名称对应的线路补贴金额；

根据每一任务单的第二计算结果和对应的司机人数，得到每一任务单的最终计算结果；

根据多个任务单的最终计算结果，得到多个任务单补贴明细。

通过采用上述技术方案，本方案能够在得到第一计算结果确定基础的路补以及油补之后，结合任务实际用油数据、OA申请补油数据和司机人数最终确定每一任务单的最终计算结果，进而得到的任务单补贴明细更符合实际情况，提高最终生成的任务单补贴明细的准确度。

本申请在一较佳示例中可以进一步配置为：

在所述在针对每一任务单，通过每一任务单对应的唯一线程，根据特定类型数据、司机信息、车辆信息，获取若干补贴计算规则之前，还包括：

利用线程池，将若干空闲的线程分配给多个任务单中的若干任务单，其中，每一任务单对应唯一线程；

若存在未分配线程的任务单，则将未分配线程的任务单放入缓存队列等待空闲的线程。

通过采用上述技术方案，能够利用设置的线程池进行任务单的计算分配，利用已设置好的缓冲队列，放置等待处理的若干任务单，有效预防了全部任务单进入线程池处理而造成阻塞情况的发生。

本申请在一较佳示例中可以进一步配置为：

所述补贴明细生成方法，还包括：

判断线程池中的空闲线程的空闲时间是否大于线程池维护线程所允许的空闲时间；

若是，则关闭空闲时间大于线程池维护线程所允许的空闲时间的空闲线程，

其中，所述线程池维护线程所允许的空闲时间是基于线程池的预设使用频率设置的。

通过采用上述技术方案，在线程池中的空闲线程的空闲时间大于线程池维护线程所允许的空闲时间后，可以关闭空闲时间大于线程池维护线程所允许的空闲时间的空闲线程，减少线程耗能。

本申请在一较佳示例中可以进一步配置为：

所述多线程下的补贴明细生成方法，还包括：

根据所有任务单的参考计算时间、待计算数据的量级、CPU性能和可接受的计算时间，设置线程池维护线程最大数量，其中，待计算数据包括多个任务单各自对应的任务单数据和司机在每一任务单运输过程中产生的相关数据，每一任务单的参考计算时间表征过去运行数量级相同的任务单所耗时间。

通过采用上述技术方案，能够结合所有任务单的参考计算时间、待计算数据的量级、CPU性能和可接受的计算时间综合确定线程池的维护线程最大数量，设置的维护线程最大数量更加准确。

本申请在一较佳示例中可以进一步配置为：

针对每一任务单，通过每一任务单对应的唯一线程，根据特定类型数据、司机信息、车辆信息，获取若干补贴计算规则，包括：

利用Synchronized和Threadlocal，将多个任务单各自对应的任务单数据和司机在每一任务单运输过程中产生的相关数据，传递至各个线程；

针对每一任务单，通过每一任务单对应的唯一线程，根据传递至各个线程的特定类型数据、司机信息、车辆信息，获取每一任务单对应的若干补贴计算规则。

通过采用上述技术方案，能够利用Synchronized和Threadlocal机制，保证同一时刻只有一个线程对变量中的数据进行操作；与此同时，使线程池的变量中的所述数据在每个线程中都有独立拷贝，避免跨层传递而造成的数据混乱。

本申请在一较佳示例中可以进一步配置为：

所述补贴明细生成方法，在应对出现的新增特定类型数据时，还包括：

获取新增特定类型数据请求信息，其中，新增特定类型数据请求信息包括新增特定类型数据和新增特定类型数据对应的规则，新增特定类型数据对应的规则包括补贴计算规则和补贴计算规则对应的优先级；

根据新增特定类型数据请求信息，更新与特定类型数据对应的补贴计算规则集；其中，所述补贴计算规则集用于基于某一特定类型数据确定相应的补贴计算规则。

通过采用上述技术方案，能够基于新增特定类型数据请求信息更新对应的补贴计算规则集，使算法有拓展性，灵活性较强。

第二方面，本申请提供一种补贴明细生成装置，采用如下的技术方案：

一种补贴明细生成装置，包括：

数据获取模块，用于获取多个任务单各自对应的任务单数据和司机在每一任务单运输过程中产生的相关数据；任务单数据至少包括：特定类型数据、司机信息、车辆信息，特定类型数据包括车牌号、挂车号、车型、线路、站点中的若干个；

计算规则匹配模块，用于针对每一任务单，通过每一任务单对应的唯一线程，根据所述特定类型数据、所述司机信息、所述车辆信息，获取若干补贴计算规则，其中，每一所述补贴计算规则至少包括费率，用以计算油补与路补；

计算规则确定模块，用于针对每一任务单，根据若干所述补贴计算规则的优先级，将优先级最高的补贴计算规则作为最终补贴计算规则；

第一计算结果获取模块，用于针对每一任务单，基于所述最终补贴计算规则对司机在每一任务单运输过程中产生的相关数据进行计算，得到第一计算结果；

任务单补贴明细生成模块，用于根据多个任务单各自对应的第一计算结果，生成多个任务单各自对应的补贴明细。

第三方面，本申请提供一种智能终端或补贴明细生成装置，采用如下的技术方案：

至少一个处理器；

存储器；

至少一个应用程序，其中至少一个应用程序被存储在存储器中并被配置为由至少一个处理器执行，所述至少一个应用程序配置用于：执行上述任一项的补贴明细生成方法。

第四方面，本申请提供一种计算机可读存储介质，采用如下的技术方案：

一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令所述计算机执行第一方面任一项所述的方法。

综上所述，本申请包括以下至少一种有益技术效果：

1.获取多个任务单各自对应的任务单数据和司机在每一任务单运输过程中产生的相关数据，将匹配规则落在任务单维度上，为获取以任务单为单位的补贴明细奠定数据基础；在每一个线程中，根据任务单数据中的特定类型数据、司机信息、车辆信息，匹配得到若干条补贴计算规则，能够极大提高匹配的效率；为保证计算结果的唯一性，最终计算只需要一条最终补贴计算规则，因而，根据若干补贴计算规则的优先级，从匹配得到的若干条补贴计算规则中选择一条最合适的补贴计算规则，作为最终补贴计算规则；根据获取到的最终补贴计算规则，基于最终补贴计算规则对司机在每一任务单运输过程中产生的相关数据，计算得到每一任务单的第一计算结果；最终根据多个任务单的第一计算结果，生成所有任务单的补贴明细，直接获取以任务单为单位的补贴明细，得到的补贴明细信息清晰易见，为后续工作节省时间。由此可见，本申请技术方案能够提升计算效率。

2.在得到第一计算结果确定基础的路补以及油补之后，结合任务实际用油数据、OA申请补油数据和司机人数最终确定每一任务单的最终计算结果，进而得到的任务单补贴明细更符合实际情况，提高最终生成的任务单补贴明细的准确度。

3.利用设置的线程池进行任务单的计算分配，利用已设置好的缓冲队列，放置等待处理的若干任务单，有效预防了全部任务单进入线程池处理而造成阻塞情况的发生。

附图说明

图1是本申请其中一实施例的补贴明细生成方法的流程示意图。

图2是本申请其中一实施例的补贴明细生成装置的结构示意图。

图3是本申请其中一实施例的电子设备的结构示意图。

具体实施方式

以下结合附图的图1至图3对本申请作进一步详细说明。

本具体实施例仅仅是对本申请的解释，其并不是对本申请的限制，本领域技术人员在阅读完本说明书后可以根据需要对本实施例做出没有创造性贡献的修改，但只要在本申请的范围内都受到专利法的保护。

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

另外，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，如无特殊说明，一般表示前后关联对象是一种“或”的关系。

具体的，本申请实施例提供了一种补贴明细生成方法，由电子设备执行，该电子设备可以为服务器也可以为终端设备，其中，该服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云计算服务的云服务器。终端设备可以是智能手机、平板电脑、笔记本电脑、台式计算机等，但并不局限于此，该终端设备以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请实施例在此不做限制，如图1所示，该方法包括步骤S101、步骤S102、步骤S103、步骤S104以及步骤S105，其中：

步骤S101：获取多个任务单各自对应的任务单数据和司机在每一任务单运输过程中产生的相关数据；任务单数据至少包括：特定类型数据、司机信息、车辆信息，特定类型数据至少包括车牌号、挂车号、车型、线路、站点中的若干个。

任务单包括运输任务单，由于运输公司的运输任务是源源不断的，故待计算任务单也是多个，各任务单对应的任务单数据也是彼此独立的数据；每一任务单对应的任务单数据至少包括：特定类型数据、司机信息、车辆信息；一般的，在运输任务进行过程中，运输车辆不会发生变化，故车辆信息是唯一的，车辆信息至少包括：车牌号，而，在运输行业中，运输路线分为短途和长途，对于司机信息来说，当运输路线属于长途时，司机信息可以包括多人信息，当运输路线属于短途运输时，司机信息可以包括单人信息；在后续选择合适计算规则计算补贴时，若根据任务单所有数据进行选择，选择过程会过于繁琐，甚至会由于这一繁琐过程导致整个补贴明细生成效率降低，故，可以选取特定类型数据，用于选择合适计算规则进行补贴明细计算。

司机在每一任务单运输过程中产生的相关数据包括但是不限定于：任务实际里程或任务实际次数或任务实际用时、司机人数、任务实际用油数据和OA申请补油数据。

步骤S102：针对每一任务单，通过每一任务单对应的唯一线程，根据特定类型数据、司机信息、车辆信息，获取若干补贴计算规则，其中，每一补贴计算规则至少包括补贴金额或油量的费率，用以计算油补与路补。

特定类型数据匹配补贴计算规则时，可以包括，特定类型数据无法匹配到对应的补贴计算规则，或，特定类型数据匹配到若干条补贴计算规则，其中，特定类型数据匹配到多条补贴计算规则时，后续对于补贴计算规则的筛选过程，可以根据预先写入的优先级进行筛选。

在本申请实施例中，由于同时有多个任务单要处理，因而可以引入线程池，使用多线程处理多个任务单，其中，每一线程对应唯一任务单，待每一线程中的唯一任务单处理结束后，下一个任务单会进入空闲线程继续进行处理，直到所有任务单处理完毕。

在本申请实施例中，补贴计算规则在数据库中可以以规则信息形式储存的，每一条规则信息包括司机信息名称、车辆信息名称、特定类型信息名称和对应补贴金额或油量的费率，规则信息中的司机信息名称、车辆信息名称和特定类型信息名称，是用于匹配补贴计算规则的匹配条件。具体的，利用任务单数据中司机信息名称、车辆信息名称和特定类型信息名称，与数据库中的规则信息匹配，若任务单数据中司机信息名称、车辆信息名称和特定类型信息名称，与规则信息中的匹配条件相同，则匹配成功，匹配成功后就将这条匹配成功的规则信息，作为补贴计算规则；但，由于每一任务单中的司机信息和特定类型信息都存在一个和多个的情况，故，每一任务单获得的补贴计算规则也不唯一，存在一个和多个的情况，也就是说，每个任务单通过匹配过程，可以获得若干补贴计算规则。

例如，当特定类型数据包括：车牌号、挂车号、车型时，对应获得的补贴计算规则为针对任务单的司机信息、任务单的车辆信息的车牌号对应的第一补贴计算规则、挂车号对应的第二补贴计算规则、车型对应的第三补贴计算规则；若特定类型数据还包括：线路和站点，则补贴计算规则还应该包括：针对任务单的司机信息、任务单的车辆信息的线路对应的第四补贴计算规则、站点对应的第五补贴计算规则。可以理解的是，由于任务单数据的特定类型数据可能需要用户上传，可能不同的任务单数据的特定类型数据的类型数量以及类型数据不同，因而，本申请实施例能够结合实际情况基于实际的特定类型数据确定对应的补贴计算规则。

其中，通过根据每一任务单的特定类型数据、司机信息、车辆信息，能够将每一任务单的所有补贴计算规则全部筛选出来，相较于相关技术，本申请实施例应用特定类型数据、司机信息、车辆信息三大类信息，直接对补贴计算规则进行筛选，避免了由每次匹配只通过一个匹配条件进行匹配，整个匹配过程可以遍历所有层级的匹配条件才能得到目标计算规则，造成的匹配时间过长、计算时间延长，甚至是计算效率不高的问题出现。

值得注意的是，本申请实施例能够提供多条线程，对多个任务单进行补贴计算规则的确认。多条线程的数量用户可根据实际情况设置，但是当存在线程数量小于任务单数量时，在进行线程分配后，每个线程分配的任务单可能是一个或者多个，只有当前一任务单执行完成后才能进行下一任务单的处理，且，当某一线程分配多个任务单时，可以基于获取的任务单的时间先后的顺序确定任务单处理顺序，还可以是基于预设的任务单的处理优先级确定任务单处理顺序，本申请实施例不再进行限定，只要是能够实现本申请实施例的目的即可。

步骤S103：针对每一任务单，根据若干补贴计算规则的优先级，将优先级最高的补贴计算规则作为最终补贴计算规则。

由于每个任务单通过匹配过程，会获得若干补贴计算规则，但，每个任务单计算补贴时只可以使用一个补贴计算规则，故，对于每一个任务单来说，可以从获得的若干补贴计算规则中选取一个最合适的补贴规则作为最终补贴规则；每一补贴计算规则的优先级，都是预先设定好的，在基于每一补贴计算规则的优先级选取最终补贴计算规则时，直接调用即可。

具体的，对于每一条任务单来说，根据既定的补贴计算规则的优先级，将获得的若干补贴计算规则与既定优先级一一对应，选取若干补贴计算规则中优先级最高的补贴计算规则，作为最终补贴计算规则。

若经过优先级的筛选，仍剩余大于一条的最高优先级补贴计算规则，在一种可实现的方式中，可以向规则信息维护人员对应的终端设备弹出警示窗口，以提示规则信息维护人员，规则信息中存在若干优先级相同的补贴计算规则，可以对补贴补贴计算规则的优先级进行重排，进而，可以获取维护人员对应的终端设备发送的重排信息，以进行最高优先级的重新确定，还可以获取维护人员对应的终端设备发送的最终确定的最高优先级。

本申请实施例通过既定优先级筛选出最终计算规则，避免每个任务单直接用获得的若干补贴计算规则进行计算获得多种计算结果之后，还要再从多个不同的计算结果中选取最合适的计算结果，减少了很多不必要的计算过程同时，也减少了计算结果混乱导致的计算结果正确率下降，节省计算时间，提高算法计算效率。

步骤S104：针对每一任务单，基于最终补贴计算规则对司机在每一任务单运输过程中产生的相关数据进行计算，得到第一计算结果。

可以理解的是，本申请实施例中，能够基于司机司机在每一任务单运输过程中产生的相关数据利用最终补贴计算规则计算油补和路补作为第一计算结果。

具体的，在一些可能的情况中，司机在每一任务单运输过程中产生的相关数据至少包括：任务实际里程或任务实际次数或任务实际用时；第一计算结果至少包括基本油补、基本路补；其中，基本油补指的是完成每一运输任务的耗油量，基本路补指的是完成每一运输任务的基本补贴金额；基本油补和基本路补的计算都要利用最终补贴计算规则的费率来完成，对于补贴计算规则的设定可以包括：

基于补贴计算规则确定基本路补和基本油补，其中：

当计算基本路补时，费率的单位至少可以包括每公里补贴金额，或，每趟运输任务补贴金额，或，每天运输任务补贴金额；

若费率单位是每公里补贴金额，则基本路补=费率*任务实际行驶里程；

若费率单位是每趟运输任务补贴金额，则基本路补=费率*任务实际行驶次数；

若费率单位是每天运输任务补贴金额，则基本路补=费率*任务实际行驶时间；

当计算基本油补时，费率的单位包括每公里补贴油量，或，每趟运输任务补贴油量，或，每天运输任务补贴油量；

若费率单位是每公里补贴油量，则基本油补=费率*任务实际行驶里程；

若费率单位是每趟运输任务补贴油量，则基本油补=费率*任务实际行驶次数；

若费率单位是每天运输任务补贴油量，则基本油补=费率*任务实际行驶时间；

其中，运输任务实际行驶里程单位为公里，运输任务实际行驶次数单位为趟，运输任务实际行驶时间单位为天。

一般的，运输任务实际行驶次数可以等于1，即，若费率单位是每趟运输任务补贴油量，则基本油补=费率*1。

在本申请实施例中，若费率单位与任务实际行驶时间相关；

对于基本油补，

可以，针对任务单，利用对应计算公式，得到基本油补；

也可以，针对运输司机，将一个单位任务实际行驶时间中可以包括若干趟运输过程，针对若干趟运输过程，可以将若干趟运输过程获得的总基本油补，归入若干趟运输过程中任一趟运输过程，其余趟运输过程中的基本油补为0，此时，将若干趟运输过程中任一趟运输过程中的总基本油补，作为一个单位任务实际行驶时间对应的费率；

对于基本路补，

可以，针对任务单，利用对应计算公式，得到基本路补；

也可以，针对运输司机，将一个单位任务实际行驶时间中可以包括若干趟运输过程，针对若干趟运输过程，可以将若干趟运输过程获得的基本路补，归入若干趟运输过程中任一趟运输过程，其余趟运输过程中的基本路补为0，此时，将若干趟运输过程中任一趟运输过程中的总基本路补，作为一个单位任务实际行驶时间对应的费率。

具体的，针对每一任务单，根据任务实际里程或任务实际次数或任务实际用时，利用最终计算规则中的对应费率，经由上述基本路补和基本油补的公式计算，获得第一计算结果。

步骤S105：根据多个任务单的第一计算结果，生成多个任务单补贴明细。

获取多个任务单各自对应的任务单数据和司机在每一任务单运输过程中产生的相关数据是针对整个线程池来说的，获取最终补贴计算规则和获得第一计算结果是针对于每一线程中的每一任务单来说的，本申请实施例最终目的是生成以任务单为单位的补贴明细，故，在各线程完成任务单处理后，对多个任务单计算结果统一调用，使多个任务单计算结果落入数据库，得到以任务单为单位的补贴明细。

进一步的，为减少实际情况与理论情况之间的偏差，还可以根据多个任务单的第一计算结果中的基本油补和基本路补，结合司机在每一任务单运输过程中产生的相关数据的任务实际用油数据和OA申请补油数据，计算得到每一任务单的油补和路补，其中，每一任务单的油补和路补均包括基本补贴和由于实际情况产生的补贴方面的偏差；通过入库操作，对每一任务单的油补和路补进行分批调用、落库，生成多个任务单补贴明细。

相较于相关技术中以罗列形式堆放的补贴明细来说，本申请实施例可以直接生成以任务单为单位的补贴明细，避免了相关技术在生成补贴明细后，人工筛选各任务单补贴明细过程中出现的人工性分筛错误，在提高整个补贴过程工作效率的前提下，还降低了后期补贴明细处理的工作量。

可知，本申请实施例获取多个任务单各自对应的任务单数据和司机在每一任务单运输过程中产生的相关数据，将匹配规则落在任务单维度上，为获取以任务单为单位的补贴明细奠定数据基础；在每一个线程中，根据任务单数据中的特定类型数据、司机信息、车辆信息，匹配得到若干条补贴计算规则，能够极大提高匹配的效率；为保证计算结果的唯一性，最终计算只需要一条最终补贴计算规则，因而，根据若干补贴计算规则的优先级，从匹配得到的若干条补贴计算规则中选择一条最合适的补贴计算规则，作为最终补贴计算规则；根据获取到的最终补贴计算规则，基于最终补贴计算规则对司机在每一任务单运输过程中产生的相关数据，计算得到每一任务单的第一计算结果；最终根据多个任务单的第一计算结果，生成所有任务单的补贴明细，直接获取以任务单为单位的补贴明细，得到的补贴明细信息清晰易见，为后续工作节省时间。

由此可见，本申请技术方案在解决由现有匹配条件过多导致的计算效率低的基础上，直接得到了以任务单为单位的补贴明细，为后续工作节省大量整理时间，不仅提升计算效率，也进一步加快了整个补贴工作的工作进程。

进一步的，针对不同任务单，获得补贴明细的计算方式又有多种，故可以确定一个合适的补贴计算规则来获得补贴明细。对于获得补贴计算规则来说，现如今大家多使用根据信息进行匹配直接获得补贴计算规则，此方式会导致匹配时间过长。故，本申请实施例将原有匹配方式改进为根据信息逐层匹配获得补贴计算规则，以减少匹配时间。

由此，在本申请实施例的一种可能的实现方式，步骤S102之前还可以包括：

针对每一任务单，根据司机信息和车辆信息，获取每一任务单中对应的若干大范围补贴计算规则。

由于生成的补贴明细是以任务单为单位的，因此在匹配补贴计算规则时，也要以任务单为单位匹配补贴计算规则；司机信息和车辆信息是运输过程中不随运输任务改变而改变的两种信息，而特定类型信息则会根据运输任务的不同而产生相应变化，故，选用司机信息和车辆信息对补贴计算规则进行首轮筛选。获取每一任务单中对应的若干大范围补贴计算规则，实质上就是对数据库中多条补贴计算规则通过匹配，筛选出适用于当前任务单的计算规则。

司机信息包括司机工号、司机属性、司机所属车队和司机所属承运商。

车辆信息包括车牌号、车型、轴数和车辆档位，其中，车辆档位可以包括自动挡或手动挡。

具体的，根据司机信息和车辆信息，进行匹配，将匹配成功的大范围补贴计算规则存入Context中，获得大范围补贴计算规则。

本申请实施例先获得大范围补贴计算规则，而不直接获取可用的补贴计算规则，增加了一次匹配过程，但在实际运行中，由于规则信息量级过大，根据信息进行匹配直接获得补贴计算规则可以从多条补贴计算规则中逐条匹配，耗时长且效率低，而，逐级匹配先通过筛选方式将可供当前任务单使用的补贴计算规则放入Context中，然后再从Context匹配出具体的补贴计算规则，相较于一次匹配反而会节省大量时间，从而提升算法工作效率。

相应的，针对每一任务单，通过每一任务单对应的唯一线程，根据特定类型数据、司机信息、车辆信息，获取若干补贴计算规则，包括：针对每一任务单，通过每一任务单对应的唯一线程，根据特定类型数据、司机信息、车辆信息和若干大范围补贴计算规则，获取若干补贴计算规则。

具体的，在每一个线程中，根据任务单数据中的特定类型数据，通过interface接口，从Context中的大范围补贴计算规则，匹配任务单中存在的特定类型数据对应的补贴计算规则，从而获得若干条补贴计算规则。

interface接口是运用策略模式构建的匹配规则总接口。interface接口包括匹配计算规则管理器和具体匹配模块两个部分。匹配计算规则管理器继承了路补对应特定类型匹配接口和油补对应特定类型匹配接口，待匹配的特定类型数据进入接口后，根据继承的路补和油补对应特定类型匹配接口，获得对应特定类型匹配的补贴计算规则，其中，特定类型数据进入路补或油补对应特定类型匹配接口后，对车牌号、挂车号、车型、线路、站点和不能匹配特定类型，通过match函数进行依次匹配，匹配到对应补贴计算规则后，根据gettype函数获取任务单中特定类型数据对应的若干补贴计算规则，不能匹配特定类型包括不能匹配到已写入特定类型数据的数据类型。

由此可见，本申请实施例通过策略模式，为本申请中新提出的补贴计算规则匹配方式提供了新的配置入口，即interface接口，通过interface接口可以获得各任务单若干特定类型数据对应的若干补贴计算规则，提高了匹配效率，整个补贴明细生成过程的工作效率。

进一步的，若特定类型数据中有新增特定类型数据，则直接在interface接口的路补和油补对应特定类型数据匹配规则接口，增加新增特定类型数据匹配接口，在实现类中增加新增特定类型数据匹配接口对应实现内容，以达到应对随运输任务变化数据的特定类型发生变化的情况，使算法具有可拓展性。

除此之外，由于相关技术由于多使用if语句进行补贴计算规则匹配，补贴计算规则匹配过程是要在成千上万的补贴计算规则中选取最合适的一条计算规则，意味着要对成千上万的补贴计算规则逐一匹配，这无异于增加了大量的匹配时间，导致在6000多个司机和20000多条规则的前提下，每次计算需要4个小时，而本申请实施例通过对补贴计算规则匹配过程的改进，缩短匹配时间，由原来需要多次四个小时的计算过程，变为仅用20分钟且，计算效率明显提升。

可知，本申请实施例能够先从数据库中的规则信息中筛取大范围补贴计算规则，再从大范围补贴计算规则中筛取适用于当前任务单的若干补贴计算规则，避免在直接从数据库中成千上万的规则信息中直接获取最终补贴计算规则，这一匹配过程中耗费过长时间，本方案能够提升获取最终补贴计算规则的效率。

进一步的，为了能够精准确定补贴明细，在本申请实施例的一种可能的实现方式，步骤S104包括：基于最终补贴计算规则对任务实际里程或任务实际次数或任务实际用时进行计算，得到第一计算结果。

一般的，在补贴计算过程中，将过往补贴数据作为参考数据，能够得出司机在每一任务单运输过程中产生的相关数据的理论数值即基础油补和基础路补，但实际情况和理论情况会存在一定偏差；故，本申请实施例的补贴计算过程可以结合实际情况进行计算，获取司机在每一任务单运输过程中，会产生一些运输前任务单上没有的数据即司机在每一任务单运输过程中产生的相关数据，其至少包括司机人数、任务实际里程或任务实际次数或任务实际用时、任务实际用油数据和OA申请补油数据，其中，在运输任务结束后补贴计算过程进行前任务单数据可以包括运输前任务单上没有的数据即司机在每一任务单运输过程中产生的相关数据；具体的，将多个任务单各自对应的任务单数据和司机在每一任务单运输过程中产生的相关数据，通过线上化处理，以便将上述数据放入数据库，以待后续使用时，能够随时从数据库中获取上述数据，进而直接将数据库中所有任务单和司机运输过程中产生的所有相关数据放入线程池，避免各线程在运行时无法获取到想要获取的数据。

具体的，根据最终补贴计算规则中的费率，计算各任务单对应的基本油补和基本路补，此时仅得到补贴计算结果，但并不输出补贴计算结果，待所有线程执行结束后，再统一输出多个任务单补贴计算结果，作为以任务单为单位的补贴明细单。

其中，基于最终补贴计算规则对任务实际里程进行计算，得到第一计算结果，以获取基本路补和基本油补。

相应的，步骤S105，具体可以包括包括步骤S1051（图中未示出）、S1052（图中未示出）与S1053（图中未示出），其中：

步骤S1051：根据线路的数据、每一任务单的第一计算结果、任务实际用油数据和OA申请补油数据，得到每一任务单的第二计算结果,其中，线路的数据包括线路名称和线路名称对应的线路补贴金额。

第二计算结果包括最终的路补和油补。其中，最终的路补=第一计算结果中的基本路补+线路补贴；其中，线路补贴表征线路对应补贴金额，金额越大，路线越困难。最终的油补=（第一计算结果中的基本油补-任务实际用油+OA申请补油）*当月油价。

具体的，针对每一任务单的路补，根据线路数据和任务单数据中的任务单名称与线路数据中的线路名称相匹配，得到每一任务单对应的线路补贴金额；根据基本路补和线路补贴金额，通过路补计算公式计算，得到每一任务单对应路补，可以理解的是，线路可能是困难线路，也可能是常规线路，当线路为常规线路是，对应的线路补贴金额可能为0，当线路为困难线路时，在一种可能的情况中，对应的补贴金额为固定金额，在另一种可能的情况中，补贴金额与困难线路的困难等级对应，具体的困难等级用户可根据实际情况预先设定。

进一步的，路补和油补可以通过模板模式来同时计算的。模板模式通过将算法模板化，来优化匹配过程，模板模式设置了计算管理器、路补计算器、油补计算器、抽象类计算器和其他计算场景计算器。计算管理器用来管理各计算场景的计算，但不对计算具体方法进行限定；路补计算器用来管理路补计算过程，不对计算具体方式进行限定；油补计算器用来管理油补计算过程，不对计算具体方式进行限定；抽象类计算器用来管理不同计算场景的计算过程，对计算步骤的顺序进行限定，不同计算场景具体计算为根据任务单号开始计算补贴，计算补贴过程依次是匹配补贴计算规则、计算补贴和分摊计算补贴结果，其中，各线程内按匹配、计算和分摊顺序依次传递的数据为事实数据、事实数据和各计算场景对应实现类方法、事实数据和各计算场景对应实现类方法；其他计算场景计算器，用于增添除路补和油补以外的计算场景。且，模板模式中各要素保持其独立性和扩展性，一方面可以配合现阶段的计算场景计算补贴，另一方面在将来产生新的计算场景时，也能满足在不影响现有功能的情况下，快速迭代，满足可持续扩展的要求。也就是说，相关技术在计算场景增加后，算法不能拓展，导致需要人工进行线下计算，而，本申请实施例则运用模板模式为新增计算场景提供位置，可以直接加入新增计算场景，后续过程仍在算法内进行，减少人工工作量的同时，通过算法计算获得的补贴明细正确率也高于人工计算获得的补贴明细正确率。

通过将运用模板模式，优化算法整体结构，使算法结构清晰，从而使算法运行更加稳定，结合匹配过程中用到的策略模式，将匹配补贴计算规则从在数据库的全部规则信息中通过逐条匹配得到补贴计算规则，改进为先得到大范围补贴计算规则，再从大范围补贴计算规则中匹配得到每一任务单中若干特定类型对应的若干补贴计算规则，最终选取若干补贴计算规则中优先级最高的补贴计算规则作为最终补贴计算规则。通过将匹配过程结构化来节省匹配时间，提升计算效率。

步骤S1052：根据每一任务单的第二计算结果和对应的司机人数，得到每一任务单的最终计算结果。

在每一线程中得到的第二计算结果，虽然已得到每一任务单各自的补贴明细，但在长途运输中，司机往往不仅一名，而获取补贴明细的最终目的是要针对每一司机进行补贴，故，可以获取每一任务单中每一司机的对应补贴。

具体的，针对各任务单，根据任务单数据中的司机人数和第二计算结果，将第二计算结果平均分至每一司机名下，完成补贴分摊，相较于相关技术中的人为分摊准确率更高，速度更快，整体效率也更高。

步骤S1053：根据多个任务单的最终计算结果，得到多个任务单补贴明细。

在每一线程中得到的第二计算结果，虽然已经得到并且分摊至每一司机名下，但这些结果仅存放于数据库中，若后期可以使用每一任务单中各司机的补贴明细，还需将各每一任务单中各司机的补贴明细从数据库中提取出来，不够直观。可以根据数据库中存放的每一任务单的第二计算结果，同时对多线程操作，对每一线程中唯一任务单计算结果进行分批调用，并落入数据库，生成多个以任务单为单位的补贴明细单。以任务单为单位的补贴明细单包括各任务单补贴明细；各任务单补贴明细包括每个司机的补贴明细；每个司机的补贴明细包括路补和油补贴明细。

本申请实施例，能够在得到第一计算结果确定基础的路补以及油补之后，结合任务实际用油数据、OA申请补油数据和司机人数最终确定每一任务单的最终计算结果，进而得到的任务单补贴明细更符合实际情况，提高最终生成的任务单补贴明细的准确度。且目前整个周期，需要开发、产品、业务三天的时间才能计算完成，而，使用本申请实施例中的方法，仅需20分钟就可以得到补贴明细。

进一步的，为提升算法计算效率，在算法中引入了线程池，使用多线程同时处理任务单，由此，本申请实施例的一种可能的实现方式，步骤S102之前，具体可以包括步骤S1011（图中未示出）、步骤S1012（图中未示出）与步骤S1013（图中未示出），其中：

步骤S1011：根据将要对线程池的使用频率，设置线程池维护线程所允许的空闲时间。

对补贴明细生成方法对应的算法的使用可能是一次或多次，且线程池每次重新启动也需要一定时间，因此基于对算法中线程池的使用频率，来设置线程池维护线程所允许的空闲时间。

具体的，若仅使用一次算法，设置线程池维护线程所允许的空闲时间为第一时间，第一时间较短，防止线程池从处理完所有任务到关闭所有线程间隔时间过长，无效损耗CPU。若需要连续多次使用算法，设置线程池维护线程所允许的空闲时间为第二时间，第二时间大于第一时间，第二时间较长，线程池维护线程所允许的空闲时间长短足够下一次算法使用开始即可，避免在多次使用算法过程中重新启动线程池浪费时间。

步骤S1012：设置allowCoreThreadTimeout。

当allowCoreThreadTimeout=false时，若线程空闲时间超过线程池维护线程所允许的空闲时间，则空闲线程退出一部分后，会存在剩余部分线程，一直维持最小线程数，仍处于待命状态；若设置成allowCoreThreadTimeout=true，则保证核心线程会超时关闭，达到将线程池中线程一键停止的目的。

具体的，由于在运行过程中会存在若干任务单等待空闲的线程、线程执行完成任务后不会完全退出这两种情况，且在若干任务单等待空闲的线程过程中，开启的线程数量是等于线程池维护线程最大数量的，一般的，在线程执行完任务并且缓冲队列中不存在等待处理的任务单时，线程等待时间超过线程池维护线程所允许的空闲时间后，此线程会退出，直至线程池中的线程数等于线程池维护线程最小数量，若在线程池中的线程数全部空闲后，仍没有待处理任务单进入线程，那线程池中的线程会以线程池维护线程最小数量继续等待任务，此时，线程池耗能较大，因此，可以设置allowCoreThreadTimeout=true，以实现核心线程会超时关闭，达到将线程池中线程一键停止的目的。由此可见，根据线程池的实际应用场景将线程池配置一一设置，可以使线程池更加适用于当下使用场景，线程池的整体工作效率也会随之提升。

步骤S1013：根据所有任务单的参考计算时间、待计算数据的量级、CPU性能和可接受的计算时间，设置线程池维护线程最大数量，其中，待计算数据包括多个任务单各自对应的任务单数据和司机在每一任务单运输过程中产生的相关数据，每一任务单的参考计算时间表征过去运行数量级相同的任务单所耗时间。

线程池中待设置元素包括线程池维护线程最大数量、线程池维护线程最小数量、线程池维护线程所允许的空闲时间、线程池维护线程所允许的空闲时间的时间单位、线程池所使用的缓冲队列和线程池对拒绝任务的处理策略。

具体的，为保证在多线程开启后随时可以接受任务的同时，又不过多损耗CPU，一般将线程池维护线程最小数量设为2至3；根据每一任务单的参考计算时间，计算全部待处理任务单需要消耗时间；根据全部待处理任务单需要消耗时间和计算可接受时间，计算线程池维护线程最大数量。通过设置线程池的维护线程最小数量和维护线程最大数量，来确定线程池基本框架，完成线程池设置，为后续多线程处理任务单提供线程。

进行步骤S1011、步骤S1012、步骤S1013配置组合的意义是：

当线程数小于线程池最小线程数，即使有线程空闲，线程池也会有限创建新线程处理；

当线程数>=线程池最小线程数，且任务队列已满时，线程池会创建新线程来处理任务；

当线程数=最大线程数，且任务队列已满时，线程池会拒绝处理任务而抛出异常；

当线程空闲时间达到线程池维护线程所允许的空闲时间时，线程会退出，直到线程数量等于线程池最小线程数；

如果allowCoreThreadTimeout=true，则会直到线程数量=0。

进而，补贴明细生成方法还可以包括：利用线程池，将若干空闲的线程分配给多个任务单中的若干任务单，其中，每一任务单对应唯一线程；若存在未分配线程的任务单，则将未分配线程的任务单放入缓存队列等待空闲的线程。

在本申请实施例中，可以根据线程池维护线程所允许的空闲时间、线程池维护线程的最大线程数量和缓冲队列，利用线程池，将若干任务单放入空闲的线程，其中，每一线程对应唯一任务单。具体的，当等待处理的任务单数量小于线程池维护线程的最大线程数量时，将通过submit放入线程池的任务单，放入空闲线程，每一任务单由唯一的一个线程进行处理。若存在未分配线程的任务单，则将未分配线程的任务单放入缓冲队列等待空闲线程。

在处理任务单过程中，一般的，线程数量都是以线程池维护最大数量运行，故，可以直接根据线程池维护最大数量设置缓冲队列。缓冲队列用于存放除线程中正在执行任务之外的待执行任务，使用缓冲队列保证在多线程执行任务时，其余未执行任务是处于等待状态的，有效预防了全部任务进入线程池处理造成的阻塞情况发生，设置线程池不能仅考虑执行的任务，还要考虑待执行任务，防止运行过程中任务不连续而造成的运行混乱发生。

本申请实施例通过已设置好的缓冲队列，放置等待处理的若干任务单，有效预防了全部任务单进入线程池处理而造成阻塞情况的发生。

可知，本申请实施例能够利用设置的线程池进行任务单的计算分配，利用已设置好的缓冲队列，放置等待处理的若干任务单，有效预防了全部任务单进入线程池处理而造成阻塞情况的发生。

进而，补贴明细生成方法还可以包括：判断线程池中的空闲线程的空闲时间是否大于线程池维护线程所允许的空闲时间；若线程池中的空闲线程的空闲时间大于线程池维护线程所允许的空闲时间，则关闭空闲时间大于线程池维护线程所允许的空闲时间的空闲线程，其中，线程池维护线程所允许的空闲时间是基于线程池的预设使用频率设置的。

具体的，当线程空闲时间大于线程池维护线程所允许的空闲时间时，此线程会退出，直至线程池中开启的线程数与线程池维护线程的最小线程数量相等，但，由于allowCoreThreadTimeout=true，故，本申请实施例的线程池中开启的线程数不必维持在线程池维护线程的最小线程数量，新增的空闲线程会一直退出，直至线程池中开启的线程数等于0。由此可见，设置allowCoreThreadTimeout=true，为线程池节省了大量能耗。

可知，本申请实施例在线程池中的空闲线程的空闲时间大于线程池维护线程所允许的空闲时间后，可以关闭空闲时间大于线程池维护线程所允许的空闲时间的空闲线程，减少线程耗能。

本申请实施例的一种可能的实现方式，步骤S102，具体可以包括步骤S1021（图中未示出）与步骤S1022（图中未示出），其中：

步骤S1021：利用Synchronized和Threadlocal，将多个任务单各自对应的任务单数据和司机在每一任务单运输过程中产生的相关数据，传递至各个线程。

步骤S1022：针对每一任务单，通过每一任务单对应的唯一线程，根据传递至各个线程的特定类型数据、司机信息、车辆信息，获取每一任务单对应的若干补贴计算规则。

在本申请实施例中，线程间数据传递分为向线程传递参数和从线程中获取返回值两种方式，由于本申请实施例中，数据存放在数据库中，在需要数据时可以通过查询数据库直接对数据进行调用，故本申请实施例不选取从线程中获取返回值。

具体的，针对线程池，利用Synchronized，先将多个任务单各自对应的任务单数据和司机在每一任务单运输过程中产生的相关数据放入线程池的变量中，保证同一时刻只有一个线程对变量中的数据进行操作，保证了多线程对变量的安全访问；针对每一线程，利用Threadlocal，使线程池的变量中的数据在每个线程中都有独立拷贝，避免跨层传递而造成的数据混乱，提升算法运行的稳定性。可以理解的是，通过上述机制能够保证放入线程池的数据在每个线程中都有独立拷贝后，利用各数的据独立拷贝匹配获得补贴计算规则。

可知，本申请实施例能够利用Synchronized和Threadlocal机制，保证同一时刻只有一个线程对变量中的数据进行操作；与此同时，使线程池的变量中的所述数据在每个线程中都有独立拷贝，避免跨层传递而造成的数据混乱。

由于数据种类是可能增加的，故可以对数据种类增加的情况有相应的应对措施。因此，针对特定类型数据增加的情况，方法还包括：

获取新增特定类型数据请求信息，其中，新增特定类型数据请求信息包括新增特定类型数据和新增特定类型数据对应的规则，新增特定类型数据对应的规则包括补贴计算规则和补贴计算规则对应的优先级；

具体的，新增特定类型数据请求信息即为特定类型数据增加时算法接收的信息，其包括的新增特定类型数据和新增特定类型数据对应的规则为后续现interface接口，并重写接口中的实现类方法提供数据支撑。

根据新增特定类型数据请求信息，更新与特定类型数据对应的补贴计算规则集；其中，补贴计算规则集用于基于某一特定类型数据确定相应的补贴计算规则。

具体的，当接收到新增特定类型数据请求信息后，会根据新增特定类型数据请求信息中的新增特定类型数据和新增特定类型数据对应的规则，实现interface接口，并重写接口中的实现类方法，接口中的实现类方法至少包括不同计算场景下的实现类方法。

进而，在利用更新后的补贴计算规则集匹配规则设计时，运用策略模式，为新增特定类型数据提供应对措施，即为新增特定类型数据预留拓展位置，使算法有拓展性，灵活性较强。

上述实施例从方法流程的角度介绍一种补贴明细生成方法，下述实施例从虚拟模块或者虚拟单元的角度介绍了一种补贴明细生成装置，具体详见下述实施例。

本申请实施例提供一种补贴明细生成装置，如图2所示，该补贴明细生成装置具体可以包括：

数据获取模块201，用于获取多个任务单各自对应的任务单数据和司机在每一任务单运输过程中产生的相关数据；任务单数据至少包括：特定类型数据、司机信息、车辆信息，特定类型数据包括车牌号、挂车号、车型、线路、站点中的若干个；

计算规则匹配模块202，用于针对每一任务单，通过每一任务单对应的唯一线程，根据特定类型数据、司机信息、车辆信息，获取若干补贴计算规则，其中，每一补贴计算规则至少包括费率，用以计算油补与路补；

计算规则确定模块203，用于针对每一任务单，根据若干补贴计算规则的优先级，将优先级最高的补贴计算规则作为最终补贴计算规则；

第一计算结果获取模块204，用于针对每一任务单，基于最终补贴计算规则对司机在每一任务单运输过程中产生的相关数据进行计算，得到第一计算结果；

任务单补贴明细生成模块205，用于根据多个任务单各自对应的第一计算结果，生成多个任务单各自对应的补贴明细。

对于本申请实施例，由数据获取模块201获取多个任务单各自对应的任务单数据和司机在每一任务单运输过程中产生的相关数据，将匹配规则落在任务单维度上，为获取以任务单为单位的补贴明细奠定数据基础；在每一个线程中，通过计算规则匹配模块202，根据任务单数据中的特定类型数据、司机信息、车辆信息，匹配得到若干条补贴计算规则；为保证计算结果的唯一性，最终计算只需要一条最终补贴计算规则，故，要在计算规则确定模块203中根据若干补贴计算规则的优先级，从匹配得到的若干条补贴计算规则中选择一条最合适的补贴计算规则，作为最终补贴计算规则；待获取到最终补贴计算规则后，利用第一计算结果获取模块204，根据获取到的最终补贴计算规则，基于最终补贴计算规则对司机在每一任务单运输过程中产生的相关数据，计算得到每一任务单的第一计算结果，这里的第一计算结果是每个任务单最终计算结果中的一部分，由于第一计算结果计算公式一定，故，先行计算第一计算结果；最终使用任务单补贴明细生成模块205根据多个任务单的第一计算结果，生成所有任务单的补贴明细，直接获取以任务单为单位的补贴明细，得到的补贴明细信息清晰易见，为后续工作节省时间。

由此可见，本申请技术方案在解决现有匹配条件过多导致的计算效率低的基础上，还直接得到了以任务单为单位的补贴明细，为后续工作节省大量整理时间，不仅提升计算效率，也进一步加快了整个补贴工作的工作进程。本申请实施例的一种可能的实现方式，还包括：大范围补贴计算规则匹配模块，用于：

针对每一任务单，根据司机信息和车辆信息，获取每一任务单中对应的若干大范围补贴计算规则，其中，大范围补贴计算规则表征每一任务单数据包含的特定类型数据和除特定类型数据之外的特定类型数据，

相应的，计算规则匹配模块202在执行针对每一任务单，通过每一任务单对应的唯一线程，根据特定类型数据、司机信息、车辆信息，获取若干补贴计算规则时，用于：

针对每一任务单，通过每一任务单对应的唯一线程，根据特定类型数据、司机信息、车辆信息和若干大范围补贴计算规则，获取若干补贴计算规则。

其中，大范围补贴计算规则匹配模块与计算规则匹配模块202可以为同一模块，也可以为不同模块。本申请实施例的一种可能的实现方式，司机在每一任务单运输过程中产生的相关数据包括：任务实际里程或任务实际次数或任务实际用时，任务实际用油数据，OA申请补油数据，司机人数，

第一计算结果获取模块204在执行基于最终补贴计算规则对司机在每一任务单运输过程中产生的相关数据进行计算，得到第一计算结果时，具体用于：

基于最终补贴计算规则对任务实际里程或任务实际次数或任务实际用时进行计算，得到第一计算结果。

相应的，本申请实施例的一种可能的实现方式，任务单补贴明细模块205在执行根据多个任务单的第一计算结果，生成多个任务单补贴明细时，用于：

根据线路的数据、每一任务单的第一计算结果、任务实际用油数据和OA申请补油数据，得到每一任务单的第二计算结果,其中，线路的数据包括线路名称和线路名称对应的线路补贴金额；

根据每一任务单的第二计算结果和对应的司机人数，得到每一任务单的最终计算结果；

根据多个任务单的最终计算结果，得到多个任务单补贴明细。

本申请实施例的一种可能的实现方式，装置，还包括：

线程分配模块，用于利用线程池，将若干空闲的线程分配给多个任务单中的若干任务单，其中，每一任务单对应唯一线程；

若存在未分配线程的任务单，则将未分配线程的任务单放入缓存队列等待空闲的线程。

本申请实施例的一种可能的实现方式，装置，还包括：

线程处理模块，用于判断线程池中的空闲线程的空闲时间是否大于线程池维护线程所允许的空闲时间；若是，则关闭空闲时间大于线程池维护线程所允许的空闲时间的空闲线程。

本申请实施例的一种可能的实现方式，装置，还包括：

线程池维护模块，用于根据所有任务单的参考计算时间、待计算数据的量级、CPU性能和可接受的计算时间，设置线程池维护线程最大数量，其中，待计算数据包括多个任务单各自对应的任务单数据和司机在每一任务单运输过程中产生的相关数据，每一任务单的参考计算时间表征过去运行数量级相同的任务单所耗时间。

本申请实施例的一种可能的实现方式，计算规则匹配模块202在执行针对每一任务单，通过每一任务单对应的唯一线程，根据特定类型数据、司机信息、车辆信息，获取若干补贴计算规则时，具体用于：

利用Synchronized和Threadlocal，将多个任务单各自对应的任务单数据和司机在每一任务单运输过程中产生的相关数据，传递至各个线程；

针对每一任务单，通过每一任务单对应的唯一线程，根据传递至各个线程的特定类型数据、司机信息、车辆信息，获取每一任务单对应的若干补贴计算规则。

本申请实施例的一种可能的实现方式，装置还包括：

新增模块，用于获取新增特定类型数据请求信息，其中，新增特定类型数据请求信息包括新增特定类型数据和新增特定类型数据对应的规则，新增特定类型数据对应的规则包括补贴计算规则和补贴计算规则对应的优先级；

根据新增特定类型数据请求信息，更新与特定类型数据对应的补贴计算规则集；其中，补贴计算规则集用于基于某一特定类型数据确定相应的补贴计算规则。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的一种装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本申请实施例中提供了一种电子设备，如图3所示，图3所示的电子设备30包括：处理器301和存储器303。其中，处理器301和存储器303相连，如通过总线302相连。可选地，电子设备30还可以包括收发器304。需要说明的是，实际应用中收发器304不限于一个，该电子设备30的结构并不构成对本申请实施例的限定。

处理器301可以是CPU（Central Processing Unit，中央处理器），通用处理器，DSP（Digital Signal Processor，数据信号处理器），ASIC（Application SpecificIntegrated Circuit，专用集成电路），FPGA（Field Programmable Gate Array，现场可编程门阵列）或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器301也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

总线302可包括一通路，在上述组件之间传送信息。总线302可以是PCI（Peripheral Component Interconnect，外设部件互连标准）总线或EISA（ExtendedIndustry Standard Architecture，扩展工业标准结构）总线等。总线302可以分为地址总线、数据总线、控制总线等。为便于表示，图3中仅用一条粗线表示，但并不表示仅有一根总线或一型的总线。

存储器303可以是ROM（Read Only Memory，只读存储器）或可存储静态信息和指令的其他类型的静态存储设备，RAM（Random Access Memory，随机存取存储器）或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM（Electrically ErasableProgrammable Read Only Memory，电可擦可编程只读存储器）、CD-ROM（Compact DiscRead Only Memory，只读光盘）或其他光盘存储、光碟存储（包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等）、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

存储器303用于存储执行本申请方案的应用程序代码，并由处理器301来控制执行。处理器301用于执行存储器303中存储的应用程序代码，以实现前述方法实施例所示的内容。

其中，电子设备包括但不限于：移动电话、笔记本电脑、数字广播接收器、PDA（个人数字助理）、PAD（平板电脑）、PMP（便携式多媒体播放器）、车载终端（例如车载导航终端）等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。还可以为服务器等。图3示出的电子设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，当其在计算机上运行时，使得计算机可以执行前述方法实施例中相应内容。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

以上所述仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。