CN117499330A - 丢包处理方法、装置、设备及可读存储介质 - Google Patents

Abstract

本申请公开了一种丢包处理方法、装置、设备及可读存储介质，涉及通信领域，包括：检测丢包处理线程是否满足预设阻塞条件，其中，所述丢包处理线程用于对待丢包处理的数据进行丢包处理，所述丢包处理包括丢包检测与发送丢包重传请求；若所述丢包处理线程满足预设阻塞条件，则阻塞所述丢包处理线程，并设置所述丢包处理线程的唤醒条件；检测到所述丢包处理线程满足所述唤醒条件时，重新唤醒所述丢包处理线程，基于唤醒后的所述丢包处理线程继续对待丢包处理的数据进行丢包处理。本申请降低了丢包处理线程的系统资源占用。

Description

丢包处理方法、装置、设备及可读存储介质

技术领域

本申请涉及通信技术领域，尤其涉及一种丢包处理方法、装置、设备及可读存储介质。

背景技术

终端向服务器发送网络数据，通常将数据按照指定大小切片后，加上发送序号传输，数据在传输过程中，受网络介质和链路影响，可能丢失。服务器需要检测终端发送的数据在传输过程中的丢失情况，反之，如果服务器向终端发送数据包，受网络介质和链路影响，数据包也可能会丢失。这样，无论是终端还是服务器，对接收到的数据进行丢包处理，丢包处理包括检测接收到的数据是否丢包，并在检测到丢包时向发送端发送丢包重传请求，以通知发送端重传丢失的数据。

目前，数据的接收端与发送端建立通信连接后，在接收端中通常会启动一个数据包接收主进程接收发送端传输过来的数据，此数据包接收主进程也可以对接收到的数据进行丢包处理，由于数据包接收主进程主要是完成数据的接收与存储，基于数据包接收主进程的丢包处理的方式丢包处理速率慢、效率低，因此，通常接收端会启动专门的丢包处理线程，用于对数据进行丢包处理。如WebRTC的服务端就是启动了专门的丢包处理线程，用于对数据进行丢包处理。

但是这种启动专门的丢包处理线程，用于对数据进行丢包处理的方式，丢包处理线程会一直循环运行对接收到的数据丢包处理，由此，丢包处理线程需要时刻去检查是否需要发送重传请求，丢包处理线程需要频繁计算丢包相关参数，导致丢包处理线程的系统资源占用，如CPU资源占用，非常高，影响系统运行。

发明内容

本申请的主要目的在于提供一种丢包处理方法、装置、设备及可读存储介质，旨在解决如何降低丢包处理线程的系统资源占用的技术问题。

为实现上述目的，本申请提供一种丢包处理方法，所述丢包处理方法包括以下步骤：

检测丢包处理线程是否满足预设阻塞条件；

若所述丢包处理线程满足预设阻塞条件，则阻塞所述丢包处理线程，并设置所述丢包处理线程的唤醒条件；

检测到所述丢包处理线程满足所述唤醒条件时，重新唤醒所述丢包处理线程，基于唤醒后的所述丢包处理线程继续对待丢包处理的数据进行丢包处理。

可选地，所述检测丢包处理线程是否满足预设阻塞条件的步骤，包括：

获取预设接收端的当前工作状态信息，所述当前工作状态信息包括当前CPU占用率，其中，所述预设接收端包括接收待丢包处理的数据的服务端；

若所述当前CPU占用率大于或等于预设占用率阈值，则确定所述丢包处理线程满足预设阻塞条件。

可选地，所述检测丢包处理线程是否满足预设阻塞条件的步骤，还包括

获取待丢包处理的数据，并基于丢包处理线程对所述待丢包处理的数据进行丢包检测；

若所述丢包处理线程未检测到所述待丢包处理的数据丢包，则将所述丢包处理线程未检测到丢包的累计次数加一；

若所述累计次数大于或等于预设次数阈值，则确定所述丢包处理线程满足预设阻塞条件。

可选地，所述基于丢包处理线程对所述待丢包处理的数据进行丢包检测的步骤之后，所述方法还包括：

若所述丢包处理线程检测到所述待丢包处理的数据丢包，基于丢包处理线程发送丢包重传请求，并将所述丢包处理线程未检测到丢包的累计次数清零，以重新累加所述丢包处理线程未检测到丢包的累计次数。

可选地，所述基于丢包处理线程对所述待丢包处理的数据进行丢包检测的步骤之后，所述方法还包括：

