CN118034602A

CN118034602A - Method, device, electronic equipment and storage medium for storing request data

Info

Publication number: CN118034602A
Application number: CN202410288276.8A
Authority: CN
Inventors: 詹小奇; 祁磊
Original assignee: Beijing Zitiao Network Technology Co Ltd
Current assignee: Beijing Zitiao Network Technology Co Ltd
Priority date: 2024-03-13
Filing date: 2024-03-13
Publication date: 2024-05-14

Abstract

Provided are a method, apparatus, electronic device, and storage medium for storing request data. The method for storing the request data comprises the following steps: in response to a first request by a client process, determining whether a first address space associated with the server process has sufficient remaining space to store data of the first request; the address space associated with the server process is divided into a first address space and a second address space; if the first address space has enough residual space, storing the data of the first request into the first address space; if the first address space does not have sufficient remaining space, then data of the first request is deposited into the second address space in response to determining that the first request does not belong to the target type of request and that the second address space has sufficient remaining space.

Description

Method, device, electronic equipment and storage medium for storing request data

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to a method, an apparatus, an electronic device, and a storage medium for storing request data.

Background

Binder is a cross-process communication mechanism. The process for initiating the request is a client process, the process for responding the request is a server process, when the client process sends the request to the server process, the related data of the request is stored in a block of shared virtual address space of the server process, and the block of virtual address space is released after the server process processes the request.

The shared address space for storing the communication data sent by the client process in the server process is limited, and the address space is shared, so that the server process can store a plurality of request data sent by a plurality of client processes at the same time. Assuming that the total shared address space of the server process is 1MB, and the data size of each Binder communication request is 100KB, the server process can only store 10 Binder communication request data at most in the shared address space. However, there may be multiple client processes in the system that communicate with one server process at the same time, if the speed of the server process responding to the request is slower than the speed of the client process sending the request, the available space in the shared address space of the server process is reduced, which eventually leads to exhaustion of the shared address space. Once there is no available shared address space, any request sent by the client process to the server process will fail, thereby causing system stability anomalies, a light person causing no response when a certain application interface or menu is clicked by the user, and a heavy person causing system crashes, black screens, etc. Typical scenarios that cause the server process to respond slower than the client process sends a request include: an application code logic exception or a system suffers from a malicious program attack, which causes a certain client process to send a large amount of Binder request data to a certain server process in a short time, and this phenomenon is particularly common in an asynchronous communication scenario (asynchronous communication refers to communication in which after data is sent, a sender can continue to send the next data without waiting for a receiver to respond).

Therefore, in order to reduce the occurrence probability of various system stability problems due to the exhaustion of the shared address space, the shared address space needs to be optimized.

Disclosure of Invention

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

In a first aspect, according to one or more embodiments of the present disclosure, there is provided a method of storing request data, comprising:

In response to a first request by a client process, determining whether a first address space associated with a server process has sufficient remaining space to store data of the first request; the address space associated with the server process is divided into a first address space and a second address space;

If the first address space has the enough residual space, storing the first requested data into the first address space;

If the first address space does not have the sufficient remaining space, then data of the first request is deposited to the second address space in response to determining that the first request is not of a target type and that the second address space has the sufficient remaining space.

In a second aspect, according to one or more embodiments of the present disclosure, there is provided an apparatus for storing request data, comprising:

a determining unit, configured to determine, in response to a first request of a client process, whether a first address space associated with a server process has enough remaining space to store data of the first request; the address space associated with the server process is divided into a first address space and a second address space;

A storage unit configured to store data of the first request to the first address space if the first address space has the sufficient remaining space, and store data of the first request to the second address space in response to determining that the first request is not of a target type and the second address space has the sufficient remaining space if the first address space does not have the sufficient remaining space.

In a third aspect, according to one or more embodiments of the present disclosure, there is provided an electronic device comprising: at least one memory and at least one processor; wherein the memory is for storing program code, and the processor is for invoking the program code stored by the memory to cause the electronic device to perform a method provided in accordance with one or more embodiments of the present disclosure.

In a fourth aspect, according to one or more embodiments of the present disclosure, there is provided a non-transitory computer storage medium storing program code which, when executed by a computer device, causes the computer device to perform a method provided according to one or more embodiments of the present disclosure.

According to one or more embodiments of the present disclosure, a process space of a server is divided into a first address space and a second address space, wherein the first address space is preferentially used for storing process request data (regardless of a request type), and when a storage space of the first address space is insufficient, non-specific type request data is stored using the second address space, namely, the second address space serving as a standby is conditionally used, so that it is possible to avoid the specific type request data from occupying the remaining second address space in case the storage space of the first address space is insufficient.

Drawings

The above and other features, advantages, and aspects of embodiments of the present disclosure will become more apparent by reference to the following detailed description when taken in conjunction with the accompanying drawings. The same or similar reference numbers will be used throughout the drawings to refer to the same or like elements. It should be understood that the figures are schematic and that elements and components are not necessarily drawn to scale.

FIG. 1 is a flow chart of a method for storing request data according to one embodiment of the present disclosure;

