Side effect recovery method and device, equipment and storage medium

Abstract

The invention discloses a side effect recovery method and device, equipment and a storage medium, and the method comprises the steps: determining a component instance to which a side effect function belongs when the side effect function is created; monitoring the execution state of the side effect function in real time, and marking the side effect function as a current active side effect before the side effect function is monitored to be executed; in the execution process of the current active side effect, establishing a dependency graph corresponding to the current active side effect; monitoring a data modification state in real time, and determining a path of the modified data; and performing side effect recovery based on the path of the modified data and the dependency graph, and performing side effect recovery based on the component instance and the dependency graph. According to the method and the device, the integrity and no omission of recovery are ensured, so that automatic recovery is realized, low efficiency and high accuracy of manual cleaning by developers are avoided, and memory leakage and resource waste are avoided.

Description

Technical Field

[0001] This application relates to the field of side effect recovery technology, specifically to a side effect recovery method, apparatus, device, and storage medium. Background Technology

[0002] As the complexity of front-end applications continues to increase, reactive data management has become the core foundation of modern web frameworks. Vue.js, as one of the mainstream frameworks, uses its Reactivity system to automate the data change to view update through dependency tracking and side effect scheduling. However, in large single-page applications, long-duration sessions, and dynamic component tree scenarios, existing reactive systems have exposed a series of performance and resource management issues.

[0003] For example, in the existing approach, side effects remain in memory after the component is destroyed or the data source fails. There is no automatic recycling process, which requires developers to clean up manually, which can easily lead to memory leaks and resource waste. Summary of the Invention

[0004] In view of this, this application provides a side effect recycling method, apparatus, device, and storage medium to solve the problem that in existing methods, side effects remain in memory after component destruction or data source failure, lack an automatic recycling process, require manual cleanup by developers, and are prone to memory leaks and resource waste.

[0005] To achieve the above objectives, the following solution is proposed:

[0006] Firstly, a method for recovering side effects includes:

[0007] When a side effect function is created, the component instance to which the side effect function belongs is determined;

[0008] The execution status of side effect functions is monitored in real time. Before a side effect function is detected to start executing, it is marked as a currently active side effect.

[0009] During the execution of the currently active side effect, a dependency graph corresponding to the currently active side effect is established;

[0010] Real-time monitoring of data modification status to determine the path of the modified data;

[0011] Side effect recycling is performed based on the path and dependency graph of the modified data, and also based on the component instance and dependency graph.

[0012] Preferably, determining the component instance to which the side effect function belongs when the side effect function is created includes:

[0013] When the side effect function is created, the framework side effect registration API is overridden;

[0014] Assign a unique identifier to the side effect function;

[0015] Record each piece of metadata for the aforementioned side effect function;

[0016] Determine the component instance to which the side effect function belongs from the metadata entries.

[0017] Preferably, the step of establishing a dependency graph corresponding to the currently active side effect during the execution of the current active side effect includes:

[0018] During the execution of the currently active side effect, intercept any read operations on reactive data to determine the path chains;

[0019] For each of the aforementioned path chains, determine each node on that path chain;

[0020] A dependency edge is established between the currently active side effect and each of the nodes;

[0021] Based on the current active side effects, each node, and each dependent edge, a dependency graph is established.

[0022] Preferably, the side effect recovery based on the path and dependency graph of the modified data includes:

[0023] Determine whether the path of the modified data has a corresponding subpath;

[0024] If so, then both the path and subpath of the modified data will be used as the target path;

[0025] For each target path, the target path is mapped to the dependency graph to determine each node contained in the target path in the dependency graph, which is then used as the first node.

[0026] Based on each of the first nodes, invalid dependency edges are identified in the dependency graph;

[0027] Remove the invalid dependency edge from the dependency graph.

[0028] Preferably, determining invalid dependency edges in the dependency graph based on each of the first nodes includes:

[0029] For each of the first nodes, find the side effect function that directly depends on the first node in the dependency graph, and use it as the first function;

[0030] Add the first function to the pre-set execution queue;

[0031] Real-time monitoring of the path set accessed by the first function during the execution of the queue to be executed a preset number of times;

[0032] The path set is compared with the dependency graph to identify dependency edges in the dependency graph that are not included in the path set as invalid dependency edges.

[0033] Preferably, the side effect recycling based on the component instance and dependency graph includes:

[0034] Establish a bidirectional association between the component instance and the side effect function;

[0035] When the component instance is destroyed, all side effects belonging to the component instance are found based on the bidirectional association;

[0036] Stop the response data and execution process of the aforementioned side effects;

[0037] Delete all dependency edges in the dependency graph that are associated with the side effects.

[0038] Preferably, before performing side effect recycling based on the path and dependency graph of the modified data, the method further includes:

[0039] When multiple side effect functions exist, determine the business scenario for each side effect function;

[0040] Based on the aforementioned business scenario, each of the side effect functions is sorted according to a pre-defined priority rule;

[0041] Define performance-sensitive rules and resource optimization rules;

[0042] According to the performance-sensitive rules and / or resource optimization rules, subsequent side effect recovery operations are performed in the sorted order.

[0043] Secondly, a side effect recovery device includes:

[0044] The component instance determination module is used to determine the component instance to which the side effect function belongs when the side effect function is created;

[0045] The marking module is used to monitor the execution status of side effect functions in real time. Before a side effect function is detected to start executing, it is marked as a currently active side effect.

[0046] A dependency graph building module is used to build a dependency graph corresponding to the currently active side effect during the execution of the currently active side effect.

[0047] The path determination module is used to monitor the data modification status in real time and determine the path of the modified data.

[0048] The side effect recovery module is used to perform side effect recovery based on the path and dependency graph of the modified data, and also based on the component instance and dependency graph.

[0049] Thirdly, a side effect recovery device, including a memory and a processor;

[0050] The memory is used to store programs;

[0051] The processor is configured to execute the program to implement the steps of the side effect recovery method as described in any of the first aspects.

[0052] Fourthly, a storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the side effect recovery method as described in any of the first aspects.

[0053] As can be seen from the above technical solution, this application determines the component instance to which the side effect function belongs when the side effect function is created; monitors the execution status of the side effect function in real time, and marks the side effect function as a currently active side effect before it is detected to start execution; establishes a dependency graph corresponding to the currently active side effect during its execution; monitors the data modification status in real time and determines the path of the modified data; performs side effect recycling based on the path of the modified data and the dependency graph, and simultaneously performs side effect recycling based on the component instance and the dependency graph. This application first focuses on determining the component instance to which a side effect function belongs when it is created. This binds the abstract side effect function to a concrete, lifecycle-based component instance. After the side effect function is created, it will be executed. Before execution begins, the side effect function needs to be marked as a currently active side effect to complete the registration process, enabling subsequent monitoring and recycling. A dependency graph corresponding to the currently active side effect is established, which clarifies which data a currently active side effect depends on and which data is depended on by the currently active side effect. When monitoring data modification status, the path of the modified data can be determined based on the dependency relationship in the dependency graph. Side effect recycling is then performed based on the modified path and the dependency graph. Further recycling is performed based on the component instance and dependency graph to ensure completeness and no omissions in recycling, thus achieving automatic recycling. This avoids the inefficiency and lack of accuracy of manual cleanup by developers, and prevents memory leaks and resource waste. Attached Figure Description

[0054] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0055] Figure 1 An optional flowchart of a side effect recovery method provided in an embodiment of this application;

[0056] Figure 2 This is a schematic diagram of the structure of a side effect recovery device provided in an embodiment of this application;

[0057] Figure 3 This is a schematic diagram of a side effect recovery device provided in an embodiment of this application. Detailed Implementation