控制所述丢包处理线程进入休眠状态，累加所述丢包处理线程的休眠时间，直至所述丢包处理线程的休眠时间大于预设休眠时间时，唤醒所述丢包处理线程，并返回执行检测丢包处理线程是否满足预设阻塞条件的步骤。

可选地，所述设置所述丢包处理线程的唤醒条件的步骤，包括：

确定所述丢包处理线程的阻塞原因，基于所述阻塞原因设置所述丢包处理线程的唤醒条件，其中，所述阻塞原因包括CPU占用率大于或等于预设占用率阈值，与未检测到丢包的累计次数大于或等于预设次数阈值。

可选地，所述基于所述阻塞原因设置所述丢包处理线程的唤醒条件的步骤，包括：

若所述阻塞原因包括CPU占用率大于或等于预设占用率阈值，则将CPU占用率小于预设占用率阈值设置为所述丢包处理线程的唤醒条件；

若所述阻塞原因包括未检测到丢包的累计次数大于或等于预设次数阈值，则将数据包接收主进程检测到丢包设置为所述丢包处理线程的唤醒条件。

此外，为实现上述目的，本申请还提供一种丢包处理装置，所述丢包处理装置包括：

检测模块，用于检测丢包处理线程是否满足预设阻塞条件；

阻塞模块，用于若所述丢包处理线程满足预设阻塞条件，则阻塞所述丢包处理线程，并设置所述丢包处理线程的唤醒条件；

唤醒模块，用于检测到所述丢包处理线程满足所述唤醒条件时，重新唤醒所述丢包处理线程，基于唤醒后的所述丢包处理线程继续对待丢包处理的数据进行丢包处理。

此外，为实现上述目的，本申请还提供一种丢包处理设备，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的丢包处理程序，所述丢包处理程序被所述处理器执行时实现如上述的丢包处理方法的步骤。

此外，为实现上述目的，本申请还提供一种可读存储介质，可读存储介质上存储有丢包处理程序，丢包处理程序被处理器执行时实现如上述的丢包处理方法的步骤。

本申请中通过检测丢包处理线程是否满足预设阻塞条件，其中，所述丢包处理线程用于对待丢包处理的数据进行丢包处理，所述丢包处理包括丢包检测与发送丢包重传请求；若所述丢包处理线程满足预设阻塞条件，则阻塞所述丢包处理线程，并设置所述丢包处理线程的唤醒条件，以使检测到所述丢包处理线程满足所述唤醒条件时，重新唤醒所述丢包处理线程，基于唤醒后的所述丢包处理线程继续对待丢包处理的数据进行丢包处理。如此，与现有技术中，丢包处理线程一直循环运行进行对接收到的数据丢包处理的丢包处理线程运行方式相比，本申请实施例通过预设丢包处理线程的阻塞条件，检测到丢包处理线程满足预设阻塞条件后，就阻塞丢包处理线程的运行，并在丢包处理线程满足唤醒条件时，在重新唤醒丢包处理线程，对待丢包处理的数据进行丢包处理，从而通过对丢包处理线程进行适当时长的阻塞，以降低丢包处理线程的系统资源占用。

附图说明

本申请目的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

图1是本申请实施例方案涉及的硬件运行环境的终端\系统结构示意图；

图2为本申请丢包处理方法第一实施例的流程示意图；

图3为丢包处理线程的丢包处理流程示意图；

图4为本申请丢包处理方法中丢包处理线程的丢包处理流程示意图；

图5为本申请丢包处理方法第二实施例的流程示意图；

图6为本申请丢包处理装置的装置结构示意图。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

参照图1，图1为本申请实施例方案涉及的硬件运行环境的丢包处理设备结构示意图。

如图1所示，该丢包处理设备可以包括：处理器1001，例如中央处理器(CentralProcessing Unit，CPU)，通信总线1002、用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如无线保真(WIreless-FIdelity，WI-FI)接口)。存储器1005可以是高速的随机存取存储器(RandomAccess Memory，RAM)存储器，也可以是稳定的非易失性存储器(Non-Volatile Memory，NVM)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储系统。

本领域技术人员可以理解，图1中示出的结构并不构成对丢包处理设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种存储介质的存储器1005中可以包括操作系统、数据存储模块、网络通信模块、用户接口模块以及丢包处理程序。

