A method and system for real-time monitoring and root cause localization of software defects

Abstract

The application provides a real-time monitoring and root cause positioning method and system for software defects. The method collects real-time monitoring data of software processing threads, generates a thread competition heat map identifying shared resource contention points through time sequence correlation processing; triggers a server memory bus embedded hardware detection device based on the contention points to dynamically capture lock state transition signals, converts them into lock event sequences; sorts and constructs a lock contention trajectory map according to timestamps, and completely displays the process path of the lock mechanism from acquisition to release; constructs a thread and lock dependency topology based on the trajectory map, identifies resource contention chains, maps the contention chains into unsynchronized shared variable access paths in the source code, and triggers real-time alarm signals. The application accurately locates the unsynchronized shared variable access path, improves the lock competition diagnosis efficiency, and reduces the risk of system deadlock to zero.

Description

Technical Field

[0001] This application relates to the field of real-time monitoring and root cause localization technology, and in particular to a method and system for real-time monitoring and root cause localization of software defects. Background Technology

[0002] Modern software systems (such as autonomous driving, industrial control, and high-concurrency services) pose a dual challenge to the real-time nature of defect response and the accuracy of root cause localization: traditional offline debugging cannot capture instantaneous anomalies in highly dynamic environments; and defect propagation paths are difficult to trace in complex dependency scenarios (such as a service timeout triggering cascading failures). Simultaneously, the expansion of system scale renders manual log analysis ineffective, necessitating a method that can correlate multi-source signals in real time and dynamically model defect propagation paths to locate root causes within seconds and prevent fault spread that could lead to system collapse.

[0003] Current targeted solutions rely on a defect monitoring architecture based on real-time constraint verification of non-functional indicators. This approach continuously collects key indicators during system runtime and triggers real-time anomaly detection through preset spatiotemporal constraints. When constraints are violated, it automatically backtracks and correlates data from multiple layers, including CPU scheduling, kernel activity, and middleware status, to generate a full-stack resource Gantt chart at the time of the failure, intuitively presenting the resource contention relationship at the defect trigger point. However, its core weakness lies in its over-reliance on preset non-functional constraint rules, lack of semantic understanding of business logic defects, and the fact that the accuracy of cross-component data sampling is limited by the intrusiveness of system probes, leading to the breakage of some implicit causal chains. Summary of the Invention

[0004] This application provides a method and system for real-time monitoring and root cause localization of software defects, which solves the problems of low efficiency in lock contention diagnosis, ambiguous localization of unsynchronized paths, and loss of control of system-level dead chains in the prior art.

[0005] Firstly, this application provides a method for real-time monitoring and root cause localization of software defects, including:

[0006] Real-time monitoring data of the processing threads during software operation is collected. The real-time monitoring data includes the duration of lock waiting and scheduling sequence information. Temporal correlation processing is performed on the duration of lock waiting and scheduling sequence information to generate a thread contention heatmap. The thread contention heatmap is used to identify points of contention for shared resources.

[0007] Based on the shared resource contention point identified by the identifier, a hardware detection device embedded in the server memory bus is triggered to dynamically capture the lock state transition signal and convert the lock state transition signal into a lock event sequence.

[0008] The timestamps of the locked event sequence are sorted, and a lock contention trajectory diagram is constructed based on the timestamp sorting. The lock contention trajectory diagram fully displays the process path of the locking mechanism from acquisition to release.

[0009] Construct the dependency topology of the processing thread and the locking mechanism based on the lock contention trajectory graph, and identify the resource contention chain in the dependency topology;

[0010] The resource contention chain is mapped to an unsynchronized shared variable access path in the software source code, and a real-time alarm signal is triggered based on the unsynchronized shared variable access path.

[0011] Optionally, real-time monitoring data of the processing threads during software operation is collected. This real-time monitoring data includes the duration of lock-wait and scheduling sequence information. Temporal correlation processing is performed on the lock-wait duration and scheduling sequence information to generate a thread contention heatmap. This heatmap is used to identify points of contention for shared resources, including:

[0012] During software operation, the start and end timestamps of the lock wait for each processing thread are recorded in real time, and the difference between the end timestamp and the start timestamp is calculated as the duration of the lock wait.

[0013] Synchronously capture the scheduling switching events of the processing thread, and record the switching time points of adjacent scheduling switching events to form scheduling sequence information, while extracting the thread scheduling time points of the scheduling sequence information;

[0014] The lock wait duration is mapped to the corresponding thread scheduling time point. When the number of thread scheduling time points covered by the lock wait duration exceeds a preset threshold, the lock wait duration is allocated to each covered thread scheduling time point.

[0015] The lock wait time value allocated to each thread scheduling time point is counted, and the lock wait time value is converted into a heat map value and marked on the corresponding thread scheduling time point;

[0016] The heatmap of all thread scheduling time points is integrated to form a thread contention heatmap that shows the distribution of lock waiting time during thread scheduling. Areas in the thread contention heatmap with heatmap values ​​higher than a preset threshold are marked as shared resource contention points.

[0017] Optionally, based on the identified shared resource contention point, an embedded hardware detection device deployed on the server memory bus is triggered to dynamically capture the lock state transition signal, and the lock state transition signal is converted into a lock event sequence, including:

[0018] When the thermal color level value at the shared resource contention point exceeds a preset trigger threshold, the hardware detection device embedded in the server memory bus is activated.

[0019] The hardware detection device monitors the level change signal in the server memory bus in real time, and records the time point of the upward transition of the level change signal as a lock acquisition event, and the time point of the downward transition of the level as a lock release event.

[0020] The lock acquisition events and lock release events are arranged in timestamp order to form an original event record set;

[0021] The lock acquisition event and lock release event are matched and bound to each other in the original event record set. When the timestamp of the lock release event is greater than the timestamp of the lock acquisition event, a lock event unit is generated.

[0022] The locked event units are arranged in timestamp order to form a locked event sequence.

[0023] Optionally, the timestamps of the locked event sequence are obtained and sorted, and a lock contention trajectory diagram is constructed based on the timestamp sorting. The lock contention trajectory diagram fully displays the process path of the locking mechanism from acquisition to release, including:

[0024] Extract the start timestamp of the lock acquisition event and the end timestamp of the lock release event for each lock event unit in the lock event sequence, and use the start timestamp as the start marker and the end timestamp as the end marker.

[0025] The start and end markers are arranged in time stamp order on the timeline, and a lock holding interval segment is drawn on the timeline for each lock event unit. The start point of the lock holding interval segment is the start marker, and the end point of the lock holding interval segment is the end marker.

[0026] Extract the overlapping area of ​​adjacent locked holding interval segments and mark the resource contention conflict at the overlapping area. When the starting mark of the later locked holding interval is located before the ending mark of the earlier locked holding interval, an overlapping conflict identifier is generated.

[0027] The locked holding interval segments and overlapping conflict identifiers are integrated to form a lock contention trajectory diagram that shows the process path of the locking mechanism from acquisition to release.

[0028] Optionally, a dependency topology of the processing thread and the locking mechanism is constructed based on the lock contention trajectory graph, and resource contention chains in the dependency topology are identified, including:

[0029] Extract the processing thread identifier and locking mechanism identifier corresponding to each lock holding interval line segment in the lock contention trajectory map, and use the processing thread identifier as the processing thread position point and the locking mechanism identifier as the locking mechanism position point.

[0030] A connection line is established between the processing thread location point and the locking mechanism location point to form a dependency topology. The number of connection lines connecting multiple processing thread location points in the dependency topology to the same locking mechanism location point is detected. When the number of connection lines exceeds a preset sharing threshold, the locking mechanism location point is marked as a resource contention core point.

[0031] Using the core point of resource contention as the hub, search for all processing thread locations connected to the core point, and arrange the processing thread locations to form a sequence of resource contention points;

[0032] The adjacent processing thread positions in the resource contention point sequence are connected in series by connecting lines to form a resource contention chain describing multiple processing threads competing for the same locking mechanism.

