State processing methods and apparatus, electronic device, and computer program product

Abstract

The present application relates to the technical field of cloud computing. Particularly disclosed are state processing methods and apparatus, an electronic device, and a computer program product. A method comprises: detecting a state change of a first device, the first device sharing resources of a shared device with other devices; in response to the state change, configuring a recovery timer for the first device, and controlling a second device among the other devices to be converted from a dormant state to a running state; and when it is detected that the recovery timer has expired, controlling the second device to be converted into the dormant state, and controlling the first device to recover to the running state. The present application solves the technical problem that when a certain device enters a dormant state, other devices occupy resources of a shared device, and thus said device may fail to be awakened and cannot work normally.

Description

[0001] TECHNICAL FIELD This application relates to the field of cloud computing technology, and more specifically, to a state processing method, apparatus, electronic device, and computer program product. Background: In cloud computing, multiple devices may share the resources of a shared device, thereby achieving efficient resource utilization and reducing costs. However, when multiple devices access a shared device in a time-sharing manner to share resources, if a device currently using the shared device's resources enters a dormant state while running a process to reduce energy consumption, directly revoking the device's access to the shared device's resources and restricting other devices from using the shared device's resources may cause the other devices to continue running, while the device itself cannot be awakened and continue running the process. Currently, no effective solution has been proposed to address this issue. SUMMARY OF THE INVENTION The present application provides a state processing method, apparatus, electronic device, and computer program product to at least address the technical issue in related technologies where it is difficult for users to configure server requirements according to their needs. According to one aspect of an embodiment of the present application, a state processing method is provided, comprising: detecting a state change of a first device, wherein the state change is exiting from a running state to a dormant state, and the first device shares resources of a shared device with other devices; in response to the state change, setting a recovery timer for the first device, and controlling a second device among the other devices to transition from the dormant state to a running state; and upon detecting expiration of the recovery timer, controlling the second device to transition from the running state to the dormant state, and controlling the first device to resume from the dormant state to the running state. According to another aspect of an embodiment of the present application, a state processing method is further provided, comprising: detecting a state change caused by a first virtual instance executing a dormant instruction, wherein the state change is exiting from a running state to a dormant state, and the first virtual instance shares resources of a physical instance with other virtual instances; in response to the state change, setting a recovery timer for the first virtual instance, and controlling a second virtual instance among the other virtual instances to transition from the dormant state to the running state; upon detecting expiration of the recovery timer, controlling the second virtual instance to transition from the running state to the dormant state, and controlling the first virtual instance to resume from the dormant state to the running state.According to another aspect of an embodiment of the present application, a state processing apparatus is provided, comprising: a detection module configured to detect a state change of a first device, wherein the state change is an exit from a running state to a dormant state, and the first device shares resources of a shared device with other devices; a first control module configured to, in response to the state change, set a recovery timer for the first device and control a second device among the other devices to transition from the dormant state to a running state; and a second control module configured to, upon detecting expiration of the recovery timer, control the second device to transition from the running state to the dormant state and control the first device to resume from the dormant state to the running state. According to another aspect of an embodiment of the present application, an electronic device is provided, comprising: a memory storing an executable program; and a processor configured to execute the program, wherein, when the program is executed, the state processing method according to various embodiments of the present application is executed. According to another aspect of an embodiment of the present application, a computer-readable storage medium is provided, wherein the computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, the device containing the computer-readable storage medium is controlled to execute the state processing method according to various embodiments of the present application. According to another aspect of the present application, a computer program product is provided, comprising a computer program. When executed by a processor, the computer program implements the state processing method described in various embodiments of the present application. In this embodiment, the use rights of a shared device during the period when a first device is dormant are transferred to a second device, and a timer is set to promptly wake up the first device and re-enter the running state. Upon detecting a state change of the first device, where the state change is from a running state to a dormant state, the first device shares the resources of a shared device with other devices. In response to the state change, a recovery timer is set for the first device, and a second device among the other devices is controlled to transition from a dormant state to a running state. Upon detecting expiration of the recovery timer, the second device is controlled to transition from a running state to a dormant state, and the first device is controlled to resume from a dormant state to a running state. This achieves the goal of fully utilizing the resources of the shared device while the first device is dormant, while ensuring that the first device can be woken up and resumed running. This achieves the technical effect of improving the utilization efficiency of shared device resources and further solves the technical problem in related technologies of the difficulty for users to configure server requirements according to their own needs. It should be noted that the general description above and the detailed description below are merely for the purpose of exemplifying and explaining the present application and do not constitute a limitation of the present application. BRIEF DESCRIPTION OF THE DRAWINGS The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application.In the accompanying drawings: Figure 1 shows a hardware block diagram of a computer terminal (or mobile device) for implementing a state processing method; Figure 2 shows a block diagram of a computing environment; Figure 3 shows a block diagram of a service grid; Figure 4 is a schematic diagram of a state processing method according to an embodiment of the present application; Figure 5 is a schematic diagram of another state processing method according to an embodiment of the present application; Figure 6 is a schematic diagram of a virtual central processing unit operating state change according to related art; Figure 7 is a schematic diagram of a virtual central processing unit operating state change according to an embodiment of the present application; Figure 8 is a block diagram of a state processing device according to an embodiment of the present application; Figure 9 is a block diagram of another state processing device according to an embodiment of the present application; and Figure 10 is a block diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION: To help those skilled in the art better understand the present invention, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the described embodiments are only some of the embodiments of the present application, and not all of them. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present application without inventive effort shall fall within the scope of protection of the present application. It should be noted that the terms "first," "second," and so on, in the specification and claims of this application, and in the accompanying drawings, are used to distinguish similar objects and are not necessarily used to describe a specific order or precedence. It should be understood that such terms are interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein. Furthermore, the terms "including," "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements is not necessarily limited to those steps or elements explicitly listed, but may include other steps or elements not explicitly listed or inherent to such process, method, product, or apparatus. First, some nouns or terms appearing in the description of the embodiments of this application are subject to the following interpretations: Central Processing Unit (CPU) includes a virtual central processing unit (VCU), which refers to a virtual processor created in a virtualized environment, simulated by virtualization software and provided to a virtual machine; and a physical central processing unit (CPU), which is the actual hardware processor, the actual CPU in a computer system.A virtual machine (VM) is a method of running underlying software, such as a computer operating system, in a simulated software environment. It can simulate multiple virtual machines on a single physical computer, enabling multi-user isolation and resource sharing. A hibernation state (Sleep) reduces energy consumption by using certain instructions to lower the CPU frequency and shut down unnecessary devices. Once a dormant CPU receives an instruction to exit the sleep state, it exits the low-power state and begins executing the next instruction. A hypervisor (Hypervisor) is the foundation of virtualization technology, responsible for managing the interaction between VMs and the physical computer.

[0002] CPU overscaling: When more than one virtual CPU runs simultaneously on the same physical CPU core, a scheduler is required to implement time-sharing multiplexing of the physical CPU core across multiple virtual CPUs. Virtual Machine Operating System: The guest operating system, or guest OS for short, is the operating system within the virtual machine, running in a software-emulated environment. Instruction leakage: The hypervisor allows the virtual machine's operating system to identify that the emulated CPU has certain instructions and can use them. If the virtual machine's operating system does not want to use an instruction, the hypervisor can block it. Virtual Machine Exit: This refers to the virtual machine's emulated CPU process (vcpu process, vcpu) exiting from guest OS mode to host (hypervisor) mode. In other words, it exits from virtual machine operating system control mode to hypervisor control mode. Example 1: According to an embodiment of the present application, a state processing method is provided. It should be noted that the steps shown in the flowcharts of the accompanying figures can be executed in a computer system, such as a set of computer-executable instructions. Although the flowcharts illustrate a logical order, in some cases, the steps shown or described may be executed in a different order than shown. The method embodiment provided in Example 1 of the present application can be executed in a mobile terminal, a computer terminal, or a similar computing device. Figure 1 shows a hardware block diagram of a computer terminal (or mobile device) for implementing the state processing method. As shown in Figure 1 , the computer terminal 10 (or mobile device) may include one or more processors 102 (illustrated as 102a, 102b, ..., 102n) (processor 102 may include, but is not limited to, a microprocessor (MCU) or a programmable logic device (FPGA), a processing device), a memory 104 for storing data, and a transmission module 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a Universal Serial Bus (USB) port (which may be included as one of the ports of a BUS), a network interface, a power supply, and / or a camera. Those skilled in the art will appreciate that the structure shown in Figure 1 is merely illustrative and does not limit the structure of the electronic device described above. For example, the computer terminal 10 may include more or fewer components than shown in Figure 1 , or have a configuration different from that shown in Figure 1 .It should be noted that the one or more processors 102 and / or other data processing circuits described above may generally be referred to herein as "data processing circuitry." This data processing circuitry may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuitry may be a single, independent processing module, or may be fully or partially integrated into any of the other components of the computer terminal 10 (or mobile device). As described in the embodiments of the present application, the data processing circuitry functions as a processor control (e.g., selecting a path for a variable resistor terminal connected to an interface). Memory 104 may be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the methods in the embodiments of the present application. Processor 102 executes the software programs and modules stored in memory 104 to perform various functional applications and data processing, thereby implementing the methods in the embodiments described above. Memory 104 may include high-speed random access memory (RAM) and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, memory 104 may further include memory remotely located from processor 102, which may be connected to computer terminal 10 via a network. Examples of the aforementioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof. Transmission device 106 is used to receive or transmit data via a network. Specific examples of the aforementioned network may include a wireless network provided by the communications provider of computer terminal 10. In one example, transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In one example, transmission device 106 may be a radio frequency (RF) module for wireless communication with the Internet. The display may be, for example, a touchscreen liquid crystal display (LCD), which enables a user to interact with the user interface of computer terminal 10 (or mobile device). The hardware structure block diagram shown in FIG1 can serve not only as an exemplary block diagram of the aforementioned computer terminal 10 (or mobile device), but also as an exemplary block diagram of the aforementioned server. In an optional embodiment, FIG2 shows a block diagram of an embodiment using the computer terminal 10 (or mobile device) shown in FIG1 as a computing node in computing environment 201.Figure 2 shows a block diagram of a computing environment. As shown in Figure 2 , computing environment 201 includes multiple computing nodes (e.g., servers) (illustrated as 210-1 through 210-2) running on a distributed network. Each computing node contains local processing and memory resources, allowing end users 202 to remotely run applications or store data in computing environment 201. Applications can be provided as multiple services 220-1, 220-2, 220-3, and 220-4 in computing environment 201, representing services "A," "D," "E," and "H," respectively. End users 202 can provision and access services through a web browser or other software application on a client. In some embodiments, end users 202's provisioning and / or requests can be provided to an ingress gateway 230. Ingress gateway 230 can include a corresponding agent to handle provisioning and / or requests for services (one or more services provided in computing environment 201). Services are provided or deployed based on various virtualization technologies supported by computing environment 201. In some embodiments, services can be provided using virtual machine (VM)-based virtualization, container-based virtualization, and / or similar approaches. VM-based virtualization can simulate a real computer by initializing a virtual machine, executing programs and applications without directly accessing any actual hardware resources. While VMs virtualize machines, container-based virtualization can launch containers to virtualize the entire operating system (OS), allowing multiple workloads to run on a single OS instance. In one embodiment of container-based virtualization, several service containers can be assembled into a pod (e.g., a Kubernetes pod). For example, as shown in Figure 2, service 220-2 can be configured with one or more pods 240-1, 240-2, and 240-N (collectively, pods). A pod can include a proxy 245 and one or more containers.