在图1所示的丢包处理设备中，网络接口1004主要用于与其他设备进行数据通信；用户接口1003主要用于与用户进行数据交互；本申请丢包处理设备中的处理器1001、存储器1005可以设置在丢包处理设备中，所述丢包处理设备通过处理器1001调用存储器1005中存储的丢包处理程序，并执行本申请实施例提供的丢包处理方法。

WebRTC是google公司力推的一个开源项目，旨在给浏览器与手机的web应用提供简单的JavaScript接口，使其具备RTC(Real-Time Communications)实时通信能力。意味着开发者在支持WebRTC浏览器上开发web应用仅需简单的JavaScript语句就可以实现复杂的多媒体R TC功能，极大降低了开发难度和开发成本，W3C等组织正在制定We bR TC标准JavaScript API接口。

WebRTC丢包重传功能：服务器在接收终端传来的数据，如视频流数据时，由于网络的不稳定，可能存在数据包丢失的情况，这种情况下需要向终端设备发送重传数据包的请求。Webrtc中启动了一个丢包处理线程，时刻去检查是否需要发送重传请求。因为每个终端都有专属的丢包处理线程，在终端数特别多的时候，丢包处理线程也会特别多，每个丢包处理线程线程都会频繁计算丢包相关参数，导致系统资源占用非常高，如CPU占用非常高，影响系统运行。

基于上述问题，请参照图2，图2为本申请丢包处理方法第一实施例的流程示意图。需要说明的是，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

在本实施例中，如图2所示，所述丢包处理方法包括以下步骤：

步骤S10，检测丢包处理线程是否满足预设阻塞条件；

其中，所述丢包处理线程用于对待丢包处理的数据进行丢包处理，所述丢包处理包括丢包检测与发送丢包重传请求。

本实施例中，丢包处理方法应用于接收端，该接收端具体可为服务端，为便于阐述与说明，本申请实施例以服务端作为直接执行主体。服务端与终端之间通信连接，服务端可针对每一与之通信连接的终端对应启动一个丢包处理线程，用于对该终端传输中服务端的数据进行丢包处理。如假设服务端与四个终端【终端A、终端B、终端C、终端D】，则服务端分别针对终端A、终端B、终端C与终端D会启动一个丢包处理线程，可记为线程A、线程B、线程C、线程D，线程A用于对终端A传输至服务端的数据进行丢包处理，线程B用于对终端B传输至服务端的数据，线程C用于对终端C传输至服务端的数据，线程D用于对终端传输至服务端的数据。可以理解地是，终端传输至服务端的数据可为任意数据，如视屏数据、音频数据等等。

可以理解地是，待丢包处理的数据为终端传输至服务端的数据，针对不同终端的丢包处理线程，对应待丢包处理的数据不同。如在上述例子中，对于线程A，待丢包处理的数据为终端A传输至服务端的数据，对于线程B，待丢包处理的数据为终端B传输至服务端的数据，对于线程C，待丢包处理的数据为终端C传输至服务端的数据，对于线程D，待丢包处理的数据为终端D传输至服务端的数据。

丢包处理线程用于对待丢包处理数据进行丢包检测，并在检测到丢包后发送丢包重传请求。丢包处理线程可采用现有或未来的丢包检测方式检测丢包检测与发送丢包重传请求，这里不再详述，本实施例对此也并不做具体限制。若未预设阻塞条件，则丢包处理线程的运行逻辑可参照图3所示，丢包处理线程会检测是否有丢包，若检测到丢包，则发送丢包重传请求后计算需要休眠的休眠时长，并进入休眠直至休眠的时间达到该休眠时长后重新检测是否有丢包，若未检测到丢包，计算休眠时长并休眠，达到休眠时长后丢包处理线程会自行唤醒，重新检测是否有丢包，丢包处理线程会一直循环此运行逻辑。需要说明地是，丢包处理线程每次进入休眠时，其自身会根据网络状态、网速等实时网络参数计算一个合适的休眠时长。

该预设阻塞条件可以是提前设置的任意条件，包括但限于丢包处理线程连续预设次数未检测到丢包、服务器端的CPU占用率大于预设占用率阈值，如还可以包括丢包处理线程连续预设次数未检测到丢包且服务器端的CPU占用率大于预设占用率阈值等等。

步骤S20，若所述丢包处理线程满足预设阻塞条件，则阻塞所述丢包处理线程，并设置所述丢包处理线程的唤醒条件；