[0058] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0059] This invention can be used in a wide variety of general-purpose or special-purpose computing device environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor devices, distributed computing environments including any of the above devices, etc.

[0060] This invention provides a method for recovering side effects. This method can be applied to various computer terminals or smart terminals, and its execution entity can be the processor or server of the computer terminal or smart terminal. The method flowchart is shown below. Figure 1 As shown, it specifically includes:

[0061] S1: When a side effect function is created, determine the component instance to which the side effect function belongs.

[0062] Determining the component instance to which a side effect function belongs involves binding an abstract side effect function to a concrete component instance with a lifecycle. The component lifecycle includes creation, mounting, updating, and destruction. Since multiple component instances may have side effect functions of the same type, this step first determines the component instance to which the side effect function belongs. This step can distinguish between the side effects of component instance A and component instance B, so that during recycling, the side effect corresponding to that component instance can be accurately determined without affecting other component instances.

[0063] Component instances can be identified through JavaScript call stack analysis or from context information injected by the framework during compilation / runtime.

[0064] S2: Monitor the execution status of side effect functions in real time. Before a side effect function is detected to start executing, mark the side effect function as a currently active side effect.

[0065] This step implements the registration process for side effect functions. Just before a side effect function is executed, it is set as a globally known or context-known currently active side effect. The execution of a currently active side effect may trigger the execution of another side effect. Therefore, by marking it, we can ensure that we are locating the correct, currently executing side effect function and avoid confusion.

[0066] S3: During the execution of the currently active side effect, establish a dependency graph corresponding to the currently active side effect.

[0067] When the current active side effect is executed, it accesses some reactive data. At this time, we can record which attribute of the reactive data the current active side effect accessed and establish an edge. Then, by collecting all these access relationships, we form a dependency graph with the current active side effect as the root node and all the data attributes it accesses as leaf nodes. This graph is bidirectional, which means that it is clear which data a side effect depends on, and it is also clear which side effects depend on a piece of data.

[0068] The dependency graph is the foundation and basis for the subsequent recycling process. When data is modified or changes, the corresponding dependencies can be found based on the dependency graph to achieve accurate recycling.

[0069] S4: Monitor data modification status in real time and determine the path of the modified data.

[0070] When data is modified, the modification event can be captured by the setter interceptor of the data object, and then the path of the modified data can be determined. For example, if the modification event corresponds to the change of an object, then the specific property of the object that has changed is the path of the modified data. This allows for precise location of the affected part, laying the foundation for subsequent garbage collection.

[0071] S5: Perform side effect recycling based on the path and dependency graph of the modified data, and simultaneously perform side effect recycling based on the component instance and dependency graph.

[0072] When performing the final cleanup, it is necessary to rely on the path of the modified data and the dependency graph to perform side effect recycling in one dimension, and rely on the component instances and dependency graph to perform side effect recycling in the second dimension. Only in this way can the roughness of manual cleanup by developers be completely eliminated.

[0073] The recycling process based on data modification involves searching the dependency graph based on the path of the modified data, finding all side-effect functions that once depended on this path, and then removing the dependencies corresponding to these side-effect functions from the graph.

[0074] Since these data have changed, the old dependencies may no longer hold true. When the side effect is executed again, the dependencies will be re-collected based on the new data access, that is, a new dependency graph will be rebuilt. In essence, this cleans up outdated dependencies, not the side effect function itself. This keeps the dependency graph concise and clean, and prevents unnecessary repeated execution due to outdated dependencies.

[0075] Meanwhile, based on the recycling of component instances, it can be understood that when a component instance is about to be unloaded and destroyed, it needs to query the dependency graph to find all the side-effect functions belonging to that component instance. Then, it will directly stop or destroy these side-effect functions (including clearing timers, canceling network requests, removing event listeners, etc.) and completely remove them from the dependency graph at the same time. This ensures the thoroughness of side-effect recycling, prevents memory unloading, and ensures that all data generated by the component is cleaned up when it is destroyed.