[0003] 242-1, 242-2, and 242-M (collectively referred to as containers). One or more containers in a pod process requests related to one or more corresponding functions of a service. Proxy 245 typically controls network functions related to the service, such as routing and load balancing. Other services may also be equipped with similar pods. During operation, executing a user request from end user 202 may require invoking one or more services in computing environment 201. Executing one or more functions of one service may require invoking one or more functions of another service. As shown in Figure 2, service "A" 220-1 receives a user request from end user 202 from ingress gateway 230. Service "A" 220-1 may invoke service "D" 220-2, and service "D" 220-2 may request service "E" 220-3 to execute one or more functions. The computing environment described above may be a cloud computing environment, where resource allocation is managed by the cloud service provider, allowing for feature development without having to worry about implementing, adjusting, or scaling servers. This computing environment allows developers to execute code in response to events without building or maintaining complex infrastructure. Instead of expanding a single hardware device to handle potential load, services can be partitioned to complete a set of functions that can be automatically and independently scaled. In another optional embodiment, FIG3 shows a block diagram of an embodiment using the computer terminal 10 (or mobile device) shown in FIG1 as a service grid. FIG3 shows a structural block diagram of a service grid. As shown in FIG3 , the service grid 300 is primarily used to facilitate secure and reliable communication between multiple microservices. Microservices refer to the decomposition of an application into multiple smaller services or instances, which are distributed and run on different clusters / machines. As shown in FIG3 , microservices may include application service instance A and application service instance B. Application service instance A and application service instance B form the functional application layer of service grid 300. In one embodiment, application service instance A runs as a container / process 308 on a machine / workload container group 314 (Pod), and application service instance B runs as a container / process 310 on a machine / workload container group 316 (Pod). oIn one embodiment, application service instance A may be a product query service, and application service instance B may be a product ordering service. As shown in Figure 3, application service instance A and grid proxy (sidecar) 303 coexist in machine workload container group 314, while application service instance B and grid proxy 305 coexist in machine workload container 316. Grid proxy 303 and grid proxy 305 form the data plane layer of service grid 300. Grid proxy 303 and grid proxy 305 run as container / process 304 and container / process 306, respectively, and can receive requests 312 for performing product query services. Bidirectional communication is possible between grid proxy 303 and application service instance A, and between grid proxy 305 and application service instance B. Furthermore, bidirectional communication is possible between grid proxy 303 and grid proxy 305. In one embodiment, all traffic from application service instance A is routed to the appropriate destination via mesh proxy 303, while all network traffic from application service instance B is routed to the appropriate destination via mesh proxy 305. It should be noted that the network traffic mentioned herein includes, but is not limited to, Hypertext Transfer Protocol (HTTP), Representational State Transfer (REST), the high-performance, general-purpose open source framework (Google Remote Procedure Call, gRPC), and the open source in-memory data structure storage system (Redis). In one embodiment, the functionality of the extended data plane layer can be implemented by writing custom filters for the proxy (Envoy) in service mesh 300. Service mesh proxy configuration can be used to enable the service mesh to correctly proxy service traffic, thereby achieving service interoperability and service governance. Grid proxy 303 and grid proxy 305 can be configured to perform at least one of the following functions: service discovery, health checking, routing, load balancing, authentication and authorization, and observability. As shown in FIG3 , service grid 300 also includes a control plane layer.The control plane layer can be comprised of a set of services running in a dedicated namespace. These services are hosted by a managed control plane component 301 within a machine / workload container group (machine / pod) 302. As shown in Figure 3, managed control plane component 301 communicates bidirectionally with grid agent 303 and grid agent 305. Managed control plane component 301 is configured to perform certain control and management functions. For example, managed control plane component 301 receives telemetry data transmitted by grid agent 303 and grid agent 305 and can further aggregate this telemetry data. Managed control plane component 301 can also provide user-oriented application programming interfaces (APIs) for these services, making it easier to manipulate network behavior and provide configuration data to grid agent 303 and grid agent 305. In a cloud computing environment, multiple devices can share the resources of a shared device. A related control system can be configured within the shared device to control the time-sharing utilization of the shared device's resources by multiple devices, thereby achieving efficient resource utilization and reducing costs. However, when multiple devices time-share access to shared device resources, problems may arise. For example, if a device enters a dormant state while running a process, simply revoking its access rights to shared device resources could cause other devices to continue running, while the device itself cannot be awakened and resume running the process. In cloud computing, efficient resource utilization is crucial, as wasted resources increase costs and impact performance. Therefore, to reduce energy consumption, devices may enter a dormant state. However, when a device enters a dormant state, access rights to shared device resources should be appropriately transferred. A resource management system within the shared device can monitor the device's status and automatically adjust resource allocation as needed. When a device enters a dormant state, the resource management system can automatically reclaim its access rights to shared device resources. Furthermore, the system can wake up other devices as needed and transfer access rights to the awakened devices, enabling them to operate normally.It should be noted that when the resource management system switches access to shared device resources between two devices, if the first device enters a dormant state while still having running processes, it may pause most other processes and enter a dormant state to save energy, waiting for the final results of the running processes. However, after the access to the shared device resources is transferred to the second device, the second device may continue to operate normally for a long time, resulting in the inability to return the access to the shared device resources to the first device in a timely manner. Consequently, the first device cannot be awakened and resume normal process operation. To address this issue, in the aforementioned operating environment, the present application provides a state processing method as shown in FIG4 . FIG4 is a schematic diagram of a state processing method according to an embodiment of the present application. In step S40L, a state change of the first device is detected, where the state change is from an operating state to a dormant state. The first device shares the resources of a shared device with other devices. This step is performed by the resource management system for controlling the resources of the shared device. The resource management system can monitor the operating status of devices capable of interacting with the shared device in real time. The first device may be the device currently enjoying access to the resources of the shared device. When the resource management system detects that the first device has transitioned from a running state to a dormant state, step S402 is executed. It should be noted that the state change of the first device here may not mean that the entire first device enters a standby state, but rather that a process within the first device that is accessing a portion of the shared device enters a dormant state. For example, the first device may interact normally with the user, but a background process may utilize server resources for computation. The background process that utilizes server resources for computation is the process accessing the shared device. In this case, the transition of the first device from a running state to a dormant state does not mean that the entire first device enters a dormant state and ceases to interact with the user. Instead, the background process within the first device that utilizes server resources for computation enters a dormant state. In step S402, in response to the state change, a recovery timer is set for the first device and a second device among the other devices is controlled to transition from a dormant state to a running state. In this step, after detecting that the first device has entered a dormant state, the resource management system may set a recovery timer for the first device and record the duration of the first device's dormant state. While setting the recovery timer, the resource management system can control the second device among the other devices to transition from a dormant state to an active state to ensure full utilization of the shared device's resources. After the recovery timer expires, the resource management system can execute step S403. The other devices are devices that can interact with the shared device, i.e., all devices that share the shared device's resources with the first device.The second device can be any other device, or any other device that meets certain conditions. Setting a corresponding recovery timer for the first device ensures that the first device has the opportunity to wake up and resume its running state, allowing it to execute instructions issued to the first device or run processes on the first device normally. Step S403: Upon detecting expiration of the recovery timer, the resource management system controls the second device to transition from a running state to a dormant state and controls the first device to resume its running state from a dormant state. In this step, upon detecting expiration of the recovery timer, the resource management system controls the second device to transition from a running state to a dormant state and controls the first device to resume its running state from a dormant state. In other words, the resource management system transfers the use rights of the physical CPU from the second device to the first device. Through the above steps, by transferring the use rights of the shared device to the second device during the first device's dormant period and setting a timer to promptly wake the first device back into operation, the computing power of the shared device is fully utilized while the first device is dormant, while ensuring that the first device can be woken up and resumed operation. This achieves the technical effect of improving the utilization efficiency of the shared device and further resolves the technical problem in related technologies that makes it difficult for users to configure server requirements based on their own needs. Since the duration of the recovery timer determines the dormant period of the first device and when it can be woken up and resumed operation, the setting of the recovery timer duration is very important. If the timer duration is set too short, only a short operating time is provided to the second device. After resuming normal operation, the first device will still have to remain in a low-power state waiting for processes to run, thus wasting some computing power. However, if the timer duration is set too long, the first device will be unable to resume normal operation for a long time, delaying the normal execution of instructions by the first device. Optionally, the recovery timer duration can be a pre-set fixed time interval. Regardless of the differences between the devices, the resource management system uniformly uses this fixed time interval to set the recovery timer when switching resource usage rights of a shared device between any two devices. However, a fixed time interval is relatively rigid and inflexible. In some cases, the fixed time interval may be too short, while in other cases, it may be too long. Therefore, the recovery timer duration can be dynamically adjusted based on the actual conditions of the two devices being adjusted (i.e., the first device and the second device) to obtain a more appropriate duration for the current handover. This application provides the following embodiments for dynamically setting the recovery timer duration based on the actual conditions of the first and second devices.As an optional embodiment, setting a recovery timer for a first device in response to a state change includes: obtaining a first priority level for the first device and a second priority level for the second device; and setting a recovery timer and a timer duration for the first device based on the first priority level and / or the second priority level. Alternatively, the first priority level for the first device and the second priority level for the second device may be obtained, and the recovery timer duration may be set based solely on the first priority level or the second priority level. Different priorities may result in different recovery timer durations. Alternatively, the first and second priorities may be considered together, a mathematical operation may be performed on the values ​​of the first and second priorities, and the recovery timer duration may be dynamically set based on the different operation results. The device operation priority may be pre-set. A higher priority may be assigned to devices running more important tasks, tasks running with faster response times, or devices with higher user permissions. In summary, the device operation priority may determine the priority with which the resource management system allocates shared device resources to the devices. As an optional embodiment, setting a recovery timer duration for the first device based on the first priority or the second priority includes: setting a recovery timer for the first device; obtaining a correspondence between priority and timer duration; determining the timer duration corresponding to the first priority as the recovery timer duration; or determining the timer duration corresponding to the second priority as the recovery timer duration. Optionally, the first priority may be considered alone when setting the recovery timer duration. When resource usage rights of a shared device are transferred from the first device to the second device, the first priority may be considered as the primary consideration, and the timer duration may be set based solely on the first priority. Furthermore, the correspondence between priority and timer duration should be inversely proportional, i.e., the higher the priority, the shorter the timer duration. In this case, when the first device has a higher priority, the shorter the sleep time of the first device, which better ensures normal operation of the first device. When the first device has a lower priority, the sleep time of the first device may be longer, providing more time for other devices to operate. Similarly, the second priority may be considered alone when setting the recovery timer duration. When the resource usage rights of the shared device are switched from the first device to the second device, whether the second device has sufficient uptime may be the primary consideration, and the timing duration may be set only based on the second priority. In addition, the correspondence between the priority and the timing duration should be in direct proportion, that is, the higher the priority, the longer the timing duration.In this case, when the second device has a higher priority, a longer sleep time for the first device ensures sufficient time for the second device to operate normally. When the second device has a lower priority, the sleep time for the first device can be shorter. As an optional embodiment, setting a recovery timer and setting a timer duration for the first device based on the first and second priorities includes: setting a recovery timer for the first device; determining a ratio between the priority value corresponding to the second priority and the priority value corresponding to the first priority; and setting a timer duration for the recovery timer for the first device based on the ratio and a preset unit duration. Alternatively, a preferred solution is to comprehensively consider the first and second priorities when setting the timer duration for the recovery timer for the first device. If a higher priority value indicates a more important device, a ratio between the second priority value and the first priority value can be determined, and the timer duration for the recovery timer for the first device can be set based on the ratio and the preset unit duration. For example, the ratio can be applied to a preset exponential function, where the base of the preset exponential function can be the preset unit duration, and the output value of the exponential function can be the timer duration for the recovery timer. As an optional embodiment, setting a recovery timer duration for the first device based on the ratio and a preset unit duration includes determining the product of the ratio and the preset unit duration as the recovery timer duration. Alternatively, the product of the ratio and the preset unit duration may be directly used as the recovery timer duration. It should be noted that the ratio of the second priority value to the first priority value herein refers to a value obtained by using the first priority value as the numerator and the second priority value as the denominator. In other words, the above ratio is sequential.For example, the first priority value may be 2, and the second priority value may be 5. If a higher priority value indicates a more important device, the second device is more important than the first device. In this case, the ratio of the second priority value to the first priority value is 5 / 2 = 2.5. In this case, the recovery timer duration can be set to 2.5 times the preset unit duration. That is, the duration can be set longer, allowing the more important second device to have a longer operating time. Similarly, if the first priority value is 5 and the second priority value is 2, the first device is more important than the second device. In this case, the ratio is 2 / 5 = 0.4. The recovery timer duration can be set to 0.4 times the preset unit duration. That is, the duration can be set shorter, allowing the more important first device to be awakened in a timely manner. If the first and second priority values ​​are equal, the ratio is 1, and the recovery timer duration can be directly set to the preset unit duration. Using the above optional embodiments, a more appropriate duration can be set for the recovery timer based on the actual conditions of the first and second devices, taking into account the values ​​of the first and second priorities. It should be noted that the above two optional embodiments only provide a division-based approach. The second priority value can be divided by the first priority value to obtain a ratio, which is then used to set the recovery timer duration. Similarly, a subtraction-based approach can be adopted, where the second priority value is subtracted from the first priority value to obtain the absolute value of the difference. The recovery timer duration is then set based on this absolute value and a preset unit duration. Specifically, the first and second priorities can be compared. If the first priority is higher than the second priority, ensuring the normal operation of the first device should be the primary consideration. In other words, the sleep timer of the first device should be set shorter. Since the preset unit duration is a fixed value, the absolute value of the difference is generally a natural number greater than 1. To obtain a smaller value, the reciprocal of the difference can be multiplied by the preset unit duration, and the resulting product can be set as the recovery timer duration. If the first priority is higher than the second priority, ensuring the normal operation of the second device should be the primary consideration. In other words, the sleep timer for the first device should be set longer. In this case, the difference can be directly multiplied by the preset unit duration, and the resulting product can be set as the duration of the recovery timer. If the difference is 1, it indicates that the difference between the first and second priorities is not significant, and the preset unit duration can also be directly used as the duration of the recovery timer.When the first priority is equal to the second priority, a preset unit duration can also be directly used as the recovery timer duration. The preset unit duration can be a pre-set average duration that is suitable for most situations. It should be noted that the above optional embodiment only provides an optional method for setting the recovery timer duration based on the absolute value of the priority difference. When dynamically setting the recovery timer duration based on specific circumstances, it is also possible to pre-determine the possible priority differences based on the respective priorities of all devices. In this case, the priority difference can be a fixed value obtained by subtracting the second priority from the first priority, that is, the priority difference can be a negative number. Then, corresponding durations can be set for all possible priority differences. In actual applications, the duration corresponding to the priority difference can be directly found and used as the recovery timer duration. The above optional embodiment shows that when determining the recovery timer duration based on the operating priority of each device, priority is an important factor in determining the recovery timer duration. In other words, how to determine the operating priority of each device is also important. This application also provides the following optional embodiments for determining the operating priority of each device. In an optional embodiment, the first priority is determined based on a process being run by the first device, and / or the second priority is determined based on a process being run by a second device. Alternatively, all devices have ongoing processes, and the priority of a device can be determined based on the processes being run. If the ongoing process on the device is important, then the corresponding device is also important, and its priority should be higher, requiring more runtime. If the ongoing process on the device is less important, then the priority of the corresponding device can be appropriately lowered so that it does not occupy a lot of runtime. In an optional embodiment, determining the first priority based on a process being run by the first device includes: determining the type of a first process being run by the first device; determining the priority corresponding to the first process type as the first priority; or determining a first response time required for the process being run by the first device; and determining the priority corresponding to the first response time as the first priority. In an optional embodiment, determining the second priority based on a process being run by the second device includes: determining the type of a second process being run by the second device; determining the priority corresponding to the second process type as the second priority; or determining a second response time required for the process being run by the second device; and determining the priority corresponding to the second response time as the second priority. Alternatively, the priority of a device can be determined based on the process type.Process types include the following: User processes: These are processes created by user-initiated programs or services. These processes typically perform user tasks, such as applications, desktop programs, and network services. System processes: These are processes created by the operating system kernel or system services. These processes perform system-level tasks, such as device drivers, system daemons, and memory management. Because system processes perform system-level tasks, they can be assigned a higher priority, while other processes can be assigned a lower priority. Device priorities can also be determined based on the required response time of the process. Processes that run automatically without direct user intervention are typically used to process large amounts of data or perform a series of automated tasks. These processes typically require longer response times, so they can be assigned a lower priority. There are also processes that are directly controlled or interacted with by the user, such as terminal sessions or graphical user interface applications. These processes require slightly shorter response times. Finally, there are processes that run under strict time constraints, typically used in systems that require real-time responses, such as control systems and real-time communications. These processes require even shorter response times, so they can be assigned a higher priority. The priority of a process can also be determined by comprehensively considering the process type and the required response time. For example, a batch process automatically executed within a system process may have a lower priority than other system processes, while a process requiring real-time response within the system process may have a higher priority. It should be noted that the above optional embodiments merely provide specific methods for determining device priorities. In specific scenarios, the operating priorities of individual devices can also be dynamically adjusted based on actual circumstances. For example, if a device does not receive sufficient execution time for an extended period, its priority can be temporarily increased. As an optional embodiment, controlling a second device among other devices to transition from a dormant state to an operational state includes: obtaining the operating priorities of the other devices; selecting the device with the highest priority among the other devices as the second device; and controlling the second device to transition from a dormant state to an operational state. Optionally, the priorities of the devices may also be considered when selecting the second device from the other devices. Specifically, the operating priorities of the other devices may be obtained, sorted, and the device with the highest priority selected as the second device. Controlling the second device to transition from a dormant state to an operational state ensures that the higher-priority device receives more runtime time.As an optional embodiment, controlling a second device among other devices to transition from a dormant state to an active state includes: determining devices among the other devices that have pending tasks; estimating the task duration required for the devices with pending tasks to complete the pending tasks; identifying a second device based on the task durations corresponding to the devices with pending tasks and the duration of a recovery timer; and controlling the second device to transition from a dormant state to an active state. Alternatively, the resource management system may determine the pending tasks among the other devices and estimate the task durations required for the devices with pending tasks to complete the pending tasks. The task durations corresponding to the devices with pending tasks and the duration of the recovery timer may be compared to select the device with a more appropriate task duration as the second device and transition the second device from a dormant state to an active state. This ensures that the processing of the second device can be completed to the greatest extent possible without affecting the expiration of the recovery timer. In an optional embodiment, determining a second device based on the task durations and recovery timer durations corresponding to devices with pending tasks includes: selecting a target device with a task duration less than the timer duration from the devices with pending tasks; if there are multiple target devices, obtaining the priorities of each of the multiple target devices; and selecting the device with the highest priority among the multiple target devices as the second device. Alternatively, a target device with a recovery duration less than the timer duration may be selected, and if there are multiple target devices, the device with the highest priority may be selected as the second device. In an optional embodiment, the first device is a first virtual central processing unit (CPU), the second device is a second virtual CPU, and the shared device is a physical CPU. Alternatively, the device may be any physical computer, and the shared device may be a server; the device may also be a virtual machine, and the shared device may also be a server. This application provides a specific embodiment in which the device may be a virtual CPU, the shared device may be a physical CPU, and the multiple virtual CPUs share resources of the physical CPU. At this point, the hypervisor, which controls the interaction between the virtual CPUs and the physical CPU, can monitor the operating status of the virtual CPUs that can interact with the physical CPU in real time and execute any of the aforementioned methods to control the first virtual CPU to relinquish access to the physical CPU's resources and control the second virtual CPU to receive access to the physical CPU's resources. Based on the duration of the restoration timer, the first virtual CPU's access to the physical CPU's resources is restored, thereby fully utilizing the computing power of the physical CPU and ensuring that the first virtual CPU can be awakened and function normally.In the related art, software emulation of underlying software, such as a computer operating system, is used on a physical machine to enable the time-sharing operation of multiple virtual instances on a single physical instance. The instructions and computing tasks of the virtual instances are mapped to the physical instance for execution. This allows multiple virtual instances to share the resources of the same physical instance, achieving efficient resource utilization and isolation. In the related art, when a virtual instance exits the running state and enters the dormant state, the resource management system in the physical instance may awaken the virtual instance and re-enter the running state, causing the virtual instance to re-enter the dormant state, causing the physical instance to continue idling and wasting computing power. The resource management system in the physical instance may also directly remove the virtual instance's access to the physical instance's resources, forcing other virtual instances to occupy the physical instance for computation, preventing the previous virtual instance from awakening and functioning properly. To this end, in the aforementioned operating environment, the present application provides a state processing method as shown in Figure 5. Figure 5 is a schematic diagram of another state processing method according to an embodiment of the present application. It should be noted that the first device mentioned above may be the first virtual instance, the second device mentioned above may be the second virtual instance, and the shared device mentioned above may be the physical instance. Step S50L detects a state change caused by the first virtual instance executing a hibernation instruction, where the state change is from a running state to a hibernation state. The first virtual instance shares the resources of a physical instance with other virtual instances. This step is performed by a hypervisor that controls the interaction between the physical instance and the virtual instances. The hypervisor can detect the running state of virtual instances that can interact with the physical instance in real time. The first virtual instance may be the virtual instance that currently controls the resources of the physical instance. Receiving a hibernation instruction causes it to exit from a running state to a hibernation state. When the hypervisor detects that the first virtual instance has exited from a running state to a hibernation state, step S502 is executed. In step S502, in response to the state change, a recovery timer is set for the first virtual instance and a second virtual instance among the other virtual instances is controlled to transition from a hibernation state to a running state. In this step, after detecting that the first virtual instance has entered a hibernation state, the hypervisor can set a recovery timer for the first virtual instance and record the hibernation time of the first virtual instance. While setting the recovery timer, the hypervisor may control the second virtual instance in the other virtual instances to switch from the dormant state to the running state in order to ensure that the resources of the physical instance are fully utilized.After the recovery timer expires, the hypervisor may execute step S503. Other virtual instances are virtual instances that can interact with the physical instance, that is, all virtual instances that share the physical instance's resources with the first virtual instance. The second virtual instance can be any one of the other virtual instances, or a virtual instance that meets certain conditions. Setting a corresponding recovery timer for the first virtual instance ensures that the first virtual instance has an opportunity to wake up and resume its running state, allowing it to execute instructions issued to it normally. In step S503, upon detecting expiration of the recovery timer, the hypervisor controls the second virtual instance to transition from a running state to a dormant state, and controls the first virtual instance to resume its running state from a dormant state. In this step, upon detecting expiration of the recovery timer, the hypervisor controls the second virtual instance to transition from a running state to a dormant state, and controls the first virtual instance to resume its running state from a dormant state. In other words, the hypervisor transfers the use rights of the physical instance from the second virtual instance to the first virtual instance. It should be noted that in the above steps, a sleep function can be used to control the state transition of a virtual instance. When the virtual instance transitions from the running state to the dormant state, the sleep function of the virtual instance is marked as sleeping, and the sleep function of the virtual instance is marked as waking, thereby transitioning the virtual instance from the dormant state to the running state. Through the above steps, by transferring the use rights of the physical instance to the second virtual instance during the dormant period of the first virtual instance and setting a timer to promptly wake up the first virtual instance and re-enter the running state, the computing power of the physical instance is fully utilized while the first virtual instance is dormant, while ensuring that the first virtual instance can be woken up and resumed running. This achieves the technical effect of improving the utilization efficiency of the physical instance. This further solves the technical problem of the virtual machine management software repeatedly waking up the virtual instance to re-enter the running state after it enters the dormant state, causing the physical instance to idle and waste computing power. It also solves the technical problem of a virtual instance entering the dormant state and other virtual instances occupying the physical instance's resources, resulting in the previous virtual instance being unable to wake up and operate normally. The duration of the recovery timer determines the sleep duration of the first virtual instance and when it can be awakened and resumed. Therefore, setting the recovery timer duration is crucial. If the duration is too short, the second virtual instance will only have a short run time, and resource access to the physical instance will be frequently switched, wasting computing power. However, if the duration is too long, the first virtual instance will be unable to resume normal operation, hindering its normal execution of instructions.Optionally, the recovery timer duration can be a pre-set fixed time interval. Regardless of the differences between virtual instances, the hypervisor uniformly uses this fixed time interval to set the recovery timer when switching resource usage rights of a physical instance between any two virtual instances among all virtual instances. However, a fixed time interval can be rigid and inflexible. In some cases, the fixed time interval may be too short, while in other cases, it may be too long. Therefore, the recovery timer duration can be dynamically adjusted based on the actual conditions of the two virtual instances being adjusted (i.e., the first virtual instance and the second virtual instance) to obtain a more appropriate duration for the current switch. This application provides the following embodiments for dynamically setting the recovery timer duration based on the actual conditions of the first and second virtual instances. As an optional embodiment, setting a recovery timer for the first virtual instance in response to a state change includes: obtaining a first priority level of the first virtual instance and a second priority level of the second virtual instance; and setting a recovery timer and a duration for the first virtual instance based on the first priority level and / or the second priority level. Optionally, the first priority of the first virtual instance and the second priority of the second virtual instance can be obtained. The recovery timer duration can be set based on either the first priority or the second priority alone. Different priorities result in different recovery timer durations. Alternatively, the first and second priorities can be considered together, a mathematical operation performed on the values ​​of the first and second priorities, and the recovery timer duration can be dynamically set based on the different operation results. The priority of the virtual instance can be pre-set. A higher priority can be assigned to a virtual instance running a task that is more important to the entire virtual operating system, or a higher priority can be assigned to a virtual instance running a task requiring faster response time. In short, the priority of the virtual instance can determine the priority with which the hypervisor allocates physical instance resources to the virtual instance. Alternatively, the method for determining the recovery timer duration of a first device based on the first priority of the first device and the second priority of the second device can be referred to above to set the recovery timer duration of the first virtual instance based on the first priority of the first virtual instance and the second priority of the second virtual instance. For example, a mathematical calculation such as subtraction, division or addition may be performed on the values ​​of the first priority and the second priority, and then combined with a preset unit time length to determine the timing duration of the recovery timer.The first priority can be determined based on the type of process or the response time of the process in the first virtual instance. Similarly, the second priority can be determined based on the type of process or the response time of the process in the second virtual instance. As an optional embodiment, controlling a second virtual instance among other virtual instances to transition from a dormant state to a running state includes: determining virtual instances among the other virtual instances that have pending tasks; estimating the task duration required for the virtual instances with pending tasks to complete the pending tasks; determining a second virtual instance based on the task durations and the duration of a recovery timer corresponding to the virtual instances with pending tasks; and controlling the second virtual instance to transition from a dormant state to a running state. Optionally, when selecting the second virtual instance from the other virtual instances, the priorities of the virtual instances can also be considered. Specifically, the running priorities of the other virtual instances can be obtained, sorted, and the virtual instance with the highest priority selected as the second virtual instance. Controlling the second virtual instance to transition from a dormant state to a running state ensures that the higher-priority virtual instance receives more running time. Alternatively, the method for determining the second device based on the respective priorities of other devices can be referred to above to determine the second virtual instance from the other virtual instances based on their respective operating priorities. For example, the virtual instances can be sorted from highest to lowest priority, with the highest priority virtual instance selected as the second virtual instance. Alternatively, the virtual instance with pending tasks can be identified as the target virtual instance from the other virtual priority levels, and the target virtual instance can be directly identified as the second virtual instance. Alternatively, the virtual instance with the highest priority among the target virtual instances can be identified as the second virtual instance. In an optional embodiment, the first virtual instance is the first virtual central processor, the other virtual instances are other virtual central processors, and the physical instance is the physical central processor. Alternatively, the virtual instance can be a virtual central processor, and the physical instance can be a physical central processor. A virtual central processing unit (VCPU) is a virtual processor created in a virtualized environment, simulated by virtualization software and provided to virtual machines. A physical central processing unit (CPU) is the actual hardware processor, the physical CPU in a computer system. Virtual machine management software assigns virtual CPUs to virtual machines and maps the virtual CPU's instructions and computing tasks to the physical CPU for execution. This allows multiple virtual machines to share the same physical CPU, achieving efficient resource utilization and isolation.A virtual CPU is simulated and executed on a physical CPU. During its runtime, the virtual CPU can use the physical CPU's computing resources and freely choose to execute certain instructions. However, some instructions are classified as sensitive. When the virtual CPU executes these instructions, the hypervisor (which manages the interaction between the physical CPU and the virtual CPU) detects that the virtual CPU is executing sensitive instructions. To ensure the security of the data stored on the physical CPU, the hypervisor will exit the virtual CPU, causing the virtual CPU to lose access to the physical CPU. Access to the physical CPU will then return to the hypervisor, which will then further investigate why the virtual CPU executed the sensitive instruction and control the process executing in the virtual CPU to the instruction immediately preceding the sensitive instruction. The hypervisor will then return access to the physical CPU to the virtual CPU. However, the virtual CPU may then execute the instruction again according to its own process schedule, causing access to the physical CPU to be repeatedly transferred between the virtual CPU and the hypervisor, causing the physical CPU to idle and waste significant computing power. It should be noted that the sleep instruction of a virtual CPU is typically set as a sensitive instruction and is typically used simultaneously with a detection instruction: the virtual CPU continuously executes the detection instruction used to detect whether data at a certain address has changed. If the detection instruction does not detect a data change, the virtual CPU executes the sleep instruction, waiting with low power consumption until a data change is detected before proceeding with subsequent operations. However, when the hypervisor detects that the virtual CPU has gone into sleep, it controls the virtual CPU to exit and investigates the reason for the virtual CPU's sleep. If it finds that the detection instruction did not detect a data change, it then returns access to the physical CPU to the virtual CPU. The virtual CPU then re-executes the detection instruction and, if the detection instruction does not detect a data change, goes into sleep again, repeating the sleep-wake cycle until the detection instruction detects a data change. Using the method provided in this application, a hypervisor controlling the interaction between the physical CPU and the virtual CPUs can detect a state change of the first virtual CPU, where the state change is from an exit from a running state to a sleep state. The first virtual CPU shares the resources of a shared device with other virtual CPUs. The virtual machine hypervisor can detect in real time the operating status of the virtual central processor that can interact with the physical central processor.The first virtual CPU may be the virtual CPU currently controlling the resources of the physical CPU. When the hypervisor detects that the first virtual CPU has transitioned from a running state to a dormant state, the hypervisor may, in response to the state change, set a resume timer for the first virtual CPU and control a second virtual CPU among the other virtual CPUs to transition from a dormant state to a running state. After detecting that the first virtual CPU has entered the dormant state, the hypervisor may set a resume timer for the first virtual CPU and record the sleep time of the first virtual CPU. While setting the resume timer, the hypervisor may control a second virtual CPU among the other virtual CPUs to transition from a dormant state to a running state to ensure full utilization of the physical CPU's resources. The other virtual CPUs are virtual CPUs that can interact with the physical CPU, that is, all virtual CPUs that share the physical CPU's resources with the first virtual CPU. The second virtual CPU may be any one of the other virtual CPUs, or a virtual CPU among the other virtual CPUs that meets certain conditions. It should be noted that if, solely to improve physical CPU resource utilization and reduce computing power waste, a resume timer is not set, and only the second virtual CPU is controlled to transition from a sleep state to a running state, the first virtual CPU may no longer have the opportunity to wake up and resume its running state. This could result in instructions issued to the first virtual CPU failing to execute normally, impacting the normal operation of the virtual machine corresponding to the first virtual CPU. Therefore, a resume timer must be set for the first virtual CPU to ensure that it has the opportunity to wake up and resume its running state, allowing it to execute instructions issued to it normally. When the resume timer expires, the hypervisor can, upon detecting the expiration of the resume timer, control the second virtual CPU to transition from a running state to a sleep state and control the first virtual CPU to resume its running state from a sleep state. Upon detecting the expiration of the resume timer, the hypervisor controls the second virtual CPU to transition from a running state to a sleep state and controls the first virtual CPU to resume its running state from a sleep state. That is, the virtual machine hypervisor transfers the right to use the physical CPU from the second virtual CPU to the first virtual CPU.It should be noted that in the above steps, a sleep function can be used to control the state transition of the virtual CPU. When transitioning from the running state to the dormant state, the sleep function of the virtual CPU is marked as sleeping, and the sleep function of the virtual CPU is marked as waking, thereby transitioning the virtual CPU from the dormant state to the running state. Through the above steps, by transferring the use rights of the physical CPU to the second virtual CPU during the time when the first virtual CPU is dormant and setting a timer to promptly wake up the first virtual CPU and re-enter the running state, the computing power of the physical CPU is fully utilized while the first virtual CPU is dormant, while ensuring that the first virtual CPU can be woken up and resumed running. This achieves the technical effect of improving the utilization efficiency of the physical CPU and further solves the technical problem of the physical CPU idling and wasting computing power due to the virtual machine management software repeatedly waking up the virtual CPU to re-enter the running state after the virtual CPU enters the dormant state. Since the duration of the recovery timer determines the sleep time of the first virtual CPU and when the first virtual CPU can be woken up and resumed running, setting the duration of the recovery timer is very important. If the timer duration is set too short, the second virtual CPU will only have a very short runtime. Furthermore, after the first virtual CPU resumes normal operation, the detection instruction will likely not detect any data changes, thus wasting some computing power. However, if the timer duration is set too long, the first virtual CPU will be unable to resume normal operation, delaying the normal execution of instructions by the first virtual CPU. Optionally, the recovery timer duration can be a pre-set fixed time interval. Regardless of the differences between virtual CPUs, the hypervisor uses this fixed time interval to set the recovery timer when switching physical CPU resource usage rights between any two virtual CPUs in all virtual CPUs. However, a fixed time interval is relatively rigid and inflexible. In some cases, the fixed time interval may be too short, while in other cases, it may be too long. Therefore, the recovery timer duration can be dynamically adjusted based on the actual conditions of the two virtual CPUs being adjusted (i.e., the first virtual CPU and the second virtual CPU) to obtain a time interval that is more appropriate for the current switch. The present application provides the following embodiments for dynamically setting the timing duration of the recovery timer according to the actual conditions of the first virtual central processing unit and the second virtual central processing unit.Optionally, a first priority level for the first virtual CPU and a second priority level for the second virtual CPU can be obtained. The first priority level can be considered alone, or the second priority level can be considered alone to set the recovery timer duration. Different priorities result in different recovery timer durations. Alternatively, the first and second priorities can be considered together, and a mathematical operation performed on the values ​​of the first and second priorities. The recovery timer duration can be dynamically set based on the different operation results. The virtual CPU operating priorities can be pre-set. A higher priority can be assigned to a virtual CPU running tasks that are more important to the entire virtual operating system, or a higher priority can be assigned to a virtual CPU running tasks requiring faster response times. In short, the virtual CPU operating priorities can determine the priority with which the hypervisor allocates physical CPU resources to the virtual CPUs. Optionally, the recovery timer duration can be set based solely on the first priority level. When the resource usage rights of a physical CPU are switched from the first virtual CPU to the second virtual CPU, the first virtual CPU's ability to operate normally can be prioritized, and the timer duration can be set based solely on the first priority. The priority and timer duration should be inversely proportional: that is, the higher the priority, the shorter the timer duration. In this case, when the first virtual CPU's priority is higher, the shorter the sleep time of the first virtual CPU, which can better ensure the first virtual CPU's normal operation. When the first virtual CPU's priority is lower, the sleep time of the first virtual CPU can be longer, providing more time for other virtual CPUs to operate. Similarly, the second priority can be considered separately when setting the recovery timer duration. When the resource usage rights of a physical CPU are switched from the first virtual CPU to the second virtual CPU, the second priority can also be prioritized, with sufficient normal operating time for the second virtual CPU. The timer duration can be set based solely on the second priority. The priority and timer duration should be in direct proportion: that is, the higher the priority, the longer the timer duration. In this case, when the second virtual CPU has a higher priority, a longer sleep time for the first virtual CPU ensures that the second virtual CPU has sufficient time to operate normally. When the second virtual CPU has a lower priority, the sleep time for the first virtual CPU can be shorter. Alternatively, a more optimal solution is to comprehensively consider the first and second priorities when setting a resume timer duration for the first virtual CPU.In the case where a higher priority value indicates a more important corresponding virtual CPU, a ratio of the second priority value to the first priority value can be determined. Based on this ratio and a preset unit duration, the duration of the recovery timer for the first virtual CPU can be set. For example, the ratio can be substituted into a preset exponential function, where the base of the preset exponential function can be the preset unit duration, and the output of the exponential function can be the duration of the recovery timer. Alternatively, the product of the ratio and the preset unit duration can be directly used as the duration of the recovery timer. It should be noted that the ratio of the second priority value to the first priority value here refers to the value obtained by using the first priority value as the numerator and the second priority value as the denominator. In other words, the above ratio is sequential. For example, the first priority value may be 2, and the second priority value may be 5. If a higher priority value indicates a more important corresponding virtual CPU, the second virtual CPU is more important than the first virtual CPU. In this case, the ratio of the second priority value to the first priority value is 5 / 2 = 2.5. In this case, the recovery timer duration can be set to 2.5 times the preset unit duration. In other words, the duration can be set longer, allowing the more important second virtual CPU to have a longer runtime. Similarly, if the first priority value is 5 and the second priority value is 2, the first virtual CPU is more important than the second virtual CPU. In this case, the ratio is 2 / 5 = 0.4. The recovery timer duration can be set to 0.4 times the preset unit duration. In other words, the duration is set shorter, allowing the more important first virtual CPU to be awakened in a timely manner. If the first and second priority values ​​are equal, the ratio is 1, and the recovery timer duration can be directly set to the preset unit duration. Using the above optional embodiments, a more appropriate duration can be set for the recovery timer based on the actual conditions of the first and second virtual CPUs, taking into account the values ​​of the first and second priorities. It should be noted that the above two optional embodiments merely provide a method based on division. The value of the second priority can be divided by the value of the first priority to obtain a ratio, and the duration of the recovery timer can be set based on the ratio. Similarly, a method based on subtraction can be used. The value of the second priority can be subtracted from the value of the first priority to obtain the absolute value of the difference, and the duration of the recovery timer can be set based on the absolute value of the difference and a preset unit duration.Specifically, the first priority and the second priority can be compared. If the first priority is higher than the second priority, ensuring the normal operation of the first virtual CPU should be the primary consideration. In other words, the sleep timer of the first virtual CPU should be set shorter. Since the preset unit duration is a fixed value, the absolute value of the difference is generally a natural number greater than 1. To obtain a smaller value, the reciprocal of the difference can be multiplied by the preset unit duration, and the resulting product can be set as the recovery timer duration. If the first priority is higher than the second priority, ensuring the normal operation of the second virtual CPU should be the primary consideration. In other words, the sleep timer of the first virtual CPU should be set longer. In this case, the difference can be directly multiplied by the preset unit duration, and the resulting product can be set as the recovery timer duration. If the difference is 1, it indicates that the difference between the first and second priorities is not significant, and the preset unit duration can be directly used as the recovery timer duration. If the first priority is equal to the second priority, the preset unit duration can also be directly used as the recovery timer duration. The preset unit duration can be a pre-set average duration that is suitable for most situations. It should be noted that the above optional embodiment merely provides an optional method for setting the recovery timer duration based on the absolute value of the priority difference. When dynamically setting the recovery timer duration based on specific circumstances, it is also possible to pre-determine the possible priority differences based on the respective priorities of all virtual CPUs. In this case, the priority difference can be a fixed value obtained by subtracting the second priority from the first priority, that is, the priority difference can be a negative number. Then, corresponding durations can be set for all possible priority differences. In actual applications, the duration corresponding to the priority difference can be directly found and used as the recovery timer duration. As can be seen from the above optional embodiment, when determining the recovery timer duration based on the operating priorities of each virtual CPU, priority is an important factor in determining the recovery timer duration. In other words, how to determine the operating priorities of each virtual CPU is also important. This application also provides the following optional embodiments for determining the operating priorities of each virtual CPU. Optionally, there are ongoing processes in the virtual central processing units, and the priority of the virtual central processing units can be determined according to the ongoing processes of the virtual central processing units.If the process running in a virtual CPU is important, then the corresponding virtual CPU should also be more important, with a higher priority and more runtime. If the process running in a virtual CPU is less important, then the priority of the corresponding virtual CPU can be appropriately lowered so that it does not occupy a lot of runtime. Alternatively, the priority of the virtual CPU can be determined based on the process type. Process types include the following: User processes: These are processes created by user-initiated programs or services. These processes typically perform user tasks, such as applications, desktop programs, and network services. System processes: These are processes created by the operating system kernel or system services. These processes perform system-level tasks, such as device drivers, system daemons, and memory management. Because system processes perform system-level tasks, their priority can be set higher, while other processes can be set lower. Virtual CPU priorities can also be determined based on the response time required by the process. Processes that run automatically without direct user intervention are typically used to process large amounts of data or perform a series of automated tasks. These processes typically require longer response times, so a lower priority can be assigned to them. There are also processes that require direct user control or interaction, such as terminal sessions or graphical user interface applications, which require slightly shorter response times. Furthermore, processes that run under strict time constraints, such as control systems and real-time communications, require even shorter response times, so a higher priority can be assigned to them. You can also determine the priority of a process based on both the process type and the required response time. For example, a batch process running automatically within the system can have a lower priority than other system processes, while processes requiring real-time response can have a higher priority. This allows you to prioritize the virtual CPU based on its contribution to the overall virtual machine's operation, helping to ensure the proper operation of the entire virtual machine. It should be noted that the above optional embodiments merely provide specific methods for determining the priorities of virtual CPUs. In specific scenarios, the operating priorities of individual virtual CPUs can also be dynamically adjusted based on actual circumstances. For example, if a virtual CPU does not receive sufficient execution time for an extended period, its priority can be temporarily increased. Optionally, the priorities of the individual virtual CPUs can also be considered when selecting a second virtual CPU from other virtual CPUs.Specifically, the operating priorities of the other virtual CPUs can be obtained and sorted. The virtual CPU with the highest priority can be selected as the second virtual CPU, and the second virtual CPU can be controlled to transition from a dormant state to a running state. This ensures that the higher-priority virtual CPU receives more runtime time. Optionally, the hypervisor can identify pending tasks on the other virtual CPUs and estimate the task duration required for the virtual CPUs with pending tasks to complete the pending tasks. The task durations corresponding to the virtual CPUs with pending tasks can be compared with the duration of the recovery timer. The virtual CPU with the most appropriate task duration can be selected as the second virtual CPU, and the second virtual CPU can be transitioned from a dormant state to a running state. This ensures that the processing of the second virtual CPU can be completed as much as possible without affecting the recovery timer's expiration. Optionally, a target virtual CPU with a recovery duration shorter than the timer duration can be selected. If there are multiple target virtual CPUs, the virtual CPU with the highest priority can be selected as the second virtual CPU. The above method can be applied in scenarios where multiple virtual CPUs share a physical CPU. However, when a virtual CPU exclusively uses a physical CPU, the right to use the physical CPU's resources may be repeatedly exchanged between the virtual CPU and the hypervisor, still wasting computing power. In situations where a virtual CPU exclusively uses the physical CPU, the configuration file can be modified to remove the virtual CPU's sleep instruction from the sensitive instruction library. This prevents the virtual CPU from transferring the right to use the physical CPU's resources to the hypervisor even if the sleep instruction is executed. This allows the virtual CPU to remain in a sleep state until a detection instruction detects a data change and wakes it up. Based on the above embodiment and optional embodiments, an optional implementation is provided below. Figure 6 is a schematic diagram illustrating the operating state changes of a virtual CPU according to related art. As shown in Figure 6, time changes from left to right. In related art, the operating state of virtual CPU 0 (vcpu0 in the figure) changes over time.Initially, virtual CPU 0 obtains access to the physical CPU's resources and runs its workload normally. At some point, it enters a dormant state (the small box in the first row indicates vCPU 0 entering the idle state). This dormant state only lasts a short while before the hypervisor, which manages the interaction between the physical CPU and the virtual CPU, detects the virtual CPU's dormant state. The hypervisor then deactivates the virtual CPU, causing it to lose access to the physical CPU and return access to the physical CPU to the hypervisor (the small box in the second row indicates that access to the physical CPU's resources is controlled by the hypervisor). The hypervisor then investigates why the virtual CPU went dormant and returns the execution of the virtual CPU's process to the instruction immediately before the dormant state. The hypervisor then returns access to the physical CPU to the virtual CPU. However, at this point, the virtual CPU may execute the instruction again according to the process schedule, causing the right to use the physical CPU to be repeatedly transferred between the virtual CPU and the hypervisor. At some point, virtual CPU vcpu0 awakens from its dormant state and resumes normal workload operation. During the period between the first and second rows of blocks in the intermediate process, the physical CPU will idle, wasting significant computing power. In a specific embodiment, the instructions executed by virtual CPU 0 may be monitor instructions (detection instructions) and mwait instructions (sleep instructions). The hypervisor can be configured to normally transmit monitor and mwait instructions. If the hypervisor determines that the vCPU has exclusive access to the physical core, the monitor and mwait instructions are configured to execute without exiting. This means that the virtual CPU executes the instruction and retains access to the physical CPU's resources, without returning access to the hypervisor. When the hypervisor determines that the vCPU does not have exclusive access to the physical core (CPU over-allocation occurs), it sets the mwait instruction to execute and trigger an exit. That is, the virtual central processor executes the instruction and loses the right to use the resources of the physical central processor, returning the right to use to the virtual machine hypervisor.When a vCPU exits the VM execution state due to an mwait condition, the hypervisor takes the following actions: a) Utilizing high-precision timer hardware and software infrastructure, a timer is set. The timer's expiration duration, T1, can be dynamically set based on the vCPU's priority or set to a fixed duration (e.g., 200us). This duration affects the balance between responsiveness and computing throughput. b) The vCPU thread proactively yields the CPU and enters the process's sleep state (a hibernation state, implemented using functions such as do usleep range()). Because the vCPU proactively yields the CPU and enters the sleep state, the hypervisor can schedule other services or vCPUs to run, fully utilizing the idle computing power of the physical CPU. After the timer expires, the hypervisor takes the following actions: a) The vCPU in the mwait sleep state is marked as need_resched (wake up). b) The scheduler is triggered to immediately schedule the vCPU, giving priority to the vCPU. c) The vCPU in the mwait sleep state enters the VM execution state. Corresponding to the above-described specific embodiments, FIG7 is a schematic diagram illustrating the operational state changes of a virtual central processing unit (CPU) according to an embodiment of the present application. As shown in FIG7 , the rectangular boxes in the first row represent vCPU0 running a workload. The small boxes in the first row represent vCPU0 sleeping and entering the idle state. The small boxes in the second row indicate that the hypervisor sets a timer and releases physical CPU resources, allowing vCPU0 to run the workload. The rectangular boxes in the third row indicate that vCPU0 runs the workload until the timer expires, at which point the hypervisor reschedules vCPU0 to run the workload. The above-described specific embodiments utilize the monitor / mwait instruction set to improve latency performance, such as process wakeup. When multiple vCPUs share a physical CPU, even if a virtual machine utilizes the monitor / mwait instruction set, idle computing power can still be released to other services or vCPUs. The timer expiration timer can be configured. This setting is not necessarily optimal, as a shorter expiration timer increases the frequency of vCPU wakeups, which in turn resembles the previous idling implementation scheme and results in greater computing power waste.The advantage of setting a shorter expiration time is that the wake-up delay is reduced. However, experimental statistical results show that using mwait in a virtual machine significantly improves both minimum and average latency performance. The maximum latency depends on the timer expiration time setting (the maximum latency will not exceed the set duration). A reasonable value that balances computing power and performance can be set based on actual business needs. It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display, etc.) involved in this application are all authorized by the user or fully authorized by all parties. The collection, use, and processing of relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or deny. It should be noted that for the sake of simplicity, the aforementioned method embodiments are described as a series of actions. However, those skilled in the art should understand that this application is not limited by the order of the actions described, as certain steps can be performed in a different order or simultaneously according to this application. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are preferred embodiments, and the actions and modules involved are not necessarily required by this application. Through the above description of the embodiments, those skilled in the art will clearly understand that the methods according to the above embodiments can be implemented using software and a necessary general-purpose hardware platform, or of course, hardware. Based on this understanding, the technical solution of this application, or the portion that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk) and includes a number of instructions for enabling a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in each embodiment of this application.Example 2 According to an embodiment of the present application, a state processing device for implementing the above-mentioned state processing method is also provided. Figure 8 is a structural block diagram of a state processing device according to an embodiment of the present application. As shown in Figure 8, the device includes: a first detection module 81, configured to detect a state change of a first device, wherein the state change is exiting from a running state to a dormant state, and the first device shares resources of a shared device with other devices; a first control module 82, connected to the detection module 81, configured to set a recovery timer for the first device in response to the state change, and control a second device among the other devices to switch from the dormant state to the running state; a second control module 83, connected to the first control module 82, configured to control the second device to switch from the running state to the dormant state when the recovery timer expires, and control the first device to recover from the dormant state to the running state. According to an embodiment of the present application, a state processing device for a virtual central processing unit for implementing the above-mentioned state processing method is further provided. FIG9 is a structural block diagram of another state processing device according to an embodiment of the present application. As shown in FIG9 , the device includes: a second detection module 91, configured to detect a state change caused by a first virtual instance executing a sleep instruction, wherein the state change is an exit from a running state to a sleep state, and the first virtual instance shares resources of a physical instance with other virtual instances; a third control module 92, connected to the second detection module 91, configured to set a recovery timer for the first virtual instance in response to the state change, and control a second virtual instance among the other virtual instances to transition from the sleep state to the running state; and a fourth control module 93, connected to the third control module 92, configured to control the second virtual instance to transition from the running state to the sleep state and control the first virtual instance to resume from the sleep state to the running state when the recovery timer expires. It should be noted here that the above-mentioned first detection module 81, first control module 82 and second control module 83 correspond to steps S401 to S403 in Example 1, and the above-mentioned second detection module 91, third control module 92 and fourth control module 93 correspond to steps S501 to S503 in Example 1. The examples and application scenarios implemented by multiple modules and corresponding steps are the same, but are not limited to the contents disclosed in the above-mentioned Example 1.It should be noted that the above-mentioned modules or units may be hardware components or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above-mentioned modules may also be part of a device and run in the computer terminal 10 provided in Example 1. It should be noted that the preferred implementation schemes involved in the above-mentioned embodiments of this application are the same as the solution provided in Example 1, as well as the application scenarios and implementation processes, but are not limited to the solution provided in Example 1. Example 3 The embodiments of this application may provide an electronic device, which may be any electronic device in a group of electronic devices. Optionally, in this embodiment, the above-mentioned electronic device may be replaced by a terminal device such as a mobile terminal. Optionally, in this embodiment, the above-mentioned electronic device may be located in at least one of multiple network devices in a computer network. In this embodiment, the above-mentioned computer terminal may execute the program code in the method. Optionally, Figure 10 is a block diagram of the structure of an electronic device according to an embodiment of this application. As shown in FIG10 , the electronic device may include one or more processors 1002 (only one is shown), a memory 1004, a storage controller, and a peripheral interface, wherein the peripheral interface is connected to a radio frequency module, an audio module, and a display. The memory may be configured to store software programs and modules, such as program instructions / modules corresponding to the methods and apparatuses in the embodiments of the present application. The processor executes the software programs and modules stored in the memory to execute various functional applications and process data, thereby implementing the methods in the embodiments. The memory may include high-speed random access memory (RAM) and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory may further include memory located remotely from the processor, which may be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof. The processor can call information and applications stored in the memory through the transmission device to perform the following steps: detecting a state change of the first device, wherein the state change is exiting from a running state to a dormant state, and the first device shares resources of a shared device with other devices; in response to the state change, setting a recovery timer for the first device, and controlling a second device among the other devices to switch from the dormant state to the running state; when it is detected that the recovery timer expires, controlling the second device to switch from the running state to the dormant state, and controlling the first device to resume from the dormant state to the running state.Optionally, the processor may further execute program code for the following steps: setting a recovery timer for the first device in response to a state change, including: obtaining a first priority level for the first device and a second priority level for the second device; and setting a recovery timer and a timer duration for the first device based on the first priority and / or the second priority. Optionally, the processor may further execute program code for the following steps: setting a timer duration for the recovery timer for the first device based on the first priority or the second priority, including: setting a recovery timer for the first device; obtaining a correspondence between priorities and timer durations; determining the timer duration corresponding to the first priority as the timer duration for the recovery timer; or determining the timer duration corresponding to the second priority as the timer duration for the recovery timer. Optionally, the processor may further execute program code for the following steps: setting a recovery timer and a timer duration for the first device based on the first priority and the second priority, including: setting a recovery timer for the first device; determining a ratio of a priority value corresponding to the second priority to a priority value corresponding to the first priority; and setting a timer duration for the recovery timer for the first device based on the ratio and a preset unit duration. Optionally, the processor may further execute program code for the following steps: setting a recovery timer duration for the first device based on the ratio and a preset unit duration, including: determining the product of the ratio and the preset unit duration as the recovery timer duration. Optionally, the processor may further execute program code for the following steps: determining a first priority based on a process performed by the first device, and / or determining a second priority based on a process performed by the second device. Optionally, the processor may further execute program code for the following steps: determining a first priority based on a process performed by the first device, including: determining a first process type performed by the first device; determining a priority corresponding to the first process type as the first priority; or determining a first response time required for the process performed by the first device; and determining a priority corresponding to the first response time as the first priority. Optionally, the processor may further execute program code for the following steps: determining a second priority based on a process performed by the second device, including: determining a second process type performed by the second device; determining a priority corresponding to the second process type as the second priority; or determining a second response time required for the process performed by the second device; and determining a priority corresponding to the second response time as the second priority. Optionally, the processor may further execute program code of the following steps: controlling a second device among other devices to switch from a sleep state to a running state, including: obtaining the running priorities of the other devices; selecting a device with the highest priority among the running priorities of the other devices as the second device, and controlling the second device to switch from a sleep state to a running state.Optionally, the processor may further execute program code for the following steps: controlling a second device among the other devices to transition from a dormant state to an active state, including: determining a device among the other devices with pending tasks; estimating the task duration required for the device with pending tasks to complete the pending tasks; determining the second device based on the task durations corresponding to the devices with pending tasks and the durations of the resume timers; and controlling the second device to transition from a dormant state to an active state. Optionally, the processor may further execute program code for the following steps: determining the second device based on the task durations corresponding to the devices with pending tasks and the durations of the resume timers, including: selecting a target device among the devices with pending tasks whose task duration is less than the duration of the resume timer; if there are multiple target devices, obtaining the priorities of the multiple target devices; and selecting the device with the highest priority among the multiple target devices as the second device. The processor may further execute program code for the following steps: detecting a state change caused by the first virtual instance executing a hibernation instruction, wherein the state change is an exit from a running state to a hibernation state, and the first virtual instance shares resources of a physical instance with other virtual instances; in response to the state change, setting a recovery timer for the first virtual instance and controlling a second virtual instance among the other virtual instances to transition from a hibernation state to a running state; upon detecting expiration of the recovery timer, controlling the second virtual instance to transition from a running state to a hibernation state, and controlling the first virtual instance to resume from a hibernation state to a running state. Optionally, the processor may further execute program code for the following steps: setting a recovery timer for the first virtual instance in response to the state change, including: obtaining a first priority level of the first virtual instance and a second priority level of the second virtual instance; and setting a recovery timer and a time duration for the first virtual instance based on the first priority level and / or the second priority level. Optionally, the processor may further execute program code for the following steps: controlling a second virtual instance among the other virtual instances to transition from a dormant state to a running state, including: determining virtual instances among the other virtual instances that have pending tasks; estimating the task durations required for the virtual instances with pending tasks to complete the pending tasks; determining a second virtual instance based on the task durations corresponding to the virtual instances with pending tasks and the durations of the recovery timers; and controlling the second virtual instance to transition from a dormant state to a running state. This embodiment of the present application provides a state processing solution.The system transfers the right to use a shared device to a second device during the time the first device is dormant, and sets a timer to promptly wake the first device up and put it back into operation. By detecting a state change of the first device, where the state change is from an operating state to a dormant state, the first device shares the resources of a shared device with other devices. In response to the state change, a recovery timer is set for the first device, and a second device among the other devices is controlled to transition from a dormant state to an operating state. Upon detecting expiration of the recovery timer, the second device is controlled to transition from an operating state to a dormant state, and the first device is controlled to resume operation from a dormant state. This achieves the goal of fully utilizing the resources of the shared device while the first device is dormant, while ensuring that the first device can be woken up and resumed operation. This improves the efficiency of resource utilization of the shared device, thereby resolving the technical problem in related technologies of the difficulty faced by users in configuring server requirements according to their own needs. Those skilled in the art will appreciate that the structure shown in the figure is merely illustrative, and the electronic device may also be a smartphone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, or a terminal device such as a mobile internet device (MID) or a PAD. This figure does not limit the structure of the electronic device described above. For example, electronic device A may include more or fewer components (such as a network interface, a display device, etc.) than those shown in the figure, or have a configuration different from that shown in the figure. Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be completed by a program instructing the hardware associated with the terminal device. The program can be stored in a computer-readable storage medium, which may include a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. Example 4: The embodiments of the present application also provide a computer-readable storage medium. Optionally, in this embodiment, the computer-readable storage medium can be used to store program code executed by the methods provided in the above embodiments. Optionally, in this embodiment, the storage medium can be located in any electronic device in a group of electronic devices in a computer network, or in any mobile terminal in a group of mobile terminals.Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for performing the following steps: detecting a state change of a first device, wherein the state change is exiting from an operating state to a dormant state, and the first device shares resources of a shared device with other devices; in response to the state change, setting a recovery timer for the first device and controlling a second device among the other devices to transition from a dormant state to an operating state; upon detecting expiration of the recovery timer, controlling the second device to transition from an operating state to a dormant state, and controlling the first device to resume from a dormant state to an operating state. Optionally, the computer-readable storage medium is further configured to store program code for performing the following steps: in response to the state change, setting a recovery timer for the first device, including: obtaining a first priority for the first device and a second priority for the second device; and setting a recovery timer and a time duration for the first device based on the first priority and / or the second priority. Optionally, the computer-readable storage medium is further configured to store program code for executing the following steps: setting a recovery timer duration for the first device based on the first priority or the second priority, including: setting a recovery timer for the first device; obtaining a correspondence between priorities and timer durations; determining the timer duration corresponding to the first priority as the timer duration of the recovery timer; or determining the timer duration corresponding to the second priority as the timer duration of the recovery timer. Optionally, the computer-readable storage medium is further configured to store program code for executing the following steps: setting a recovery timer and setting the timer duration for the first device based on the first priority and the second priority, including: setting the recovery timer for the first device; determining a ratio between a priority value corresponding to the second priority and a priority value corresponding to the first priority; and setting the timer duration for the recovery timer for the first device based on the ratio and a preset unit duration. Optionally, the computer-readable storage medium is further configured to store program code for executing the following steps: setting a recovery timer duration for the first device based on the ratio and a preset unit duration, including: determining the product of the ratio and the preset unit duration as the timer duration of the recovery timer. Optionally, the computer-readable storage medium is further configured to store program code for executing the following steps: determining the first priority according to a process performed by the first device, and / or determining the second priority according to a process performed by the second device.Optionally, the computer-readable storage medium is further configured to store program code for executing the following steps: determining a first priority based on a process performed by a first device, including: determining a type of a first process performed by the first device; determining a priority corresponding to the first process type as the first priority; or determining a first response time required for the process performed by the first device; and determining a priority corresponding to the first response time as the first priority. Optionally, the computer-readable storage medium is further configured to store program code for executing the following steps: determining a second priority based on a process performed by a second device, including: determining a type of a second process performed by the second device; determining a priority corresponding to the second process type as the second priority; or determining a second response time required for the process performed by the second device; and determining a priority corresponding to the second response time as the second priority. Optionally, the computer-readable storage medium is further configured to store program code for executing the following steps: controlling a second device among other devices to transition from a dormant state to an active state, including: obtaining the operating priorities of each of the other devices; selecting the device with the highest priority among the operating priorities of the other devices as the second device, and controlling the second device to transition from the dormant state to an active state. Optionally, the computer-readable storage medium is further configured to store program code for executing the following steps: controlling a second device among other devices to transition from a dormant state to an active state, including: determining a device among the other devices with pending tasks; estimating the task duration required for the device with pending tasks to complete the pending tasks; determining the second device based on the task durations and resume timer durations corresponding to the devices with pending tasks; and controlling the second device to transition from a dormant state to an active state. Optionally, the computer-readable storage medium is further configured to store program code for executing the following steps: determining the second device based on the task durations and resume timer durations corresponding to the devices with pending tasks, including: selecting a target device among the devices with pending tasks whose task duration is less than the resume timer duration; if there are multiple target devices, obtaining the priorities of the multiple target devices; and selecting the device with the highest priority among the multiple target devices as the second device.The computer-readable storage medium is further configured to store program code for performing the following steps: detecting a state change caused by a first virtual instance executing a hibernation instruction, wherein the state change is an exit from a running state to a hibernation state, and the first virtual instance shares resources of a physical instance with other virtual instances; in response to the state change, setting a recovery timer for the first virtual instance and controlling a second virtual instance among the other virtual instances to transition from a hibernation state to a running state; upon detecting expiration of the recovery timer, controlling the second virtual instance to transition from a running state to a hibernation state, and controlling the first virtual instance to resume from a hibernation state to a running state. Optionally, the computer-readable storage medium is further configured to store program code for performing the following steps: in response to the state change, setting a recovery timer for the first virtual instance, including: obtaining a first priority level of the first virtual instance and a second priority level of the second virtual instance; and setting a recovery timer and a time duration for the first virtual instance based on the first priority level and / or the second priority level. Optionally, the computer-readable storage medium is further configured to store program code for executing the following steps: controlling a second virtual instance among the other virtual instances to transition from a dormant state to a running state, including: determining virtual instances among the other virtual instances that have pending tasks; estimating the task duration required for the virtual instances with pending tasks to complete the pending tasks; determining a second virtual instance based on the task durations corresponding to the virtual instances with pending tasks and the duration of a recovery timer; and controlling the second virtual instance to transition from a dormant state to a running state. Example 5 An embodiment of the present application further provides a computer program product. Optionally, in this embodiment, the computer program product may include a computer program that, when executed by a processor, implements the method provided in the above embodiment. Example 6 An embodiment of the present application further provides a computer program product. Optionally, the computer program product may include a non-volatile computer-readable storage medium that may be used to store a computer program that, when executed by a processor, implements the method provided in the above embodiment. Example 7 An embodiment of the present application further provides a computer program. Optionally, in this embodiment, when the computer program is executed by a processor, the method provided in the above embodiment is implemented. The serial numbers of the above embodiments of this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments. In the above embodiments of this application, the description of each embodiment has its own focus. For portions not described in detail in a particular embodiment, reference can be made to the relevant descriptions of other embodiments. In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways.The device embodiments described above are merely illustrative. For example, the division of units is merely a logical functional division. In actual implementation, other divisions may be employed. For example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not implemented. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be through interfaces, or indirect couplings or communication connections between units or modules, and may be electrical or other forms. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, i.e., they may be located in one location or distributed across multiple network units. Some or all of these units may be selected to achieve the objectives of the present embodiments as needed. Furthermore, the functional units in the various embodiments of the present application may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. These integrated units may be implemented in either hardware or software functional units. If the integrated unit is implemented as a software functional unit 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 application, or the portion that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product, stored in a storage medium, includes instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memories (ROMs), random access memories (RAMs), removable hard drives, magnetic disks, or optical disks. The above description is merely a preferred embodiment of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and such improvements and modifications should also be considered within the scope of protection of this application.