[0033] Optionally, a connection line is established between the processing thread location point and the locking mechanism location point to form a dependency topology, and the number of connection lines connecting multiple processing thread location points in the dependency topology to the same locking mechanism location point is detected. When the number of connection lines exceeds a preset sharing threshold, the locking mechanism location point is marked as a resource contention core point, including:

[0034] A connection line is drawn between the processing thread location point and the locking mechanism location point to form a dependency topology. The direction of the connection line is from the processing thread location point to the locking mechanism location point, and the connection line represents the dependency relationship of the processing thread on the locking mechanism.

[0035] Iterate through all locking mechanism locations to accumulate the total number of connecting lines connected to each locking mechanism location;

[0036] The total number of connection lines is compared with a preset sharing threshold. When the total number of connection lines exceeds the preset sharing threshold, the locking mechanism location point is marked as the core point of resource contention.

[0037] Optionally, the resource contention chain is mapped to an unsynchronized shared variable access path in the software source code, and a real-time alarm signal is triggered based on the unsynchronized shared variable access path, including:

[0038] Extract the thread identifier of the processing thread and the memory address identifier of the locking mechanism in the resource contention chain, and use the memory address identifier as a memory location marker for shared variables;

[0039] The symbol table generated during the software compilation process is queried, and the variable names and source code file location information recorded in the symbol table are obtained.

[0040] The memory address identifier is matched and bound with the variable name and source code file location information to obtain the source code location point of the shared variable access path;

[0041] The synchronization mechanism status of the shared variable access path is retrieved at the source code location to obtain the unsynchronized shared variable access path;

[0042] When an unsynchronized shared variable access path is detected, the real-time alarm signal generator is activated to generate a real-time alarm signal.

[0043] Secondly, this application provides a real-time monitoring and root cause localization system for software defects, comprising:

[0044] The processing module is used to collect real-time monitoring data of the processing threads during software operation. The real-time monitoring data includes the duration of lock waiting and scheduling sequence information. The module performs time-series correlation processing on the duration of lock waiting and scheduling sequence information to generate a thread contention heatmap. The thread contention heatmap is used to identify points of contention for shared resources.

[0045] The triggering module is used to trigger a hardware detection device embedded in the server memory bus to dynamically capture lock state transition signals based on the shared resource contention point identified by the identifier, and convert the lock state transition signals into a lock event sequence.

[0046] The module is used to obtain the timestamp sorting of the locking event sequence and construct a locking contention trajectory diagram based on the timestamp sorting. The locking contention trajectory diagram fully displays the process path of the locking mechanism from acquisition to release.

[0047] The identification module is used to construct the dependency topology of the processing thread and the locking mechanism based on the lock contention trajectory graph, and to identify the resource contention chain in the dependency topology.

[0048] The mapping module is used to map the resource contention chain to an unsynchronized shared variable access path in the software source code, and to trigger a real-time alarm signal based on the unsynchronized shared variable access path.

[0049] Thirdly, this application provides a computing device, including a processing component and a storage component; the storage component stores one or more computer instructions; the one or more computer instructions are invoked and executed by the processing component to implement a real-time monitoring and root cause localization method for software defects as described in the first aspect above.

[0050] Fourthly, this application provides a computer storage medium storing a computer program, which, when executed by a computer, implements a method for real-time monitoring and root cause localization of software defects as described in the first aspect.

[0051] This application's technical solution achieves accurate diagnosis of software thread contention through multi-source data fusion and intelligent trajectory analysis. Specifically, the thread contention heatmap based on temporal correlation significantly improves the visualization and location capabilities of shared resource contention points; dynamic capture of hardware-level lock state transition signals ensures complete reconstruction of the lock event sequence; and resource contention chain analysis based on topology structure enables intelligent tracing of asynchronous access paths. This method overcomes the lag inherent in traditional log analysis, forming a full-link contention detection system from hardware signals to source code level, effectively improving the debugging efficiency and operational stability of multi-threaded software, and providing real-time decision support for performance optimization of high-concurrency systems.

[0052] Furthermore, precise visualization of multi-threaded resource contention is achieved through time-series data fusion and dynamic heatmap analysis. Specifically, lock wait duration calculation based on precise timestamp alignment ensures quantitative assessment of thread blocking states; the correlation mapping between scheduling events and lock states significantly improves the spatiotemporal resolution of the contention heatmap; and the dynamic annotation mechanism of heatmap color levels intuitively presents the distribution of resource contention in high-concurrency scenarios. This method overcomes the sampling limitations of traditional performance analysis, capturing the coupling relationship between thread scheduling and lock contention at a micro-timescale, providing a high-precision visual diagnostic tool for locating and optimizing software concurrency bottlenecks, and significantly improving the debugging efficiency and operational stability of multi-threaded systems.

[0053] These or other aspects of this application will become more apparent in the following description of the embodiments. Attached Figure Description

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

[0055] Figure 1 A flowchart of a real-time monitoring and root cause localization method for software defects provided in this application is shown;

[0056] Figure 2 A schematic diagram of the structure of a real-time monitoring and root cause localization system for software defects provided in this application is shown.

[0057] Figure 3 A schematic diagram of the structure of a computing device provided in this application is shown. Detailed Implementation

[0058] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0059] In some of the processes described in the specification, claims, and accompanying drawings of this application, multiple operations appearing in a specific order are included. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or may be executed in parallel. The operation numbers, such as 101, 102, etc., are merely used to distinguish different operations and do not themselves represent any execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first," "second," etc., in this document are used to distinguish different messages, devices, modules, etc., and do not represent a chronological order, nor do they limit "first" and "second" to different types.

[0060] Researchers have discovered a fundamental bottleneck in the diagnosis of defects in modern highly dynamic software systems: while monitoring schemes based on non-functional indicator constraints can capture resource contention anomalies, their lack of semantic understanding and broken causal chains lead to inaccurate root cause localization. Specifically, cascading failures caused by business logic defects (such as unsynchronized access to shared variables) are difficult to trace back using resource Gantt charts, and the blind spots in software probe sampling result in a high rate of missed detection of locked state transition signals, making it impossible to fully reconstruct implicit deadlock chains. This contradiction stems from the blind spot in decoupling the micro-mechanisms of thread contention from the semantics of the source code, necessitating the construction of a closed-loop diagnostic architecture that integrates hardware-level signal tracing and code semantic mapping.

[0061] To address the aforementioned challenges, this invention proposes a real-time monitoring and root cause localization method for software defects. Its innovation lies in breaking through the limitations of software probe monitoring by real-time capture of memory bus signals and semantic inversion of contention trajectories. Specifically: It collects thread lock waiting times and scheduling sequences in real time, generating a shared resource contention heatmap through time-series correlation; it triggers embedded hardware probes to dynamically capture memory bus lock state transition signals, constructing a lock event sequence with millisecond-level precision; it reconstructs the lock contention trajectory map based on timestamp sorting, fully presenting the lock mechanism's lifecycle path; and it identifies resource contention chains through topology dependency and accurately maps them to the path of unsynchronized shared variable access in the source code, triggering alarms in real time. This method revolutionizes the traditional monitoring paradigm: the hardware probe achieves lossless capture of nanosecond-level lock state transition signals for the first time; the contention trajectory map reveals hidden deadlock propagation chains that traditional Gantt charts cannot present by visualizing lock contention paths; and the source code mapping engine inversely correlates machine instruction-level events to programming semantics, forming a closed-loop diagnostic chain of "contention monitoring - signal capture - trajectory reconstruction - source code localization," reducing the time required for root cause localization of business logic defects from hours.

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

[0063] Figure 1 This application provides a flowchart of a method for real-time monitoring and root cause localization of software defects, as illustrated in the embodiments of this application. Figure 1 As shown, the method includes:

[0064] 101. Collect real-time monitoring data of the processing threads during software operation. The real-time monitoring data includes the duration of lock waiting and scheduling sequence information. Perform time-series correlation processing on the duration of lock waiting and scheduling sequence information to generate a thread contention heatmap. The thread contention heatmap is used to identify points of contention for shared resources.

[0065] Optionally, step 101 may specifically include the following steps:

