An interface thread lockup detection and self-healing method, device, equipment and medium

Abstract

The application discloses an interface thread lock detection and self-recovery method, device, equipment and medium, and the method comprises the following steps: identifying the risk of being stuck for the survival state, the message sending path, the embedded browser life cycle path and the background synchronization key path of the interface thread, obtaining the desensitization feature field with the assumption mark and the active detection index; determining the current lock or risk as one of a plurality of preset failure link categories according to the desensitization feature field and the active detection index, and obtaining the failure link determination result; calling the corresponding prevention or self-recovery processing according to the failure link determination result, wherein the self-recovery processing comprises rebuilding the embedded browser outside the interface thread, refreshing the tool window and retransmitting the unconfirmed message by the independent scheduling thread through the integrated development environment asynchronous scheduling interface, and obtaining the self-recovery processing result; and re-verifying the self-recovery processing result. According to the application, the interface response and the message link can be automatically recovered without restarting the integrated development environment when the interface thread is locked.

Description

Technical Field

[0001] This application relates to the field of thread detection technology, specifically to a method, apparatus, device, and medium for detecting and self-healing interface thread deadlock. Background Technology

[0002] In recent years, AI programming assistants have been widely deployed in software development processes as plugins for Integrated Development Environments (IDEs). These plugins are typically embedded within the host IDE process, rendering the interactive interface through an embedded browser, such as a WebView component based on Chromium or Electron kernels, to support features like code completion suggestions, interactive dialogue, and intelligent question answering. The rendering of the interactive interface, user input responses, and message sending and receiving with the backend large language model service are all driven by the host IDE's UI thread. During the IDE plugin's operation, the UI thread needs to simultaneously handle multiple critical paths, including embedded browser rendering scheduling, script injection, message channel communication, backend configuration synchronization, and callback listener registration. Because these functions are highly coupled to the same UI thread, a blockage in any critical path can cause the entire UI thread to freeze, manifesting as an unresponsive interface, a frozen sidebar, or a seemingly frozen IDE. In severe cases, the user needs to manually restart the IDE, resulting in code loss and work interruption.

[0003] In the specific implementation of intelligent development tools, the embedded browser serves as the carrier of the IDE plugin interaction interface. It communicates bidirectionally with the plugin logic module on the host side via script injection, such as injecting JavaScript code segments. The communication process typically employs a postMessage mechanism: the plugin logic module writes scripts and transmits message data to the interaction interface by calling the synchronous injection interface provided by the embedded browser. The interaction interface receives and processes the data, then sends a response back to the host side via postMessage. Simultaneously, the plugin logic module needs to synchronize its background configuration with a remote configuration server to obtain configuration items such as function switches, model parameters, and prompt templates. This synchronization process is typically initiated by a background task thread that initiates a network request, retrieves the configuration, and writes it to local storage for the interface to read. Furthermore, each time the plugin logic module sends a request message to the embedded browser, it needs to register a callback listener to wait for the corresponding response message. The listener's lifecycle management depends on the event dispatch loop of the interface thread. This architecture makes the embedded browser rendering mode, browser instance lifecycle, message sending and confirmation mechanism, background synchronization task, and listener management all critical dependency paths for the stable operation of the interface thread.

[0004] Regarding the rendering mode of embedded browsers, modern IDE platforms, such as Chromium-based IDEs, may default to out-of-process rendering (separating the rendering process from the main process) and remote rendering (delegating rendering operations to a remote rendering service) architectures. On certain baseline versions of IDE platforms, this architecture may cause input channel anomalies or rendering pipeline blockages in the embedded browser, leading to UI thread freezes. Furthermore, the lifecycles of the embedded browser instance and the host IDE project object may be out of sync: when the project object is released or the browser instance is closed, if the plugin logic module still injects scripts or sends messages to the released browser instance, it will trigger null pointer dereferences or channel anomalies, causing UI thread blockage. This "object release" problem is particularly prominent in IDE plugin scenarios because the IDE may release the browser instance when switching projects, closing panels, or performing garbage collection, and the plugin logic module's awareness of this release event is delayed.

[0005] One existing solution addresses the UI thread deadlock issue through the following steps: First, embed tracking points on the UI thread for message sending paths, browser lifecycle paths, and critical background synchronization paths to collect feature data. Second, perform a deadlock risk assessment on the UI thread based on the collected feature data and output the failure assessment result. Third, execute self-recovery processing on the UI thread based on the assessment result, including rebuilding the embedded browser instance, refreshing the tool window, and resending unacknowledged messages. Fourth, re-verify the self-recovery processing result on the UI thread. While this solution logically covers the closed-loop process of detection, assessment, self-healing, and re-verification, it has a fundamental flaw because the embedding of detection tracking points, the collection of feature data, the assessment of deadlock risk, and the execution of self-recovery processing all depend on the UI thread itself.

[0006] However, the existing implementation has the following drawbacks: First, the detection points are implanted on the critical path of the UI thread. When the UI thread is locked, the detection points cannot be triggered, resulting in missing detection data and the inability to obtain the on-site characteristics when the deadlock occurs. Second, the deadlock risk judgment logic runs on the UI thread, and the judgment process depends on the scheduling of the UI event dispatch loop. Once the UI thread is blocked, the judgment logic cannot be executed, and the risk judgment becomes meaningless. Third, browser instance reconstruction, window refresh, and message resending in the self-recovery process all need to be executed through the asynchronous scheduling interface of the UI thread. After the UI thread is locked, these operations cannot be scheduled, and the recovery action is frozen. Fourth, if the background configuration synchronization task does not set reasonable connection timeouts and read timeouts, it will block the calling thread when the remote configuration server is unreachable. If this thread is associated with the UI thread, it will cause a chain lock-up. Fifth, callback listeners are not removed in time after the response message is returned. As the number of message interactions increases, the number of listeners continues to accumulate, eventually exhausting memory resources and slowing down the UI event dispatch loop. More importantly, the existing solution faces a self-referential paradox: if the UI thread is locked and the recovery action is performed by the UI thread itself, then the recovery action is also frozen. The "object that needs to be self-healed" is precisely the "subject that performs the self-healing," meaning that the self-healing mechanism itself depends on the locked thread to execute, forming an unbreakable deadlock. Summary of the Invention

[0007] To address the aforementioned technical problems, embodiments of this application provide a method, apparatus, device, and medium for detecting and self-healing interface thread deadlock.

[0008] In a first aspect, embodiments of this application provide a thread deadlock detection and self-healing method, applied to an intelligent development tool provided as an integrated development environment (IDE) plugin and internally based on an embedded browser rendering interactive interface, wherein the interactive interface is driven by the interface thread of the host IDE, and the method includes: An independent scheduling thread, which runs in the background task of the host integrated development environment and does not depend on the interface thread, identifies the risk of deadlock in the interface thread's survival status, message sending path, embedded browser lifecycle path, and background synchronization critical path, and obtains de-identified feature fields with hypothesis labels and active detection indicators. Based on the desensitized feature fields and the active detection indicators, the current deadlock or risk is determined as one of multiple preset failure link categories, and the failure link determination result is obtained; Based on the failure determination result, the corresponding prevention or self-recovery process is invoked. The self-recovery process includes rebuilding the embedded browser, refreshing the tool window, and resending the unacknowledged message outside the interface thread by the independent scheduling thread through the integrated development environment asynchronous scheduling interface, so as to obtain the self-healing result. The self-healing process result is re-verified. If the re-verification fails, the process returns to the stuck risk identification and the prevention or self-recovery process is re-executed to restore the responsiveness of the interface thread.