当丢包处理线程满足预设阻塞条件时，则阻塞丢包处理线程，也即控制丢包处理线程进入阻塞状态，阻塞状态指的是线程不继续执行，而在等待，阻塞解除后，重新进入就绪状态。进一步地，设置唤醒条件，等待满足丢包处理线程的唤醒条件后，重新唤醒丢包处理线程。

需要说明地是，预设不同终端的丢包处理线程对应的阻塞条件，也即针对不同终端的丢包处理线程对应的预设阻塞条件可不同，每一丢包处理线程有其对应的预设阻塞条件，若存在多个丢包处理线程，则确定每一丢包处理线程对应的预设阻塞条件，检测每一丢包处理线程是否满足其对应的预设阻塞条件，若任一丢包处理线程满足其对应的预设阻塞条件，则阻塞该丢包处理线程。如在上述例子中，假设线程A、线程B、线程C、线程D对应的预设阻塞条件分别为条件A、条件B、条件C、条件D，线程A满足条件A时，则阻塞线程A，线程B满足条件B时，则阻塞线程B，线程C满足条件C时，则阻塞线程C，线程D满足条件D时，则阻塞线程D，条件A、条件B、条件C、条件D彼此之间相互独立，可相同也可不同。由此，通过设置每一丢包处理线程的预设阻塞条件，实现了多个丢包处理线程得到差异化阻塞。

步骤S30，检测到所述丢包处理线程满足所述唤醒条件时，重新唤醒所述丢包处理线程，基于唤醒后的所述丢包处理线程继续对待丢包处理的数据进行丢包处理。

丢包处理线程满足唤醒条件时，唤醒丢包处理线程，避免丢包处理线程一直被阻塞，而无法进行丢包处理。作为其中一种实施方式，可由数据接收主进程唤醒此丢包处理线程。

那么与丢包处理线程的阻塞条件类似，每一丢包处理线程可独立的设置其对应的唤醒条件，彼此之间相互独立，互不影响。

进一步地，为了助于理解本申请的技术构思或工作原理，列举一具体实施例：

在本具体实施例中，预设阻塞条件为丢包处理线程连续10次未检测到丢包，基于此，参见图4所示，本具体实施例中丢包处理线程的丢包处理流程为：

1)检测是否有丢包，若是则执行步骤2)，若否则执行步骤3)。

2)若检测到丢包，发送重传请求，计算休眠时长(也即休眠时间)并休眠，休眠此休眠时长后，返回执行步骤1)。

3)若检测到无丢包，则判断是否连续10次未检测到丢包，若是则阻塞线程。

需要说明的是，上述具体实施例仅用于理解本申请，并不构成对本申请丢包处理线程的丢包处理流程的限定，基于此技术构思进行更多形式的简单变换，均在本申请的保护范围内。

本实施例中通过检测丢包处理线程是否满足预设阻塞条件，其中，所述丢包处理线程用于对待丢包处理的数据进行丢包处理，所述丢包处理包括丢包检测与发送丢包重传请求；若所述丢包处理线程满足预设阻塞条件，则阻塞所述丢包处理线程，并设置所述丢包处理线程的唤醒条件；检测到所述丢包处理线程满足所述唤醒条件时，重新唤醒所述丢包处理线程，基于唤醒后的所述丢包处理线程继续对待丢包处理的数据进行丢包处理。如此，与现有技术中，丢包处理线程一直循环运行进行对接收到的数据丢包处理的丢包处理线程运行方式相比，本实施例通过预设丢包处理线程的阻塞条件，检测到丢包处理线程满足预设阻塞条件后，就阻塞丢包处理线程的运行，并在丢包处理线程满足唤醒条件时，再重新唤醒丢包处理线程，对待丢包处理的数据进行丢包处理，从而通过对丢包处理线程进行适当时长的阻塞，以降低丢包处理线程的系统资源占用。

进一步地，基于上述本申请的第一实施例，提出本申请丢包处理方法的第二实施例，与上述第一实施例相同或相似的内容，可以参考上文介绍，后续不再赘述。在本实施例中，上述实施例步骤S20所述检测丢包处理线程是否满足预设阻塞条件的步骤细化，包括：

步骤A10，获取预设接收端的当前工作状态信息，所述当前工作状态信息包括当前CPU占用率，其中，所述预设接收端包括接收待丢包处理的数据的服务端；

步骤A20，若所述当前CPU占用率大于或等于预设占用率阈值，则确定所述丢包处理线程满足预设阻塞条件。