[0076] The two processes described above complement each other and work together to ensure efficient and accurate recovery of side effects.

[0077] As can be seen from the above technical solution, this application determines the component instance to which the side effect function belongs when the side effect function is created; monitors the execution status of the side effect function in real time, and marks the side effect function as a currently active side effect before it is detected to start execution; establishes a dependency graph corresponding to the currently active side effect during its execution; monitors the data modification status in real time and determines the path of the modified data; performs side effect recycling based on the path of the modified data and the dependency graph, and simultaneously performs side effect recycling based on the component instance and the dependency graph. This application first focuses on determining the component instance to which a side effect function belongs when it is created. This binds the abstract side effect function to a concrete, lifecycle-bound component instance. After the side effect function is created, it will be executed. Before execution begins, the side effect function needs to be marked as a currently active side effect, completing the registration process. This allows for subsequent monitoring and recycling. A dependency graph corresponding to the currently active side effect is established, which clarifies which data a currently active side effect depends on and which data is depended upon by the currently active side effect. When monitoring data modification status, the path of the modified data can be determined based on the dependency relationships in the dependency graph. Side effect recycling is then performed based on the modified path and the dependency graph. Further recycling is performed based on the component instance and dependency graph, ensuring completeness and no omissions. This achieves automatic recycling, avoiding the inefficiency and lack of accuracy of manual cleanup by developers, and preventing memory leaks and resource waste. This application, through the mapping of component instance-side effect function-dependency data, can automatically and accurately recycle all side effects generated when a component is destroyed, fundamentally solving the problem of easy omissions in manual management.

[0078] On the other hand, invalid side-effect functions not only consume memory, but may also perform unnecessary calculations in sequence, or even attempt to update DOM elements that no longer exist, causing application lag. This application can release resources by timely recycling these side effects, ensuring the smoothness and stability of application operation.

[0079] The method provided in this embodiment of the invention, which determines the component instance to which the side effect function belongs when the side effect function is created, is described in detail below:

[0080] When the side effect function is created, the framework side effect registration API is overridden;

[0081] Assign a unique identifier to the side effect function;

[0082] Record each piece of metadata for the aforementioned side effect function;

[0083] Determine the component instance to which the side effect function belongs from the metadata entries.

[0084] Specifically, any side effect function (such as computed properties, listeners, and rendering functions) must be registered through the system's rewritten API when it is created. To maintain uniqueness, each side effect function needs to be assigned a unique identifier.

[0085] The metadata of the side effect function can be recorded, including its creation location, creation time, last execution time, list of dependent nodes, priority, etc. Based on this metadata, a two-way association is established between the side effect function and the component instance, forming a side effect-component association mapping relationship. This allows the component to know which side effects it manages, and the side effects to know which component they belong to. Generally, a manager will manage this metadata. The manager can also monitor the execution status of the side effects, such as active or paused status, to understand the execution status of the side effects.

[0086] When a component instance is mounted onto the page, all side effects belonging to that component are officially activated, making it responsive to data changes. Before a side effect function that needs to respond to data changes begins execution, it is marked as the currently active side effect, completing the side effect registration.

[0087] The following describes in detail the process of establishing a dependency graph corresponding to the current active side effect during the execution of the current active side effect.

[0088] During the execution of the currently active side effect, intercept any read operations on reactive data to determine the path chains;

[0089] For each of the aforementioned path chains, determine each node on that path chain;

[0090] A dependency edge is established between the currently active side effect and each of the nodes;

[0091] Based on the current active side effects, each node, and each dependent edge, a dependency graph is established.