Claims

Claims 1. A device status processing method, comprising: A state change of a first device is detected, wherein the state change is exiting from a running state to a dormant state, and the first device shares resources of a shared device with other devices; in response to the state change, a recovery timer is set for the first device, and a second device among the other devices is controlled to transition from the dormant state to the running state; and when expiration of the recovery timer is detected, the second device is controlled to transition from the running state to the dormant state, and the first device is controlled to resume from the dormant state to the running state.

2. The method according to claim 1, wherein: The step of setting a recovery timer for the first device in response to the state change includes: obtaining a first priority of the first device and a second priority of the second device; and setting the recovery timer and the timing duration for the first device according to the first priority and / or the second priority.

3. The method according to claim 2, wherein Setting the recovery timer and setting the timing duration for the first device according to the first priority or the second priority includes: setting the recovery timer for the first device; obtaining the correspondence between the priority and the timing duration; determining the timing duration corresponding to the first priority as the timing duration of the recovery timer; or determining the timing duration corresponding to the second priority as the timing duration of the recovery timer.

4. The method according to claim 2, wherein The method of setting the recovery timer and the timing duration for the first device based on the first priority and the second priority includes: setting the recovery timer for the first device; determining the ratio of the priority value corresponding to the second priority to the priority value corresponding to the first priority; and setting the timing duration of the recovery timer for the first device based on the ratio and a preset unit duration.