FIG. 2 is a schematic diagram of a cross-process communication framework provided in an embodiment of the present disclosure;

FIG. 3 is a flow chart of a method of storing request data provided by another embodiment of the present disclosure;

FIG. 4 is a flow chart of a method for determining a first target type request provided by an embodiment of the present disclosure;

FIG. 5 is a flow chart of a method for freeing address space provided by an embodiment of the present disclosure;

FIG. 6 is a schematic diagram of an apparatus for storing request data according to an embodiment of the disclosure;

fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the disclosure.

Detailed Description

Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the present disclosure have been shown in the accompanying drawings, it is to be understood that the present disclosure may be embodied in various forms and should not be construed as limited to the embodiments set forth herein, but are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustration purposes only and are not intended to limit the scope of the present disclosure.

It should be understood that the steps recited in the embodiments of the present disclosure may be performed in a different order, and/or performed in parallel. Furthermore, embodiments may include additional steps and/or omit performing the illustrated steps. The scope of the present disclosure is not limited in this respect.

The term "including" and variations thereof as used herein are intended to be open-ended, i.e., including, but not limited to. The term "based on" is based at least in part on. The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments. The term "responsive to" and related terms mean that one signal or event is affected to some extent by another signal or event, but not necessarily completely or directly. If event x occurs "in response to" event y, x may be directly or indirectly in response to y. For example, the occurrence of y may ultimately lead to the occurrence of x, but other intermediate events and/or conditions may exist. In other cases, y may not necessarily result in the occurrence of x, and x may occur even though y has not yet occurred. Furthermore, the term "responsive to" may also mean "at least partially responsive to".

The term "determining" broadly encompasses a wide variety of actions, which may include obtaining, calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like, and may also include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like, as well as parsing, selecting, choosing, establishing and the like. Related definitions of other terms will be given in the description below. Related definitions of other terms will be given in the description below.

It will be appreciated that the data (including but not limited to the data itself, the acquisition or use of the data) involved in the present technical solution should comply with the regulations of the relevant legal regulations.

It will be appreciated that prior to using the technical solutions disclosed in the embodiments of the present disclosure, the user should be informed and authorized of the type, usage range, usage scenario, etc. of the personal information related to the present disclosure in an appropriate manner according to relevant legal regulations. For example, in response to receiving an active request from a user, prompt information is sent to the user to explicitly prompt the user that the operation requested to be performed will require obtaining and using personal information to the user, so that the user may autonomously select whether to provide personal information to software or hardware such as an electronic device, an application, a server, or a storage medium that performs the operation of the technical solution of the present disclosure according to the prompt information.

As an alternative but non-limiting implementation, in response to receiving an active request from a user, the prompt information may be sent to the user, for example, in a popup window, where the prompt information may be presented in a text manner. In addition, a selection control for the user to select to provide personal information to the electronic device in a 'consent' or 'disagreement' manner can be carried in the popup window.

It will be appreciated that the above-described notification and user authorization process, and image processing, are merely illustrative, and not limiting of the implementations of the present disclosure, as other ways of satisfying relevant legal regulations may be applied to the implementations of the present disclosure.

It should be noted that the terms "first," "second," and the like in this disclosure are merely used to distinguish one device, module, or unit from another, and are not used to define an order or interdependence of functions performed by the devices, modules, or units.

It should be noted that references to "one", "a plurality" and "a plurality" in this disclosure are intended to be illustrative rather than limiting, and those of ordinary skill in the art will appreciate that "one or more" is intended to be understood as "one or more" unless the context clearly indicates otherwise.

For the purposes of this disclosure, the phrase "a and/or B" means (a), (B), or (a and B).

The names of messages or information interacted between the various devices in the embodiments of the present disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

In some asynchronous cross-process communication schemes, if multiple client threads send requests to the same object of a server process at the same time, the server process responds to the client requests serially, and only one thread in the server process responds to various requests of the same object, this easily causes the cross-process communication shared address space to be exhausted, thereby causing a series of stability problems.

Referring to fig. 1, a flowchart of a method 100 for storing request data according to an embodiment of the present disclosure is shown, where the method 100 includes steps S110-S130.

Step S110: in response to a first request by a client process, determining whether a first address space associated with a server process has sufficient remaining space to store data of the first request; the address space associated with the server process comprises the first address space and the second address space.

If the first address space has the enough remaining space, step S120 is performed: and storing the data of the first request into the first address space.

If the first address space does not have the sufficient remaining space, then step 130 is performed: in response to determining that the first request is not of a target type and that the second address space has the sufficient remaining space, data of the first request is deposited to the second address space.

The address space represents the amount of space occupied by a computer entity, which may include a physical address space and a virtual address space. In some embodiments, the address space may comprise a virtual address space. Illustratively, application processes participating in cross-process communication are each assigned a block of fixed-size virtual address space for storing request data sent by client processes.