[0066] 1011. During software operation, record the start and end timestamps of the lock waiting for each processing thread in real time, and calculate the difference between the end timestamp and the start timestamp as the duration of the lock waiting.

[0067] 1012. Synchronously capture the scheduling switching events of the processing thread, and record the switching time points of adjacent scheduling switching events to form scheduling sequence information, and extract the thread scheduling time points of the scheduling sequence information.

[0068] 1013. Map the lock wait duration to the corresponding thread scheduling time point. When the number of thread scheduling time points covered by the lock wait duration exceeds a preset threshold, allocate the lock wait duration to each covered thread scheduling time point.

[0069] 1014. Calculate the lock waiting time value allocated to each thread scheduling time point, and convert the lock waiting time value into a heat map value and mark it on the corresponding thread scheduling time point.

[0070] 1015. Integrate the heat map color scale annotations of all thread scheduling time points to form a thread contention heat map that shows the distribution of lock waiting time during thread scheduling, and mark the areas in the thread contention heat map with heat map color scale values ​​higher than a preset threshold as shared resource contention points.

[0071] In the above scheme, a processing thread refers to an execution unit in software operation. Real-time monitoring data refers to runtime data collected in real time. Lock wait duration refers to the length of time a thread waits for a lock. Scheduling sequence information refers to the sequential record of thread scheduling. Time-series association processing refers to the processing of data associated in chronological order. Thread contention heatmap refers to a heat map reflecting the distribution of thread contention. Shared resource contention point refers to the location of intense resource contention. Start timestamp refers to the time when lock wait begins. End timestamp refers to the time when lock wait ends. Scheduling switch event refers to the event of thread switching. Thread scheduling time point refers to the specific time of thread scheduling. Heatmap color value refers to the color value representing the intensity of heat. Preset threshold refers to the critical value for judging intense contention. Lock wait duration value refers to the specific time value of lock wait.

[0072] In this embodiment, the system first records the start and end timestamps of the lock waiting for each processing thread in real time during software operation: A lock state monitor tracks lock request events when threads attempt to acquire shared resources. When a thread enters a blocked state due to resource occupancy, the start timestamp (accurate to microseconds) is recorded; when the thread successfully acquires the lock resource, the end timestamp is recorded. The duration calculation engine uses the difference between the two timestamps as the lock waiting duration, which directly quantifies the delay caused by resource contention. This process relies on a high-precision clock source to ensure timestamp synchronization, providing raw delay data for subsequent timing analysis.

[0073] Subsequently, the system synchronously captures thread scheduling switching events and forms scheduling sequence information: the scheduling event hook program intercepts operating system thread switching signals (such as context switching interrupts) and records the precise switching time point of each switch. The sequence construction module arranges consecutive switching events in chronological order, generates scheduling sequence information containing all thread scheduling moments, and extracts the starting point of the time segment allocated for execution of each thread (i.e., the thread scheduling time point). This process employs event stream processing technology to ensure strict alignment of the timelines of scheduling events and lock wait events.

[0074] Next, the system maps the lock wait duration to the corresponding thread scheduling time points: the time mapping algorithm scans the time interval covered by each lock wait duration and identifies all thread scheduling time points contained within that interval. If the number of covered time points exceeds a preset threshold (e.g., a single wait event spans more than 3 thread scheduling events), the wait duration is proportionally allocated to each covered thread scheduling time point. For example, if a 10ms wait covers 5 scheduling time points, each time point is assigned a weight of 10ms / 5ms = 2ms. This process establishes a correlation model between lock waiting and scheduling behavior through time interval matching technology.

[0075] Then, the system calculates the lock wait duration allocated to each thread's scheduling time and converts it into a thermal color scale value: the weight aggregator accumulates all lock wait duration values ​​mapped to the same thread's scheduling time (e.g., if a time point is allocated 3 wait events, its duration is accumulated). The color scale conversion engine converts the accumulated value into the corresponding color-coded value according to a preset thermal color scale mapping table (e.g., red represents high latency, blue represents low latency). This process uses non-linear normalization technology to ensure that wait durations of different orders of magnitude can be intuitively reflected in the color scale changes.

[0076] Finally, the system integrates the heatmap color-gradient annotations of all thread scheduling time points to generate a thread contention heatmap and identify shared resource contention points: the heatmap generator uses the thread scheduling time point as the horizontal axis (time dimension) and the thread ID as the vertical axis (spatial dimension), filling the coordinate grid with the heatmap color-gradient value corresponding to each time point to form the thread contention heatmap. The contention point identification module scans areas in the heatmap where the heatmap color-gradient value is higher than a preset threshold (such as continuous red blocks) and marks them as shared resource contention points (such as hot spots of contention in database connection pools or memory pools). This process transforms abstract competition into a localizable graphical interface through spatiotemporal data visualization technology.

[0077] In practical applications, in high-concurrency scenarios of e-commerce flash sale systems, the system first records the start and end timestamps of the lock waiting for each processing thread in real time (e.g., the lock start and release times of the inventory deduction interface thread during database row lock contention), and calculates the difference between the end and start timestamps as the lock waiting duration (step 1011). Simultaneously, it captures the scheduling switching events of processing threads (e.g., threads suspended or awakened by the operating system due to lock contention), records the switching times of adjacent scheduling switching events to form scheduling sequence information, and extracts the thread scheduling timestamps from the scheduling sequence information (e.g., the time sequence of threads in the ready queue) (step 1012). Then, it maps the lock waiting duration to the corresponding thread scheduling timestamps (e.g., associating a 200ms lock wait with the five thread scheduling timestamps it covers). When the number of thread scheduling timestamps covered by the lock waiting duration exceeds a preset threshold (e.g., the number of covered timestamps exceeds a set value), the lock waiting duration is allocated to each covered thread scheduling timetamp (step 1013). Next, the lock wait duration allocated to each thread scheduling time point is calculated (e.g., a thread is allocated 3 lock waits at a certain time point). This lock wait duration is then converted into a heatmap color value (e.g., the total duration is mapped to a red gradient) and marked on the corresponding thread scheduling time point (step 1014). Finally, the heatmap color values ​​of all thread scheduling time points are integrated (e.g., the heatmap values ​​of thread scheduling events throughout the entire time period are superimposed) to form a thread contention heatmap showing the distribution of lock wait durations during thread scheduling. Areas in the thread contention heatmap with heatmap color values ​​higher than a preset threshold are marked as shared resource contention points (e.g., the database connection pool area is consistently dark red in the heatmap) (step 1015). This heatmap drives performance optimization: shared resource contention points accurately locate database row lock contention hotspots, guiding developers to break down synchronization locks into fine-grained locks; the heatmap distribution of thread scheduling time points can identify thread starvation phenomena (e.g., a thread scheduling time point has a consistently high color value), thereby adjusting thread priority strategies.

[0078] The solution described in step 101 above enables real-time visual monitoring and analysis of software thread contention status. By accurately collecting the locking wait time and scheduling sequence information of processing threads, an innovative thread contention heatmap reflecting the contention for shared resources is constructed. This technology employs timestamp alignment and heatmap color-gradient mapping algorithms to transform the abstract thread scheduling process into an intuitive visual representation, accurately identifying high-contention areas. Through an intelligent judgment mechanism with preset thresholds, key contention points can be quickly located from massive amounts of monitoring data, providing a reliable basis for subsequent in-depth analysis. This technical approach of transforming time-series data into spatial distribution characteristics significantly improves the efficiency of performance diagnosis for multi-threaded software.

[0079] 102. Based on the shared resource contention point identified by the identifier, a hardware detection device embedded in the server memory bus is triggered to dynamically capture the lock state transition signal and convert the lock state transition signal into a lock event sequence.

[0080] Optionally, step 102 may specifically include the following steps:

[0081] 1021. When the thermal color level value at the shared resource contention point exceeds a preset trigger threshold, the hardware detection device embedded in the server memory bus is activated.

[0082] 1022. The hardware detection device monitors the level change signal in the server memory bus in real time, records the time point when the level of the level change signal jumps upward as a lock acquisition event, and the time point when the level jumps downward as a lock release event.

[0083] 1023. Arrange the lock acquisition events and lock release events in timestamp order to form an original event record set.