5. The method according to claim 4, wherein: The step of setting the timing duration of the resumption timer for the first device according to the ratio and the preset unit duration includes determining a product of the ratio and the preset unit duration as the timing duration of the resumption timer.

6. The method according to claim 2, wherein: The first priority is determined according to a process performed by the first device, and the second priority is determined according to a process performed by the second device.

7. The method according to claim 6, wherein: Determining the first priority according to a process performed by the first device includes: 32 Determine a first process type performed by the first device, and determine a priority corresponding to the first process type as the first priority; or determine a first response time required by the process performed by the first device, and determine a priority corresponding to the first response time as the first priority.

8. The method according to claim 6, wherein: Determining the second priority based on the process performed by the second device includes: determining the type of the second process performed by the second device, and determining that the priority corresponding to the second process type is the second priority; or determining a second response time required by the process performed by the second device, and determining that the priority corresponding to the second response time is the second priority.

9. The method according to claim 1, wherein: The controlling the second device among the other devices to switch from a dormant state to a running state includes: obtaining the running priorities of the other devices; selecting the device with the highest priority among the running priorities of the other devices as the second device, and controlling the second device to switch from a dormant state to a running state.

10. The method according to claim 1, wherein: The controlling of converting the second device among the other devices from a sleep state to a running state includes: determining a device among the other devices that has pending tasks; estimating the task duration required for the device with pending tasks to complete processing the pending tasks; determining the second device based on the task durations corresponding to the devices with pending tasks and the timing duration of the recovery timer; and controlling the second device to convert from a sleep state to a running state.