In some embodiments, the address space allocated for the application process may be divided into a first address space and a second address space in advance. Referring to fig. 2, a server process is allocated a block of memory space (e.g., virtual address space) storing cross-process shared data, the address space being divided into a first address space and a second address space, and the physical address space to which it maps being correspondingly divided into two portions. Assuming that the total size of the address space is 1024KB, the first and second address spaces may be set to 900KB and 124KB, respectively, and the physical address space sizes mapped by the two are also 900KB and 124KB. The size of the space allocated by the address space, the first address space, and the second address space may be other values, and the disclosure is not limited herein. In some embodiments below, when the first address space is exhausted, the request data in the first address space needs to be traversed, the method call with the most occupied space is found and marked, and the method is considered as a main cause of the exhaustion of the address space, and interception and cleaning are performed in subsequent processing.

In some embodiments, the first request is a request for data interaction between different application processes, including, but not limited to, a request for data transfer, data sharing, information transfer, resource sharing, process control, service invocation, and the like.

It should be noted that any application process in the system may be a client process or a server process. For example, when the application process a sends a request to the application process B, the application process a is a client process, and the application process B is a server process; when the application process B sends response data to the application process A, the identity of the application process B is converted into a client process from a server process, and correspondingly, the identity of the application process A receiving the data is converted into the server process from the client process.

In some embodiments, the amount of data of the first request may be compared to the remaining available space in the first address space, and if the former is smaller than the latter, it may be determined that the first address space currently has the sufficient remaining space; conversely, it may be determined that the first address space does not currently have the sufficient remaining space.

In some embodiments, if the first request is of the target type, then data for the first request is not stored in response to determining that the second address space does not have the sufficient remaining space. For example, a notification indicating a storage error (e.g., "address space is insufficient") may be returned directly to the client process and the first request intercepted. In this way, some unreasonable requests in the system can be prevented from being frequently sent to the server, and the probability of the shared address space of the server being exhausted is reduced.

According to one or more embodiments of the present disclosure, a shared address space of a server process is divided into a first address space and a second address space, where the first address space is preferentially used to store process request data (regardless of a request type), and when a storage space of the first address space is insufficient, the second address space is used to store non-specific type request data, i.e. conditionally use the second address space as a spare, so that it is possible to avoid that specific type request data occupies the remaining second address space in case that the storage space of the first address space is insufficient, for example, it is possible to prevent some unreasonable requests in the system from being frequently sent to the server, and reduce a probability of exhaustion of the shared address space of the server.

In some embodiments, the request of the target type includes a request of a first target type or a request of a second target type; or the request of the target type includes an intersection of the request of the first target type and the request of the second target type; wherein the request of the first target type is a request of which occupied resources in the address space meet a preset condition; the method requested by the request of the second target type does not belong to the target method.

The request of the first target type is a request of which the condition of occupied resources in the address space meets a preset condition or situation; the method requested by the request of the second target type does not belong to the target method. The request of the first target type may be a request that has been requested more times in the address space (i.e., a frequent request), or may be a request that the requested method does not belong to the core method.

When a request of a target type comprises a request of a first target type or a request of a second target type, it means that if a request belongs to a request of a first target type it can be considered as a request of a target type or if a request belongs to a request of a second target type it can also be considered as a request of a target type.

When a request of a target type comprises an intersection of a request of a first target type and a request of a second target type, it means that a request can only be considered as a request of a target type if it belongs to both the request of the first target type and the request of the second target type. For example, the request of the target type is a request of which the request number is frequent and the requested method is a non-core method, so that in the case where the first address space is exhausted and the second address has a remaining space, the second address space is used to store request data of other requests than the request of the target type (i.e., the request of which the request number is frequent and corresponds to the non-core method).

In some embodiments, the number of requests corresponding to requests of the first target type of the same type in the address space exceeds a first threshold, or the size of space occupied by requests of the first target type of the same type in the address space exceeds a second threshold.

In one embodiment, two requests may be considered to be of the same type of request if the objects and methods involved in the two requests are the same; if the objects and methods involved in the two requests are different, then the requests are not of the same type. For example, requests involving the same method of different objects or different methods of the same object are not all requests of the same class.

In some embodiments, the target methods include methods involving key functions of the system, such as methods of interacting directly with the user, or methods of the system finding an exception that requires termination of the application process, but the disclosure is not so limited, as those skilled in the art will make setting certain methods as target methods based on the teachings and actual scenarios. In some embodiments, all methods of a certain object may be set as core methods (i.e. target methods), or only some methods of the object may be set as core methods, and the application process may notify the kernel space through a system call. Each method in each object has a unique number, for example, each method of each object is numbered sequentially from 1, and if 10 methods exist in a certain object, all methods of the object are numbered sequentially from 1 to 10, and when an application process sends a request to a server, the method number of a specific object of the corresponding server is notified. Taking the binder communication as an example, the client application process needs to notify the binder driver through a system call, and the binder driver marks a related method in a corresponding server object.

According to one or more embodiments of the present disclosure, if a first request to be currently stored is determined to belong to an abnormal request (for example, data of multiple requests of the same type are already stored in an address space, or data of requests of the same type occupy a higher memory space), and a method involved in the first request is a non-core method, the data of the request will not be stored in a spare second address space if the first address space is exhausted, so that some unreasonable requests in the system can be prevented from being frequently sent to a server, and the probability of shared memory space exhaustion of the server is reduced.