[0084] 1024. Match and bind adjacent lock acquisition events and lock release events in the original event record set. When the timestamp of the lock release event is greater than the timestamp of the lock acquisition event, generate a lock event unit.

[0085] 1025. Arrange the locked event units in timestamp order to form a locked event sequence.

[0086] In the above scheme, a hardware detection device refers to a device that monitors hardware signals. A lock state transition signal refers to a signal indicating a change in lock state. A lock event sequence refers to lock events arranged chronologically. A preset trigger threshold refers to a critical value that activates the detection device. A level change signal refers to a signal indicating a change in voltage level. A lock acquisition event refers to an event that acquires the lock. A lock release event refers to an event that releases the lock. The raw event record set refers to unprocessed event records. A lock event unit refers to a combination of events that includes both acquisition and release. The timestamp order refers to the order in which events are arranged chronologically.

[0087] In this embodiment, the system first activates the hardware detection device when the heatmap color level value at the shared resource contention point exceeds a preset trigger threshold. When the heatmap color level value (a color-coded value reflecting the intensity of resource contention) corresponding to the shared resource contention point (such as a high-concurrency memory area) identified in the thread contention heatmap generated in step 101 continuously exceeds the preset trigger threshold (a pre-set hardware response threshold), the threshold trigger engine sends an electrical pulse signal to the hardware detection device embedded on the server memory bus, activating its low-power standby state. This process employs a hardware interrupt response mechanism to ensure real-time linkage between heatmap data and hardware operations, providing physical layer support for lockout state monitoring.

[0088] Subsequently, the hardware detection device monitors the voltage level changes in the server's memory bus in real time and records locking events: Once activated, the hardware detection device continuously captures the voltage level changes (high / low voltage transitions) on the memory bus through its high-speed sampling circuitry (such as an ADC analog-to-digital converter). The signal transition analyzer identifies voltage transitions from low to high as upward transitions (indicating the start of lock acquisition) and records their precise timestamps as lock acquisition events; it also identifies voltage transitions from high to low as downward transitions (indicating lock release) and records their timestamps as lock release events. This process relies on nanosecond-level timing stamping technology to ensure that the event timing accuracy meets the requirements of concurrent analysis.

[0089] Next, the system arranges the lock acquisition and lock release events in timestamp order to form a raw event record set: the event sorting engine reads all event timestamps recorded by the hardware detection device (including lock acquisition and lock release events), and rearranges all events in absolute chronological order using a timestamp incrementing algorithm (such as quicksort), generating a linearly ordered raw event record set. This process employs pipelined buffering technology to avoid event loss in high-concurrency scenarios, providing a time-ordered basic dataset for event matching.

[0090] Then, the system matches and binds adjacent lock acquisition and lock release events in the original event record set: the event binding logic scans the original event record set, starting from the lock acquisition event and searching backwards for the nearest lock release event. If its timestamp is greater than the timestamp of the acquisition event (i.e., the release occurred after the acquisition), the two are bound into a single lock event unit (including start and end timestamps and an event type flag). If the release event is missing (e.g., the lock was not released), the unit is marked as an abnormal state. This process uses a greedy matching algorithm to ensure the pairwise association of adjacent events, eliminating fragmented noise in hardware signal acquisition.

[0091] Finally, the system arranges the locked event units in timestamp order to form a locked event sequence: the sequence generation module arranges all successfully bound locked event units in ascending order of their starting timestamps and integrates them into a continuous locked event sequence (such as a "acquire-release-acquire-release" chain structure) using a linked list storage structure. This sequence accurately represents the complete lifecycle of the shared resource from the triggering of contention to its release, providing a structured timeline for subsequent contention analysis.