11. The method according to claim 10, wherein The determining of the second device based on the task durations corresponding to the devices with pending tasks and the timing duration of the recovery timer includes: selecting a target device whose task duration is less than the timing duration from the devices with pending tasks; when there are multiple target devices, obtaining the respective priorities of the multiple target devices; and selecting the device with the highest priority among the respective priorities of the multiple target devices as the second device.

12. The method according to any one of claims 1 to 11, wherein The first device is a first virtual central processing unit, the second device is a second virtual central processing unit, and the shared device is a physical central processing unit.

13. A state processing method, comprising: A state change caused by the execution of a sleep instruction by a first virtual instance is detected, wherein the state change is exiting from a running state to a sleep state, and the first virtual instance shares a physical instance with other virtual instances. 33 In response to the state change, setting a recovery timer for the first virtual instance, and controlling a second virtual instance among the other virtual instances to switch from a dormant state to a running state; when detecting that the recovery timer has expired, controlling the second virtual instance to switch from a running state to a dormant state, and controlling the first virtual instance to resume from a dormant state to a running state.

14. The method according to claim 13, wherein: The step of setting a recovery timer for the first virtual instance in response to the state change includes: obtaining a first priority level of the first virtual instance and a second priority level of the second virtual instance; and setting a recovery timer and a timing duration for the first virtual instance according to the first priority level and / or the second priority level.