In some embodiments, if the first address space does not have the sufficient remaining space, then in response to determining that the first request does not belong to the first target type of request, that a method to which the first request corresponds belongs to the target method, and that the second address space does not have the sufficient remaining space, memory space occupied by at least one of the first target type of requests is freed in the address space to store data of the first request to the address space. In this embodiment, under the condition that both the first address space and the second address space are exhausted, by releasing the data of the first target request in the address space, the request data of the second target request (for example, the core method of the infrequent request) which is not the first target request can be continuously stored, so as to ensure that the core request data can be successfully stored and processed as much as possible, and further improve the system stability.

In some embodiments, step S130 includes:

Step A1: determining a request of a first target type in the address space;

step A2: determining whether the first request belongs to a request of the first target type;

Step A3: and if the first request does not belong to the request of the first target type, storing the data of the first request into a second address space in response to the second address space having the enough residual space.

In this embodiment, the second address space may store any requests of a non-first target type in the event that the first address space is exhausted and there is a free second address space.

Further, in some embodiments, if the first request belongs to a request of the first target type, determining whether a method corresponding to the first request belongs to a target method; if the method corresponding to the first request belongs to the target method, storing the data of the first request into the second address space; and if the method corresponding to the first request does not belong to the target method, not storing the data of the first request. In this embodiment, if the first request is a request of both the first target type and the second target type, the request data may be stored if the second address space is free; if the first request is a request of a first target type but not a request of a second target type (e.g., a request that is frequently sent and does not involve a core method), then its request data is not stored.

In some embodiments, if the first request is not a request of a first target type, before depositing the data of the first request into a second address space, determining whether the second address space has the sufficient remaining space, if the second address space does not have the sufficient remaining space, determining whether a method corresponding to the first request belongs to a target method, and if the method corresponding to the first request does not belong to the target method, not storing the data of the first request. In this embodiment, although the first request is not a request of the first target type (e.g., a request that is sent infrequently), in the event that the second address space is exhausted, its request data is not stored if its first request is further determined to be a request of a non-second target type (e.g., the first request does not involve a core method).

Further, in some embodiments, if the method corresponding to the first request belongs to the target method, a storage space occupied by at least one request of the target type is released in the address space to store data of the first request in the address space. In this embodiment, if the first request is not a request of the first target type and the requested method is a target method, then, in the case of insufficient second address space, the address space occupied by at least one target type request in the address space is released, so that the relevant data of the first request can be stored in the corresponding address space. In some embodiments, the memory space occupied by at least one request of the target type may be freed up in the address space in sequence in a first address space and a second address space until either the first address space or the second address space is capable of storing the data of the first request.

Referring to fig. 3, a method for storing request data according to an embodiment of the present disclosure is shown, including the following steps.

In step 210, the client process sends a first request.

In step 220, it is determined whether the first address space has sufficient remaining space to store the first requested data. If there is enough space left in the first address space, step 221 is executed: the first requested data is deposited into a first address space. If the first address space does not have enough remaining space, then step 230 is performed.

In step S230, a request of a first target type is determined. For example, the shared address space of the server process may be traversed, the most called request method of the address space is found, and the request method is marked.

In step S240, it is determined whether the first request is a request of a first target type. For example, it may be determined whether the method (and its object) involved in the first request is the same as the method (and its object) marked in the above step. If the first request is not a request of the first target type, step 242 is performed.

In step 242, it is determined whether the second address space has sufficient remaining space to store the first requested data. If the second address space has enough remaining space, then step 290 is performed, i.e., the first requested data is stored in the second address space; if the second address space does not have enough remaining space, step 252 is performed.

In step 252, it is determined whether the method corresponding to the first request is a target method.

If the method corresponding to the first request is not the target method, step 251 is executed, i.e. the data of the first request is not stored. For example, a first request may be intercepted and a notification of a request failure returned to the client process.

If the method corresponding to the first request is the target method, step 262 is executed: the space occupied by the request of at least one target type is released in the first address space or the second address space.

In step 272, the first requested data is deposited into the first or second address space.

For example, if the method corresponding to the first request is the target method, the request data corresponding to at least one non-target method in the first address space is cleaned to release the storage space, so as to store the data of the first request in the first address space; if all the request data stored in the first address space correspond to the target method, i.e. the request data of the non-target method does not exist in the first address space, the request data of at least one non-target method in the second address space can be cleaned up so as to store the data of the first request in the second address space; if the request data stored in the second address space also all corresponds to the target method, the data of the first request is not stored, for example, the first request may be intercepted, and a notification of the failure of the request may be returned to the client process.

Returning to step 240, if the first request is a request of a first target type, step 250 is performed: and judging whether the method corresponding to the first request is a target method or not.

If the method corresponding to the first request is not the target method, step 251 is executed, i.e. the data of the first request is not stored.