[0092] In practical applications, in an embedded server memory bus monitoring system, after the system identifies a shared resource contention point (such as a high-heat-level area in the database connection pool region) based on the thread contention heatmap generated in step 101, when the heat-level value at the shared resource contention point exceeds a preset trigger threshold (such as the heat-level value reaching a deep red level), the embedded hardware detection device deployed on the server memory bus is activated (step 1021). This hardware detection device monitors the level change signals in the server memory bus in real time (such as voltage fluctuations in the SDRAM control signal line), records the time points of upward transitions in the level change signals as lock acquisition events (such as a voltage jump from low to high indicating the lock is occupied), and records the time points of downward transitions as lock release events (such as a voltage jump from high to low indicating the lock is released) (step 1022). Subsequently, the lock acquisition and lock release events are arranged in timestamp order to form an original event record set (step 1023). Next, adjacent lock acquisition and lock release events in the original event record set are matched and bound (e.g., event A is a lock acquisition, and event B is its most recent lock release). When the timestamp of the lock release event is greater than the timestamp of the lock acquisition event, a lock event unit is generated (step 1024). Finally, the lock event units are arranged in timestamp order to form a lock event sequence (step 1025). This sequence reveals the essence of resource contention: the continuous generation of lock event units can locate threads with abnormal lock holding times (e.g., a thread's lock duration is continuously abnormal, causing other threads to be blocked), and the time distribution pattern of the lock event sequence can distinguish between short-term lock contention (dense event clusters) and long-term lock holding (sparse long-interval events), providing a hardware-level evidence chain for optimizing lock granularity.

[0093] The scheme described in step 102 above achieves accurate capture and event serialization of hardware-level lock state changes. Based on the triggering mechanism of thread contention heatmap, an innovative low-latency response scheme for embedded hardware detection devices is designed. This technology converts physical signals into logical event records through real-time monitoring of memory bus level changes, constructing a complete lock state transition sequence. An innovative adjacent event matching algorithm ensures the precise correspondence between lock acquisition and release operations, forming event units with strict temporal relationships. This hardware-software collaborative monitoring architecture overcomes the limitations of traditional software probes, providing high-precision time reference data for lock mechanism analysis.

[0094] 103. Obtain the timestamp sorting of the lock event sequence, and construct a lock contention trajectory diagram based on the timestamp sorting. The lock contention trajectory diagram fully displays the process path of the lock mechanism from acquisition to release.

[0095] Optionally, step 103 may specifically include the following steps:

[0096] 1031. Extract the start timestamp of the lock acquisition event and the end timestamp of the lock release event of each lock event unit in the lock event sequence, and use the start timestamp as the start marker and the end timestamp as the end marker.

[0097] 1032. Arrange the start and end markers on the timeline in the order of timestamps, and draw a lock holding interval line segment on the timeline for each lock event unit. The starting point of the lock holding interval line segment is the start marker point, and the ending point of the lock holding interval line segment is the end marker point.

[0098] 1033. Extract the overlapping area of ​​adjacent locked holding interval segments and mark the resource contention conflict at the overlapping area. When the starting mark of the next locked holding interval is located before the ending mark of the previous locked holding interval, generate an overlapping conflict identifier.

[0099] 1034. Integrate the locked holding interval line segments and overlapping conflict identifiers to form a lock contention trajectory diagram that shows the process path of the locking mechanism from acquisition to release.

[0100] In the above scheme, timestamp sorting refers to a sequence of events arranged chronologically. A lock contention trajectory diagram is a graphical representation of the lock contention process. The start timestamp is the time the lock was acquired. The end timestamp is the time the lock was released. The start marker is the marked position where the lock was acquired. The end marker is the marked position where the lock was released. The time axis is a coordinate axis representing time. The lock holding interval segment is the duration of the lock. The overlapping area is an interval that overlaps in time. The resource contention conflict marker is a marker identifying resource conflicts. The overlapping conflict identifier is a symbol representing a conflict. The process path is the complete process of the lock from acquisition to release.

[0101] In this embodiment, the system first extracts the start timestamp of the lock acquisition event and the end timestamp of the lock release event for each lock event unit in the lock event sequence. The system reads the lock event sequence (containing lock event units arranged chronologically) generated in step 102 using a timestamp parsing engine, and separates the start timestamp (precisely recording the start time when the lock is occupied) corresponding to the lock acquisition event and the end timestamp (precisely recording the end time when the lock is released) corresponding to the lock release event from each unit. A marker generator defines the start timestamp as the starting marker point and the end timestamp as the ending marker point, forming key time anchors describing the complete lifecycle of a single lock. This process employs event flow decomposition technology to ensure that the time boundaries of each event unit are accurately extracted, providing basic coordinate data for timeline construction.

[0102] Subsequently, the system arranges the start and end markers on the timeline in timestamp order and draws the lock holding interval line segment: the time alignment engine arranges all start and end markers in ascending order of timestamp on a unified timeline. The line segment drawing module generates a lock holding interval line segment for each lock event unit, with its starting point aligned with the start marker of the unit and its ending point aligned with the end marker of the unit. The length of the line segment visually represents the lock holding duration. This process uses a dynamic coordinate mapping algorithm to transform discrete time points into a continuous interval visualization, forming the spatiotemporal distribution basis of the lock occupancy state.

[0103] Next, the system extracts the overlapping areas of adjacent locked holding interval segments and marks them with resource contention conflict markers: The conflict detection algorithm scans adjacent locked holding interval segments on the time axis and compares the positional relationship between the starting marker point of the later segment and the ending marker point of the previous segment. If the starting marker point of the later segment is detected to be before the ending marker point of the previous segment (i.e., the time intervals overlap), the marker generator immediately generates an overlapping conflict identifier (such as a highlighted red block) in the overlapping area. This process relies on interval intersection determination technology to accurately locate the conflict period when multiple threads are simultaneously competing for the same resource and quantify the intensity of resource contention.

[0104] Finally, the system integrates the lock holding interval segments and overlapping conflict identifiers to form a lock contention trajectory map: the trajectory synthesis engine overlays all lock holding interval segments on the timeline according to thread ID, while embedding overlapping conflict identifiers to mark the resource contention location. The path generation module constructs a complete process path from lock acquisition to release based on the connection relationship between the start and end points of the segments, ultimately generating an interactive lock contention trajectory map. This process uses spatiotemporal topology modeling technology to unify lock state transitions, resource contention conflicts, and thread scheduling behavior into a unified visual diagnostic model, fully revealing the dynamic process of the locking mechanism.

[0105] In practical applications, in high-concurrency scenarios of e-commerce order processing systems, after the system generates a lock event sequence (containing lock event units arranged in timestamp order) based on step 102, it first extracts the start timestamp of the lock acquisition event and the end timestamp of the lock release event for each lock event unit in the lock event sequence (such as the start timestamp of locking and the end timestamp of releasing an order inventory lock). The start timestamp is used as the start marker and the end timestamp as the end marker (step 1031). Subsequently, the start and end markers are arranged in timestamp order on the timeline (such as arranging lock operation events with millisecond precision on the timeline). For each lock event unit, a lock holding interval line segment is drawn on the timeline (such as line segment A representing the time period during which thread A holds the order lock). The starting point of the lock holding interval line segment is the start marker, and the ending point is the end marker (step 1032). Next, the overlapping areas of adjacent locked holding interval segments are extracted (e.g., the end marker of segment A is later than the start marker of segment B). Resource contention conflict markers (e.g., red cross symbols) are marked at the overlapping areas. When the start marker of the later locked holding interval is before the end marker of the earlier locked holding interval, an overlapping conflict identifier is generated (step 1033). Finally, the locked holding interval segments and overlapping conflict identifiers are integrated (e.g., segments A and B are overlaid with conflict markers on a timeline) to form a lock contention trajectory diagram showing the process path of the locking mechanism from acquisition to release (step 1034). This trajectory diagram accurately locates resource contention: overlapping conflict identifiers intuitively show the blocking hotspots of database row locks (e.g., thread blocking in the order submission interface due to lock overlap), and densely overlapping areas of locked holding interval segments reveal the defects of insufficient lock granularity under high concurrency (e.g., inventory locks are not bucketed by order ID), driving developers to refactor the lock allocation strategy (e.g., splitting global locks into order hash sharded locks).

[0106] The solution described in step 103 above achieves a visualized reconstruction of the entire lifecycle trajectory of the locking mechanism. By mapping the timeline of the locking event sequence, a spatiotemporal trajectory map reflecting the lock holding state is innovatively constructed. This technology employs an interval segment overlap detection algorithm to accurately identify conflict periods in resource contention and intuitively presents the intensity of competition using conflict identifiers. This method of transforming discrete events into continuous trajectories fully demonstrates the dynamic process of the locking mechanism from acquisition to release, providing a key analytical tool for understanding resource contention patterns in complex concurrent scenarios.

[0107] 104. Construct the dependency topology of the processing thread and the locking mechanism based on the lock contention trajectory graph, and identify the resource contention chain in the dependency topology.

[0108] Optionally, step 104 may specifically include the following steps:

[0109] 1041. Extract the processing thread identifier and locking mechanism identifier corresponding to each locked holding interval line segment in the locking contention trajectory diagram, and use the processing thread identifier as the processing thread position point and the locking mechanism identifier as the locking mechanism position point.

[0110] 1042. Establish connection lines between the processing thread location point and the locking mechanism location point to form a dependency topology, and detect the number of connection lines connecting multiple processing thread location points in the dependency topology to the same locking mechanism location point. When the number of connection lines exceeds a preset sharing threshold, mark the locking mechanism location point as a resource contention core point.

[0111] Specifically, step 1042 may include the following process: drawing connecting lines between the processing thread location point and the locking mechanism location point to form a dependency topology, wherein the direction of the connecting lines is from the processing thread location point to the locking mechanism location point, and the connecting lines represent the dependency relationship of the processing thread on the locking mechanism; traversing all locking mechanism location points to accumulate the total number of connecting lines connected to the locking mechanism location points; comparing the total number of connecting lines with a preset sharing threshold, and when the total number of connecting lines exceeds the preset sharing threshold, marking the locking mechanism location point as a resource contention core point.

[0112] 1043. Using the resource contention core point as the hub, search for all processing thread locations connected to the core point, and arrange the processing thread locations to form a resource contention point sequence.

[0113] 1044. Connect adjacent processing thread positions in the resource contention point sequence with connecting lines to form a resource contention chain describing multiple processing threads competing for the same locking mechanism.

[0114] In the above scheme, dependency topology refers to the structure reflecting the dependency relationship between threads and locks. Resource contention chain refers to the sequence of threads competing for the same resource. Processing thread identifier refers to the unique code that identifies the thread. Locking mechanism identifier refers to the unique code that identifies the lock. Processing thread location point refers to the node representing the thread. Locking mechanism location point refers to the node representing the lock. Connecting line refers to the line segment representing the dependency relationship. Preset shared threshold refers to the critical value for judging resource contention. Resource contention core point refers to the lock location with intense competition. Resource contention point sequence refers to the sequence of threads competing for the lock. Chaining refers to the process of connecting threads sequentially.

[0115] In this embodiment, the system first extracts the processing thread identifier and locking mechanism identifier corresponding to each lock holding interval segment in the lock contention trajectory graph: The system reads the lock contention trajectory graph generated in step 103 (visually displaying the time interval of thread lock holding) through the identifier resolution engine, and separates the unique processing thread identifier (such as thread ID) and locking mechanism identifier (such as lock name or memory address) from each lock holding interval segment. The coordinate mapping module converts the processing thread identifier into a processing thread location point (representing the thread's coordinates in the topology graph), and simultaneously converts the locking mechanism identifier into a locking mechanism location point (representing the coordinates of the lock resource). This process uses graph node mapping technology to ensure that each entity in the trajectory graph has a unique spatial location in the topology structure, providing a basic node set for dependency modeling.

[0116] Subsequently, the system establishes connections between processing thread locations and locking mechanism locations to form a dependency topology and marks core resource contention points: the topology builder draws a unidirectional connection (direction from thread to lock) between each processing thread location and its dependent locking mechanism location, generating a dependency topology describing the thread-lock dependency relationship. The contention detection algorithm traverses all locking mechanism locations, accumulates the total number of connections (i.e., the number of threads dependent on the lock), and compares the total number with a preset sharing threshold (minimum contention threshold): if the total number exceeds the threshold, the lock coordinates are marked as a core resource contention point (such as a database connection pool lock). This process uses degree centrality analysis to locate highly contentionable lock resources, avoiding blind spots in manual identification.

[0117] Next, the system searches for connected processing thread positions using the resource contention core point as a hub, forming a resource contention point sequence: the core point diffusion module uses the resource contention core point as the center and searches for all processing thread positions directly pointing to that point using an adjacency traversal algorithm. The sequence generator sorts the positions according to the timing or priority rules of thread lock contention (such as first-come, first-served), generating a resource contention point sequence (such as the contention order of threads A→B→C). This process uses breadth-first search technology to ensure that no competing threads are missed, and the sequence accurately reflects the thread contention queue of the core lock resource.

[0118] Finally, the system connects adjacent processing thread positions in the resource contention point sequence to form a resource contention chain: the chain-building engine draws connecting lines between adjacent processing thread positions according to the order of the resource contention point sequence (the direction is from the first competing thread to the next competing thread), integrating them into a resource contention chain describing multiple threads circularly waiting for the same lock (e.g., thread A waits for thread B to release the lock, and thread B waits for thread A). This process uses directed cycle detection technology to transform discrete competition relationships into closed-loop paths, intuitively revealing the topology of deadlocks or high-contention links.

[0119] In practical applications, in distributed file system write lock monitoring scenarios, after the system generates a lock contention trajectory diagram (showing the holding interval segments of file write locks and overlapping conflict identifiers) based on step 103, it first extracts the processing thread identifier and locking mechanism identifier corresponding to each lock holding interval segment in the lock contention trajectory diagram (e.g., the thread A identifier corresponds to the file block write thread, and the locking mechanism identifier corresponds to the distributed file lock). The processing thread identifier is used as the processing thread position point (marked as a circular node in the topology diagram), and the locking mechanism identifier is used as the locking mechanism position point (marked as a square node) (step 1041). Subsequently, a connection line is established between the processing thread position point and the locking mechanism position point to form a dependency topology (e.g., the thread A node points to the file lock node). The direction of the connection line is from the processing thread position point to the locking mechanism position point, and the connection line represents the dependency relationship of the processing thread on the locking mechanism (step 1042). The system iterates through all locking mechanism locations to accumulate the total number of connections between them (e.g., a file lock node is simultaneously connected by threads A, B, and C). The total number of connections is compared to a preset shared threshold. When the total number of connections exceeds the preset shared threshold, the locking mechanism location is marked as a resource contention core point (a file lock is marked as a red core node due to exceeding the connection threshold) (step 1042). Next, using the resource contention core point as a hub (e.g., a file lock node), all processing thread locations connected to the core point are searched (locating nodes for threads A, B, and C). These processing thread locations are arranged to form a resource contention point sequence (in the order of the timestamps of thread lock requests) (step 1043). Finally, adjacent processing thread locations in the resource contention point sequence are connected by lines (e.g., thread A → thread B → thread C) to form a resource contention chain describing multiple processing threads competing for the same locking mechanism (step 1044). This chain reveals the system bottleneck: the resource contention chain clearly shows the blocking queue formed by file writing threads contending for the global file lock (e.g., thread C needs to wait for thread B to release the lock before it can operate on the file block). The high connection density in the topology exposes the design flaws of the lock granularity (e.g., not splitting the lock according to file fragments), driving the developers to reconstruct the global lock into a fragmented lock to eliminate the risk of chain blocking.

[0120] The solution described in step 104 above achieves topological modeling and analysis of multi-threaded resource dependencies. By processing the association between thread and locking mechanism identifiers, an innovative dependency topology reflecting the system's resource contention status is constructed. The core point identification algorithm designed in this technology can intelligently locate nodes with high contention for resources and reveal potential competition chains through connection line analysis. This method of transforming linear event sequences into a networked topology model achieves a leap from local observation to global analysis, providing a system-level analytical perspective for locating the root cause of concurrency bottlenecks.

[0121] 105. Map the resource contention chain to an unsynchronized shared variable access path in the software source code, and trigger a real-time alarm signal based on the unsynchronized shared variable access path.

[0122] Optionally, step 105 may specifically include the following steps:

[0123] 1051. Extract the thread identifier of the processing thread and the memory address identifier of the locking mechanism in the resource contention chain, and use the memory address identifier as a shared variable memory location marker.

[0124] 1052. Query the symbol table records generated during the software compilation process, and obtain the variable names and source code file location information recorded in the symbol table.

[0125] 1053. Match and bind the memory address identifier with the variable name and source code file location information to obtain the source code location point of the shared variable access path.

[0126] 1054. Retrieve the synchronization mechanism status of the shared variable access path at the source code location to obtain the unsynchronized shared variable access path.

[0127] 1055. When an unsynchronized shared variable access path is detected, activate the real-time alarm signal generator to generate a real-time alarm signal.

[0128] In the above scheme, an unsynchronized shared variable access path refers to an unlocked shared variable access path. A real-time alarm signal refers to a warning signal issued immediately. A thread identifier is a unique code that identifies a thread. A memory address identifier is the address of a variable in memory. A shared variable memory location marker is a marker that identifies the location of a shared variable. A symbol table record refers to symbol information generated during compilation. A variable name refers to the variable name in the source code. Source code file location information refers to the location of the variable in the source code. Synchronization mechanism status refers to the synchronization status of variable access. A real-time alarm signal generator is a device that generates alarm signals. A source code location point refers to a specific location in the code.

[0129] In this embodiment, the system first extracts the thread identifiers of the processing threads and the memory address identifiers of the locking mechanisms in the resource contention chain. The resource contention chain resolver reads the chain generated in step 104 (containing the sequential relationship of multiple threads competing for the same lock), separating the unique thread identifier (e.g., thread ID) of each processing thread and the memory address identifier (e.g., the physical memory address of the lock variable) corresponding to the locking mechanism it is competing for. The address tag generator converts the memory address identifiers into shared variable memory location tags (precisely pointing to the storage location of the shared variable in memory), providing a physical layer positioning reference for subsequent source code mapping. This process employs memory address resolution technology to ensure a precise association between concurrent behavior and hardware storage location.

[0130] Subsequently, the system queries the symbol table records generated during the software compilation process to obtain variable information: the symbol table loader calls the symbol table records generated during the compilation phase (a structured database that stores the mapping relationship between variable names, memory addresses, and source code locations), and retrieves the variable names and source code file location information (such as source code file paths and line numbers) associated with the memory address identifiers through the symbol query interface. This process relies on compile-time metadata extraction technology to map binary-level addresses back to high-level language symbols, establishing a bridge between debugging information and runtime entities.

[0131] Next, the system matches and binds memory address identifiers with variable names and source code locations: the address binding engine traverses each entry in the symbol table, comparing the memory address identifier with the memory address value recorded in the symbol table using an address matching algorithm. When the two match perfectly, the location association module binds the shared variable's memory address identifier, variable name, and source code file location information into a triple, generating the source code location point for the shared variable's access path. This process eliminates ambiguous mappings through precise address alignment technology, ensuring a one-to-one correspondence between physical addresses and source code locations.

[0132] Then, the system retrieves the synchronization mechanism status of shared variable access paths at the source code location points: the source code analyzer locates the code region corresponding to the source code location point and scans the code structure near that location point through the syntax tree parser. The synchronization state detector checks for the existence of synchronization mechanisms (such as mutexes, atomic operations, or memory barrier instructions): if the variable access path is not wrapped by a synchronization keyword or does not call a thread-safe API, it is marked as an unsynchronized shared variable access path. This process uses static code analysis techniques to directly identify synchronization defects in the source code.

[0133] Finally, the system activates a real-time alarm signal generator when it detects an unsynchronized shared variable access path: the alarm triggering engine monitors the unsynchronized shared variable access paths output in step 1054 in real time. When at least one path is detected, the signal generation module drives the real-time alarm signal generator (a plugin integrated into the development environment). The alarm encoder encapsulates the variable name, source code location, and risk type into a structured alarm message, which is pushed to the IDE interface and logging system via a cross-process communication protocol, resulting in flashing highlight prompts and beeping alarms. This process uses an event-driven response mechanism to achieve a millisecond-level closed loop from vulnerability identification to real-time intervention.

[0134] In practical applications, in the distributed configuration center management platform, after the system generates a resource contention chain based on step 104 (such as a chain in which configuration update thread A → thread B → thread C compete for the global configuration cache lock), it first extracts the thread identifier of the processing thread and the memory address identifier of the locking mechanism in the resource contention chain (such as the thread identifier of thread A corresponding to the configuration loading thread, and the memory address identifier pointing to the physical memory location of the cache object), and uses the memory address identifier as a shared variable memory location marker (step 1051). The system then queries the symbol table records generated during the software compilation process to obtain the variable names and source code file location information recorded in the symbol table (step 1052). Next, it matches and binds the memory address identifier with the variable name and source code file location information to obtain the source code location point of the shared variable access path (step 1053). The system searches the synchronization mechanism status of the shared variable access path at the source code location point to obtain unsynchronized shared variable access paths (e.g., it finds that the configuration cache read method has not added a synchronization lock) (step 1054). Finally, when an unsynchronized shared variable access path is detected (e.g., it is confirmed that thread B directly reads and writes cache variables without lock protection), the real-time alarm signal generator is activated to generate a real-time alarm signal (step 1055).

[0135] The solution described in step 105 above achieves intelligent diagnosis and real-time early warning of unsynchronized access paths. Through the reverse mapping of resource contention chains to source code, an innovative correlation analysis mechanism between runtime behavior and static code is established. This technology integrates symbol table lookup and synchronization status detection to accurately locate code positions with concurrency risks. The innovative real-time alarm triggering mechanism ensures immediate feedback on potential problems, providing developers with clear targets for rapid remediation. This closed-loop system, combining runtime monitoring with source code analysis, significantly improves the development quality and debugging efficiency of multithreaded software.

[0136] The following are specific examples for steps 101 to 105:

[0137] In distributed database connection pool management scenarios, when the system manages high-concurrency database connections, it first collects real-time monitoring data of the processing threads during software operation (such as the duration of lock waiting for connection request threads and thread scheduling sequence information). By recording the start and end timestamps of the lock waiting for each processing thread in real time and calculating the difference, the duration of lock waiting is obtained. At the same time, the scheduling switching events of processing threads are captured synchronously to form scheduling sequence information. The duration of lock waiting is mapped to the corresponding thread scheduling time point. When the number of covered time points exceeds a preset threshold, a duration value is allocated. The cumulative duration of each time point is counted and converted into a heat map color level value. Finally, the data is integrated to generate a thread contention heat map, where high heat map color level value areas (such as the time point cluster of the connection allocation module) are identified as shared resource contention points. Subsequently, based on the shared resource contention points identified, when the thermal color level value exceeds a preset trigger threshold, an embedded hardware detection device deployed on the server memory bus is activated. This device monitors the level change signals in the server memory bus in real time, recording upward level transitions as lock acquisition events (e.g., a memory bus voltage jump indicates slot occupancy) and downward level transitions as lock release events. Events are sorted by timestamp to form an original event record set. Adjacent events are matched and bound to generate lock event units (lock release timestamp is greater than acquisition timestamp), and finally arranged in sequence to form a lock event sequence. Next, the timestamps of the lock event sequence are sorted, and the start timestamp of the lock acquisition event and the end timestamp of the lock release event of each lock event unit are extracted as start and end markers. Lock holding interval segments are drawn on the timeline (e.g., a segment represents the period when thread A holds a slot). Overlapping areas of adjacent segments are extracted and marked with resource contention conflict markers (an overlap conflict identifier is generated when the start marker of a later segment is before the end marker of a previous segment). These are then integrated to form a lock contention trajectory map, fully displaying the path of the slot from acquisition to release and the blocking hotspots. Then, based on the lock contention trajectory map, the processing thread identifier and locking mechanism identifier corresponding to each lock holding interval segment are extracted as processing thread position points and locking mechanism position points. Directional connection lines are established between position points to form a dependency topology. The total number of connection lines is accumulated by traversing the locking mechanism position points. When the number exceeds a preset shared threshold (e.g., a connection slot node is connected by 5 threads), it is marked as a resource contention core point. The processing thread position points connected by the resource contention core point are searched and sorted by timestamp to form a resource contention point sequence. Adjacent position points are connected to form a resource contention chain (e.g., threads A→B→C compete for the same connection slot).Ultimately, the resource contention chain is mapped to unsynchronized shared variable access paths in the software source code: the thread identifier and the memory address identifier of the locking mechanism are extracted as memory location markers for shared variables, and the symbol table records of the software compilation process are queried to obtain the variable name and source code location; the synchronization mechanism status is retrieved at the source code location point to confirm the unsynchronized shared variable access path (such as the connection counter without lock protection), the real-time alarm signal generator is activated, the risky code line is highlighted in the IDE and the repair process is triggered.

[0138] Figure 2 This application provides a schematic diagram of the structure of a real-time monitoring and root cause localization system for software defects, as shown in the embodiments of this application. Figure 2 As shown, the system includes:

[0139] Processing module 21 is used to collect real-time monitoring data of processing threads during software operation. The real-time monitoring data includes lock waiting duration and scheduling sequence information. The module performs time-series correlation processing on the lock waiting duration and scheduling sequence information to generate a thread contention heatmap. The thread contention heatmap is used to identify shared resource contention points.

[0140] Trigger module 22 is used to trigger a hardware detection device embedded in the server memory bus to dynamically capture a locked state transition signal based on the shared resource contention point identified by the identifier, and convert the locked state transition signal into a locked event sequence.

[0141] Module 23 is used to obtain the timestamp sorting of the locking event sequence and construct a locking contention trajectory diagram based on the timestamp sorting. The locking contention trajectory diagram fully displays the process path of the locking mechanism from acquisition to release.

[0142] The identification module 24 is used to construct the dependency topology of the processing thread and the locking mechanism based on the locking contention trajectory graph, and to identify the resource contention chain in the dependency topology.

[0143] The mapping module 25 is used to map the resource contention chain to an unsynchronized shared variable access path in the software source code, and to trigger a real-time alarm signal based on the unsynchronized shared variable access path.

[0144] Figure 2 The aforementioned real-time monitoring and root cause localization system for software defects can perform... Figure 1 The implementation principle and technical effects of the real-time monitoring and root cause localization method for software defects described in the illustrated embodiment will not be repeated here. The specific methods by which each module and unit performs its operations in the real-time monitoring and root cause localization system for software defects described in the above embodiments have been described in detail in the embodiments related to this method, and will not be elaborated upon here.

[0145] In one possible design, Figure 2 The real-time monitoring and root cause localization system for software defects shown in the embodiment can be implemented as a computing device, such as... Figure 3 As shown, the computing device may include a storage component 31 and a processing component 32;

[0146] The storage component 31 stores one or more computer instructions, wherein the one or more computer instructions are invoked and executed by the processing component 32.

[0147] The processing component 32 is used for the above Figure 1 The embodiment describes a method for real-time monitoring and root cause localization of software defects.

[0148] The processing component 32 may include one or more processors to execute computer instructions to complete all or part of the steps in the above-described method. Alternatively, the processing component may be implemented as one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above-described method.

[0149] Storage component 31 is configured to store various types of data to support operations at the terminal. The storage component can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0150] Of course, computing devices may also include other components, such as input / output interfaces, display components, communication components, etc.

[0151] Input / output interfaces provide interfaces between processing components and peripheral interface modules, which can be output devices, input devices, etc.

[0152] The communication components are configured to facilitate wired or wireless communication between computing devices and other devices.

[0153] The computing device can be a physical device or an elastic computing host provided by a cloud computing platform. In this case, the computing device can refer to a cloud server, and the aforementioned processing components, storage components, etc., can be basic server resources rented or purchased from the cloud computing platform.

[0154] This application also provides a computer storage medium storing a computer program, which, when executed by a computer, can perform the above-described functions. Figure 1 The embodiment shown illustrates a method for real-time monitoring and root cause localization of software defects.

[0155] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0156] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0157] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0158] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended 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 of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for real-time monitoring and root cause localization of software defects, characterized in that, include: Real-time monitoring data of the processing threads during software operation is collected. The real-time monitoring data includes the duration of lock waiting and scheduling sequence information. Temporal correlation processing is performed on the duration of lock waiting and scheduling sequence information to generate a thread contention heatmap. The thread contention heatmap is used to identify points of contention for shared resources. Based on the shared resource contention point identified by the identifier, a hardware detection device embedded in the server memory bus is triggered to dynamically capture the lock state transition signal and convert the lock state transition signal into a lock event sequence. This includes: activating the hardware detection device embedded in the server memory bus when the thermal color level value at the shared resource contention point exceeds a preset trigger threshold; the hardware detection device monitors the level change signal in the server memory bus in real time, recording the time point of the level change signal's upward transition as a lock acquisition event and the time point of the level transition downward as a lock release event; arranging the lock acquisition and lock release events in timestamp order to form an original event record set; matching and binding adjacent lock acquisition and lock release events in the original event record set, generating a lock event unit when the timestamp of the lock release event is greater than the timestamp of the lock acquisition event; and arranging the lock event units in timestamp order to form a lock event sequence. The timestamps of the locked event sequence are sorted, and a lock contention trajectory diagram is constructed based on the timestamp sorting. The lock contention trajectory diagram fully displays the process path of the locking mechanism from acquisition to release. Constructing a dependency topology of the processing threads and locking mechanisms based on the lock contention trajectory diagram, and identifying resource contention chains in the dependency topology, includes: extracting the processing thread identifier and locking mechanism identifier corresponding to each lock holding interval line segment in the lock contention trajectory diagram; using the processing thread identifier as the processing thread position point and the locking mechanism identifier as the locking mechanism position point; establishing connecting lines between the processing thread position points and the locking mechanism position points to form a dependency topology, and detecting the number of connecting lines connecting multiple processing thread position points to the same locking mechanism position point in the dependency topology; when the number of connecting lines exceeds a preset sharing threshold, marking the locking mechanism position point as a resource contention core point; using the resource contention core point as a hub, searching for all processing thread position points connected to the core point, and arranging the processing thread position points to form a resource contention point sequence; connecting adjacent processing thread position points in the resource contention point sequence to form a resource contention chain describing multiple processing threads competing for the same locking mechanism; The resource contention chain is mapped to an unsynchronized shared variable access path in the software source code, and a real-time alarm signal is triggered based on the unsynchronized shared variable access path.

