Bytecode-based thread safety monitoring methods, devices, equipment, and readable media

Abstract

This disclosure provides embodiments of a bytecode-based thread safety monitoring method, apparatus, device, and readable medium. One specific implementation of the method includes: controlling a monitoring module within a thread safety monitoring system to monitor field access operations on a target thread in real time; performing access analysis processing on the field access operations to generate access analysis results; determining the thread type of the accessing thread; generating thread safety issue information corresponding to the field access operation; generating an access report and recording the stack information accessed by the field access operation; adding the stack information to the access report and sending the added access report to a target terminal for display; and terminating the target thread in response to receiving a stop command from the target terminal indicating a thread safety issue. This implementation can promptly terminate access operations when access anomalies occur, thereby protecting the RSM system and improving its operational security.

Description

Technical Field

[0001] Embodiments of this disclosure relate to the field of computer technology, and more specifically to bytecode-based thread safety monitoring methods, apparatus, devices, and readable media. Background Technology

[0002] In Replicated State Machine (RSM) applications, the core thread bears the critical responsibility of state replication. From an RSM system architecture perspective, the core thread needs exclusive access to critical state data, especially static fields. When non-core threads (such as the main thread, scheduled task threads, HTTP threads, etc.) write to this state data, it can lead to inconsistencies in the application state during RSM replay execution, and even cause system crashes. Therefore, how to protect RSM systems has become an important research topic. Currently, the common methods for protecting RSM systems are: using static code analysis tools or AOP aspect-oriented monitoring to monitor and protect the RSM system's state.

[0003] However, when using the above methods to protect RSM systems, the following technical problems often arise:

[0004] When protecting RSM systems, static code analysis tools cannot perceive the actual running state of the program and have difficulty detecting dynamic problems caused by complex thread interactions, resulting in a large number of false positives and false negatives. When using AOP aspect-based monitoring, it is impossible to directly monitor finer-grained operations such as field access, and AOP cannot monitor critical scenarios such as constructors, static initialization blocks, and reflection calls, thus leading to low security of RSM systems.

[0005] The information disclosed in this background section is only intended to enhance the understanding of the background of the inventive concept, and therefore may contain information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0007] Some embodiments of this disclosure provide bytecode-based thread safety monitoring methods, apparatuses, electronic devices, and computer-readable media to address one or more of the technical problems mentioned in the background section above.

[0008] In a first aspect, some embodiments of this disclosure provide a bytecode-based thread safety monitoring method, the method comprising: controlling a monitoring module included in the thread safety monitoring system to monitor field access operations targeting a target thread in real time; in response to detecting a field access operation targeting a target thread, performing access analysis processing on the field access operation to generate an access analysis result; in response to the access analysis result characterizing the access to a static field, determining the thread type of the accessing thread; generating thread safety issue information corresponding to the field access operation based on the thread type of the accessing thread and the field access operation; in response to the thread safety issue information characterizing an access conflict, generating an access report and recording the stack information accessed by the field access operation; adding the stack information to the access report and sending the added access report to a target terminal for display; and in response to receiving a stop instruction sent by the target terminal regarding the thread safety issue information, terminating the target thread.

[0009] Secondly, some embodiments of this disclosure provide a bytecode-based thread safety monitoring device, comprising: a control unit configured to control a monitoring module included in the thread safety monitoring system to monitor field access operations targeting a target thread in real time; an access analysis unit configured to perform access analysis processing on the field access operations in response to the detected field access operations targeting the target thread, to generate access analysis results; a determination unit configured to determine the thread type of the accessing thread in response to the access analysis results indicating access to a static field; a first generation unit configured to generate thread safety problem information corresponding to the field access operation based on the thread type of the accessing thread and the field access operation; a second generation unit configured to generate an access report in response to the thread safety problem information indicating an access conflict, and to record the stack information accessed by the field access operation; an adding unit configured to add the stack information to the access report and send the added access report to a target terminal for display; and a termination unit configured to terminate the target thread in response to receiving a stop instruction sent by the target terminal regarding the thread safety problem information.

[0010] Thirdly, some embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any implementation of the first aspect above.

[0011] Fourthly, some embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method described in any of the implementations of the first aspect above.