If the method corresponding to the first request is the target method, step 260 is executed: it is determined whether the second address space has sufficient remaining space to store the first requested data.

If there is enough space left in the second address space, then step 290 is performed: the first requested data is deposited into the second address space.

If the second address space does not have enough remaining space, then step 251 is executed: the first requested data is not stored.

According to one or more embodiments of the present disclosure, in the case that the remaining space of the first address space is insufficient:

1) If the first request does not belong to the request of the first target type (for example, the request times of the first request do not belong to frequently), storing the data of the first request in the second address space;

2) If the first request belongs to a request of a first target type and the requested method does not belong to a target method (e.g., the number of requests of the first request is frequent and the requested method is not a core method), then the request data of the first request is not stored;

3) If the first request belongs to a request of the first target type but the requested method belongs to the target method (for example, the requested method is a core method although the number of requests of the first request is frequent), the data of the first request is stored in the second address space.

Further, under the condition that the remaining space of the second address space is insufficient, if the method requested by the first request does not belong to the target method, the data of the first request is not stored, and if the method requested by the first request belongs to the target method, the address spaces corresponding to the target type requests in the first address space and the second address space are sequentially released until the first address space or the second address space can store the data of the first request. For example, the request data corresponding to the non-target method in the first address space may be released first, so as to store the first requested data in the first address space; and if the request data corresponding to the target method (such as the core method) is stored in the first address space, releasing the request data corresponding to the non-target method in the second address space so as to store the first request data in the second address space, and if the request data corresponding to the target method (such as the core method) is stored in the second address space, not storing the first request data.

According to one or more embodiments of the present disclosure, by intercepting an abnormal uncore request, it may be ensured that request data corresponding to a core method can be stored in an address space as much as possible.

Referring to FIG. 4, a method of determining a request of a first target type is shown, including steps 231-236.

In step 231, all or part of the address space is traversed, e.g., data deposited per request in the process shared address space may be traversed.

In step 232, the number of requests per request is counted. For example, statistics may be performed in the form of key-value pairs (keys) where keys represent objects and methods, and the same method for different objects or different methods for the same object are all different keys, and value represents the number of requests.

In step 233, the requests are ordered from big to small. Illustratively, the keys (i.e., methods and objects) may be ordered from big to small by value of value, and then loops of steps 234-236 may be sequentially performed according to the ordering.

In step 234, it is determined whether the number of requests (e.g., value) of the current order request (e.g., key) exceeds a preset threshold. If the threshold is not exceeded, the loop is exited. For example, if the number of requests of the first order does not exceed the preset threshold, the loop is directly exited.

If the threshold is exceeded, then step 235 is performed: the current-order request is marked to identify a first target type of request.

In step 236, the next request is obtained to make the determination described above until the loop is exited.

In some embodiments, in order to find the request to send the first target type faster, according to the locality of program execution principle, all the request data in the shared address space may not be traversed in step 231, but only the address space size of at most 1/3 or 1/2.

Referring to FIG. 5, a method of freeing address space is shown as provided by an embodiment of the present disclosure, including steps 2621-2625.

In step 2621, all or part of the address space is traversed, e.g., data deposited per request in the process shared address space may be traversed.

In step 2622, it is determined whether the currently traversed request is marked (refer to step 235) and the corresponding method is the target method.

If the current request is marked and the corresponding method is not the target method, step 2623 is performed, i.e., the address space occupied by the currently traversed request is released.

In step 2624, it is determined whether the first requested data is less than the remaining available space size of the current address space (e.g., the first address space or the second address space).

If the first requested data is less than the remaining available space size of the current address space, then step 2625 is performed: the first requested data is deposited into the current address space. Otherwise, the above steps are continued.

In this embodiment, when the first address space and the second address space are both exhausted, for a request related to a target method (such as a core method), an attempt is made to clear an address space occupied by a frequently sent non-core method in the first or second address space, and when the cleared address space can store current request data, clearing logic is stopped to store the current request data in the address space.

According to the method provided by one or more embodiments of the present disclosure, a large number of requests (such as requests of a first target type) frequently sent to a server process in extreme scenarios such as a malicious program attack, an abnormal application program code logic, etc. can be identified, and intercepted, so that the risk of exhaustion of the shared address space of the server is reduced, the occurrence probability of faults such as system crashes and no response is reduced, and the system stability is improved. In addition, under the condition that the shared address space of the server is exhausted, successful sending and processing of a request related to a key or core method (such as a target method) can be ensured as much as possible, so that the stability of the system is further improved, and the probability of abnormal core functions of the system is reduced.

Accordingly, referring to fig. 6, an apparatus 600 for storing request data is provided according to an embodiment of the present disclosure, comprising:

A determining unit 601, configured to determine, in response to a first request of a client process, whether a first address space associated with a server process has enough remaining space to store data of the first request; the address space associated with the server process is divided into a first address space and a second address space;

A storage unit 602, configured to store data of the first request into the first address space if the first address space has the sufficient remaining space, and store data of the first request into the second address space in response to determining that the first request is not of a target type and the second address space has the sufficient remaining space if the first address space does not have the sufficient remaining space.