2. The method according to claim 1, characterized in that, Real-time monitoring data of processing threads during software operation is collected. This real-time monitoring data includes the duration of lock-wait and scheduling sequence information. Timing correlation processing is performed on the lock-wait duration and scheduling sequence information to generate a thread contention heatmap. This heatmap is used to identify points of contention for shared resources, including: During software operation, the start and end timestamps of the lock wait for each processing thread are recorded in real time, and the difference between the end timestamp and the start timestamp is calculated as the duration of the lock wait. Synchronously capture the scheduling switching events of the processing thread, and record the switching time points of adjacent scheduling switching events to form scheduling sequence information, while extracting the thread scheduling time points of the scheduling sequence information; The lock wait duration is mapped to the corresponding thread scheduling time point. When the number of thread scheduling time points covered by the lock wait duration exceeds a preset threshold, the lock wait duration is allocated to each covered thread scheduling time point. The lock wait time value allocated to each thread scheduling time point is counted, and the lock wait time value is converted into a heat map value and marked on the corresponding thread scheduling time point; The heatmap of all thread scheduling time points is integrated to form a thread contention heatmap that shows the distribution of lock waiting time during thread scheduling. Areas in the thread contention heatmap with heatmap values ​​higher than a preset threshold are marked as shared resource contention points.