[0009] In some embodiments of this application, the step of using an independent scheduling thread running in the background task of the host integrated development environment and not dependent on the interface thread to identify the deadlock risk of the interface thread's survival status, message sending path, embedded browser lifecycle path, and background synchronization critical path, and obtaining de-identified feature fields with hypothesis markers and active detection indicators, includes: Structured tracking points are embedded in the message sending path, the embedded browser lifecycle path, and the background synchronization critical path. Each tracking point record has a hypothesis identifier and code location. The hypothesis identifier is used to distinguish different deadlock cause hypotheses and obtain de-identified feature fields. The independent scheduling thread periodically detects the liveness status of the interface thread using a heartbeat detection method, and counts the blocking time of the interface event distribution loop, the backlog time of the queue to be sent, and the message confirmation waiting time. When at least one of the blocking time, the backlog time, and the message confirmation waiting time exceeds a preset threshold, it is determined that there is a risk of being stuck, and active detection indicators are obtained.

[0010] In some embodiments of this application, the preset failure category includes rendering mode risk, browser lifecycle unavailability risk, large message injection risk, background synchronization blocking risk, and listener leakage risk; the step of determining the current freeze or risk into one of multiple preset failure categories based on the de-identified feature fields and the active detection indicators, and obtaining the failure determination result, includes: The desensitized feature fields and the active detection indicators are matched with preset judgment conditions for each category, and the successfully matched categories are used as the judgment results of the failure link.

[0011] In some embodiments of this application, the step of matching the desensitized feature field and the active detection index with preset judgment conditions for each category, and taking the successfully matched category as the failure link judgment result, includes: When the blocking duration of the interface event distribution loop in the active detection index exceeds the first preset threshold, the rendering mode risk matching is determined to be successful, and the failure link determination result is obtained. When the browser instance identifier or project identifier in the desensitization feature field indicates that it has been released, it is determined that the browser lifecycle unavailability risk is successfully matched, and the failure link determination result is obtained. When the message body size in the desensitization feature field exceeds the second preset threshold, it is determined that the risk of the ultra-large message injection is successfully matched, and the failure link determination result is obtained. When the background synchronization path embedding point in the desensitization feature field indicates a connection timeout or abnormal response, it is determined that the background synchronization blocking risk is successfully matched, and the failure link determination result is obtained. When the number of listeners in the desensitized feature field exceeds the third preset threshold, it is determined that the listener leakage risk is successfully matched, and the failure link determination result is obtained.

[0012] In some embodiments of this application, the step of invoking corresponding prevention or self-recovery processing based on the failure determination result includes the following: the self-recovery processing includes rebuilding the embedded browser, refreshing the tool window, and resending the unacknowledged message by the independent scheduling thread outside the interface thread via the integrated development environment asynchronous scheduling interface. When the failure step is determined to be a rendering mode risk, a compatibility parameter is injected before the embedded browser is initialized and before the browser availability is determined. Out-of-process rendering and remote rendering are turned off for the affected integrated development environment platform baseline version, so that the embedded browser falls back to a non-remote rendering architecture. When the failure step is determined to be a rendering mode risk and the embedded browser is detected to be still in remote rendering or the input channel is abnormal during runtime, the independent scheduling thread switches the rendering parameters, rebuilds the embedded browser instance and refreshes the tool window outside the interface thread through the integrated development environment asynchronous scheduling interface. After the reconstruction is completed, the unconfirmed message is resent.

[0013] In some embodiments of this application, injecting compatibility parameters before the embedded browser initialization and earlier than the browser availability determination, and disabling out-of-process rendering and remote rendering for the affected integrated development environment platform baseline version, causing the embedded browser to fall back to a non-remote rendering architecture, includes: Obtain the platform type and version number of the host integrated development environment to determine whether the version number belongs to the affected baseline version; When the version number belongs to a preset set of affected baseline versions, inject out-of-process rendering disable flags and remote rendering disable flags into the startup parameters of the embedded browser, so that the embedded browser starts directly with a non-remote rendering architecture during the initialization phase.

[0014] In some embodiments of this application, when the failure stage determines that the rendering mode is at risk and the embedded browser is still in remote rendering or the input channel is abnormal, the independent scheduling thread switches rendering parameters, rebuilds the embedded browser instance, and refreshes the tool window outside the interface thread via the integrated development environment asynchronous scheduling interface. After the reconstruction is completed, the unconfirmed message is resent, including: The independent scheduling thread periodically reads the runtime log fields of the embedded browser to determine whether the embedded browser is still in a remote rendering architecture or whether the input channel is abnormal. If it is confirmed that the remote rendering architecture is still in place or the input channel is abnormal, the independent scheduling thread performs the following operations outside the interface thread via the integrated development environment asynchronous scheduling interface: switch rendering parameters to make the embedded browser fall back to the non-remote rendering architecture, destroy the original embedded browser instance and rebuild a new instance, refresh the tool window display, and resend the unconfirmed message after the reconstruction is completed.

[0015] In some embodiments of this application, the step of switching rendering parameters to cause the embedded browser to fall back to a non-remote rendering architecture, destroying the original embedded browser instance and recreating a new instance, refreshing the tool window display, and resending unacknowledged messages after reconstruction includes: The rendering mode identifier in the runtime log field can be used to confirm whether the embedded browser is still in a remote rendering architecture. If it is confirmed that the browser is still in a remote rendering architecture, both out-of-process rendering parameters and remote rendering parameters are set to the off state, causing the embedded browser to fall back to a non-remote rendering architecture. Destroy the original embedded browser instance and create a new instance, injecting the compatibility parameters into the startup parameters of the new instance; After the new instance is initialized, refresh the tool window and resend any unconfirmed messages.

[0016] In some embodiments of this application, the step of invoking corresponding prevention or self-recovery processing based on the failure determination result includes the following: the self-recovery processing includes rebuilding the embedded browser, refreshing the tool window, and resending the unacknowledged message by the independent scheduling thread outside the interface thread via the integrated development environment asynchronous scheduling interface; and further includes: When the failure stage determines that the browser's lifecycle is unavailable, the system checks whether the project and the browser have been released before sending a message to the interface, and detects whether the browser is closing or closed by reflection. If the project has been released, the browser has been released, or the browser is closing or has been closed, return failure without injecting scripts, and rebuild the embedded browser instance and refresh the tool window outside the interface thread via the independent scheduling thread through the integrated development environment asynchronous scheduling interface; if asynchronous sending fails or sending queue refresh fails, the message is re-enqueued, and for idempotent messages, only the latest one is retained by type and handed over to the sending queue for resending.

[0017] The second aspect of this application provides a UI thread deadlock detection and self-healing device. The device includes a plug-in logic module, a background configuration synchronization module, a callback listener management module, an embedded browser, and a detection and self-healing controller. The detection and self-healing controller runs in a background task and is an independent scheduling thread that does not depend on the UI thread. It is used to execute the UI thread deadlock detection and self-healing method described in the embodiments of this application.

[0018] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the interface thread deadlock detection and self-healing method described in the embodiments of this application.

[0019] The fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor to implement the interface thread deadlock detection and self-healing method as described in the embodiments of this application.

[0020] The thread deadlock detection and self-healing method provided in this application uses an independent scheduling thread running in the background task of the host integrated development environment and not dependent on the interface thread to identify the deadlock risk of the interface thread's survival status, message sending path, embedded browser lifecycle path, and background synchronization critical path, and obtains de-identified feature fields with hypothesis labels and active detection indicators; it can continuously monitor multiple critical paths in a way that does not depend on the interface thread, and can obtain the feature data required for deadlock risk identification before or during interface thread deadlock, and the data collected by the instrumentation points are de-identified feature fields, without disclosing sensitive data such as tokens, prompt words, and file contents.