[0012] The above embodiments of this disclosure have the following beneficial effects: the bytecode-based thread safety monitoring method of some embodiments of this disclosure improves the operational security of the RSM system. Specifically, the reason for the low operational security of the RSM system is that when protecting the RSM system, static code analysis tools cannot perceive the actual running state of the program and are difficult to detect dynamic problems caused by complex thread interactions, resulting in a large number of false positives and false negatives. When using AOP aspect monitoring, it is impossible to directly monitor finer-grained operations such as field access, and AOP cannot monitor key scenarios such as constructors, static initialization blocks, and reflection calls, thus leading to low security of the RSM system. Based on this, the bytecode-based thread safety monitoring method of some embodiments of this disclosure first controls the monitoring module included in the above thread safety monitoring system to monitor field access operations for the target thread in real time. Thus, field access operations in the RSM system can be monitored in real time. Second, in response to the detection of field access operations for the target thread, access analysis processing is performed on the above field access operations to generate access analysis results. Thus, the type of the access field corresponding to the access operation can be analyzed. Then, in response to the above access analysis results characterizing the accessed static field, the thread type of the accessing thread is determined. Therefore, the thread type of the accessing thread can be determined. Then, based on the thread type and the field access operation, thread safety issue information corresponding to the field access operation is generated. In response to the thread safety issue information indicating an access conflict, an access report is generated, and the stack information of the accessed field is recorded. This allows for timely recording when an access conflict occurs. Next, the stack information is added to the access report, and the updated report is sent to the target terminal for display. This allows the generated information to be sent to staff for processing. Finally, in response to receiving a stop command from the target terminal regarding the thread safety issue, the target thread is terminated. This allows for timely termination of access operations in case of access anomalies, thereby protecting the RSM system and improving its operational security. Attached Figure Description

[0013] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0014] Figure 1 This is a flowchart of some embodiments of the bytecode-based thread safety monitoring method according to this disclosure;

[0015] Figure 2 This is a schematic diagram of the structure of some embodiments of the bytecode-based thread safety monitoring device according to the present disclosure;

[0016] Figure 3 This is a schematic diagram of the structure of an electronic device suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0017] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0018] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0019] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0020] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0021] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0022] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0023] Figure 1 A flow 100 of some embodiments of a bytecode-based thread safety monitoring method according to this disclosure is shown. This bytecode-based thread safety monitoring method includes the following steps:

[0024] Step 101: Control the monitoring module included in the thread safety monitoring system to monitor field access operations for the target thread in real time.

[0025] In some embodiments, the execution entity (e.g., a server) of the bytecode-based thread safety monitoring method can control the monitoring module included in the thread safety monitoring system to monitor field access operations for the target thread in real time. The thread safety monitoring system may include a bytecode enhancement module and a monitoring module. The bytecode enhancement module is used to perform transformation enhancement on the bytecode in the class. The monitoring module is used to monitor field read / write operations of the RSM (Replicated State Machine) application.

[0026] In some optional implementations of certain embodiments, the monitoring module described above may be written through the following steps:

[0027] The first step, in response to the detected startup of the target thread, is to initialize the monitoring environment and parse the preset configuration parameters to generate a set of parsed configuration parameters. These parsed configuration parameters may include, but are not limited to, the target package name and exclusion prefixes.

[0028] The second step is to construct a class converter for the target thread. In practice, this can be done by registering an ASMTransformer with the JVM as a class converter.

[0029] Third, in response to the detection of a class loading operation for the target thread, the class converter is controlled to perform conversion processing on the target class corresponding to the class loading operation to generate a converted class.

[0030] In the process of adopting technical solutions to address the aforementioned technical problems, the following issues often arise: Typically, when writing monitoring modules into the source code, the source code is modified for runtime monitoring. However, modifications to the source code may lead to performance issues or deadlocks due to abnormal situations (e.g., excessively large or small lock granularity). Furthermore, scattered code modifications are difficult to manage and maintain uniformly, resulting in significant performance overhead and wasted performance resources. In light of these technical problems and the current state of available technology, the following solution can be adopted.

[0031] In practice, the class converter described above can be controlled to perform conversion processing on the target class corresponding to the above class loading operation through the following sub-steps:

[0032] The first sub-step involves determining whether to perform a conversion process on the target class based on its class name and the set of parsing configuration parameters. In practice, if the class name of the target class matches the target package name represented in the set of parsing configuration parameters, then the target class is converted.

[0033] The second sub-step involves extracting the bytecode of the target class as initial bytecode in response to the transformation process performed on the target class. Here, ClassReader can be used to extract the bytecode of the target class as initial bytecode.