3. The method according to claim 1, characterized in that, The timestamps of the locked event sequence are sorted, and a lock contention trajectory diagram is constructed based on the timestamp sorting. The lock contention trajectory diagram fully displays the process path of the locking mechanism from acquisition to release, including: Extract the start timestamp of the lock acquisition event and the end timestamp of the lock release event for each lock event unit in the lock event sequence, and use the start timestamp as the start marker and the end timestamp as the end marker. The start and end markers are arranged in time stamp order on the timeline, and a lock holding interval segment is drawn on the timeline for each lock event unit. The start point of the lock holding interval segment is the start marker, and the end point of the lock holding interval segment is the end marker. Extract the overlapping area of ​​adjacent locked holding interval segments and mark the resource contention conflict at the overlapping area. When the starting mark of the later locked holding interval is located before the ending mark of the earlier locked holding interval, an overlapping conflict identifier is generated. The locked holding interval segments and overlapping conflict identifiers are integrated to form a lock contention trajectory diagram that shows the process path of the locking mechanism from acquisition to release.

4. The method according to claim 1, characterized in that, A connection line is established between the processing thread location point and the locking mechanism location point to form a dependency topology. The number of connection lines connecting multiple processing thread location points in the dependency topology to the same locking mechanism location point is detected. When the number of connection lines exceeds a preset sharing threshold, the locking mechanism location point is marked as a resource contention core point, including: A connection line is drawn between the processing thread location point and the locking mechanism location point to form a dependency topology. The direction of the connection line is from the processing thread location point to the locking mechanism location point, and the connection line represents the dependency relationship of the processing thread on the locking mechanism. Iterate through all locking mechanism locations to accumulate the total number of connecting lines connected to each locking mechanism location; The total number of connection lines is compared with a preset sharing threshold. When the total number of connection lines exceeds the preset sharing threshold, the locking mechanism location point is marked as the core point of resource contention.