[0021] Based on the desensitized feature fields and the active detection indicators, the current deadlock or risk is determined as one of multiple preset failure link categories, and the failure link determination result is obtained; it can accurately distinguish different failure links such as rendering mode risk, browser lifecycle unavailability risk, large message injection risk, background synchronization blocking risk, and listener leakage risk according to the cause, providing a basis for selecting the corresponding prevention or self-recovery processing.

[0022] Based on the failure determination result, the corresponding prevention or self-recovery process is invoked. The self-recovery process includes rebuilding the embedded browser, refreshing the tool window, and resending unacknowledged messages outside the interface thread by the independent scheduling thread through the integrated development environment asynchronous scheduling interface, thereby obtaining the self-healing result. This makes the execution of the self-recovery process independent of the scheduling of the interface thread. Even if the interface thread is locked, the independent scheduling thread can still complete recovery operations such as browser instance reconstruction, window refresh, and message resending outside the interface thread through the asynchronous scheduling interface, achieving true lockout self-healing.

[0023] The self-healing process result is re-verified. If the re-verification fails, the process returns to the stuck risk identification and the prevention or self-recovery process is re-executed to restore the responsiveness of the interface thread. This ensures the effectiveness of the self-healing process result, avoids residual risks caused by incomplete recovery in a single operation, and forms a closed-loop process of detection-judgment-self-healing-re-verification, continuously guaranteeing the responsiveness of the interface thread.

[0024] Overall, this application solves the technical problem of unreliable self-healing under UI thread deadlock, and achieves the technical effect of automatically restoring UI response and message chain without restarting the integrated development environment when UI thread is deadlocked. In internal comparative tests, the sidebar freezing rate was reduced from about 18.7% to 0% after long-term operation, and no user restart or session loss was required.

[0025] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of this application are described below. Attached Figure Description

[0026] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiments below. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This application provides a schematic diagram of the overall architecture and message channel of an intelligent development tool, as shown in some embodiments. Figure 2 A schematic diagram illustrating the steps of a UI thread deadlock detection and self-healing method provided in some embodiments of this application; Figure 3 A flowchart illustrating the overall process of interface thread deadlock detection and self-healing provided in some embodiments of this application; Figure 4 A flowchart illustrating interface message sending guarding and failure re-entry queuing provided for some embodiments of this application; Figure 5 A flowchart of a large message fragmentation encoding injection and interface-side reassembly provided in some embodiments of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0027] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0028] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which embodiments of this application pertain; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the embodiments of this application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings of this application are intended to cover non-exclusive inclusion.

[0029] In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0030] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0031] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0032] In recent years, with the deep integration of AI programming assistants into IDEs, plugin interfaces have generally adopted embedded browsers, with rendering, communication, and configuration synchronization tasks highly concentrated on the UI thread. Although existing solutions attempt to address thread deadlock through event tracking, risk assessment, and self-recovery mechanisms, these solutions suffer from insurmountable flaws: the detection and assessment logic both run on the UI thread, and once the thread is blocked, event tracking cannot be triggered, and assessment cannot be executed; self-recovery operations rely on UI thread scheduling, and the recovery action is frozen after a deadlock; improper timeout settings in background synchronization can also block the UI thread; and accumulated callback listeners can slow down the event loop. More importantly, existing solutions fall into a "self-paradox," where the entity performing self-healing is the locked UI thread itself, rendering the recovery mechanism ineffective. Therefore, there is an urgent need for a solution that does not rely on the UI thread itself and can independently detect and automatically recover from UI thread deadlock.

[0033] Therefore, this application provides a thread deadlock detection and self-healing method, applied to intelligent development tools provided as integrated development environment plugins and internally based on embedded browser rendering of the interactive interface. Figure 1 This is a schematic diagram of the overall architecture and message channel of an intelligent development tool, illustrating the composition of each module within the host integrated development environment process and its connection relationship with the remote configuration server. Figure 1 As shown, the intelligent development tool is deployed as an IDE plugin within the host IDE process (100). The host IDE process (100) includes the following functional modules: Plugin logic module (110): responsible for the core business logic of the intelligent development tool, including communication with the remote large language model service, generation of code completion suggestions, and processing of dialogue interaction. The plugin logic module (110) and the embedded browser (140) communicate bidirectionally through script injection / message channel (160). Specifically, the plugin logic module (110) writes JavaScript script code to the interactive interface side and transmits message data by calling the synchronous injection interface provided by the embedded browser (140). After the interactive interface side completes the processing, it sends the response message back to the plugin logic module (110) through the postMessage mechanism. Background configuration synchronization module (120): responsible for obtaining configuration items such as function switches, model parameters, and prompt word templates from the external remote configuration server (200), and writing the obtained configuration to local storage for the plugin logic module (110) and the interactive interface (141) to read. The background configuration synchronization module (120) and the remote configuration server (200) are connected via network communication, and the synchronization process is initiated by the background task thread. The callback listener management module (130) is responsible for registering callback listeners each time the plugin logic module (110) sends a request message to the embedded browser (140), and managing the removal or retention of listeners after receiving a response message. The lifecycle management of the listeners is dependent on the event dispatch loop of the interface thread.

[0034] Embedded browser (140): As the rendering carrier of the interactive interface (141), it is responsible for rendering and displaying interactive interfaces such as code completion suggestion panel and dialog interaction panel (141). The rendering mode of the embedded browser (140) may be out-of-process rendering or remote rendering architecture, and its instance life cycle may not be synchronized with the project object life cycle of the host IDE.

[0035] The detection and self-healing controller (150) is an independent scheduling thread that runs in the background and does not depend on the interface thread. It is responsible for identifying the risk of deadlock, determining the failure link, triggering the self-recovery process, and re-verifying the critical paths of the above modules. The detection and self-healing controller (150) is the core module that distinguishes this application from the existing solutions. Its independence ensures that even if the interface thread is locked, the detection and self-healing controller (150) can still run normally and trigger the recovery operation.

[0036] In the above architecture, the operation of the plug-in logic module (110), the background configuration synchronization module (120), the callback listener management module (130), and the embedded browser (140) all depend on the scheduling of the interface thread to varying degrees, while the detection and self-healing controller (150) runs on an independent scheduling thread and does not depend on the interface thread, thus breaking the paradoxical dilemma that "the object that needs to be self-healed" is precisely "the subject that performs self-healing." The interactive interface is driven by the interface thread of the host integrated development environment, such as... Figure 2 As shown, the thread deadlock detection and self-healing method includes steps S11-S14: S11. An independent scheduling thread, which runs in the background task of the host integrated development environment and does not depend on the interface thread, identifies the deadlock risk of the interface thread's survival status, message sending path, embedded browser lifecycle path, and background synchronization critical path, and obtains de-identified feature fields with hypothesis labels and active detection indicators.

[0037] In one possible implementation, S11 includes embedding structured tracking points in the message sending path, the embedded browser lifecycle path, and the background synchronization critical path. Each tracking point record has a hypothesis identifier and code location. The hypothesis identifier is used to distinguish different deadlock cause hypotheses and obtain desensitized feature fields. An independent scheduling thread periodically detects the liveness status of the interface thread in a heartbeat detection manner, and counts the blocking time of the interface event distribution loop, the backlog time of the queue to be sent, and the message confirmation waiting time. When at least one of the blocking time, backlog time, and message confirmation waiting time exceeds a preset threshold, it is determined that there is a risk of deadlock and active detection indicators are obtained.

