基于自适应乐观锁的文件锁定方法、系统及存储介质

技术领域

本申请涉及计算机技术领域，特别是涉及基于自适应乐观锁的文件锁定方法、系统、电子设备及计算机可读存储介质。

背景技术

当多个进程对同一文件进行访问时，为了避免并发操作引起的数据混乱，通常会对需要操作的文件进行加锁。但如果不同进程访问的是该文件的不同区间数据，那么对整个文件加锁的开销就相对较高，这种情况下需要使用字节范围锁来减少冲突。范围锁锁定的是文件当中的某个区域，对同一文件可以允许多个范围锁，从而提高多进程同时访问的并发度。但是在单个进程多次访问同一文件的不同区域的情况下，字节范围锁的效率就不如文件锁。

目前采用乐观锁机制来解决范围锁在单个进程多次访问同一文件不同区域时效率较低的问题。乐观锁机制的主要思想如图1所示：在收到对文件某个区域的访问请求时，根据已经分配的锁范围，给予该请求进程包括请求区域在内的最大范围锁。也就是说请求进程得到的不是请求锁的准确范围，而是在不与当前已有的其他范围锁发生冲突的前提下，覆盖请求锁范围，同时扩展了与请求范围连续的最大范围。

现有技术对单个进程多次访问某一文件的不同范围时非常有效，但如果有多个进程需要交错访问文件的不同范围时，这种乐观锁机制又很容易造成冲突，从而需要大量的释放锁操作，这样会导致锁请求的效率大大降低，并且会造成网络负载增多以及操作延迟。

发明内容

本申请实施例提供了一种基于自适应乐观锁的文件锁定方法、系统、电子设备及计算机可读存储介质，以至少解决乐观锁机制面临多个进程交错访问文件的不同范围时锁请求效率降低的问题。

第一方面，本申请实施例提供了一种基于自适应乐观锁的文件锁定方法，包括：

访问请求获取步骤，用于接收一客户端的文件访问请求并通过一等待队列缓存所述访问请求对应的锁请求；

锁冲突判断步骤，用于当已分配锁发生资源释放时，获取所述等待队列中队首锁请求，判断所述队首锁请求是否与所述队首锁请求对应的文件中已有锁请求的范围存在冲突；

请求处理步骤，用于当所述队首锁请求与所述文件中已存在的锁请求无冲突时，赋予所述队首锁请求对应的资源；反之，根据所述队首锁请求与所述已有锁请求的冲突范围是否属于扩展范围获取释放资源。

基于上述步骤，本申请实施例对所有的锁请求均通过所述等待队列进行缓存，并取所述等待队列队首锁请求判断其是否与已有锁请求冲突，解决了在多个进程交错访问文件的情况下大量释放锁操作导致的锁请求处理效率低下的问题，降低操作延迟，提高请求处理效率。

在其中一些实施例中，所述请求处理步骤进一步包括：

请求资源赋予步骤，用于当所述队首锁请求与所述文件中已有锁请求无冲突时，赋予所述队首锁请求对应的资源；

扩展范围判断步骤，用于判断所述队首锁请求与所述已有锁请求的冲突范围是否属于扩展范围；

资源释放步骤，用于若所述冲突范围属于拓展范围，则当所述已有锁请求所属客户端释放所述扩展范围资源时，即为对所述扩展范围的资源进行解锁时，根据所述队首锁请求对所述扩展范围进行加锁，并将所述队首锁请求移出所述等待队列；否则，所述队首锁请求等待所述已有锁请求释放资源并执行所述锁冲突判断步骤。

在其中一些实施例中，所述请求资源赋予步骤进一步包括：

唯一锁请求处理步骤，用于判断所述队首锁请求是否为所述等待队列中唯一的锁请求，若所述队首锁请求为所述等待队列中唯一的锁请求，则根据乐观锁机制对所述队首锁请求对应的资源的扩展范围加锁并将所述队首锁请求移出所述等待队列；

客户端锁请求获取步骤，用于若所述队首锁请求不是所述等待队列中唯一的锁请求，则依序遍历所述等待队列中锁请求并获取所述客户端的锁请求；