[0034] The third sub-step involves determining whether the initial bytecode corresponds to an annotation marker. This annotation marker can be the @RsmThreadSafe annotation.

[0035] The fourth sub-step involves determining the field information for each field in the initial bytecode, in response to the annotation markers corresponding to those fields, thus obtaining a field information set. This field information includes field access permissions and modifiers.

[0036] The fifth sub-step involves determining at least one method included in the initial bytecode to generate a method set.

[0037] The sixth sub-step involves identifying at least one field access instruction included in each of the methods in the above method set to generate a field access instruction set.

[0038] The seventh sub-step involves injecting monitoring code into each field access instruction within the generated field access instruction group to generate an injected access instruction group, thus obtaining a set of injected access instruction groups. Here, the aforementioned monitoring code injection process can involve injecting pre-defined monitoring code before or after the aforementioned field access instructions.

[0039] The eighth sub-step involves updating the initial bytecode based on the above-mentioned set of injected access instructions to generate updated initial bytecode, which serves as the conversion class.

[0040] The aforementioned first to eighth sub-steps, as an inventive point of this disclosure, combined with step "Step 107" below, solve the technical problem: "Typically, when writing source code into a monitoring module, the source code is usually modified for monitoring during runtime. However, modifications to the source code may lead to performance issues or deadlocks due to abnormal situations (e.g., excessively large or small lock granularity). Furthermore, scattered code modifications are difficult to manage and maintain uniformly, resulting in significant performance overhead and wasted performance resources." The reasons for thread performance problems or deadlocks, and the waste of performance resources, are as follows: Typically, when writing source code into a monitoring module, the source code is usually modified for monitoring during runtime. However, modifications to the source code may lead to performance problems or deadlocks due to abnormal situations (e.g., excessively large or small lock granularity). Furthermore, scattered code modifications are difficult to manage and maintain uniformly, resulting in significant performance overhead and wasted performance resources. Solving these factors can avoid thread performance problems or deadlocks, and prevent the waste of performance resources. To achieve this effect, this disclosure firstly determines whether to perform a conversion process on the target class based on the class name of the target class and the set of parsing configuration parameters. This confirms whether the target class needs conversion. Secondly, in response to performing a conversion process on the target class, the bytecode of the target class is extracted as initial bytecode. This determines the bytecode of the class. Thirdly, it is determined whether the initial bytecode corresponds to an annotation marker; in response to the initial bytecode corresponding to an annotation marker, the field information of each field in the initial bytecode is determined, resulting in a field information set. This allows for not checking when annotation markers are present. Fourthly, at least one method is identified in the initial bytecode to generate a method set; for each method in the method set, at least one field access instruction is identified to generate a field access instruction group. This determines the access instruction corresponding to each method. Fifthly, monitoring code injection processing is performed on each field access instruction included in the generated field access instruction groups to generate an injected access instruction group, resulting in an injected access instruction group set. Therefore, monitoring code can be injected before and after field access instructions to monitor the method and transmit information such as the current thread, the accessed object instance, class name, field name, and access type. Sixth, based on the injected set of access instructions, the initial bytecode is updated to generate updated initial bytecode, which serves as the conversion class. This completes the injection of monitoring code. Combined with "Step 107," in response to receiving a stop instruction from the target terminal regarding the aforementioned thread safety issue, the target thread is terminated. Thus, when the injected monitoring code detects a safety issue, the thread is terminated, preventing thread performance problems or deadlocks, and avoiding waste of performance resources.

[0041] The fourth step is to generate the complete class bytecode in response to the detection that the conversion is complete.

[0042] Fifth, based on the complete class bytecode described above, start the target thread.

[0043] Step 102: In response to the detection of field access operations targeting the target thread, perform access analysis processing on the field access operations to generate access analysis results.

[0044] In some embodiments, the aforementioned execution entity may, in response to detecting a field access operation targeting a target thread, perform access analysis processing on the field access operation to generate access analysis results. In practice, in response to detecting a field access operation targeting a target thread, the injected pre-defined monitoring code may transmit information related to the target thread, such as the current thread, the accessed object instance, the class name, the field name, and the access type, and determine the field type of the accessed field. The aforementioned field types include static fields and instance fields.

[0045] Step 103: In response to the access analysis results characterizing the accessed static fields, determine the thread type of the accessing thread.