[0038] In practical implementation, taking structured event tracking as an example, structured event tracking is embedded in three critical paths: the message sending path, the embedded browser lifecycle path, and the background synchronization critical path. Each event tracking record carries a hypothesis identifier and code location. The hypothesis identifier is used to distinguish different deadlock trigger hypotheses. For example, hypothesis identifier "H1" corresponds to the rendering mode abnormality hypothesis, hypothesis identifier "H2" corresponds to the browser lifecycle unavailability hypothesis, hypothesis identifier "H3" corresponds to the large message injection hypothesis, hypothesis identifier "H4" corresponds to the background synchronization blocking hypothesis, and hypothesis identifier "H5" corresponds to the listener leakage hypothesis. When an event tracking record is triggered, its hypothesis identifier indicates the possible deadlock trigger associated with the path where the event tracking record is located. The code location records the file name, function name, and line number of the code containing the event tracking record, which is used to locate the specific code location where the deadlock occurred in subsequent analysis. The anonymized feature fields collected by event tracking include, but are not limited to: message type (e.g., completion request, dialog request, configuration refresh), message identifier (whether the request message carries a unique identifier), browser instance identifier (used to determine if the current browser instance is valid), whether the project has been released (used to determine if the host IDE project object has been garbage collected or released), whether the browser is in a released / closed / closing state, message body size (original number of bytes), encoded size (e.g., Base64 encoded number of bytes), whether it is fragmented, the number of fragments, and exception types (e.g., null pointer exception, timeout exception, channel closure exception). It is important to note that the fields collected by event tracking are anonymized, and the following sensitive data is not collected: access token, prompt content, user file content, and complete configuration item data. This design ensures the sufficiency of data required for identifying deadlock risks while avoiding the risk of sensitive data leakage in the detection chain, complying with data security and privacy protection requirements.

[0039] In practice, an independent scheduling thread periodically checks the liveness status of the UI thread using a heartbeat probe. Specifically, the independent scheduling thread sends a heartbeat probe request to the UI thread every preset time interval, such as 500 milliseconds or 1 second. This is done by submitting a lightweight probe task through the event dispatch interface provided by the IDE framework, and recording the timestamp of when the UI thread processes the probe task. If the independent scheduling thread does not receive a response to the heartbeat probe request from the UI thread within a preset waiting time, it determines that the UI thread is at risk of being stuck.

[0040] Simultaneously, an independent scheduling thread tracks the blocking duration of the UI event dispatch loop, the backlog duration of the pending message queue, and the message acknowledgment waiting time. The blocking duration of the UI event dispatch loop is used to track the time taken for a single scheduling operation by the UI thread during the event dispatch loop. If the UI thread fails to complete a single event dispatch loop scheduling operation for an extended period, it indicates that blocking has occurred. For example, a preset threshold of 5 seconds is used; if the blocking duration exceeds 5 seconds, a risk of freezing is identified. For another example... Figure 1As shown, the backlog duration of the message queue is used to count the waiting time of the earliest unsent message in the message queue of the plugin logic module (110) to be sent to the embedded browser (140). If the backlog duration exceeds a preset threshold, such as 3 seconds, it indicates that the message sending channel may be blocked. The waiting time of messages sent by the plugin logic module (110) but for which no response confirmation has been received is also counted. If the message confirmation waiting time exceeds a preset threshold, such as 10 seconds, it indicates that the message channel may be broken or the browser instance may be unavailable.

[0041] When at least one of the aforementioned blocking duration, backlog duration, and message confirmation waiting time exceeds a preset threshold, the independent scheduling thread determines that there is a risk of being stuck and obtains active detection indicators. These active detection indicators, along with passively collected de-identified feature fields, serve as input data for the subsequent failure determination in step S12. It can be understood that by combining passive collection with active detection, this implementation method achieves comprehensive and continuous monitoring of the risk of UI thread being stuck, and the entire process does not depend on the execution capability of the UI thread itself.

[0042] In one specific implementation, deadlock risk identification includes two aspects: passive data collection and active detection. Passive data collection refers to embedding structured tracking points in key paths such as message sending paths, embedded browser lifecycle paths, and background synchronization key paths. Each tracking point record carries a hypothesis identifier and code location information. The collected data includes anonymized feature fields such as message type, message identifier existence, browser instance identifier, whether the project has been released, whether the browser is in a released / closed / closing state, message body size, encoded size, whether it is fragmented, number of fragments, and exception type. Sensitive data such as tokens, prompts, file content, and complete configurations are not collected. Active detection refers to an independent scheduling thread periodically checking the liveness status of the UI thread using a watchdog or heartbeat probe. It calculates metrics such as the blocking duration of the UI event distribution loop, the backlog duration of the pending message queue, and the message confirmation waiting time. When any metric exceeds a preset threshold, a deadlock risk is determined, and active detection metrics are obtained.

[0043] It is important to emphasize that, since the deadlock risk identification is performed by an independent scheduling thread rather than by the UI thread itself, even if the UI thread is locked, the independent scheduling thread can still continuously acquire the on-site feature data when the deadlock occurs, thus solving the problems of the tracking points not being triggered and the detection data being missing after the UI thread is locked in the existing solution.

[0044] S12. Based on the desensitized feature fields and the active detection indicators, the current deadlock or risk is determined as one of multiple preset failure link categories, and the failure link determination result is obtained.

[0045] Specifically, the preset failure categories include rendering mode risk, browser lifecycle unavailability risk, large message injection risk, background synchronization blocking risk, and listener leakage risk. Based on anonymized feature fields and active detection indicators, the current freeze or risk is determined to be one of several preset failure categories, obtaining a failure category determination result. This includes matching the anonymized feature fields and active detection indicators with preset determination conditions for each category, and using the successfully matched category as the failure category determination result. Further, matching the anonymized feature fields and active detection indicators with preset determination conditions for each category, and using the successfully matched category as the failure category determination result, includes: when the blocking duration of the interface event dispatch loop in the active detection indicators exceeds a first preset threshold, the rendering mode risk is determined to be a successful match, obtaining a failure category determination result; for example, the first preset threshold is set to 5 seconds, and when the independent scheduling thread detects that the single scheduling blocking duration of the interface event dispatch loop exceeds 5 seconds, the rendering mode risk is determined to be a successful match. In this case, the freeze may be caused by the embedded browser enabling out-of-process rendering or a remote rendering architecture, leading to rendering pipeline blockage. After a successful match, the failure step is determined as "rendering mode risk," and subsequent step S13 will invoke the rendering mode compatibility and reconstruction mechanism for processing. When the browser instance identifier or project identifier in the desensitized feature field indicates that the browser lifecycle unavailability risk has been successfully matched, the failure step determination result is obtained. If the browser instance identifier collected by the tracking points is null or invalid, indicating that the browser instance has been destroyed, or the project identifier indicates that the host IDE project object has been released, such as the project identifier being null or marked as disposed, then the browser lifecycle unavailability risk has been successfully matched. At this point, the cause of the freeze is... Figure 1 The plugin logic module (110) attempts to inject scripts or send messages to a released browser instance or project object. Upon successful matching, the failure determination result is "browser lifecycle unavailability risk," and subsequent steps will call... Figure 1 Mechanism 2, namely lifecycle guarding and reentry queue, handles the process. When the message body size in the de-identified feature field exceeds the second preset threshold, a successful match for the risk of excessively large message injection is determined, and the failure step determination result is obtained. For example, if the second preset threshold is set to 1MB (megabytes), when the message body size of a message to be sent collected by the tracking point exceeds 1MB, a successful match for the risk of excessively large message injection is determined. At this time, the cause of the deadlock is that the excessively large message body causes the script injection process to block the interface thread for a long time. After a successful match, the failure step determination result is "excessively large message injection risk", and subsequent steps will call... Figure 1 Mechanism 3, namely large message fragmentation encoding injection, is used for prevention. When the background synchronization path tracking point in the de-identified feature field indicates a connection timeout or abnormal response, it is determined that the background synchronization blocking risk has been successfully matched, and the failure link judgment result is obtained; the tracking points on the critical path of background synchronization record... Figure 1 The connection and response status of the back-end configuration synchronization module (120) when executing remote synchronization tasks. If the tracking point indicates a connection timeout (e.g., the network connection is not established within a preset time) or an abnormal response (e.g., the remote configuration server (200) returns an error status code or the response body parsing fails), then the back-end synchronization blocking risk is determined to be successfully matched. At this time, the cause of the deadlock is that the synchronization task blocks the calling thread associated with the interface thread. After successful matching, the failure step is determined as "back-end synchronization blocking risk", and subsequent steps will call Figure 1 Mechanism 4, namely remote configuration synchronization hardening, handles the issue. When the number of listeners in the de-identified feature field exceeds the third preset threshold, the listener leakage risk is determined to be a successful match, and the failure step is determined. For example, if the third preset threshold is set to 100, when the number of active listeners exceeds 100, the listener leakage risk is determined to be a successful match. At this point, the cause of the freeze is that the number of listeners continues to accumulate due to their failure to be removed in time, slowing down the interface event distribution cycle. After a successful match, the failure step determination result is "listener leakage risk," and subsequent steps will call Mechanism 5, namely listener lifecycle governance, for processing.