锁请求处理步骤，用于若所述等待队列中所述客户端的锁请求为所述队首锁请求，即为所述等待队列中不存在其他来自所述客户端的锁请求，则根据乐观锁机制对所述队首锁请求对应的资源进行加锁并将所述队首锁请求移出所述等待队列，值得注意的是，此时并非对所述队首锁请求对应的资源的扩展范围进行加锁；

扩展锁请求处理步骤，用于若所述等待队列中所述客户端的锁请求为包括所述队首锁请求的至少二锁请求，即为所述等待队列中还有其他来自所述客户端的锁请求，则根据所述至少二锁请求在所述等待队列的位置进行锁请求处理。

在其中一些实施例中，扩展锁请求处理步骤进一步包括：

锁请求位置获取步骤，用于判断所述至少二锁请求是否位于所述等待队列的预设位置，若所述至少二锁请求位于所述等待队列的预设位置，则根据乐观锁机制对所述队首锁请求对应的资源的扩展范围加锁并将所述队首锁请求移出所述等待队列；否则，根据所述队首锁请求对应的资源进行加锁并将所述队首锁请求移出所述等待队列，值得注意的是，此时并未对所述队首锁请求对应的资源的扩展范围进行加锁。

基于上述步骤，提供了一种决定队首锁请求的加锁方式的判断规则及多种针对所述队首锁请求进行加锁的方式，一方面，尽可能保留了乐观锁针对锁请求的扩展范围进行加锁，以保留其在单线程访问时的优势；另一方面，通过直接针对所请求进行加锁的非乐观锁形式，以避免与其他锁请求产生冲突，进一步提高在多个进程交错访问文件的情况下的请求处理效率。

在其中一些实施例中，所述预设位置为所述等待队列的前四分之一段的位置范围。

在其中一些实施例中，本申请实施例的进行范围索引采用B+树作为数据结构实现，利用B+树的叶节点包含全部关键字信息且顺序链接的特性，进一步优化范围查找，B+树是一种树数据结构，通常用于数据库和操作系统的文件系统中，B+树的特点是能够保持数据稳定有序，其插入与修改拥有较稳定的对数时间复杂度。

第二方面，本申请实施例提供了一种基于自适应乐观锁的文件锁定系统，包括：

访问请求获取模块，用于接收一客户端的文件访问请求并通过一等待队列缓存所述访问请求对应的锁请求；

锁冲突判断模块，用于当已分配锁发生资源释放时，获取所述等待队列中队首锁请求，判断所述队首锁请求是否与所述队首锁请求对应的文件中已有锁请求的范围存在冲突；

请求处理模块，用于当所述队首锁请求与所述文件中已存在的锁请求无冲突时，赋予所述队首锁请求对应的资源；反之，判断所述队首锁请求与所述已有锁请求的冲突范围是否属于扩展范围并获取释放资源。

基于上述模块，本申请实施例对所有的锁请求均通过所述等待队列进行缓存，并取所述等待队列队首锁请求判断其是否与已有锁请求冲突，解决了在多个进程交错访问文件的情况下大量释放锁操作导致的锁请求处理效率低下的问题，降低操作延迟，提高请求处理效率。

在其中一些实施例中，所述请求处理模块进一步包括：

请求资源赋予模块，用于当所述队首锁请求与所述文件中已有锁请求无冲突时，赋予所述队首锁请求对应的资源；

扩展范围判断模块，用于判断所述队首锁请求与所述已有锁请求的冲突范围是否属于扩展范围；

资源释放模块，用于若所述冲突范围属于拓展范围，则当所述已有锁请求所属客户端释放所述扩展范围资源时，即为对所述扩展范围的资源进行解锁时，根据所述队首锁请求对相应资源加锁，并将所述队首锁请求移出所述等待队列；否则，所述队首锁请求等待所述已有锁请求释放资源并进入所述锁冲突判断模块。

在其中一些实施例中，所述请求资源赋予模块进一步包括：