15. The method according to claim 13, wherein: The controlling the second virtual instance among the other virtual instances to transition from a dormant state to a running state includes: determining a virtual instance among the other virtual instances that has pending tasks; estimating the task duration required for the virtual instance with pending tasks to complete processing the pending tasks; determining the second virtual instance based on the task durations corresponding to the virtual instances with pending tasks and the timing duration of the recovery timer; and controlling the second virtual instance to transition from a dormant state to a running state.

16. The method according to any one of claims 13 to 15, wherein: The first virtual instance is a first virtual central processing unit, the other virtual instances are other virtual central processing units, and the physical instance is a physical central processing unit.

17. A state processing device, comprising: A detection module is configured to detect a state change of a first device, wherein the state change is exiting from a running state to a dormant state, and the first device shares resources of a shared device with other devices; a timing module is configured to set a recovery timer for the first device in response to the state change, and control a second device among the other devices to transition from the dormant state to the running state; and a control module is configured to, upon detecting expiration of the recovery timer, control the second device to transition from the running state to the dormant state, and control the first device to resume from the dormant state to the running state.

18. An electronic device, comprising: a memory storing an executable program; A processor is configured to run the program, wherein the program executes the state processing method according to any one of claims 1 to 16 when running.

19. A computer-readable storage medium comprising a stored executable program, wherein when the executable program is executed, the device where the storage medium is located is controlled to execute claims 1 to 16. The state processing method described in any one of the above.

20. A computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the computer program implements the state processing method according to any one of claims 1 to 16.

Images