[0046] The above five matching conditions can be triggered independently or simultaneously. For example, if the duration of the UI event dispatch loop blocking exceeds the first preset threshold and the number of listeners also exceeds the third preset threshold, then the rendering mode risk and the listener leakage risk are matched successfully at the same time. The independent scheduling thread can handle the rendering mode risk first and then the listener leakage risk according to the preset priority, or trigger the two self-healing mechanisms in parallel.

[0047] S13. Based on the failure determination result, call the corresponding prevention or self-recovery process. The self-recovery process includes rebuilding the embedded browser, refreshing the tool window and resending the unacknowledged message outside the interface thread by the independent scheduling thread through the integrated development environment asynchronous scheduling interface, so as to obtain the self-healing result.

[0048] In one specific implementation, based on the failure assessment result, the corresponding prevention or self-recovery process is invoked. The self-recovery process includes rebuilding the embedded browser outside the UI thread by an independent scheduling thread via the IDE's asynchronous scheduling interface, refreshing the tool window, and resending unacknowledged messages. This includes: when the failure assessment result indicates a rendering mode risk, injecting compatibility parameters before the embedded browser initialization and before the browser availability assessment, disabling out-of-process rendering and remote rendering for the affected IDE platform baseline version, causing the embedded browser to fall back to a non-remote rendering architecture; when the failure assessment result indicates a rendering mode risk and runtime detection indicates that the embedded browser is still in remote rendering or the input channel is abnormal, switching rendering parameters, rebuilding the embedded browser instance, and refreshing the tool window by an independent scheduling thread via the IDE's asynchronous scheduling interface outside the UI thread, and resending unacknowledged messages after reconstruction. Specifically, before the embedded browser is initialized and before the browser availability is determined, compatibility parameters are injected to disable out-of-process rendering and remote rendering for the affected integrated development environment platform baseline version, causing the embedded browser to fall back to a non-remote rendering architecture. This includes: obtaining the platform type and version number of the host integrated development environment to determine whether the version number belongs to the affected baseline version; and when the version number belongs to the preset set of affected baseline versions, injecting out-of-process rendering disable flags and remote rendering disable flags into the startup parameters of the embedded browser, so that the embedded browser starts directly in a non-remote rendering architecture during the initialization phase.

[0049] Figure 3 This is a flowchart illustrating the overall process of UI thread deadlock detection and self-healing. Figure 3 As shown, depending on the different failure determination results, the self-healing mechanism in step S13 is distributed to five paths: rendering mode risk response mechanism 1, namely rendering mode compatibility and reconstruction; browser lifecycle unavailability risk response mechanism 2, namely lifecycle guarding and re-entry queuing; large message injection risk response mechanism 3, namely large message fragment encoding injection; background synchronization blocking risk response mechanism 4, namely remote configuration synchronization hardening; and listener leakage risk response mechanism 5, namely listener lifecycle governance.

[0050] In practice, during the prevention phase, when the failure mechanism is determined to be a rendering mode risk, or even as a preventative measure when no freeze occurs, an independent scheduling thread injects compatibility parameters before the embedded browser initialization and before the browser availability check. Compatibility parameters include out-of-process rendering disable flags such as the command-line parameter `--disable-gpu-process` or equivalent API parameters, and remote rendering disable flags such as the command-line parameters `--disable-remote-fonts`, `--disable-remote-playback`, or equivalent rendering parameter configurations. For the baseline version of the affected IDE platform, injecting the above compatibility parameters disables out-of-process and remote rendering, allowing the embedded browser to start directly in a non-remote rendering architecture, i.e., a local rendering architecture, during the initialization phase. The compatibility parameter injection process during the prevention phase includes: First, the independent scheduling thread obtains the platform type and version number of the host IDE. The platform type is used to distinguish different IDE products, as the embedded browser component implementation differs across platform types, and the degree to which it is affected by rendering mode issues also varies. The version number is used to precisely identify the specific version of the IDE, such as "2023.1", "2023.2", etc. Then, an independent scheduling thread determines whether the obtained version number belongs to a pre-defined set of affected baseline versions. The set of affected baseline versions is a pre-determined list of IDE versions that have been tested and verified to cause UI thread freezing issues due to out-of-process rendering or remote rendering. For example, assuming the affected baseline version set is {2023.1, 2023.2, 2023.3}, if the obtained version number is within this set, it is determined to be an affected baseline version. Finally, when the version number belongs to the affected baseline version set, the independent scheduling thread injects out-of-process rendering and remote rendering disable flags into the embedded browser's startup parameters, allowing the embedded browser to start directly with a non-remote rendering architecture during the initialization phase. If the version number does not belong to the affected baseline version set, no compatibility parameters are injected, and the embedded browser starts with the default rendering architecture, avoiding excessive intervention on unaffected versions.

[0051] It's important to note that the key timing for the prevention phase is injecting compatibility parameters "before the browser's availability check." If parameters are injected after the browser's availability check, the browser may have already completed initialization with a remote rendering architecture. Switching parameters at this point would be ineffective and could potentially trigger secondary exceptions. Therefore, this implementation injects compatibility parameters before browser initialization, ensuring that the browser uses a non-remote rendering architecture from startup.