唯一锁请求处理模块，用于判断所述队首锁请求是否为所述等待队列中唯一的锁请求，若所述队首锁请求为所述等待队列中唯一的锁请求，则根据乐观锁机制对所述队首锁请求对应的资源的扩展范围加锁并将所述队首锁请求移出所述等待队列；

客户端锁请求获取模块，用于若所述队首锁请求不是所述等待队列中唯一的锁请求，则依序遍历所述等待队列中锁请求并获取所述客户端的锁请求；

锁请求处理模块，用于若所述等待队列中所述客户端的锁请求为所述队首锁请求，即为所述等待队列中不存在其他来自所述客户端的锁请求，则根据乐观锁机制对所述队首锁请求对应的资源进行加锁并将所述队首锁请求移出所述等待队列，值得注意的是，此时并非对所述队首锁请求对应的资源的扩展范围进行加锁；

扩展锁请求处理模块，用于若所述等待队列中所述客户端的锁请求为包括所述队首锁请求的至少二锁请求，即为所述等待队列中还有其他来自所述客户端的锁请求，则根据所述至少二锁请求在所述等待队列的位置进行锁请求处理。

基于上述模块，本申请实施例通过判断等待队列中即将处理到的请求是否与当前的所述队首锁请求属于同一进程，即为来自同一所述客户端的锁请求，从而确定对所述队首锁请求的加锁方式。

在其中一些实施例中，扩展锁请求处理模块进一步包括：

锁请求位置获取模块，用于判断所述至少二锁请求是否位于所述等待队列的预设位置，若所述至少二锁请求位于所述等待队列的预设位置，则根据乐观锁机制对所述队首锁请求对应的资源的扩展范围加锁并将所述队首锁请求移出所述等待队列；否则，根据所述队首锁请求对应的资源进行加锁并将所述队首锁请求移出所述等待队列，值得注意的是，此时并非对所述队首锁请求对应的资源的扩展范围进行加锁。

基于上述模块，本申请实施例提供了一种决定队首锁请求的加锁方式的基于判断的预测规则及多种针对所述队首锁请求进行加锁的方式，一方面，尽可能保留了乐观锁针对锁请求的扩展范围进行加锁，以保留其在单线程访问时的优势；另一方面，通过直接针对所请求进行加锁的非乐观锁形式，以避免与其他锁请求产生冲突，进一步提高在多个进程交错访问文件的情况下的请求处理效率。

在其中一些实施例中，所述预设位置为所述等待队列的前四分之一段的位置范围。

在其中一些实施例中，本申请实施例的进行范围索引采用B+树作为数据结构实现，利用B+树的叶节点包含全部关键字信息且顺序链接的特性，进一步优化范围查找，B+树是一种树数据结构，通常用于数据库和操作系统的文件系统中，B+树的特点是能够保持数据稳定有序，其插入与修改拥有较稳定的对数时间复杂度。

第三方面，本申请实施例提供了一种电子设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述第一方面所述的基于自适应乐观锁的文件锁定方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述第一方面所述的基于自适应乐观锁的文件锁定方法。

相比于相关技术，本申请实施例提供的基于自适应乐观锁的文件锁定方法及系统，既解决现有技术方案在多个进程交错访问文件的情况下效率较低的问题，同时又让其保留在单个线程访问时的优势。

本申请的一个或多个实施例的细节在以下附图和描述中提出，以使本申请的其他特征、目的和优点更加简明易懂。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据相关技术的乐观锁机制的示意图；

图2是根据本申请实施例的基于自适应乐观锁的文件锁定方法的流程示意图；

图3是根据本申请实施例的基于自适应乐观锁的文件锁定方法的分步骤流程示意图；

图4是根据本申请优选实施例的基于自适应乐观锁的文件锁定方法的流程示意图；

图5是根据本申请实施例的基于自适应乐观锁的文件锁定系统的结构框图；

图6是根据本申请实施例的基于自适应乐观锁的文件锁定系统的子结构框图。

附图说明：

1、访问请求获取模块；2、锁冲突判断模块；3、请求处理模块；