[0046] In some embodiments, the execution entity may determine the thread type of the accessing thread in response to the access analysis results characterizing the accessed static field.

[0047] Optionally, after step 103, the following steps are also included:

[0048] The first step is to determine whether the instance field meets the first preset condition in response to the access analysis results characterizing the access instance field.

[0049] In some embodiments, the execution entity may, in response to the access analysis result characterizing the access instance field, determine whether the instance field meets a first preset condition. The first preset condition may be that the instance field is a field shared between multiple threads.

[0050] In the process of adopting technical solutions to address the aforementioned technical problems, the following issues often arise: When determining whether an instance field is a shared field, it is typically necessary to identify the shared field by recording the thread that accessed the field after it has been accessed, and then record the information of the shared field. However, because information prior to the field access is not recorded, the recorded field access information is incomplete. Faced with these technical problems, and considering the current state of available technology, the following solution can be adopted.

[0051] In some optional implementations of certain embodiments, the execution entity may determine whether the instance field satisfies the first preset condition through the following sub-steps:

[0052] The first sub-step involves determining the number of methods corresponding to the aforementioned instance fields to generate the number of methods. Here, the methods corresponding to the aforementioned instance fields can be methods that access the aforementioned instance fields.

[0053] The second sub-step involves obtaining the configuration information corresponding to the instance fields based on the aforementioned number of methods, serving as the field configuration information. This field configuration information may include, but is not limited to, the modification method and the shared resource pool status. The modification method indicates whether the instance field is modified by `volatile` or `synchronized`. The shared resource pool status indicates whether the instance field is within a thread-shared resource pool (such as a database connection pool). In practice, in response to the aforementioned number of methods being greater than or equal to a preset number, the execution entity can obtain the configuration information corresponding to the instance fields as the field configuration information.

[0054] The third sub-step involves marking the instance field as a potential shared field in response to the above field configuration information satisfying a preset sharing condition. This preset sharing condition may be that the instance field is modified by `volatile` or `synchronized`, or that the instance field is within a thread-shared resource pool (such as a database connection pool).

[0055] The fourth sub-step involves determining the thread source that accessed the potential shared field in response to the detection that the potential shared field has been accessed.

[0056] The fifth sub-step involves determining that, in response to the number of thread sources accessing the potential shared field being greater than or equal to a preset number of threads, the potential shared field is identified as a shared field, and the instance field is determined to satisfy the first preset condition. The preset number of threads may be a pre-set number of threads accessing the potential shared field.

[0057] Optionally, after the fifth sub-step, the following steps may also be included:

[0058] The sixth sub-step involves determining the thread read information corresponding to the aforementioned shared fields. This thread read information includes the read-write ratio and the thread read frequency.

[0059] The seventh sub-step involves performing field lock classification processing on the shared fields based on the information read by the aforementioned threads, in order to generate field lock classification results.

[0060] The eighth sub-step involves selecting a preset field lock from the preset field lock set that corresponds to the above field lock classification results, and using it as the target field lock. This preset field lock may include, but is not limited to, optimistic read locks, pessimistic write locks, and read-write locks.

[0061] The ninth sub-step involves detecting a conversion process for the target class corresponding to the aforementioned instance field, and injecting the target field lock into the aforementioned target class.

[0062] The aforementioned first to ninth sub-steps, as an inventive point of this disclosure, solve the technical problem: "When determining whether an instance field is a shared field, it is usually necessary to determine the shared field by recording the thread accessing the field after the field is accessed, and then record the information of the shared field. However, due to the lack of recording of information before the field is accessed, the recorded field access information is missing." The reason for the missing recorded field access information is as follows: When determining whether an instance field is a shared field, it is usually necessary to determine the shared field by recording the thread accessing the field after the field is accessed, and then record the information of the shared field. However, due to the lack of recording of information before the field is accessed, the recorded field access information is missing. If the above factors are solved, it is possible to avoid thread performance problems or deadlocks, and to avoid wasting performance resources. To achieve this effect, this disclosure firstly determines the number of methods corresponding to the aforementioned instance field to generate a method count. Thus, the number of methods accessing the aforementioned instance field can be determined. Secondly, based on the aforementioned method count, the configuration information corresponding to the aforementioned instance field is obtained as field configuration information. Thus, the information of the aforementioned instance field can be determined. Third, in response to the above field configuration information satisfying the preset sharing conditions, the above instance field is marked as a potential shared field. This determines whether an instance field is a potential shared field. Fourth, in response to detecting that the above potential shared field is accessed, the thread source accessing the above potential shared field is determined. This determines each thread accessing the instance field. Fifth, in response to the number of thread sources accessing the above potential shared field being greater than or equal to a preset number of threads, the above potential shared field is determined as a shared field, and the above instance field is determined to satisfy the above first preset condition. This determines the instance field as a shared field. Sixth, the thread read information corresponding to the above shared field is determined. This determines the thread read information of the shared field after determining the shared field. Seventh, based on the above thread read information, the above shared field is classified into field locks to generate field lock classification results; a preset field lock corresponding to the above field lock classification results is selected from the preset field lock set as the target field lock. This allows for dynamic allocation of read-write locks to shared fields based on different read information, thus avoiding the performance loss of full synchronization when different threads access the field simultaneously through dynamic lock allocation. Eighth, in response to the detection of a conversion process for the target class corresponding to the aforementioned instance field, the lock for the aforementioned target field is injected into the aforementioned target class. This completes the injection of the selected lock, preventing the loss of recorded field access information.