[0052] In another specific implementation, when the failure assessment result indicates a rendering mode risk and the runtime detects that the embedded browser is still in remote rendering or the input channel is abnormal, an independent scheduling thread switches rendering parameters, rebuilds the embedded browser instance, and refreshes the tool window outside the UI thread via the integrated development environment's asynchronous scheduling interface. After reconstruction, it resends unacknowledged messages. This includes: the independent scheduling thread periodically reading the embedded browser's runtime log fields to determine whether the embedded browser is still in a remote rendering architecture or whether the input channel is abnormal; if it is confirmed that the embedded browser is still in a remote rendering architecture or the input channel is abnormal, the independent scheduling thread performs the following operations outside the UI thread via the integrated development environment's asynchronous scheduling interface: switches rendering parameters to revert the embedded browser to a non-remote rendering architecture, destroys the original embedded browser instance and rebuilds a new instance, refreshes the tool window display, and resends unacknowledged messages after reconstruction. The process involves switching rendering parameters to revert the embedded browser to a non-remote rendering architecture, destroying the original embedded browser instance and recreating a new one, refreshing the tool window display, and resending unacknowledged messages after reconstruction. This includes: confirming whether the embedded browser is still in a remote rendering architecture using the rendering mode identifier in the runtime log field; if it is confirmed to still be in a remote rendering architecture, simultaneously setting both out-of-process rendering parameters and remote rendering parameters to "off" to revert the embedded browser to a non-remote rendering architecture; destroying the original embedded browser instance and creating a new one, injecting compatibility parameters into the new instance's startup parameters; and refreshing the tool window and resending unacknowledged messages after the new instance is initialized.

[0053] Specifically, when the compatibility parameter injection during the prevention phase fails to fully take effect, runtime recovery is required. An independent scheduling thread periodically reads the embedded browser's runtime log fields to determine whether the embedded browser is still in a remote rendering architecture or whether the input channel is abnormal. Runtime log fields include, but are not limited to, rendering mode identifiers and input channel status identifiers. The independent scheduling thread reads the runtime log fields every preset time interval, such as 2 seconds. If the rendering mode identifier indicates a remote rendering architecture, the embedded browser is determined to still be in a remote rendering architecture; if the input channel status identifier indicates an abnormality, the input channel is determined to be abnormal. When either of the above conditions is met, the independent scheduling thread confirms that runtime recovery needs to be performed.

[0054] If it is confirmed that the remote rendering architecture is still in progress or the input channel is abnormal, the independent scheduling thread performs the following operations outside the UI thread via the IDE asynchronous scheduling interface: Step 1: Confirm whether the embedded browser is still in a remote rendering architecture by checking the rendering mode identifier in the runtime log field. If the value of the rendering mode identifier field is "remote" or an equivalent value, it is confirmed that it is still in a remote rendering architecture; if it is "local" or an equivalent value, it is confirmed that it is in a non-remote rendering architecture, and no parameter switching is required.

[0055] Step 2: Once it's confirmed that the browser is still in a remote rendering architecture, simultaneously disable both out-of-process rendering parameters and remote rendering parameters to revert the embedded browser to a non-remote rendering architecture. It's crucial that both parameters be disabled simultaneously; disabling only one may lead to inconsistencies in the rendering architecture and introduce new exceptions. For example, if only out-of-process rendering is disabled while remote rendering remains, although the rendering process returns to the main process, rendering operations are still delegated to the remote rendering service, and input channel anomaly issues may persist.

[0056] Step 3: Destroy the original embedded browser instance and create a new instance, injecting the compatibility parameters into the startup parameters of the new instance. When destroying the original instance, ensure that the memory resources, rendering context, and message channels occupied by the original instance are correctly released. When creating the new instance, inject the compatibility parameters, namely the out-of-process rendering disable flag and the remote rendering disable flag, into the startup parameters of the new instance to ensure that the new instance adopts a non-remote rendering architecture from initialization.

[0057] Step 4: After the new instance initialization is complete, refresh the tool window and resend any unacknowledged messages. The criteria for determining whether new instance initialization is complete include: the rendering mode identifier is confirmed to be "local" or an equivalent value, the message channel status is normal, and the rendering context is ready. After the new instance initialization is complete, a separate scheduling thread triggers a tool window refresh, making the interactive interface immediately available. Figure 1 141 is re-rendered and displayed using the new instance as the carrier, and unacknowledged messages are retrieved from the unacknowledged message queue and resent to the new instance. During resending, the unique identifier of the original message is retained so that the interactive interface can recognize the message as a resentment and perform idempotent processing.

[0058] The above operations are executed outside the UI thread through the IDE's asynchronous scheduling interface. Therefore, even if the UI thread is locked due to rendering pipeline blockage, the independent scheduling thread can still complete all recovery operations independently without waiting for the UI thread to resume scheduling. This is the core technical contribution of this application that distinguishes it from existing solutions: the self-healing execution subject, namely the independent scheduling thread, is independent of the self-healed object, namely the UI thread, fundamentally breaking the deadlock dilemma of self-references.

[0059] In another specific implementation, based on the failure assessment result, the corresponding prevention or self-recovery process is invoked. The self-recovery process includes rebuilding the embedded browser, refreshing the tool window, and resending the unacknowledged message outside the UI thread by an independent scheduling thread via the integrated development environment's asynchronous scheduling interface. It also includes: when the failure assessment result indicates a risk of browser lifecycle unavailability, checking whether the project and browser have been released before sending the message to the UI, and detecting the browser's closing or closed state through reflection; if the project, browser, or browser is detected as released, or is closing or closed, returning failure without injecting scripts, and rebuilding the embedded browser instance and refreshing the tool window outside the UI thread by an independent scheduling thread via the integrated development environment's asynchronous scheduling interface; when asynchronous sending fails or the sending queue refresh fails, the message is re-enqueued, and for idempotent messages, only the latest one is retained by type and handed over to the sending queue for resending.

[0060] Figure 4 This is a flowchart illustrating a UI message sending guard and failure re-entry queuing process. It shows the browser availability check before message sending, the idempotent re-entry queuing after sending failure, and the queue retransmission path. When the failure step determines a risk of browser unavailability throughout its lifecycle... Figure 1 Before sending a message to the interactive interface (141), the plugin logic module (110) performs a availability check. The availability check includes the following three sub-checks: (1) Project release check: Check whether the project object of the host IDE has been released. The project object may be released due to the IDE switching projects, closing the panel or performing garbage collection. If the project object has been released, all subsequent operations that depend on the project object will throw an exception. (2) Browser release check: Check whether the embedded browser instance has been released. If the browser instance has been released, subsequent operations that inject scripts or send messages to the instance will fail. (3) Browser closing or closed state detection: Detect whether the embedded browser is in the closing or closed state through reflection mechanism. The necessity of reflection detection is that some IDE platform browser components set internal state flags during the closing process, but these flags may not be exposed through public APIs and need to be obtained by accessing the internal fields of the component through reflection.

[0061] When the plugin logic module (110) detects that the project has been released, the browser has been released, or the browser is closing or has already closed, it returns failure without injecting the script into the browser. This design avoids null pointer references or channel exceptions caused by performing script injection operations when the browser instance is unavailable, thus preventing the UI thread from being blocked. When the browser is detected to be unavailable, an independent scheduling thread rebuilds the embedded browser instance and refreshes the tool window outside the UI thread via the IDE asynchronous scheduling interface. The specific operation is similar to the instance reconstruction process described in Mechanism 1: destroy the original (released or closing) browser instance, create a new instance, inject compatible parameters into the startup parameters of the new instance, and refresh the tool window after the new instance is initialized.

[0062] See Figure 4 When asynchronous sending fails or the sending queue refresh fails, the message is re-enqueued. During re-enqueueing, only the latest idempotent message is retained by type. Idempotent messages are those where multiple sendings of the same type only require the final sending to achieve the desired effect, such as configuration refresh notifications and UI status update notifications. For idempotent messages, if a message of the same type already exists in the queue, the new message replaces the old one, avoiding a backlog of redundant messages of the same type. For non-idempotent messages, such as user dialogue requests, where each message has different content and context, all messages are retained and sent sequentially according to the enqueue order. After re-enqueueing, the message is handed over to the sending queue for retransmission. When the sending queue retransmits, it first checks if the new browser instance is available. If available, the message is retransmitted through the new instance's message channel; if still unavailable, it continues to wait for the new instance to be rebuilt before retransmitting.