31、请求资源赋予模块；32、扩展范围判断模块；33、资源释放模块；

311、唯一锁请求处理模块；312、客户端锁请求获取模块；

313、锁请求处理模块；314、扩展锁请求处理模块；

3141、锁请求位置获取模块。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行描述和说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。基于本申请提供的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。此外，还可以理解的是，虽然这种开发过程中所作出的努力可能是复杂并且冗长的，然而对于与本申请公开的内容相关的本领域的普通技术人员而言，在本申请揭露的技术内容的基础上进行的一些设计，制造或者生产等变更只是常规的技术手段，不应当理解为本申请公开的内容不充分。

在本申请中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域普通技术人员显式地和隐式地理解的是，本申请所描述的实施例在不冲突的情况下，可以与其它实施例相结合。

除非另作定义，本申请所涉及的技术术语或者科学术语应当为本申请所属技术领域内具有一般技能的人士所理解的通常意义。本申请所涉及的“一”、“一个”、“一种”、“该”等类似词语并不表示数量限制，可表示单数或复数。本申请所涉及的术语“包括”、“包含”、“具有”以及它们任何变形，意图在于覆盖不排他的包含；例如包含了一系列步骤或模块(单元)的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可以还包括没有列出的步骤或单元，或可以还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。本申请所涉及的“连接”、“相连”、“耦接”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电气的连接，不管是直接的还是间接的。本申请所涉及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。本申请所涉及的术语“第一”、“第二”、“第三”等仅仅是区别类似的对象，不代表针对对象的特定排序。

为了解决乐观锁机制应用于文件访问中多个进程交错访问文件的不同范围时容易造成冲突的问题，本申请实施例提供了一种基于自适应乐观锁的文件锁定方法，图2是根据本申请实施例的基于自适应乐观锁的文件锁定方法的流程示意图，图3是根据本申请实施例的基于自适应乐观锁的文件锁定方法的分步骤流程示意图，如图2-3所示，该流程包括如下步骤：

访问请求获取步骤S1，用于接收一客户端的文件访问请求并通过一等待队列缓存访问请求对应的锁请求；

锁冲突判断步骤S2，用于当已分配锁发生资源释放时，获取等待队列中队首锁请求，判断队首锁请求是否与队首锁请求对应的文件中已有锁请求的范围存在冲突；

请求处理步骤S3，用于当队首锁请求与文件中已存在的锁请求无冲突时，赋予队首锁请求对应的资源；反之，根据队首锁请求与已有锁请求的冲突范围是否属于扩展范围获取释放资源。

基于上述步骤，本申请实施例对所有的锁请求均通过等待队列进行缓存，并取等待队列队首锁请求判断其是否与已有锁请求冲突，解决了在多个进程交错访问文件的情况下大量释放锁操作导致的锁请求处理效率低下的问题，降低操作延迟，提高请求处理效率。

在其中一些实施例中，请求处理步骤S3进一步包括：

请求资源赋予步骤S31，用于当队首锁请求与文件中已有锁请求无冲突时，赋予队首锁请求对应的资源；

扩展范围判断步骤S32，用于判断队首锁请求与已有锁请求的冲突范围是否属于扩展范围；

资源释放步骤S33，用于若冲突范围属于拓展范围，则当已有锁请求所属客户端释放扩展范围资源时，即为对扩展范围的资源进行解锁时，根据队首锁请求对扩展范围进行加锁，并将队首锁请求移出等待队列；否则，队首锁请求等待已有锁请求释放资源并执行锁冲突判断步骤。

在其中一些实施例中，请求资源赋予步骤S31进一步包括：

唯一锁请求处理步骤S311，用于判断队首锁请求是否为等待队列中唯一的锁请求，若队首锁请求为等待队列中唯一的锁请求，则根据乐观锁机制对队首锁请求对应的资源的扩展范围加锁并将队首锁请求移出等待队列；

客户端锁请求获取步骤S312，用于若队首锁请求不是等待队列中唯一的锁请求，则依序遍历等待队列中锁请求并获取客户端的锁请求；