作为其中一种实施方式，预设阻塞条件可设置为CPU占用率大于或等于预设占用率阈值，该预设占用率阈值可提前设置，如80％、70％、60％等等，从而检测到当前CPU占用率大于或等于此预设占用率阈值时，确定丢包处理线程满足预设阻塞条件，当前CPU占用率大于或等于预设占用率阈值，则确定所述丢包处理线程满足预设阻塞条件，可以避免CPU过载的问题。

在一种可能的实施方式中，所述检测丢包处理线程是否满足预设阻塞条件的步骤，还包括

步骤B10，获取进行待丢包处理的数据，并基于丢包处理线程对所述待丢包处理的数据进行丢包检测；

步骤B20，若所述丢包处理线程未检测到所述待丢包处理的数据丢包，则将所述丢包处理线程未检测到丢包的累计次数加一；

步骤B30，若所述累计次数大于或等于预设次数阈值，则确定所述丢包处理线程满足预设阻塞条件。

作为其中一种实施方式，预设阻塞条件可设置丢包处理线程未检测到丢包的累计次数大于或等于预设次数阈值，该预设次数阈值可提前任意设置，如8、9、10等等。从而丢包处理线程未检测到丢包的累计次数大于或等于预设次数阈值，则确定丢包处理线程满足预设阻塞条件，以阻塞丢包处理线程，连续多次未检测到丢包，可说明当前服务端与终端之前的传输网络稳定，已较长时间未出现丢包的现象，传输网络稳定，可预测未来一段时间出现丢包的概率较低，此时阻塞丢包处理线程即可以降低系统资源占用。

作为另外一种实施方式，预设阻塞条件可设置为丢包处理线程未检测到丢包的累计次数大于或等于预设次数阈值且CPU占用率大于或等于预设占用率阈值，此时，若丢包处理线程未检测到丢包的累计次数大于或等于预设次数阈值且预设接收端的当前CPU占用率大于或等于预设占用率阈值，则确定丢包处理线程满足预设阻塞条件，且此时该预设占用率阈值可设置为一个较低的数值，如30％、40％等，以兼顾丢包处理的及时性与系统资源占用。丢包处理线程未检测到丢包的累计次数大于或等于预设次数阈值，但CPU占用率小于预设占用率阈值，此时可认为CPU较为空闲，此时不阻塞丢包处理线程，始终保持丢包处理线程的运行，可以增加对丢包处理的及时性。根据丢包情况和实时CPU占用率对丢包重传的性能进行了优化，有效地降低了资源占用。

在一种可能的实施方式中，所述基于丢包处理线程对所述待丢包处理的数据进行丢包检测的步骤之后，所述方法还包括：

步骤C10，若所述丢包处理线程检测到所述待丢包处理的数据丢包，基于丢包处理线程发送丢包重传请求，并将所述丢包处理线程未检测到丢包的累计次数清零，以重新累加所述丢包处理线程未检测到丢包的累计次数。

丢包处理线程检测到丢包时，会发送丢包重传请求，以请求终端重传丢失的数据包。

可以理解地是，丢包处理线程未检测到丢包的累计次数在丢包处理线程检测到丢包时，该累计次数会清零，并重新开始累加该累计次数，从而保证该累计次数的准确性。

在一种可能的实施方式中，所述基于丢包处理线程对所述待丢包处理的数据进行丢包检测的步骤之后，所述方法还包括：

步骤D10，控制所述丢包处理线程进入休眠状态，累加所述丢包处理线程的休眠时间，直至所述丢包处理线程的休眠时间大于预设休眠时间时，唤醒所述丢包处理线程，并返回执行检测丢包处理线程是否满足预设阻塞条件的步骤。

本实施例中，丢包处理线程检测到的丢包时，发送丢包重传请求后会进入休眠，丢包处理线程未检测到丢包时，也会进入休眠，休眠时间大于预设休眠时间后，丢包处理线程会自行唤醒，该预设休眠时间由丢包处理线程自行计算，丢包处理线程每次休眠时，均会计算本次需休眠的时长，休眠此时长后，自行唤醒，保证丢包处理的及时性。同时无论是否检测到丢包均进入休眠，休眠一段时间后在重新进行下一次检测，从而可以延长丢包处理线程进行一次丢包处理(包括检测是否丢包，检测到丢包时发送重传请求)的周期，避免丢包处理线程长时间处于运行状态，而导致系统资源占用高、CPU升温快等等运行异常的现象。