[0063] Figure 5 This is a flowchart illustrating a large message fragmentation encoding injection and interface-side reassembly process. It shows the fragmentation encoding write on the program side and the buffer accumulation, reassembly decoding, and delivery process on the interface side. When the failure step determines a risk of excessively large message injection (i.e., the message size exceeds a second preset threshold, such as 1MB), Figure 1The plugin logic module (110) performs fragmented encoding injection processing on the message to avoid the script injection process blocking the interface thread for a long time due to the injection of too large a message body at once. The specific process is as follows: First, the original bytes of the message body are encoded into a Base64 string. Base64 encoding ensures that the binary data in the message body can be safely transmitted through the script injection interface in text form. Then, the Base64 encoded string is divided into multiple fragments according to a fixed fragment size, such as 2MB. Each fragment carries fragment index and total fragment information. Then, a multi-stage script of initialization-write-reassembly-cleanup is injected sequentially through the synchronous injection interface: In the initialization stage, an initialization script is injected into the interactive interface to create a buffer object for receiving fragmented data; In the write stage, a write script for each fragment is injected into the interactive interface sequentially to append the fragmented data to the buffer object; In the reassembly stage, after all fragments are written, a reassembly script is injected into the interactive interface to concatenate all the fragments accumulated in the buffer into a complete Base64 string according to the fragment index order, and then perform Base64 decoding to restore the bytes or objects of the original message body, and then parse it into structured message data and deliver it to the message processing logic of the interactive interface (141); In the cleanup stage, after the reassembly is completed, a cleanup script is injected to release the memory occupied by the buffer object. If an exception occurs in the write or reassembly stage, the cleanup script is also executed to avoid memory leaks.

[0064] S14. Re-verify the self-healing process result. If the re-verification fails, return to the stuck risk identification and re-execute the prevention or self-recovery process to restore the response of the interface thread.

[0065] Re-verification is the process of validating the self-healing results obtained in step S13. For example, for the self-healing results after browser instance reconstruction, re-verification includes checking whether the new browser instance was successfully initialized, whether the message channel was restored to normal operation, and whether unconfirmed messages were successfully resent. If re-verification passes, it is determined that the interface thread has resumed response, and the process ends or enters the next monitoring cycle; if re-verification fails, it returns to step S11 to re-identify the deadlock risk and re-execute the prevention or self-recovery process, forming a closed-loop process of detection-judgment-self-healing-re-verification.

[0066] For example Figure 3 As shown, S11 to S14 form a closed loop, that is... Figure 3 The process involves "S1 detection → S2 judgment → S3 self-healing → S4 re-verification". If S4 re-verification fails, it returns to S1 and continues running until the UI thread becomes responsive again. This closed-loop process is driven by an independent scheduling thread and does not depend on the UI thread itself, therefore it is not affected by UI thread deadlock.

[0067] This application also provides a UI thread deadlock detection and self-healing device in some embodiments, which can be further referred to. Figure 1 The device includes a plug-in logic module, a background configuration synchronization module, a callback listener management module, an embedded browser, and a detection and self-healing controller. The detection and self-healing controller runs as an independent scheduling thread in the background, independent of the UI thread, and is used to execute the UI thread deadlock detection and self-healing method. This device solves the technical problem of unreliable self-healing under UI thread deadlock, achieving the technical effect of automatically restoring UI response and message chain without restarting the integrated development environment when the UI thread is deadlocked. In internal comparative tests, after long-term operation, the sidebar deadlock rate decreased from approximately 18.7% to 0%, without requiring user restart or losing session data.

[0068] In some embodiments of this application, an electronic device is also provided to perform the above-described interface thread deadlock detection and self-healing method. Please refer to... Figure 6 This illustrates a schematic diagram of an electronic device provided by some embodiments of this application. For example... Figure 6 As shown, the electronic device 9 includes: a processor 901, a memory 902, a bus 903 and a communication interface 904. The processor 901, the communication interface 904 and the memory 902 are connected through the bus 903. The memory 902 stores a computer program that can run on the processor 901. When the processor 901 runs the computer program, it executes the interface thread deadlock detection and self-healing method provided in any of the foregoing embodiments of this application.

[0069] The memory 902 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this device network element and at least one other network element is achieved through at least one communication interface 904 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc.

[0070] Bus 903 can be an ISA bus, PCI bus, or EISA bus, etc. Buses can be divided into address buses, data buses, control buses, etc. Memory 902 is used to store programs. After receiving execution instructions, processor 901 executes the program. The interface thread deadlock detection and self-healing method disclosed in any of the aforementioned embodiments of this application can be applied to processor 901, or implemented by processor 901.

[0071] The processor 901 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 901 or by instructions in software form. The processor 901 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or can be executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 902. Processor 901 reads the information in memory 902 and, in conjunction with its hardware, completes the steps of the above method.

[0072] The electronic device provided in this application embodiment and the interface thread deadlock detection and self-healing method provided in this application embodiment are based on the same inventive concept and have the same beneficial effects as the methods they adopt, run or implement.

[0073] This application also provides a computer-readable storage medium corresponding to the interface thread deadlock detection and self-healing method provided in the foregoing embodiments, wherein a computer program (i.e., a program product) is stored thereon. When the computer program is run by a processor, it executes the interface thread deadlock detection and self-healing method provided in any of the foregoing embodiments.

[0074] It should be noted that computer-readable storage media may include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory, optical disc or other optical and magnetic storage media, etc., which will not be elaborated here.

[0075] The computer-readable storage medium provided in this application embodiment and the interface thread deadlock detection and self-healing method provided in this application embodiment are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

[0076] This application also provides a computer program product corresponding to the interface thread deadlock detection and self-healing method provided in the foregoing embodiments, including a computer program that is executed by a processor to implement the above-described interface thread deadlock detection and self-healing method.

[0077] The computer program product provided in this application embodiment is based on the same inventive concept as the interface thread deadlock detection and self-healing method provided in this application embodiment, and has the same beneficial effects as the method implemented by the computer program being executed by the processor.

[0078] It is understood that the description of the various embodiments above tends to emphasize the differences between the various embodiments, and the similarities or similarities can be referred to each other. For the sake of brevity, these will not be repeated here.

[0079] Those skilled in the art will understand that, in the methods described above in specific embodiments, the order in which the steps are written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined based on its function and possible internal logic.

[0080] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application, and they should all be covered within the scope of the claims and specification of this application. In particular, as long as there is no structural conflict, the various technical features mentioned in the embodiments can be combined in any way. This application is not limited to the specific embodiments disclosed herein, but includes all technical solutions falling within the scope of the claims.

Claims

1. A method for detecting and self-healing UI thread deadlock, applied to an intelligent development tool provided as an integrated development environment (IDE) plugin and internally based on an embedded browser for rendering the interactive interface, wherein the interactive interface is driven by the UI thread of the host IDE, characterized in that... The method includes: An independent scheduling thread, which runs in the background task of the host integrated development environment and does not depend on the interface thread, identifies the risk of deadlock in the interface thread's survival status, message sending path, embedded browser lifecycle path, and background synchronization critical path, and obtains de-identified feature fields with hypothesis labels and active detection indicators. Based on the desensitized feature fields and the active detection indicators, the current deadlock or risk is determined as one of multiple preset failure link categories, and the failure link determination result is obtained; Based on the failure determination result, the corresponding prevention or self-recovery process is invoked. The self-recovery process includes rebuilding the embedded browser, refreshing the tool window, and resending the unacknowledged message outside the interface thread by the independent scheduling thread through the integrated development environment asynchronous scheduling interface, so as to obtain the self-healing result. The self-healing process result is re-verified. If the re-verification fails, the process returns to the stuck risk identification and the prevention or self-recovery process is re-executed to restore the responsiveness of the interface thread.