[0063] The second step is to check and process the instance fields in response to the above instance fields meeting the first preset condition.

[0064] In some embodiments, the execution entity may perform a check on the instance field in response to the instance field satisfying the first preset condition.

[0065] Step 104: Generate thread safety issue information for the corresponding field access operation based on the thread type of the accessing thread and the field access operation.

[0066] In some embodiments, the execution entity may generate thread safety issue information corresponding to the field access operation based on the thread type of the access thread and the field access operation.

[0067] In practice, the following steps can be used to generate thread safety issue information corresponding to the above-mentioned field access operations, based on the thread type of the accessing thread and the above-mentioned field access operations:

[0068] The first step is to determine the thread type of the aforementioned access thread. This thread type can include core threads and non-core threads. The core thread can be the main thread. Non-core threads can include, but are not limited to, initialization threads, scheduled task threads, and HTTP service threads.

[0069] The second step, in response to the fact that the thread type of the aforementioned access thread is a core thread, is to determine whether the target field meets the second preset condition. This second preset condition may be whether the target field is stored in the checkAccess method.

[0070] The third step is to obtain at least one historical access operation information corresponding to the target field in response to the above-mentioned second preset condition, so as to obtain a set of historical access operation information.

[0071] Fourth step: In response to the existence of historical access operation information that meets the third preset condition in the above historical access operation information set, mark the above field access operation as an abnormal access operation, wherein the above third preset condition may be that the historical access operation information represents the writing of the above target field by a non-core thread.

[0072] The fifth step is to generate alarm logs corresponding to the above abnormal access operations, and to merge the alarm logs and the access analysis results corresponding to the above field access operations into thread safety issue information.

[0073] Optionally, after step five, the following steps may also be included:

[0074] Step 6: In response to the absence of historical access operation information that meets the third preset condition in the historical access operation information set, generate access operation information corresponding to the above field access operation.

[0075] Step 7: Update the above historical access operation information set based on the above access operation information to generate an updated historical access operation information set.

[0076] Step 105: In response to the access conflict characterization of thread safety issue information, generate an access report and record the stack information accessed by the field access operation.

[0077] In some embodiments, the execution entity may generate an access report and record the stack information accessed by the field access operation in response to the thread safety issue information characterizing the access conflict.

[0078] Step 106: Add the stack information to the access report and send the added access report to the target terminal for display.

[0079] In some embodiments, the execution entity may add the stack information to the access report and send the added access report to the target terminal for display.

[0080] Step 107: In response to receiving a stop instruction from the target terminal regarding thread safety issues, terminate the target thread.

[0081] In some embodiments, the execution entity may terminate the target thread in response to receiving a stop instruction from the target terminal that addresses the thread safety issue.