5. The method according to claim 1, characterized in that, The resource contention chain is mapped to an unsynchronized shared variable access path in the software source code, and a real-time alarm signal is triggered based on the unsynchronized shared variable access path, including: Extract the thread identifier of the processing thread and the memory address identifier of the locking mechanism in the resource contention chain, and use the memory address identifier as a memory location marker for shared variables; The symbol table generated during the software compilation process is queried, and the variable names and source code file location information recorded in the symbol table are obtained. The memory address identifier is matched and bound with the variable name and source code file location information to obtain the source code location point of the shared variable access path; The synchronization mechanism status of the shared variable access path is retrieved at the source code location to obtain the unsynchronized shared variable access path; When an unsynchronized shared variable access path is detected, the real-time alarm signal generator is activated to generate a real-time alarm signal.

6. A real-time monitoring and root cause localization system for software defects, applied to the real-time monitoring and root cause localization method for software defects according to any one of claims 1-5, characterized in that, include: The processing module is used to collect real-time monitoring data of the processing threads during software operation. The real-time monitoring data includes the duration of lock waiting and scheduling sequence information. The module performs time-series correlation processing on the duration of lock waiting and scheduling sequence information to generate a thread contention heatmap. The thread contention heatmap is used to identify points of contention for shared resources. The triggering module is used to trigger a hardware detection device embedded in the server memory bus to dynamically capture lock state transition signals based on the shared resource contention point identified by the identifier, and convert the lock state transition signals into a lock event sequence. The module is used to obtain the timestamp sorting of the locking event sequence and construct a locking contention trajectory diagram based on the timestamp sorting. The locking contention trajectory diagram fully displays the process path of the locking mechanism from acquisition to release. The identification module is used to construct the dependency topology of the processing thread and the locking mechanism based on the lock contention trajectory graph, and to identify the resource contention chain in the dependency topology. The mapping module is used to map the resource contention chain to an unsynchronized shared variable access path in the software source code, and to trigger a real-time alarm signal based on the unsynchronized shared variable access path.

7. A computing device, characterized in that, It includes a processing component and a storage component; the storage component stores one or more computer instructions; the one or more computer instructions are invoked and executed by the processing component to implement a real-time monitoring and root cause localization method for software defects as described in any one of claims 1 to 5.

8. A computer storage medium, characterized in that, The device contains a computer program that, when executed by a computer, implements a method for real-time monitoring and root cause localization of software defects as described in any one of claims 1 to 5.

Images