2. The method as described in claim 1, characterized in that, The independent scheduling thread, running in the background tasks of the host integrated development environment and not dependent on the interface thread, identifies the risk of deadlocks by assessing the survival status of the interface thread, message sending paths, embedded browser lifecycle paths, and critical background synchronization paths. This results in de-identified feature fields with hypothesis markers and proactive detection indicators, including: Structured tracking points are embedded in the message sending path, the embedded browser lifecycle path, and the background synchronization critical path. Each tracking point record has a hypothesis identifier and code location. The hypothesis identifier is used to distinguish different deadlock cause hypotheses and obtain de-identified feature fields. The independent scheduling thread periodically detects the liveness status of the interface thread using a heartbeat detection method, and counts the blocking time of the interface event distribution loop, the backlog time of the queue to be sent, and the message confirmation waiting time. When at least one of the blocking time, the backlog time, and the message confirmation waiting time exceeds a preset threshold, it is determined that there is a risk of being stuck, and active detection indicators are obtained.

3. The method as described in claim 1, characterized in that, The preset failure categories include rendering mode risks, browser lifecycle unavailability risks, large message injection risks, background synchronization blocking risks, and listener leakage risks. Based on the de-identified feature fields and the active detection indicators, the current freeze or risk is determined to be one of several preset failure categories, obtaining a failure category determination result, including: The desensitized feature fields and the active detection indicators are matched with preset judgment conditions for each category, and the successfully matched category is taken as the judgment result of the failure link.

4. The method as described in claim 3, characterized in that, The step of matching the desensitized feature fields and the active detection indicators with preset judgment conditions for each category, and taking the successfully matched category as the failure link judgment result, includes: When the blocking duration of the interface event distribution loop in the active detection index exceeds the first preset threshold, the rendering mode risk matching is determined to be successful, and the failure link determination result is obtained. When the browser instance identifier or project identifier in the desensitization feature field indicates that it has been released, it is determined that the browser lifecycle unavailability risk is successfully matched, and the failure link determination result is obtained. When the message body size in the desensitization feature field exceeds the second preset threshold, it is determined that the risk of the ultra-large message injection is successfully matched, and the failure link determination result is obtained. When the background synchronization path embedding point in the desensitization feature field indicates a connection timeout or abnormal response, it is determined that the background synchronization blocking risk is successfully matched, and the failure link determination result is obtained. When the number of listeners in the desensitized feature field exceeds the third preset threshold, it is determined that the listener leakage risk is successfully matched, and the failure link determination result is obtained.

5. The method as described in claim 1, characterized in that, Based on the failure determination result, the corresponding prevention or self-recovery process is invoked. The self-recovery process includes rebuilding the embedded browser, refreshing the tool window, and resending the unacknowledged message outside the interface thread by the independent scheduling thread via the integrated development environment asynchronous scheduling interface, including: When the failure step is determined to be a rendering mode risk, a compatibility parameter is injected before the embedded browser is initialized and before the browser availability is determined. Out-of-process rendering and remote rendering are turned off for the affected integrated development environment platform baseline version, so that the embedded browser falls back to a non-remote rendering architecture. When the failure step is determined to be a rendering mode risk and the embedded browser is detected to be still in remote rendering or the input channel is abnormal during runtime, the independent scheduling thread switches the rendering parameters, rebuilds the embedded browser instance and refreshes the tool window outside the interface thread through the integrated development environment asynchronous scheduling interface. After the reconstruction is completed, the unconfirmed message is resent.

6. The method as described in claim 5, characterized in that, The step of injecting compatibility parameters before the embedded browser initialization and before the browser availability determination, disabling out-of-process rendering and remote rendering for the affected integrated development environment platform baseline version, and causing the embedded browser to fall back to a non-remote rendering architecture, includes: Obtain the platform type and version number of the host integrated development environment to determine whether the version number belongs to the affected baseline version; When the version number belongs to a preset set of affected baseline versions, inject out-of-process rendering disable flags and remote rendering disable flags into the startup parameters of the embedded browser, so that the embedded browser starts directly with a non-remote rendering architecture during the initialization phase.

7. The method as described in claim 5, characterized in that, When the failure assessment result indicates a rendering mode risk and the embedded browser is still in remote rendering or the input channel is abnormal during runtime, the independent scheduling thread switches rendering parameters, rebuilds the embedded browser instance, and refreshes the tool window outside the interface thread via the integrated development environment's asynchronous scheduling interface. After reconstruction, it resends unconfirmed messages, including: The independent scheduling thread periodically reads the runtime log fields of the embedded browser to determine whether the embedded browser is still in a remote rendering architecture or whether the input channel is abnormal. If it is confirmed that the remote rendering architecture is still in place or the input channel is abnormal, the independent scheduling thread performs the following operations outside the interface thread via the integrated development environment asynchronous scheduling interface: switch rendering parameters to make the embedded browser fall back to the non-remote rendering architecture, destroy the original embedded browser instance and rebuild a new instance, refresh the tool window display, and resend the unconfirmed message after the reconstruction is completed.

8. The method as described in claim 7, characterized in that, The switching of rendering parameters causes the embedded browser to fall back to a non-remote rendering architecture, destroy the original embedded browser instance and rebuild a new instance, refresh the tool window display, and resend unconfirmed messages after the reconstruction is complete, including: The rendering mode identifier in the runtime log field can be used to confirm whether the embedded browser is still in a remote rendering architecture. If it is confirmed that the browser is still in a remote rendering architecture, both out-of-process rendering parameters and remote rendering parameters are set to the off state, causing the embedded browser to fall back to a non-remote rendering architecture. Destroy the original embedded browser instance and create a new instance, injecting the compatibility parameters into the startup parameters of the new instance; After the new instance is initialized, refresh the tool window and resend any unconfirmed messages.

9. The method as described in claim 1, characterized in that, Based on the failure determination result, the corresponding prevention or self-recovery process is invoked. The self-recovery process includes rebuilding the embedded browser, refreshing the tool window, and resending the unacknowledged message by the independent scheduling thread outside the interface thread via the integrated development environment asynchronous scheduling interface, and also includes: When the failure stage determines that the browser's lifecycle is unavailable, the system checks whether the project and the browser have been released before sending a message to the interface, and detects whether the browser is closing or closed by reflection. If the project has been released, the browser has been released, or the browser is closing or has been closed, return failure without injecting scripts, and rebuild the embedded browser instance and refresh the tool window outside the interface thread via the independent scheduling thread through the integrated development environment asynchronous scheduling interface; if asynchronous sending fails or sending queue refresh fails, the message is re-enqueued, and for idempotent messages, only the latest one is retained by type and handed over to the sending queue for resending.

10. A device for detecting and self-healing thread deadlock in an interface, characterized in that, The device includes a plug-in logic module, a background configuration synchronization module, a callback listener management module, an embedded browser, and a detection and self-healing controller. The detection and self-healing controller runs in a background task and is an independent scheduling thread that does not depend on the interface thread. It is used to execute the interface thread deadlock detection and self-healing method according to any one of claims 1 to 9.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor runs the computer program to implement the interface thread deadlock detection and self-healing method as described in any one of claims 1-9.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, The computer program is executed by a processor to implement the interface thread deadlock detection and self-healing method as described in any one of claims 1-9.

Images