锁请求处理步骤S313，用于若等待队列中客户端的锁请求为队首锁请求，即为等待队列中不存在其他来自客户端的锁请求，则根据乐观锁机制对队首锁请求对应的资源进行加锁并将队首锁请求移出等待队列，值得注意的是，此时并非对队首锁请求对应的资源的扩展范围进行加锁；

扩展锁请求处理步骤S314，用于若等待队列中客户端的锁请求为包括队首锁请求的至少二锁请求，即为等待队列中还有其他来自客户端的锁请求，则根据至少二锁请求在等待队列的位置进行锁请求处理。

在其中一些实施例中，扩展锁请求处理步骤S314进一步包括：

锁请求位置获取步骤S3141，用于判断至少二锁请求是否位于等待队列的预设位置，若至少二锁请求位于等待队列的预设位置，则根据乐观锁机制对队首锁请求对应的资源的扩展范围加锁并将队首锁请求移出等待队列；否则，根据队首锁请求对应的资源进行加锁并将队首锁请求移出等待队列，值得注意的是，此时并未对队首锁请求对应的资源的扩展范围进行加锁，可选的，预设位置为等待队列的前四分之一段的位置范围。

在其中一些实施例中，本申请实施例的进行范围索引采用B+树作为数据结构实现。

基于上述步骤，提供了一种决定队首锁请求的加锁方式的判断规则及多种针对队首锁请求进行加锁的方式，一方面，尽可能保留了乐观锁针对锁请求的扩展范围进行加锁，以保留其在单线程访问时的优势；另一方面，通过直接针对所请求进行加锁的非乐观锁形式，以避免与其他锁请求产生冲突，进一步提高在多个进程交错访问文件的情况下的请求处理效率。

下面通过优选实施例对本申请实施例进行描述和说明。

图4是根据本申请优选实施例的基于自适应乐观锁的文件锁定方法的流程图，如图4所示，该基于自适应乐观锁的文件锁定方法包括如下步骤：

步骤S401，客户端发出访问请求，将锁请求放入等待队列。

步骤S402，当已分配锁发生资源释放，取等待队列首部的请求，即为队首锁请求，将队首锁请求与已有锁请求范围进行冲突判断。如果队首锁请求与已有锁请求发生冲突，转到步骤S403，否则转到步骤S404。

步骤S403，判断队首锁请求与已有锁请求的冲突范围是否属于扩展范围，如果是扩展范围冲突，则需要让该已有锁请求所属客户端释放扩展范围的锁，然后为当前队首锁请求分配锁，并将该队首锁请求移出等待队列，成功处理一次锁请求，流程结束；如果不是扩展范围冲突，则让当前队首锁请求等待已有锁的资源释放，转入步骤S402。

步骤S404，如果队首锁请求与已有锁请求不发生冲突，需要为客户端请求赋予锁资源。具体的，先判断等待队列中是否只包含当前队首锁请求这一个请求，如果是，则转到步骤S405，否则转到步骤S406。

步骤S405，若等待队列中不存在其他请求，则按照乐观锁机制进行扩展范围的加锁，并移除等待队列头部的请求，成功处理一次锁请求，流程结束。

步骤S406，若等待队列中还有其他请求，从前往后查找等待队列中和当前队首锁请求同为一个客户端的其他请求，如果找到满足该条件的请求，转到步骤S407，否则转到步骤S408。

步骤S407，判断满足条件的请求是否位于等待队列的前四分之一段的位置，如果是，按照乐观锁机制进行扩展范围的加锁；如果不是，按队首锁请求的范围正常加锁，不进行范围的扩展。移除等待队列头部的请求，成功处理一次锁请求，流程结束。

步骤S408，队列中不存在满足条件的其他请求，按锁请求的范围正常加锁，不进行范围的扩展，移除等待队列头部的请求。成功处理一次锁请求，流程结束。