[0092] Specifically, during the execution of the side-effect function, any read operation on reactive data will be intercepted by the corresponding proxy. This application can achieve finer-grained precision in dependency recording based on Vue 3's proxy-based reactive system. During the data access interception phase, it not only records the currently accessed property but also dynamically constructs the path chain for accessing the property. For example, if the four properties user, profile, address, and city are accessed sequentially, the path chain "user.profile.address.city" is constructed. It maintains a dependency set not only for the final leaf node but also for each intermediate node in the path chain: user, user.profile, and user.profile.address. Then, a dependency edge is drawn between the currently active side-effect and these nodes, meaning that this currently active side-effect depends on these paths.

[0093] Therefore, the above process constructs and maintains a global dependency graph. The nodes in the graph represent reactive data attributes or paths. Each node is associated with a dependency set and records all side effects of subscribing to that node. An incremental update strategy can be adopted to dynamically add dependency edges when accessing data, so that the relevant side effects can be triggered precisely when the data changes.

[0094] To achieve real-time dependency graphs, version management can be implemented, which involves monitoring data changes in real time, incrementing the version number after each data change, and verifying the version before side effects are executed to avoid duplicate execution or loss of updates.

[0095] To improve performance, a hierarchical structure can be adopted for the dependency graph, that is, the dependency graph can be divided according to component subtrees or business modules to form various dependency subgraphs, thereby achieving dependency isolation and local updates, preventing the impact on the whole and improving stability.

[0096] On the other hand, it can monitor the data access sequence during the execution of side effects in real time, identify dependent edges that have not been accessed for a long time, such as edges that have exceeded a set time threshold or edges that have no actual read operations. At the same time, for stable data, such as configuration items, lazy tracking is used, and updates are triggered only when there is an explicit change; for frequently changing data, such as real-time streams, active tracking is used to ensure timely updates. This can optimize tracking efficiency and reduce redundant tracking.

[0097] The following embodiments provide a detailed explanation of the steps for side effect recovery based on the path and dependency graph of the modified data in this application.

[0098] Determine whether the path of the modified data has a corresponding subpath;

[0099] If so, then both the path and subpath of the modified data will be used as the target path;

[0100] For each target path, the target path is mapped to the dependency graph to determine each node contained in the target path in the dependency graph, which is then used as the first node.

[0101] Based on each of the first nodes, invalid dependency edges are identified in the dependency graph;

[0102] Remove the invalid dependency edge from the dependency graph.

[0103] Specifically, in reactive systems, data is usually nested objects. Modifying obj.ab means that obj.a also changes. Therefore, in order to ensure that all potentially affected nodes in the dependency graph are taken into account and to avoid omissions, it is not enough to just check ordinary paths. It is also necessary to determine whether these modified paths still have corresponding sub-paths. If they do, they need to be used as target paths together so that they can be removed together when removing them, and also to ensure the thoroughness of recycling.

[0104] The step of determining invalid dependency edges in the dependency graph based on each of the first nodes in the above process may include:

[0105] For each of the first nodes, find the side effect function that directly depends on the first node in the dependency graph, and use it as the first function;

[0106] Add the first function to the pre-set execution queue;

[0107] Real-time monitoring of the path set accessed by the first function during the execution of the queue to be executed a preset number of times;

[0108] The path set is compared with the dependency graph to identify dependency edges in the dependency graph that are not included in the path set as invalid dependency edges.

[0109] Specifically, identifying the first node and invalid dependency edges allows for precise location of specific edges in the dependency graph (i.e., the dependencies of side-effect functions on a particular data node) that become invalid due to the data modification. In one example, a side-effect function previously depended on obj.a, but obj.a has now been completely replaced. Therefore, all deep dependencies previously built upon the old obj.a (such as obj.ab) become invalid. This method allows for the accurate identification and removal of these invalid dependency edges.

[0110] In the above process, this application monitors in real time the set of paths accessed by the first function during the execution of the queue to be executed a preset number of times. This method collects which data the side-effect function actually accesses in the current data state through actual execution. This set of paths represents the most realistic and accurate dependency requirements at present. After comparison with the dependency graph, any dependency edge that exists in the historical record but is not in the current requirement list can be considered an invalid dependency edge.