在一种可能的实施方式中，所述设置所述丢包处理线程的唤醒条件的步骤，包括：

步骤E10，确定所述丢包处理线程的阻塞原因，基于所述阻塞原因设置所述丢包处理线程的唤醒条件，其中，所述阻塞原因包括CPU占用率大于或等于预设占用率阈值与未检测到丢包的累计次数大于或等于预设次数阈值。

可以理解地是，该阻塞原因为实际阻塞丢包处理线程的原因，如因为CPU占用率大于或等于预设占用率阈值，则丢包处理线程的阻塞原因为CPU占用率大于或等于预设占用率阈值，因为未检测到丢包的累计次数大于或等于预设次数阈值，则阻塞原因为未检测到丢包的累计次数大于或等于预设次数阈值。

可以预设不同的阻塞原因与唤醒条件之间的对应关系，基于此对应关系设置丢包处理线程的唤醒条件，若阻塞原因不在此对应关系中，则可以设置丢包处理线程的唤醒条件为默认唤醒条件，默认唤醒条件可为阻塞时长大于预设时长等等。

本实施例中，通过设置丢包处理线程的唤醒条件，从而保证了阻塞后的丢包处理线程可以有效的被唤醒，而不会一直被阻塞。

在一种可能的实施方式中，所述基于所述阻塞原因设置所述丢包处理线程的唤醒条件的步骤，包括：

步骤F10，若所述阻塞原因包括CPU占用率大于或等于预设占用率阈值，则将CPU占用率小于预设占用率阈值设置为所述丢包处理线程的唤醒条件；

步骤F20，若所述阻塞原因包括未检测到丢包的累计次数大于或等于预设次数阈值，则将数据包接收主进程检测到丢包设置为所述丢包处理线程的唤醒条件。

本实施例中，基于阻塞原因设置对应的唤醒条件，从而保证了导致阻塞丢包处理线程的阻塞原因解除后，可以成功的唤醒丢包处理线程，且解除阻塞原因后才解除，可以避免唤醒丢包处理线程后线程又因为触发阻塞原因而又立即被阻塞，保证丢包处理线程的有效唤醒。

进一步地，为了助于理解本申请的技术构思或工作原理，列举一具体实施例：

参照图5所示，在本具体实施例中丢包处理流程为：

在丢包处理线程检测丢包之前对CPU资源占用情况进行判断，如果CPU占用超过第一预设资源占用率阈值，如70％，则直接阻塞丢包处理线程以避免CPU过载，并在0.5S后再次进行检测，如果未超过70％则进行后续丢包检测流程。检测是否有丢包，如果有丢包则发送重传请求，并进行休眠，等待下一次检测，如果没有丢包则计算休眠时间并暂时休眠。如果连续10次未检测到丢包，则对CPU占用进行判断，如果CPU占用超过了第二预设资源占用率阈值，如30％，则需要对CPU占用进行降低，由程序阻塞该线程，直到再次出现丢包。如果CPU占用低于30％，则始终保持丢包处理线程的运行，以增加对丢包处理的及时性。

需要说明的是，上述具体实施例仅用于理解本申请，并不构成对本申请丢包处理流程的限定，基于此技术构思进行更多形式的简单变换，均在本申请的保护范围内。

此外，本申请还提供一种丢包处理装置，参照图6，所述丢包处理装置包括：

检测模块10，用于检测丢包处理线程是否满足预设阻塞条件；

阻塞模块20，用于若所述丢包处理线程满足预设阻塞条件，则阻塞所述丢包处理线程，并设置所述丢包处理线程的唤醒条件；

唤醒模块30，用于检测到所述丢包处理线程满足所述唤醒条件时，重新唤醒所述丢包处理线程，基于唤醒后的所述丢包处理线程继续对待丢包处理的数据进行丢包处理。

此外，本申请实施例还提出一种丢包处理设备，丢包处理设备括存储器、处理器及存储在所述存储器上并可在所述处理器上执行的丢包处理程序，所述丢包处理程序被所述处理器执行时实现如上述的丢包处理方法的步骤。

本申请丢包处理设备具体实施方式与上述丢包处理方法各实施例基本相同，在此不再赘述。

此外，为实现上述目的，本申请还提供一种可读存储介质，可读存储介质上存储有丢包处理程序，丢包处理程序被处理器执行时实现如上述的丢包处理方法的步骤。