In some embodiments, the memory unit is further configured to: and if the first request belongs to the request of the target type, responding to the determination that the second address space does not have the enough residual space, and not storing the data of the first request.

In some embodiments, the request of the target type includes a request of a first target type or a request of a second target type; or the request of the target type includes an intersection of the request of the first target type and the request of the second target type; the request of the first target type is a request of occupied resources in the address space meeting preset conditions; the method requested by the request of the second target type does not belong to the target method.

In some embodiments, the memory unit is further configured to:

In response to determining that the first request belongs to a request of the first target type and that the requested method does not belong to the target method, not storing request data for the first request; and/or

In response to determining that the first request belongs to a request of the first target type and that the requested method belongs to the target method, data of the first request is deposited to the second address space.

In some embodiments, the means for storing the request data further comprises:

And the cleaning unit is used for responding to the determination that the first request does not belong to the request of the first target type, the method corresponding to the first request belongs to the target method and the second address space does not have the enough residual space, and releasing the storage space occupied by at least one request of the target type in the address space so as to store the data of the first request into the address space.

In some embodiments, the scrubbing unit is configured to sequentially release, in the first address space and the second address space, a storage space occupied by at least one request of the target type until the first address space or the second address space is capable of storing data of the first request.

In some embodiments, the target method comprises at least one of: to a method of user interaction, a method of terminating an application process.

In some embodiments, the determining unit is further configured to determine a request of a first target type in the address space, and determine whether the first request belongs to a request of the first target type; the storage unit is configured to store data of the first request to the second address space in response to the second address space having the sufficient remaining space if the first request does not belong to the request of the first target type.

In some embodiments, the determining unit is further configured to determine, if the first request belongs to a request of the first target type, whether a method corresponding to the first request belongs to a target method; the storage unit is further configured to store the data of the first request into the second address space if the method corresponding to the first request belongs to the target method, and not store the data of the first request if the method corresponding to the first request does not belong to the target method.

In some embodiments, the determining unit is further configured to determine, before depositing the data of the first request into a second address space, whether the second address space has the sufficient remaining space, and if the second address space does not have the sufficient remaining space, determine whether a method corresponding to the first request belongs to a target method; the storage unit is further configured to not store the data of the first request if the method corresponding to the first request does not belong to the target method.

In some embodiments, the means for storing the request data further comprises:

and the first cleaning unit is used for releasing the storage space occupied by at least one request of the target type in the first address space to store the data of the first request into the first address space if the method corresponding to the first request belongs to the target method.

In some embodiments, the means for storing the request data further comprises:

And the second cleaning unit is used for releasing the storage space occupied by at least one request of the target type in the second address space to store the data of the first request into the first address space in response to determining that the request data stored in the first address space currently belong to the target method if the method corresponding to the first request belongs to the target method.

For embodiments of the device, reference is made to the description of method embodiments for the relevant points, since they essentially correspond to the method embodiments. The apparatus embodiments described above are merely illustrative, wherein the modules illustrated as separate modules may or may not be separate. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art will understand and implement the present invention without undue burden.

Accordingly, in accordance with one or more embodiments of the present disclosure, there is provided an electronic device comprising:

at least one memory and at least one processor;

Wherein the memory is for storing program code, and the processor is for invoking the program code stored by the memory to cause the electronic device to perform a method of storing request data provided in accordance with one or more embodiments of the present disclosure.

Accordingly, in accordance with one or more embodiments of the present disclosure, there is provided a non-transitory computer storage medium storing program code executable by a computer device to cause the computer device to perform a method of storing request data provided in accordance with one or more embodiments of the present disclosure.

Referring now to fig. 7, a schematic diagram of an electronic device (e.g., a terminal device or server) 800 suitable for use in implementing embodiments of the present disclosure is shown. The terminal devices in the embodiments of the present disclosure may include, but are not limited to, mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and the like, and stationary terminals such as digital TVs, desktop computers, and the like. The electronic device shown in fig. 7 is merely an example and should not be construed to limit the functionality and scope of use of the disclosed embodiments.

As shown in fig. 7, the electronic device 800 may include a processing means (e.g., a central processor, a graphics processor, etc.) 801, which may perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 802 or a program loaded from a storage means 808 into a Random Access Memory (RAM) 803. In the RAM803, various programs and data required for the operation of the electronic device 800 are also stored. The processing device 801, the ROM 802, and the RAM803 are connected to each other by a bus 804. An input/output (I/O) interface 805 is also connected to the bus 804.

In general, the following devices may be connected to the I/O interface 805: input devices 806 including, for example, a touch screen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, and the like; an output device 807 including, for example, a Liquid Crystal Display (LCD), speakers, vibrators, etc.; storage 808 including, for example, magnetic tape, hard disk, etc.; communication means 809. The communication means 809 may allow the electronic device 800 to communicate wirelessly or by wire with other devices to exchange data. While fig. 7 shows an electronic device 800 having various means, it is to be understood that not all of the illustrated means are required to be implemented or provided. More or fewer devices may be implemented or provided instead.