需要说明的是，在上述流程中或者附图的流程图中示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本实施例还提供了一种基于自适应乐观锁的文件锁定系统，该系统用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”、“单元”、“子单元”等可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的系统较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图5是根据本申请实施例的基于自适应乐观锁的文件锁定系统的结构框图，图6是根据本申请实施例的基于自适应乐观锁的文件锁定系统的子结构框图，如图5-6所示，该系统包括：

访问请求获取模块1，用于接收一客户端的文件访问请求并通过一等待队列缓存访问请求对应的锁请求；

锁冲突判断模块2，用于当已分配锁发生资源释放时，获取等待队列中队首锁请求，判断队首锁请求是否与队首锁请求对应的文件中已有锁请求的范围存在冲突；

请求处理模块3，用于当队首锁请求与文件中已存在的锁请求无冲突时，赋予队首锁请求对应的资源；反之，判断队首锁请求与已有锁请求的冲突范围是否属于扩展范围并获取释放资源。

基于上述模块，本申请实施例对所有的锁请求均通过等待队列进行缓存，并取等待队列队首锁请求判断其是否与已有锁请求冲突，解决了在多个进程交错访问文件的情况下大量释放锁操作导致的锁请求处理效率低下的问题，降低操作延迟，提高请求处理效率。

其中，请求处理模块3进一步包括：请求资源赋予模块31，用于当队首锁请求与文件中已有锁请求无冲突时，赋予队首锁请求对应的资源；扩展范围判断模块32，用于判断队首锁请求与已有锁请求的冲突范围是否属于扩展范围；资源释放模块33，用于若冲突范围属于拓展范围，则当已有锁请求所属客户端释放扩展范围资源时，即为对扩展范围的资源进行解锁时，根据队首锁请求对相应资源加锁，并将队首锁请求移出等待队列；否则，队首锁请求等待已有锁请求释放资源并进入锁冲突判断模块2。

请求资源赋予模块31进一步包括：唯一锁请求处理模块311，用于判断队首锁请求是否为等待队列中唯一的锁请求，若队首锁请求为等待队列中唯一的锁请求，则根据乐观锁机制对队首锁请求对应的资源的扩展范围加锁并将队首锁请求移出等待队列；客户端锁请求获取模块312，用于若队首锁请求不是等待队列中唯一的锁请求，则依序遍历等待队列中锁请求并获取客户端的锁请求；锁请求处理模块313，用于若等待队列中客户端的锁请求为队首锁请求，即为等待队列中不存在其他来自客户端的锁请求，则根据乐观锁机制对队首锁请求对应的资源进行加锁并将队首锁请求移出等待队列，值得注意的是，此时并非对队首锁请求对应的资源的扩展范围进行加锁；扩展锁请求处理模块314，用于若等待队列中客户端的锁请求为包括队首锁请求的至少二锁请求，即为等待队列中还有其他来自客户端的锁请求，则根据至少二锁请求在等待队列的位置进行锁请求处理。具体的，扩展锁请求处理模块314进一步包括：锁请求位置获取模块3141，用于判断至少二锁请求是否位于等待队列的预设位置，若至少二锁请求位于等待队列的预设位置，则根据乐观锁机制对队首锁请求对应的资源的扩展范围加锁并将队首锁请求移出等待队列；否则，根据队首锁请求对应的资源进行加锁并将队首锁请求移出等待队列，值得注意的是，此时并非对队首锁请求对应的资源的扩展范围进行加锁。可选的，预设位置为等待队列的前四分之一段的位置范围。具体的，本申请实施例进行范围索引采用B+树作为数据结构实现。

基于上述模块，通过判断等待队列中即将处理到的请求是否与当前的队首锁请求属于同一进程，即为来自同一客户端的锁请求，从而确定对队首锁请求的加锁方式。本系统还提供了一种决定队首锁请求的加锁方式的基于判断的预测规则及多种针对队首锁请求进行加锁的方式，一方面，尽可能保留了乐观锁针对锁请求的扩展范围进行加锁，以保留其在单线程访问时的优势；另一方面，通过直接针对所请求进行加锁的非乐观锁形式，以避免与其他锁请求产生冲突，进一步提高在多个进程交错访问文件的情况下的请求处理效率。