[0111] Furthermore, the process of performing side effect recycling based on the component instance and dependency graph may include the following steps:

[0112] Establish a bidirectional association between the component instance and the side effect function;

[0113] When the component instance is destroyed, all side effects belonging to the component instance are found based on the bidirectional association;

[0114] Stop the response data and execution process of the aforementioned side effects;

[0115] Delete all dependency edges in the dependency graph that are associated with the side effects.

[0116] Specifically, establishing bidirectional associations can instantly and completely locate all targets that need to be cleaned up, avoiding the inefficient operation of traversing the entire side effect pool; stopping response data and execution processes actively cuts off the connection between side effects and other data, including canceling the side effect's listening to any data, clearing any existing timers, and canceling any network requests that may be in progress, thus achieving comprehensive side effect recycling.

[0117] In addition, the relevant data for this side effect needs to be removed from the global dependency graph. This ensures that the dependency graph does not become bloated and inaccurate due to the residual dependencies of a large number of destroyed components.

[0118] Specifically, to further prevent garbage collection omissions, a passive fallback mechanism can be built using WeakRef and FinalizationRegistry. When a side effect function is left with only a weak reference, a callback will be automatically triggered in a subsequent garbage collection cycle to perform the final resource release.

[0119] In one embodiment provided in this application, before performing side effect recovery based on the path and dependency graph of the modified data, the method further includes:

[0120] When multiple side effect functions exist, determine the business scenario for each side effect function;

[0121] Based on the aforementioned business scenario, each of the side effect functions is sorted according to a pre-defined priority rule;

[0122] Define performance-sensitive rules and resource optimization rules;

[0123] According to the performance-sensitive rules and / or resource optimization rules, subsequent side effect recovery operations are performed in the sorted order.

[0124] Specifically, not all side effects are equal. In different business scenarios, the priority and optimization goals for handling side effects should be different. This application can make more intelligent decisions by introducing business scenario recognition and rule engine.

[0125] The system can prioritize side-effect functions according to pre-defined priority rules. For example, side-effects that directly respond to user interactions can be assigned high priority, those affecting core business data medium priority, and deferred, analytical side-effects low priority. When system resources (such as CPU time and garbage collection overhead) are strained, the smooth execution and immediate recycling of high-priority side-effects can be prioritized, while low-priority side-effects can be appropriately delayed, thereby improving user-perceived performance and the reliability of core business processes.

[0126] Performance-sensitive rules aim to maximize response speed. They refer to prioritizing the most aggressive and timely recycling of high-priority, frequently executed side effects to ensure that their dependencies are always kept as streamlined as possible and that execution speed is as fast as possible. This may sacrifice some memory efficiency in exchange for high performance.

[0127] Resource optimization rules aim to minimize memory usage and computational overhead. This refers to adopting a lazier recycling strategy, such as batch processing of recycling requests, reducing the frequency of recycling operations, and for low-priority side effects, even skipping the most granular recycling steps and waiting to clean up when the component is destroyed.

[0128] and Figure 1 Corresponding to the method described above, embodiments of the present invention also provide a side effect recovery device for... Figure 1 In the specific implementation of the method, the side effect recovery device provided in this embodiment of the invention can be integrated into a computer terminal or various mobile devices. Figure 2 The side effect recovery device is introduced, such as... Figure 2 As shown, the device may include:

[0129] The component instance determination module 10 is used to determine the component instance to which the side effect function belongs when the side effect function is created;

[0130] The marking module 20 is used to monitor the execution status of side effect functions in real time. When a side effect function is detected to start executing, it marks the side effect function as a currently active side effect.

[0131] The dependency graph building module 30 is used to build a dependency graph corresponding to the current active side effect during the execution of the current active side effect;

[0132] The path determination module 40 is used to monitor the data modification status in real time and determine the path of the modified data.