In particular, according to embodiments of the present disclosure, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flowcharts. In such an embodiment, the computer program may be downloaded and installed from a network via communication device 809, or installed from storage device 808, or installed from ROM 802. The above-described functions defined in the methods of the embodiments of the present disclosure are performed when the computer program is executed by the processing device 801.

It should be noted that the computer readable medium described in the present disclosure may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this disclosure, a computer-readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present disclosure, however, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, fiber optic cables, RF (radio frequency), and the like, or any suitable combination of the foregoing.

In some embodiments, the clients, servers may communicate using any currently known or future developed network protocol, such as HTTP (HyperText Transfer Protocol ), and may be interconnected with any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), the internet (e.g., the internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future developed networks.

The computer readable medium may be contained in the electronic device; or may exist alone without being incorporated into the electronic device.

The computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to perform the methods of the present disclosure described above.

Computer program code for carrying out operations of the present disclosure may be written in one or more programming languages, including an object oriented programming language such as Java, smalltalk, C ++ and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units involved in the embodiments of the present disclosure may be implemented by means of software, or may be implemented by means of hardware. Wherein the names of the units do not constitute a limitation of the units themselves in some cases.

The functions described above herein may be performed, at least in part, by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), an Application Specific Standard Product (ASSP), a system on a chip (SOC), a Complex Programmable Logic Device (CPLD), and the like.

In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

According to one or more embodiments of the present disclosure, there is provided a method of storing request data, including: in response to a first request by a client process, determining whether a first address space associated with a server process has sufficient remaining space to store data of the first request; the address space associated with the server process is divided into a first address space and a second address space; if the first address space has the enough residual space, storing the first requested data into the first address space; if the first address space does not have the sufficient remaining space, then data of the first request is deposited to the second address space in response to determining that the first request is not of a target type and that the second address space has the sufficient remaining space.

According to one or more embodiments of the present disclosure, if the first request belongs to a request of the target type, the method further comprises: in response to determining that the second address space does not have the sufficient remaining space, the first requested data is not stored.

According to one or more embodiments of the present disclosure, the request of the target type includes a request of a first target type or a request of a second target type; or the request of the target type includes an intersection of the request of the first target type and the request of the second target type; the request of the first target type is a request of occupied resources in the address space meeting preset conditions; the method requested by the request of the second target type does not belong to the target method.

According to one or more embodiments of the present disclosure, if the first address space does not have the sufficient remaining space, the method further comprises: in response to determining that the first request belongs to a request of the first target type and that the requested method does not belong to the target method, not storing request data for the first request; and/or in response to determining that the first request belongs to a request of the first target type and that the requested method belongs to the target method, depositing data of the first request to the second address space.

According to one or more embodiments of the present disclosure, if the first address space does not have the sufficient remaining space, the method further comprises: in response to determining that the first request does not belong to the first target type of request, that a method to which the first request corresponds belongs to the target method, and that the second address space does not have the sufficient remaining space, freeing up memory space in the address space occupied by at least one request of the target type to store data of the first request to the address space.

According to one or more embodiments of the present disclosure, the releasing, in the address space, a storage space occupied by at least one request of the target type includes: and sequentially releasing at least one storage space occupied by the target type request in the first address space and the second address space until the first address space or the second address space can store the data of the first request.

According to one or more embodiments of the present disclosure, the number of requests corresponding to requests of the first target type of the same type in the address space exceeds a first threshold, or the size of space occupied by requests of the first target type of the same type in the address space exceeds a second threshold.

According to one or more embodiments of the present disclosure, the target method includes at least one of: to a method of user interaction, a method of terminating an application process.

In accordance with one or more embodiments of the present disclosure, the depositing data of the first request into the second address space in response to determining that the first request is not of a target type and that the second address space has the sufficient remaining space includes: determining a request of a first target type in the address space; determining whether the first request belongs to a request of the first target type; and if the first request does not belong to the request of the first target type, storing the data of the first request into the second address space in response to the second address space having the enough residual space.

A method of storing request data provided according to one or more embodiments of the present disclosure further includes: if the first request belongs to the request of the first target type, determining whether a method corresponding to the first request belongs to a target method or not; if the method corresponding to the first request belongs to the target method, storing the data of the first request into the second address space; and if the method corresponding to the first request does not belong to the target method, not storing the data of the first request.

In accordance with one or more embodiments of the present disclosure, before depositing the first requested data into the second address space, the method further comprises: determining whether the second address space has the sufficient remaining space; if the second address space does not have the enough residual space, determining whether a method corresponding to the first request belongs to a target method; and if the method corresponding to the first request does not belong to the target method, not storing the data of the first request.

A method of storing request data provided according to one or more embodiments of the present disclosure further includes: and if the method corresponding to the first request belongs to the target method, releasing at least one storage space occupied by the request of the target type in the first address space to store the data of the first request into the first address space.

A method of storing request data provided according to one or more embodiments of the present disclosure further includes: and if the method corresponding to the first request belongs to the target method, releasing the storage space occupied by at least one request of the target type in the second address space to store the data of the first request into the first address space in response to determining that the request data stored in the first address space currently belong to the target method.