基于上述系统，本申请实施例对所有的锁请求，都需要先进入到一个等待队列中，取队首锁请求判断是否与已有锁请求冲突。如果队首锁请求与已有锁请求不发生冲突，则需要赋予客户端相应的范围锁，采用自适应的乐观锁机制，如记队首锁请求为Q1，当前请求的客户端为A，从前往后查找等待队列中同样为客户端A的请求，记找到的第一个请求为Q2，判断请求Q2在等待队列中的位置是否处于前四分之一段，如果是，说明相同的客户端可能在短时间内会再次发出锁请求，按乐观锁机制给队首锁请求Q1进行扩展范围的加锁，如果等待队列中不存在其他请求，也按照乐观锁方式进行扩展范围加锁；如果没找到同为客户端A的请求或者找到请求的不是位于队列前四分之一段的位置，则说明近期的请求均为其他进程，为了避免冲突，按锁请求的范围正常加锁，不进行范围的扩展。

如果队首锁请求与已有锁请求发生冲突，判断冲突范围是否属于扩展范围。如果是扩展范围冲突，则需要让该已有锁所属客户端释放扩展范围的锁，然后为当前队首锁请求分配锁，并将该队首锁请求移出等待队列。如果不是扩展范围冲突则等待已有锁的资源释放。

需要说明的是，上述各个模块可以是功能模块也可以是程序模块，既可以通过软件来实现，也可以通过硬件来实现。对于通过硬件来实现的模块而言，上述各个模块可以位于同一处理器中；或者上述各个模块还可以按照任意组合的形式分别位于不同的处理器中。

另外，结合图2-3描述的本申请实施例基于自适应乐观锁的文件锁定方法可以由电子设备来实现。电子设备可以包括处理器以及存储有计算机程序指令的存储器。具体地，上述处理器可以包括中央处理器(CPU)，或者特定集成电路(Application SpecificIntegrated Circuit，简称为ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

其中，存储器可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器可包括硬盘驱动器(Hard Disk Drive，简称为HDD)、软盘驱动器、固态驱动器(SolidState Drive，简称为SSD)、闪存、光盘、磁光盘、磁带或通用串行总线(Universal SerialBus，简称为USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器可在数据处理装置的内部或外部。在特定实施例中，存储器是非易失性(Non-Volatile)存储器。在特定实施例中，存储器包括只读存储器(Read-Only Memory，简称为ROM)和随机存取存储器(Random AccessMemory，简称为RAM)。在合适的情况下，该ROM可以是掩模编程的ROM、可编程ROM(Programmable Read-Only Memory，简称为PROM)、可擦除PROM(Erasable ProgrammableRead-Only Memory，简称为EPROM)、电可擦除PROM(Electrically Erasable ProgrammableRead-Only Memory，简称为EEPROM)、电可改写ROM(Electrically Alterable Read-OnlyMemory，简称为EAROM)或闪存(FLASH)或者两个或更多个以上这些的组合。在合适的情况下，该RAM可以是静态随机存取存储器(Static Random-Access Memory，简称为SRAM)或动态随机存取存储器(Dynamic Random Access Memory，简称为DRAM)，其中，DRAM可以是快速页模式动态随机存取存储器(Fast Page Mode Dynamic Random Access Memory，简称为FPMDRAM)、扩展数据输出动态随机存取存储器(Extended Date Out Dynamic RandomAccess Memory，简称为EDODRAM)、同步动态随机存取内存(Synchronous Dynamic Random-Access Memory，简称SDRAM)等。

存储器可以用来存储或者缓存需要处理和/或通信使用的各种数据文件，以及处理器所执行的可能的计算机程序指令。

处理器通过读取并执行存储器中存储的计算机程序指令，以实现上述实施例中的任意一种基于自适应乐观锁的文件锁定方法。

另外，结合上述实施例中的基于自适应乐观锁的文件锁定方法，本申请实施例可提供一种计算机可读存储介质来实现。该计算机可读存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现上述实施例中的任意一种基于自适应乐观锁的文件锁定方法。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。