本申请可读存储介质具体实施方式与上述丢包处理方法各实施例基本相同，在此不再赘述。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例所述的方法。

以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (10)

1.一种丢包处理方法，其特征在于，所述丢包处理方法包括以下步骤：

检测丢包处理线程是否满足预设阻塞条件；

若所述丢包处理线程满足预设阻塞条件，则阻塞所述丢包处理线程，并设置所述丢包处理线程的唤醒条件；

检测到所述丢包处理线程满足所述唤醒条件时，重新唤醒所述丢包处理线程，基于唤醒后的所述丢包处理线程继续对待丢包处理的数据进行丢包处理。

2.如权利要求1所述的丢包处理方法，其特征在于，所述检测丢包处理线程是否满足预设阻塞条件的步骤，包括：

获取预设接收端的当前工作状态信息，所述当前工作状态信息包括当前CPU占用率，其中，所述预设接收端包括接收待丢包处理的数据的服务端；

若所述当前CPU占用率大于或等于预设占用率阈值，则确定所述丢包处理线程满足预设阻塞条件。

3.如权利要求1所述的丢包处理方法，其特征在于，所述检测丢包处理线程是否满足预设阻塞条件的步骤，还包括

获取待丢包处理的数据，并基于丢包处理线程对所述待丢包处理的数据进行丢包检测；

若所述丢包处理线程未检测到所述待丢包处理的数据丢包，则将所述丢包处理线程未检测到丢包的累计次数加一；

若所述累计次数大于或等于预设次数阈值，则确定所述丢包处理线程满足预设阻塞条件。

4.如权利要求3所述的丢包处理方法，其特征在于，所述基于丢包处理线程对所述待丢包处理的数据进行丢包检测的步骤之后，所述方法还包括：

若所述丢包处理线程检测到所述待丢包处理的数据丢包，基于丢包处理线程发送丢包重传请求，并将所述丢包处理线程未检测到丢包的累计次数清零，以重新累加所述丢包处理线程未检测到丢包的累计次数。

5.如权利要求3所述的丢包处理方法，其特征在于，所述基于丢包处理线程对所述待丢包处理的数据进行丢包检测的步骤之后，所述方法还包括：

控制所述丢包处理线程进入休眠状态，累加所述丢包处理线程的休眠时间，直至所述丢包处理线程的休眠时间大于预设休眠时间时，唤醒所述丢包处理线程，并返回执行检测丢包处理线程是否满足预设阻塞条件的步骤。

6.如权利要求1-5任一项所述的丢包处理方法，其特征在于，所述设置所述丢包处理线程的唤醒条件的步骤，包括：

确定所述丢包处理线程的阻塞原因，基于所述阻塞原因设置所述丢包处理线程的唤醒条件，其中，所述阻塞原因包括CPU占用率大于或等于预设占用率阈值，与未检测到丢包的累计次数大于或等于预设次数阈值。

7.如权利要求6所述的丢包处理方法，其特征在于，所述基于所述阻塞原因设置所述丢包处理线程的唤醒条件的步骤，包括：

若所述阻塞原因包括CPU占用率大于或等于预设占用率阈值，则将CPU占用率小于预设占用率阈值设置为所述丢包处理线程的唤醒条件；

若所述阻塞原因包括未检测到丢包的累计次数大于或等于预设次数阈值，则将数据包接收主进程检测到丢包设置为所述丢包处理线程的唤醒条件。

8.一种丢包处理装置，其特征在于，所述丢包处理装置包括：

检测模块，用于检测丢包处理线程是否满足预设阻塞条件；

阻塞模块，用于若所述丢包处理线程满足预设阻塞条件，则阻塞所述丢包处理线程，并设置所述丢包处理线程的唤醒条件；

唤醒模块，用于检测到所述丢包处理线程满足所述唤醒条件时，重新唤醒所述丢包处理线程，基于唤醒后的所述丢包处理线程继续对待丢包处理的数据进行丢包处理。

9.一种丢包处理设备，其特征在于，所述丢包处理设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的丢包处理程序，所述丢包处理程序被所述处理器执行时实现如权利要求1至7中任一项所述的丢包处理方法的步骤。

10.一种可读存储介质，其特征在于，所述可读存储介质上存储有丢包处理程序，所述丢包处理程序被处理器执行时实现如权利要求1至7中任一项所述的丢包处理方法的步骤。