According to one or more embodiments of the present disclosure, there is provided an apparatus for storing request data, including: a determining unit, configured to determine, in response to a first request of a client process, whether a first address space associated with a server process has enough remaining space to store data of the first request; the address space associated with the server process is divided into a first address space and a second address space; a storage unit configured to store data of the first request to the first address space if the first address space has the sufficient remaining space, and store data of the first request to the second address space in response to determining that the first request is not of a target type and the second address space has the sufficient remaining space if the first address space does not have the sufficient remaining space.

According to one or more embodiments of the present disclosure, there is provided an electronic device including: at least one memory and at least one processor; wherein the memory is for storing program code, and the processor is for invoking the program code stored by the memory to cause the electronic device to perform a method of storing request data provided in accordance with one or more embodiments of the present disclosure.

According to one or more embodiments of the present disclosure, there is provided a non-transitory computer storage medium storing program code which, when executed by a computer device, causes the computer device to perform a method of storing request data provided according to one or more embodiments of the present disclosure.

The foregoing description is only of the preferred embodiments of the present disclosure and description of the principles of the technology being employed. It will be appreciated by persons skilled in the art that the scope of the disclosure referred to in this disclosure is not limited to the specific combinations of features described above, but also covers other embodiments which may be formed by any combination of features described above or equivalents thereof without departing from the spirit of the disclosure. Such as those described above, are mutually substituted with the technical features having similar functions disclosed in the present disclosure (but not limited thereto).

Moreover, although operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of the present disclosure. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are example forms of implementing the claims.

Claims

1. A method of storing request data, comprising:

2. The method of claim 1, wherein if the first request is of the target type, the method further comprises:

in response to determining that the second address space does not have the sufficient remaining space, the first requested data is not stored.

3. The method of claim 1, wherein the step of determining the position of the substrate comprises,

The request of the target type comprises a request of a first target type or a request of a second target type; or alternatively

The request of the target type includes an intersection of the request of the first target type and the request of the second target type;

The request of the first target type is a request of occupied resources in the address space meeting preset conditions; the method requested by the request of the second target type does not belong to the target method.

4. A method according to claim 3, wherein if the first address space does not have the sufficient remaining space, the method further comprises:

5. A method according to claim 3, wherein if the first address space does not have the sufficient remaining space, the method further comprises:

In response to determining that the first request does not belong to the first target type of request, that a method to which the first request corresponds belongs to the target method, and that the second address space does not have the sufficient remaining space, freeing up memory space in the address space occupied by at least one request of the target type to store data of the first request to the address space.

6. The method of claim 5, wherein freeing memory space occupied by at least one request of the target type in the address space comprises:

And sequentially releasing at least one storage space occupied by the target type request in the first address space and the second address space until the first address space or the second address space can store the data of the first request.

7. A method according to claim 3, characterized in that the number of requests corresponding to requests of the first target type of the same type in the address space exceeds a first threshold value, or the size of the space occupied by requests of the first target type of the same type in the address space exceeds a second threshold value.

8. A method according to any one of claims 3, wherein the target method comprises at least one of: to a method of user interaction, a method of terminating an application process.

9. A method according to claim 3, wherein said depositing data of said first request into said second address space in response to determining that said first request is not of a target type and that said second address space has said sufficient remaining space comprises:

Determining a request of a first target type in the address space;

determining whether the first request belongs to a request of the first target type;

And if the first request does not belong to the request of the first target type, storing the data of the first request into the second address space in response to the second address space having the enough residual space.

10. The method as recited in claim 9, further comprising:

If the first request belongs to the request of the first target type, determining whether a method corresponding to the first request belongs to a target method or not;

if the method corresponding to the first request belongs to the target method, storing the data of the first request into the second address space;

And if the method corresponding to the first request does not belong to the target method, not storing the data of the first request.

11. The method of claim 9, wherein prior to depositing the first requested data into the second address space, the method further comprises:

determining whether the second address space has the sufficient remaining space;

If the second address space does not have the enough residual space, determining whether a method corresponding to the first request belongs to a target method;

12. The method as recited in claim 11, further comprising:

And if the method corresponding to the first request belongs to the target method, releasing at least one storage space occupied by the request of the target type in the first address space to store the data of the first request into the first address space.

13. The method as recited in claim 12, further comprising:

And if the method corresponding to the first request belongs to the target method, releasing the storage space occupied by at least one request of the target type in the second address space to store the data of the first request into the first address space in response to determining that the request data stored in the first address space currently belong to the target method.

14. An apparatus for storing requested data, comprising:

15. An electronic device, comprising:

at least one memory and at least one processor;

Wherein the memory is for storing program code and the processor is for invoking the program code stored by the memory to cause the electronic device to perform the method of any of claims 1-13.

16. A non-transitory computer storage medium comprising,

The non-transitory computer storage medium stores program code that, when executed by a computer device, causes the computer device to perform the method of any of claims 1 to 13.