[0082] The above embodiments of this disclosure have the following beneficial effects: the bytecode-based thread safety monitoring method of some embodiments of this disclosure improves the operational security of the RSM system. Specifically, the reason for the low operational security of the RSM system is that when protecting the RSM system, static code analysis tools cannot perceive the actual running state of the program and are difficult to detect dynamic problems caused by complex thread interactions, resulting in a large number of false positives and false negatives. When using AOP aspect monitoring, it is impossible to directly monitor finer-grained operations such as field access, and AOP cannot monitor key scenarios such as constructors, static initialization blocks, and reflection calls, thus leading to low security of the RSM system. Based on this, the bytecode-based thread safety monitoring method of some embodiments of this disclosure first controls the monitoring module included in the above thread safety monitoring system to monitor field access operations for the target thread in real time. Thus, field access operations in the RSM system can be monitored in real time. Second, in response to the detection of field access operations for the target thread, access analysis processing is performed on the above field access operations to generate access analysis results. Thus, the type of the access field corresponding to the access operation can be analyzed. Then, in response to the above access analysis results characterizing the accessed static field, the thread type of the accessing thread is determined. Therefore, the thread type of the accessing thread can be determined. Then, based on the thread type and the field access operation, thread safety issue information corresponding to the field access operation is generated. In response to the thread safety issue information indicating an access conflict, an access report is generated, and the stack information of the accessed field is recorded. This allows for timely recording when an access conflict occurs. Next, the stack information is added to the access report, and the updated report is sent to the target terminal for display. This allows the generated information to be sent to staff for processing. Finally, in response to receiving a stop command from the target terminal regarding the thread safety issue, the target thread is terminated. This allows for timely termination of access operations in case of access anomalies, thereby protecting the RSM system and improving its operational security.

[0083] Further reference Figure 2 As an implementation of the methods shown in the above figures, this disclosure provides some embodiments of a bytecode-based thread safety monitoring device, which are similar to... Figure 1 Corresponding to the method embodiments shown, this bytecode-based thread safety monitoring device can be specifically applied to various electronic devices.

[0084] like Figure 2As shown, some embodiments of the bytecode-based thread safety monitoring device 200 include: a control unit 201, an access analysis unit 202, a determination unit 203, a first generation unit 204, a second generation unit 205, an addition unit 206, and a termination unit 207. The system includes a control unit configured to control the monitoring module of the thread safety monitoring system to monitor field access operations targeting a target thread in real time; an access analysis unit configured to perform access analysis processing on the field access operations detected for the target thread to generate access analysis results; a determination unit configured to determine the thread type of the accessing thread based on the access analysis results indicating access to a static field; a first generation unit configured to generate thread safety issue information corresponding to the field access operation based on the thread type of the accessing thread and the field access operation; a second generation unit configured to generate an access report and record the stack information accessed by the field access operation in response to the access conflict indicated by the thread safety issue information; an adding unit configured to add the stack information to the access report and send the added access report to the target terminal for display; and a termination unit configured to terminate the target thread in response to receiving a stop command from the target terminal regarding the thread safety issue information.

[0085] It is understandable that the units described in the bytecode-based thread safety monitoring device 200 and the reference Figure 1 The steps in the described method correspond to each other. Therefore, the operations, features, and beneficial effects described above for the method also apply to the bytecode-based thread safety monitoring device 200 and the units contained therein, and will not be repeated here.

[0086] The following is for reference. Figure 3 This document illustrates a structural schematic of an electronic device 300 suitable for implementing some embodiments of the present disclosure. The electronic devices in some embodiments of the present disclosure may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0087] like Figure 3As shown, the electronic device 300 may include a processing unit 301 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0088] Typically, the following devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 3 Each box shown can represent a device or multiple devices as needed.

[0089] In particular, according to some embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 309, or installed from storage device 308, or installed from ROM 302. When the computer program is executed by processing device 301, it performs the functions defined in the methods of some embodiments of this disclosure.

[0090] It should be noted that, in some embodiments of this disclosure, the computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In some embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In some embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0091] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0092] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to: control the monitoring module included in the aforementioned thread safety monitoring system to monitor field access operations targeting a target thread in real time; in response to detecting field access operations targeting a target thread, perform access analysis processing on the field access operations to generate access analysis results; in response to the access analysis results characterizing access to static fields, determine the thread type of the accessing thread; based on the thread type of the accessing thread and the aforementioned field access operations, generate thread safety issue information corresponding to the aforementioned field access operations; in response to the thread safety issue information characterizing access conflicts, generate an access report and record the stack information accessed by the aforementioned field access operations; add the stack information to the aforementioned access report and send the added access report to a target terminal for display; and in response to receiving a stop command from the target terminal regarding the aforementioned thread safety issue information, terminate the aforementioned target thread.