[0133] The side effect recovery module 50 is used to perform side effect recovery based on the path and dependency graph of the modified data, and also based on the component instance and dependency graph.

[0134] As can be seen from the above technical solution, this application determines the component instance to which the side effect function belongs when the side effect function is created; monitors the execution status of the side effect function in real time, and marks the side effect function as a currently active side effect before it is detected to start execution; establishes a dependency graph corresponding to the currently active side effect during its execution; monitors the data modification status in real time and determines the path of the modified data; performs side effect recycling based on the path of the modified data and the dependency graph, and simultaneously performs side effect recycling based on the component instance and the dependency graph. This application first focuses on determining the component instance to which a side effect function belongs when it is created. This binds the abstract side effect function to a concrete, lifecycle-based component instance. After the side effect function is created, it will be executed. Before execution begins, the side effect function needs to be marked as a currently active side effect to complete the registration process, enabling subsequent monitoring and recycling. A dependency graph corresponding to the currently active side effect is established, which clarifies which data a currently active side effect depends on and which data is depended on by the currently active side effect. When monitoring data modification status, the path of the modified data can be determined based on the dependency relationship in the dependency graph. Side effect recycling is then performed based on the modified path and the dependency graph. Further recycling is performed based on the component instance and dependency graph to ensure completeness and no omissions in recycling, thus achieving automatic recycling. This avoids the inefficiency and lack of accuracy of manual cleanup by developers, and prevents memory leaks and resource waste.

[0135] Furthermore, embodiments of this application provide a side effect recovery device. Optionally, Figure 3 The hardware structure block diagram of the side effect recovery device is shown, with reference to Figure 3The hardware structure of the side effect recovery device may include: at least one processor 01, at least one communication interface 02, at least one memory 03, and at least one communication bus 04.

[0136] In this embodiment, the number of processor 01, communication interface 02, memory 03 and communication bus 04 is at least one, and processor 01, communication interface 02 and memory 03 communicate with each other through communication bus 04.

[0137] Processor 01 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention.

[0138] Memory 03 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device.

[0139] The memory stores a program that the processor can call. The program is used to execute the following side effect recovery methods, including:

[0140] When a side effect function is created, the component instance to which the side effect function belongs is determined;

[0141] The execution status of side effect functions is monitored in real time. Before a side effect function is detected to start executing, it is marked as a currently active side effect.

[0142] During the execution of the currently active side effect, a dependency graph corresponding to the currently active side effect is established;

[0143] Real-time monitoring of data modification status to determine the path of the modified data;

[0144] Side effect recycling is performed based on the path and dependency graph of the modified data, and also based on the component instance and dependency graph.

[0145] Optionally, the refined and extended functions of the program can be found in the description of the side effect recovery method in the method embodiments.

[0146] This application embodiment also provides a storage medium that can store a program suitable for execution by a processor. When the program runs, it controls the device where the storage medium is located to perform the following side effect recovery method, including:

[0147] When a side effect function is created, the component instance to which the side effect function belongs is determined;

[0148] The execution status of side effect functions is monitored in real time. Before a side effect function is detected to start executing, it is marked as a currently active side effect.

[0149] During the execution of the currently active side effect, a dependency graph corresponding to the currently active side effect is established;

[0150] Real-time monitoring of data modification status to determine the path of the modified data;

[0151] Side effect recycling is performed based on the path and dependency graph of the modified data, and also based on the component instance and dependency graph.

[0152] Specifically, the storage medium can be a computer-readable storage medium, which can be an electronic storage device such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM.

[0153] Optionally, the refined and extended functions of the program can be found in the description of the side effect recovery method in the method embodiments.

[0154] Furthermore, the functional modules in the various embodiments of this disclosure can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part. If the function is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a live streaming device, or a network device, etc.) to execute all or part of the steps of the methods in the various embodiments of this disclosure.

[0155] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0156] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0157] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method of recovering by-products, characterized by, The application comprises: When the side effect function is created, determine the component instance to which the side effect function belongs; Real-time monitoring of the execution state of the side effect function, and marking the side effect function as a current active side effect before monitoring the start of the execution of the side effect function; During the execution of the current active side effect, a dependency graph corresponding to the current active side effect is established; Real-time monitoring of the data modification state to determine the path of the modified data; Based on the path of the modified data and the dependency graph, side effect recovery is performed, and based on the component instance and the dependency graph, side effect recovery is performed.

2. The method of claim 1, wherein, When the side effect function is created, the component instance to which the side effect function belongs is determined, comprising: When the side effect function is created, the side effect registration API is rewritten through the framework; Assign a unique identifier to the side effect function; Record each piece of metadata of the side effect function; Determine the component instance to which the side effect function belongs from each piece of metadata.

3. The method of claim 1, wherein, During the execution of the current active side effect, a dependency graph corresponding to the current active side effect is established, comprising: During the execution of the current active side effect, intercept any read operation on reactive data to determine each path chain; For each path chain, determine each node on the path chain; A dependency edge is established between the current active side effect and each node; Based on the current active side effect, each node, and each dependency edge, a dependency graph is established.

4. The method of any one of claims 1, wherein, Based on the path of the modified data and the dependency graph, side effect recovery is performed, comprising: Determine whether the path of the modified data has a corresponding sub-path; If yes, the path of the modified data and the sub-path are both used as target paths; For each target path, the target path is compared with the dependency graph to determine each node contained in the target path in the dependency graph as each first node; Based on each first node, determine invalid dependency edges in the dependency graph; Remove the invalid dependency edges from the dependency graph.

5. The method of claim 4, wherein, Based on each first node, determine invalid dependency edges in the dependency graph, comprising: For each first node, find a side effect function that directly depends on the first node in the dependency graph as a first function; Add the first function to a pre-set execution queue; Real-time monitoring of the execution process of the execution queue for a preset number of times, the path set accessed by the first function; Compare the path set with the dependency graph to identify dependency edges in the dependency graph that are not included in the path set as invalid dependency edges.

6. The method of claim 1, wherein, Based on the component instance and the dependency graph, side effect recovery is performed, comprising: Establish a bidirectional association between the component instance and the side effect function; When the component instance is destroyed, find all side effects belonging to the component instance according to the bidirectional association; Stop the response data and execution process of the side effect; deleting each dependency edge associated with the side effect in the dependency graph.

7. The method according to any one of claims 1 to 6, characterized in that, Before the side effect recovery based on the path and the dependency graph of the modified data, the method further comprises: when there are multiple side effect functions, determining the business scenario of each side effect function; based on the business scenario, sorting each side effect function according to a pre-set priority rule; defining performance sensitive rules and resource optimization rules; according to the performance sensitive rules and / or resource optimization rules, performing subsequent side effect recovery operations in the order of the sorting.

8. A side effect recovery apparatus characterized by comprising: comprises: a component instance determination module, configured to determine a component instance to which a side effect function belongs when the side effect function is created; a marking module, configured to monitor the execution state of a side effect function in real time, and mark the side effect function as a current active side effect when it is monitored that the side effect function starts to execute; a dependency graph establishment module, configured to establish a dependency graph corresponding to the current active side effect during the execution process of the current active side effect; a path determination module, configured to monitor the data modification state in real time, and determine the path of the modified data; a side effect recovery module, configured to perform side effect recovery based on the path and the dependency graph of the modified data, and perform side effect recovery based on the component instance and the dependency graph.

9. A side effect recovery apparatus characterized by comprising: comprises a memory and a processor; the memory is used to store a program; the processor is used to execute the program, and realize each step of the side effect recovery method according to any one of claims 1-7.

10. A storage medium having stored thereon a computer program, characterized in that the computer program is executed by the processor, and realizes each step of the side effect recovery method according to any one of claims 1-7.

Images