[0093] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0094] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0095] The units described in some embodiments of this disclosure can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor may be described as including a control unit, an access analysis unit, a determination unit, a first generation unit, a second generation unit, an addition unit, and a termination unit. The names of these units do not necessarily limit the specific unit; for example, a control unit may also be described as "a unit that controls the monitoring module included in the aforementioned thread safety monitoring system to monitor field access operations on a target thread in real time."

[0096] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0097] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A bytecode-based thread safety monitoring method, applied to a thread safety monitoring system, the thread safety monitoring system comprising: The monitoring module and bytecode enhancement module, the method includes: The thread safety monitoring system includes a monitoring module that monitors field access operations targeting the target thread in real time. In response to the detection of a field access operation targeting a target thread, the field access operation is subjected to access analysis processing to generate access analysis results; In response to the access analysis results characterizing the accessed static fields, the thread type of the accessing thread is determined; Based on the thread type of the accessing thread and the field access operation, generate thread safety issue information corresponding to the field access operation; In response to the thread safety issue information indicating an access conflict, an access report is generated, and the stack information accessed by the field access operation is recorded; The stack information is added to the access report, and the access report with the added information is sent to the target terminal for display. In response to receiving a stop command from the target terminal regarding the thread safety issue, the target thread is terminated. The monitoring module is written through the following steps: In response to the detection of the target thread's startup operation, the monitoring environment is initialized, and the preset configuration parameters are parsed and processed to generate a set of parsed configuration parameters; Construct a class converter for the target thread; In response to detecting a class loading operation for the target thread, the class converter is controlled to perform conversion processing on the target class corresponding to the class loading operation to generate a converted class; Upon detecting that the conversion is complete, the complete class bytecode is generated; Based on the complete class bytecode, the target thread is started.

2. The method according to claim 1, wherein, After determining the thread type of the target thread in response to the access analysis result characterizing the access static field, the method further includes: In response to the access analysis result characterizing the access instance field, determine whether the instance field meets a first preset condition; In response to the instance field satisfying the first preset condition, the instance field is checked and processed.

3. The method according to claim 1, wherein, The step of generating thread safety issue information corresponding to the field access operation based on the thread type of the accessing thread and the field access operation includes: Determine the thread type of the accessing thread; In response to the fact that the thread type of the accessing thread is a core thread, determine whether the target field meets the second preset condition; In response to the target field not meeting the second preset condition, at least one historical access operation information corresponding to the target field is obtained to obtain a set of historical access operation information; In response to the existence of historical access operation information that meets the third preset condition in the historical access operation information set, the field access operation is marked as an abnormal access operation. Generate alarm logs corresponding to the abnormal access operations, and merge the alarm logs and the access analysis results corresponding to the field access operations into thread safety issue information.

4. The method according to claim 3, wherein, The method further includes: In response to the absence of historical access operation information that satisfies the third preset condition in the historical access operation information set, access operation information corresponding to the field access operation is generated; Based on the access operation information, the historical access operation information set is updated to generate an updated historical access operation information set.

5. A bytecode-based thread safety monitoring system, comprising: The control unit is configured to control the monitoring module included in the thread safety monitoring system to monitor field access operations targeting the target thread in real time. The access analysis unit is configured to perform access analysis processing on the field access operation in response to the detection of a field access operation for a target thread, so as to generate access analysis results; The determining unit is configured to determine the thread type of the access thread in response to the access analysis results characterizing the access static field; The first generation unit is configured to generate thread safety issue information corresponding to the field access operation based on the thread type of the accessing thread and the field access operation. The second generation unit is configured to generate an access report and record the stack information accessed by the field access operation in response to the thread safety issue information characterizing the access conflict. The adding unit is configured to add the stack information to the access report and send the added access report to the target terminal for display. The termination unit is configured to terminate the target thread in response to receiving a stop instruction from the target terminal regarding the thread safety issue; the termination unit is further configured to: In response to the detection of the target thread's startup operation, the monitoring environment is initialized, and the preset configuration parameters are parsed and processed to generate a set of parsed configuration parameters; Construct a class converter for the target thread; In response to detecting a class loading operation for the target thread, the class converter is controlled to perform conversion processing on the target class corresponding to the class loading operation to generate a converted class; Upon detecting that the conversion is complete, the complete class bytecode is generated; Based on the complete class bytecode, the target thread is started.

6. An electronic device, comprising: One or more processors; A storage device on which one or more programs are stored; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1 to 4.

7. A computer-readable medium having a computer program stored thereon, wherein, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 4.

Images