Thread identification method and apparatus, electronic device, storage medium, program product

Abstract

The present disclosure relates to a thread identification method and device, an electronic device, a storage medium and a program product. To solve the problem of poor thread identification effect of Go program related tasks, the present disclosure provides a thread identification method, which comprises: in the case where a Go program is executed, obtaining thread related information based on a scheduling path of a Go runtime, wherein the scheduling path is at least one key function called by the Go runtime during execution of the Go program, and the thread related information is information related to a thread hitting the scheduling path, and at least includes identification information of the thread; obtaining identification information of a current thread based on a target path of a kernel, and identifying whether the current thread is a thread executing a Go program related task based on the identification information of the current thread and the thread related information, thereby accurately and efficiently identifying whether the current thread is a thread executing a Go program related task, and improving the thread identification effect.

Description

Technical Field

[0001] This disclosure relates to the field of computers, and more particularly to a thread identification method, thread identification device, electronic device, storage medium, and program product. Background Technology

[0002] Go is widely used in cloud computing, network services, middleware, and distributed systems. Go programs use Goroutines as the primary concurrent entities, scheduled in user space by the Go runtime. The operating system kernel can schedule the threads that execute Goroutines. This runtime model gives Go programs high concurrency capabilities, but it also makes it difficult for the kernel to identify the threads executing Go program tasks, hindering targeted optimizations such as dedicated scheduling, resource management, and runtime statistics. Current technologies attempt to identify threads through process names, command-line arguments, ELF (Executable and Linkable Format) file information, thread creation paths, system call patterns, call stack backtracking, static signatures, sampling profiling, symbol resolution, debugging information, or offline log analysis. However, these methods are either inaccurate, costly, inefficient, or only work offline, resulting in poor performance in identifying threads executing Go program tasks and failing to meet user needs. Therefore, a better technology for identifying threads executing Go program tasks is urgently needed. Summary of the Invention

[0003] This disclosure provides a thread identification method, thread identification device, electronic device, storage medium, and program product to at least solve the problem of poor thread identification performance for Go program-related tasks in the related art.

[0004] According to a first aspect of the present disclosure, a thread identification method is provided. The thread identification method may include: when a Go program is executed, obtaining thread-related information based on the scheduling path of the Go runtime, wherein the scheduling path is at least one key function called by the Go runtime during the execution of the Go program, and the thread-related information is information related to the thread that hits the scheduling path, and includes at least the identification information of the thread; obtaining the identification information of the current thread based on the kernel's target path, and identifying whether the current thread is a thread executing a Go program-related task based on the identification information of the current thread and the thread-related information, wherein the Go program-related task is a thread task related to the execution of the Go program.

[0005] Optionally, obtaining thread-related information based on the Go runtime's scheduling path may include: detecting whether the scheduling path is hit by a thread through at least one first observation point, wherein the at least one first observation point is deployed on the scheduling path based on eBPF (extended Berkeley Packet Filter); in response to detecting that the scheduling path is hit by a thread, running a first eBPF program to collect the thread-related information and recording the thread-related information in the eBPF map.

[0006] Optionally, obtaining the identification information of the current thread based on the kernel target path may include: detecting whether the kernel target path is hit by the current thread through at least one second observation point, wherein the at least one second observation point is deployed on the target path based on eBPF; and in response to detecting that the target path is hit by the current thread, running a second eBPF program to obtain the identification information of the current thread.

[0007] Optionally, identifying whether the current thread is executing a Go program-related task based on the current thread's identification information and the thread-related information may include: querying the thread-related information to see if there is identification information matching the current thread's identification information; identifying the current thread as not executing a Go program-related task in response to the absence of identification information matching the current thread's identification information in the thread-related information; and identifying the current thread as executing a Go program-related task in response to the presence of identification information matching the current thread's identification information in the thread-related information, or in response to the presence of identification information matching the current thread's identification information in the thread-related information and the satisfaction of a predetermined condition related to the thread-related information.

[0008] Optionally, the predetermined conditions may include at least one of the following: the number of times the scheduling path is hit by the current thread exceeds a threshold; the thread-related information is within its validity period.

[0009] Optionally, the thread identification method may further include: when it is identified that the current thread is a thread executing a Go program-related task, saving the identification result in a state that the kernel can read, wherein the identification result includes information indicating that the current thread is a thread executing a Go program-related task or information indicating that the process to which the current thread belongs is a process executing a Go program-related task, wherein saving the identification result in a state that the kernel can read includes: saving the identification result in a kernel-mode data structure, wherein the kernel-mode data structure includes the kernel's inherent task structure or extended task structure; saving the identification result in a newly created kernel map of the task type; or, saving the identification result in the process-level cache corresponding to the current thread.

[0010] Optionally, the thread-related information may further include at least one of the following: the identification information of the process to which the thread that hits the scheduling path belongs; the current timestamp when the scheduling path is hit by the thread; the number of times the scheduling path is hit by the thread; the time when the scheduling path is first hit by the thread; and the time when the scheduling path is last hit by the thread.

[0011] Optionally, the thread identification method may further include: cleaning up the recorded thread-related information and the saved identification results when at least one of the following conditions is met: the thread that hits the scheduling path exits or the process to which the thread belongs exits; the thread-related information has not been updated for a preset time; the size of the storage space of the eBPF map reaches a preset threshold; the identification information of the process to which the thread belongs is used to identify the process corresponding to another program different from the Go program.

[0012] According to a second aspect of the present disclosure, a thread identification device is provided. The thread identification device may include: a thread-related information acquisition unit configured to acquire thread-related information based on a scheduling path of the Go runtime when a Go program is executed, wherein the scheduling path is at least one key function called by the Go runtime during the execution of the Go program, and the thread-related information is information related to the thread that hits the scheduling path, and includes at least the identification information of the thread; and a thread identification unit configured to acquire the identification information of the current thread based on a kernel target path, and to identify whether the current thread is a thread executing a Go program-related task based on the identification information of the current thread and the thread-related information, wherein the Go program-related task is a thread task related to the execution of the Go program.

[0013] Optionally, the thread-related information acquisition unit can be configured to acquire thread-related information by: detecting whether a scheduling path is hit by a thread through at least one first observation point, wherein the at least one first observation point is deployed on the scheduling path based on eBPF; in response to detecting that the scheduling path is hit by a thread, running a first eBPF program to collect thread-related information and recording the thread-related information in the eBPF map.

[0014] Optionally, the thread-related information may also include at least one of the following: the identification information of the process to which the thread that hit the scheduling path belongs; the current timestamp when the scheduling path is hit by the thread; the number of times the scheduling path is hit by the thread; the time when the scheduling path is first hit by the thread; and the time when the scheduling path is last hit by the thread.

[0015] Optionally, the thread identification unit can be configured to obtain the identification information of the current thread by: detecting whether the target path of the kernel is hit by the current thread through at least one second observation point, wherein the at least one second observation point is deployed on the target path based on eBPF; and in response to detecting that the target path is hit by the current thread, running a second eBPF program to obtain the identification information of the current thread.

[0016] Optionally, the thread identification unit may be configured to identify whether the current thread is a thread executing Go program-related tasks by: querying whether there is identification information matching the current thread's identification information in the thread-related information; identifying the current thread as not being a thread executing Go program-related tasks in response to the absence of identification information matching the current thread's identification information in the thread-related information; or identifying the current thread as a thread executing Go program-related tasks in response to the presence of identification information matching the current thread's identification information in the thread-related information, or in response to the presence of identification information matching the current thread's identification information in the thread-related information and the satisfaction of predetermined conditions related to the thread-related information.

[0017] Optionally, the predetermined conditions may include at least one of the following: the number of times the scheduling path is hit by the current thread exceeds a threshold; the thread-related information is within its validity period.

[0018] Optionally, the thread identification device may further include an identification result storage unit, wherein the identification result storage unit may be configured to save the identification result in a state that the kernel can read when it is identified that the current thread is a thread executing a Go program-related task. The identification result includes information indicating that the current thread is a thread executing a Go program-related task or information indicating that the process to which the current thread belongs is a process executing a Go program-related task. The identification result storage unit may be configured to: save the identification result in a kernel-mode data structure, wherein the kernel-mode data structure includes the kernel's inherent task structure or extended task structure; save the identification result in a newly created kernel map of the task type; or save the identification result in the process-level cache corresponding to the current thread.

[0019] Optionally, the thread identification device may further include a data cleaning unit, wherein the data cleaning unit may be configured to clean the recorded thread-related information and the saved identification results when at least one of the following conditions is met: the thread that hits the scheduling path exits or the process to which the thread belongs exits; the thread-related information has not been updated for a preset time; the size of the storage space of the eBPF map reaches a preset threshold; the identification information of the process to which the thread belongs is used to identify the process corresponding to another program different from the Go program.

[0020] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a memory for storing instructions; and a processor, wherein the processor is configured to execute the instructions to implement a thread identification method according to an embodiment of the present disclosure.

[0021] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided that, when instructions in the computer-readable storage medium are executed by at least one processor, causes at least one processor to perform a thread identification method according to the present disclosure.

[0022] According to a fifth aspect of the present disclosure, a computer program product is provided, including computer instructions that, when executed by a processor, implement the thread identification method according to the present disclosure.

[0023] The technical solutions provided by the embodiments of this disclosure bring at least the following beneficial effects: According to the thread identification method and apparatus, electronic device, storage medium, and program product of this disclosure, when a Go program is executed, thread-related information is obtained based on the scheduling path of the Go runtime. Since the scheduling path is at least one key function called by the Go runtime during the execution of the Go program, and the thread-related information is information related to the thread that hits the scheduling path, the thread-related information reflects the actual activity of the Go runtime during the execution of the Go program. Therefore, it can be used to more accurately identify the thread executing the Go program-related tasks. Moreover, since the thread-related information includes at least the identification information of the thread that hits the scheduling path, in this case, as long as the identification information of the current thread is obtained based on the kernel's target path, it is possible to identify whether the current thread is executing the Go program-related tasks based on the identification information of the current thread and the thread-related information, thereby accurately and efficiently identifying whether the current thread is executing the Go program-related tasks and improving the thread identification effect.

[0024] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0025] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0026] Figure 1 This is a flowchart illustrating a thread identification method according to an exemplary embodiment of the present disclosure.

[0027] Figure 2 This is a schematic diagram illustrating an example of a state model according to an exemplary embodiment of the present disclosure.

[0028] Figure 3 This is a flowchart illustrating an example of a thread identification method according to an exemplary embodiment of the present disclosure.

[0029] Figure 4 This is a block diagram of a thread identification device according to an exemplary embodiment of the present disclosure.

[0030] Figure 5 This is an example illustrating the modules included in a thread identification device according to an exemplary embodiment of the present disclosure.

[0031] Figure 6 This is based on exemplary embodiments of the present disclosure. Figure 5 The diagram shows the interaction timing between the modules of the thread identification device.

[0032] Figure 7 This is a block diagram of an electronic device according to exemplary embodiments of the present disclosure. Detailed Implementation

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

[0034] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following examples do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0035] It should be noted that the phrase "at least one of several items" in this disclosure refers to three parallel cases: "any one of the several items", "a combination of any number of the several items", and "all of the several items". For example, "including at least one of A and B" includes the following three parallel cases: (1) including A; (2) including B; (3) including A and B. Another example is "performing at least one of step one and step two", which means the following three parallel cases: (1) performing step one; (2) performing step two; (3) performing both step one and step two.

[0036] As described in the background section, existing technologies, particularly kernels and operating systems, struggle to accurately identify threads executing Go program-related tasks. For instance, current technologies typically rely on process names, command-line arguments, or ELF file information to identify whether a thread is executing Go program-related tasks. Alternatively, they may use thread creation paths, system call patterns, or static signatures. However, process names, ELF information, or ordinary thread behavior alone cannot accurately prove that a current thread is executing Go program-related tasks. Furthermore, static signatures and file information are susceptible to instability due to variations in compilation parameters, pruning, static linking, version changes, and project structure, leading to low accuracy in thread identification. Another example is indirectly inferring whether a thread is executing Go program-related tasks through offline performance log analysis. This method not only has low accuracy but also only allows for offline identification, resulting in poor timeliness.

[0037] The low accuracy of the aforementioned identification methods stems from their lack of support from actual Go runtime activity or semantics when identifying threads. To address this, this disclosure proposes a thread identification method. This method, while a Go program is being executed, obtains thread-related information that truly reflects Go runtime activity based on the Go runtime's scheduling path, acquires the current thread's identifier information based on the kernel's target path, and then identifies whether the current thread is executing tasks related to the Go program based on both the identifier and thread-related information. This approach accurately and efficiently identifies whether a current thread is executing tasks related to the Go program while it is being executed, thereby improving thread identification performance.

[0038] Hereinafter, with reference to the accompanying drawings, a thread identification method, a thread identification device, an electronic device, a storage medium, and a program product according to exemplary embodiments of the present disclosure will be described in detail.

[0039] Figure 1 This is a flowchart illustrating a thread identification method according to an exemplary embodiment of the present disclosure.

[0040] Reference Figure 1 In step S110, when the Go program is executed, thread-related information is obtained based on the Go runtime's scheduling path.

[0041] In this disclosure, "Go program" refers to a program obtained by programming in the Go language. The Go runtime is the Go language runtime system, embedded in the executable file of a Go program, and is responsible for scheduling Goroutines, thread management, memory allocation, and system call coordination. A Goroutine is a lightweight user-space concurrent execution unit in a Go program, not directly perceived by the kernel, and is also known as a "coroutine". The execution of any Goroutine must ultimately occur on a real thread in the kernel.

[0042] According to an exemplary embodiment, the scheduling path in step S110 can be at least one critical function called by the Go runtime during the execution of a Go program. The at least one critical function is a function that any Go program will necessarily call during its execution. Hereinafter, the critical function may also be referred to as a "critical path," a "critical scheduling path," or a "critical behavioral event." As an example, thread identification can be based on multiple critical paths instead of relying on a single critical path in the Go runtime.

[0043] For example, one or more critical functions, critical scheduling paths, or critical behavioral events in the Go runtime can be at least one of the following: `runtime.newproc`; `runtime.execute`; `runtime.schedule`; `runtime.goexit`; `runtime.mstart`; and other critical paths related to switching, execution, and waking up in the GMP model, but not limited to these. Here, `runtime.newproc` is the core function of the Go runtime used to create new Goroutines. `runtime.execute` is the core function of the Go runtime used to execute Goroutines. `runtime.schedule` is the core function of the Go runtime scheduler, responsible for coordinating the scheduling relationships between goroutines (G), logical processors (P), and machine threads (M) in user space to achieve efficient concurrent execution. `runtime.goexit()` is the function of the Go runtime used to immediately terminate the current Goroutine. `runtime.mstart` is the key function of the Go runtime used to start a machine thread (M) and enter the scheduling loop. The GPM model is the scheduling model for the Go runtime. G stands for goroutine, P for logical processor (also called logical processing resource), and M for machine thread (also called thread or operating system thread). The GPM model is used to multiplex multiple goroutines onto operating system threads, thereby achieving high concurrency and low overhead coroutine scheduling in user space. The common characteristic of the aforementioned key functions or key scheduling paths is that if they are hit by a thread, it indicates that the thread is currently carrying out actual Go runtime activity; in other words, the thread is executing Go program-related tasks. Go program-related tasks are thread tasks related to the execution of the Go program; in other words, they are thread tasks executed to execute the Go program. For example, Go program-related tasks can be thread tasks belonging to the Go program's process space that carry the Go runtime execution flow or have recently executed Go runtime key paths.

[0044] According to an exemplary embodiment, the thread-related information in step S110 may be information related to the thread that hits the scheduling path, and at least includes the thread's identification information. A thread hitting a critical scheduling path in the Go runtime indicates that at least one critical function of the Go runtime has been called, and that the thread is executing tasks related to the Go program. Therefore, when the Go program is executed, information related to the thread hitting the critical scheduling path in the Go runtime can be obtained, and this information can be used to determine whether the current thread is executing tasks related to the Go program.

[0045] Thread-related information may include at least the identification information of the thread (the thread that hits the critical scheduling path of the Go runtime), such as the thread ID (e.g., tid). Optionally, thread-related information may also include at least one of the following: the identification information of the process to which the thread that hit the scheduling path belongs (e.g., tgid); the current timestamp when the scheduling path was hit by the thread; the number of times the scheduling path was hit by the thread; the time when the scheduling path was first hit by the thread; and the time when the scheduling path was last hit by the thread. Further combining at least one of the above items with the thread identification information can improve the accuracy of thread identification, which will be further described in the following description of step S120.

[0046] Optionally, thread-related information may also include at least one of the following: the current state of the thread that hits the scheduling path; the control group (cgroup) information of the process to which the thread that hits the scheduling path belongs; the current command name associated with the thread that hits the scheduling path; and the namespace information associated with the thread that hits the scheduling path. For example, cgroups are used to limit, record, and isolate the physical resources used by a process, and each process can be assigned to one or more cgroups. For example, the current command name associated with the thread that hits the scheduling path may include the current command name of the thread and / or the current command name of the process to which the thread belongs. For example, the namespace information associated with the thread that hits the scheduling path may include the namespace information of the thread and / or the namespace information of the process to which the thread belongs. At least one of the current state, cgroup information, current command name, and namespace information can be used to use or control the thread after identifying the thread performing a task related to the Go program. For example, the physical resources used by the identified thread can be controlled based on the cgroup information.

[0047] Optionally, in step S110, when the Go program is executed, thread-related information can be obtained by deploying observation points on the scheduling path based on eBPF. For example, according to an exemplary embodiment, obtaining thread-related information based on the scheduling path of the Go runtime in step S110 may include: detecting whether the scheduling path is hit by a thread through at least one first observation point, wherein the at least one first observation point is deployed on the scheduling path based on eBPF; in response to detecting that the scheduling path is hit by a thread, running a first eBPF program to collect thread-related information, and recording the thread-related information in eBPFmap. eBPF is a mechanism for safely executing programmable logic in the kernel. It allows developers to write safe and efficient programs (eBPF programs) and dynamically load them into the kernel space for execution, thereby extending kernel functionality without modifying the kernel source code. Using eBPF to deploy observation points on the scheduling path to obtain thread-related information can obtain thread-related information in real time and online with lower overhead, thereby enabling low-overhead, real-time, and online thread identification.

[0048] For example, the first observation point could be an uprobe or equivalent deployed on a critical path in the Go runtime, used to observe whether a scheduling path is hit by a thread. An uprobe is a dynamic probe deployed in a user-space critical function. The first eBPF program can be an eBPF-based program used to collect thread-related information and record it in the eBPF map when a scheduling path is hit by a thread. When the first observation point is triggered, i.e., when a scheduling path is hit by a thread, the first eBPF program is run to collect thread-related information and record it in the eBPF map. The eBPF map is a data structure in the eBPF mechanism used to share data between kernel space and user space, and among multiple eBPF programs; it is essentially a key-value storage container. The kernel can read the eBPF map to obtain the recorded thread-related information. As an example, thread-related information can be written into the following eBPF map with the following structure: struct go_tid_state { u32 tgid; u32 tid; u64 first_seen_ns; u64 last_seen_ns; u32 hit_cnt; u32 state; }; Wherein, u32 tgid represents the process identification information of the thread that hit the scheduling path, u32 tid represents the thread identification information itself, u64 first_seen_ns represents the time when the scheduling path was first hit by the thread, u64 last_seen_ns represents the time when the scheduling path was last hit by the thread, u32 hit_cnt represents the number of times the scheduling path was hit by the thread, and u32 state represents the current state.

[0049] Alternatively, thread-related information can be obtained without using eBPF. For example, the Go program's source code can be modified so that when a thread hits a scheduling path, thread-related information can be recorded in user space. The Go program can then notify the kernel that it has recorded this information. The kernel can then provide an interface to the Go program, which provides the recorded thread-related information to the kernel. This method also achieves the acquisition of thread-related information, but it incurs greater overhead compared to the eBPF-based approach.

[0050] Although the above examples illustrate two ways to obtain thread-related information, the methods for obtaining thread-related information in step S110 are not limited to the examples described above.

[0051] In step S120, the identification information of the current thread is obtained based on the target path of the kernel, and based on the identification information and thread-related information of the current thread, it is determined whether the current thread is the thread that executes the Go program-related tasks.

[0052] Optionally, according to an exemplary embodiment, the identification information of the current thread can be obtained by: detecting whether the target path of the kernel is hit by the current thread through at least one second observation point, wherein the at least one second observation point is deployed on the target path based on eBPF; in response to detecting that the target path is hit by the current thread, running a second eBPF program to obtain the identification information of the current thread.

[0053] For example, the second observation point can be a kprobe or equivalent observation point deployed on the target path in the kernel, used to observe whether the target path is hit by the current thread. A kprobe is a dynamic probe deployed on the target path in the kernel. As an example, the kernel target path can include at least one of the following: a kernel scheduling path, a task switching path, a wake-up path, a clock interrupt or sampling path, a specific kernel control entry point, but is not limited to these. The second eBPF program can be an eBPF program written based on eBPF used to obtain the identification information of the current thread when the target path is hit by the current thread. When the second observation point is triggered, that is, when the target path is hit by the current thread, the second eBPF program is run to obtain the identification information of the current thread.

[0054] After obtaining the identifier information of the current thread in the kernel, it is possible to identify whether the current thread is executing a Go program-related task based on the identifier information and thread-related information. Optionally, according to an exemplary embodiment, the identification of whether the current thread is executing a Go program-related task can be achieved through the following operations: querying the thread-related information to see if there is identifier information matching the identifier information of the current thread; in response to the absence of identifier information matching the identifier information of the current thread in the thread-related information, identifying the current thread as not executing a Go program-related task; in response to the presence of identifier information matching the identifier information of the current thread in the thread-related information, or in response to the presence of identifier information matching the identifier information of the current thread in the thread-related information and the satisfaction of predetermined conditions related to the thread-related information, identifying the current thread as executing a Go program-related task. According to an exemplary embodiment, the predetermined conditions may include at least one of the following: the number of times the scheduling path is hit by the current thread exceeds a threshold, or the thread-related information is within its validity period, but is not limited to these.

[0055] For example, if thread-related information is obtained by deploying observation points on the scheduling path based on eBPF, the kernel can access the eBPF map to query whether there is identification information matching the current thread's identification information in the thread-related information. For example, it can query whether the identification information recorded in the eBPF map contains the current thread's identification information. Optionally, in an exemplary embodiment, if the identification information recorded in the eBPF map contains the current thread's identification information, the current thread can be identified as the thread executing Go program-related tasks. However, since there is a possibility of erroneously detecting that the scheduling path has been hit by a thread, in order to improve the identification accuracy, even if the identification information recorded in the eBPF map contains the current thread's identification information, other factors can be further considered to identify whether the current thread is the thread executing Go program-related tasks. As mentioned above, for example, the thread-related information may also include the number of times the scheduling path has been hit by a thread. In this case, the current thread can be further identified as the thread executing Go program-related tasks based on the satisfaction of predetermined conditions related to the number of times the scheduling path has been hit by a thread. For example, the current thread is identified as executing Go program-related tasks only if a matching identifier exists in the thread-related information and the current thread has been hit more than a threshold number of times the scheduling path has been hit. As another example, thread-related information may also include the current timestamp when the scheduling path is hit. If the current timestamp differs significantly from the time of the query execution, the thread-related information is considered expired. Therefore, even if a matching identifier exists in the thread-related information, the current thread may not be identified as executing Go program-related tasks because the thread-related information is expired. Furthermore, thread-related information may include the time of the first and last hits of the scheduling path. If the time between the last hit and the first hit exceeds a predetermined time, the thread-related information is considered expired. Therefore, even if a matching identifier exists in the thread-related information, the current thread may not be identified as executing Go program-related tasks because the thread-related information is expired. Conversely, if a matching identifier exists in the thread-related information and the thread-related information is valid, the current thread can be identified as the thread executing Go program-related tasks. Alternatively, the current thread can be identified as the thread executing Go program-related tasks only if a matching identifier exists in the thread-related information, the scheduling path is hit by the current thread more than a threshold number of times, and the thread-related information is valid. These methods can further improve the accuracy of thread identification.

[0056] according to Figure 1 The method shown improves thread identification by obtaining information related to threads that hit the critical scheduling path of the Go runtime (the thread-related information mentioned above, including at least the identification information of the threads that hit the critical scheduling path) based on the critical scheduling path of the Go runtime when the Go program is executed, obtaining the identification information of the current thread based on the target path of the kernel, and identifying whether the current thread is executing the Go program-related tasks based on the identification information and the thread-related information. Therefore, it can accurately and efficiently identify threads when the Go program is executed by means of a two-stage linkage of user-mode information acquisition and kernel-mode current thread identification, thereby improving the thread identification effect.

[0057] Optionally, Figure 1 The thread identification method shown may further include: when it is identified that the current thread is a thread executing a Go program-related task, saving the identification result in a state that the kernel can read. That is, saving the identification result in a state that the kernel can consume. In this way, different kernel modules can share the identification result without having to read the thread-related information stored in the eBPF map for thread identification when needed, thereby saving computational resources and improving identification efficiency. Furthermore, this method allows the kernel to use the saved identification result to perform targeted optimization operations on threads belonging to Go program-related tasks. For example, implementing specific scheduling policies for threads belonging to Go program-related tasks, performing resource management and priority control for threads belonging to Go program-related tasks, and performing observation, statistics, auditing, or anomaly detection for threads belonging to Go program-related tasks, etc.

[0058] According to an exemplary embodiment, the identification result may include information indicating that the current thread is a thread executing a task related to the Go program, or information indicating that the process to which the current thread belongs is a process executing a task related to the Go program, but is not limited thereto. Optionally, saving the identification result in a state that the kernel can read may include: saving the identification result in a kernel-mode data structure, wherein the kernel-mode data structure includes the kernel's inherent task structure or extended task structure; saving the identification result in a newly created kernel map of the task type; or saving the identification result in the process-level cache corresponding to the current thread. In the following text, the identification result may also be referred to as a task tag, and saving the identification result may also be referred to as executing a task tag.

[0059] For example, in the Linux kernel, the kernel's inherent task structure is `task_struct`. This is the core data structure used by the kernel to describe and manage all tasks. Each running program (whether an independent process or a thread) corresponds to a unique `task_struct` in the kernel. For instance, a Go task flag field can be added to `task_struct` to record the identification results.

[0060] For example, the kernel's extended task structure can be a structure that extends the kernel for specific tasks, and the recognition results can be recorded in such a structure.

[0061] For example, the recognition results can be recorded in the kernel map, which uses a key-value pair mapping mechanism for storage. For instance, a separate kernel map can record the tid and its corresponding task_type. For example, task_type=0 indicates that the thread corresponding to tid is not a thread executing Go-related tasks, while task_type=1 indicates that the thread corresponding to tid is a thread executing Go-related tasks.

[0062] For example, if the current thread is identified as a thread executing Go program-related tasks, other threads in the process to which the current thread belongs may also be threads executing Go program-related tasks. Therefore, the process corresponding to the current thread can be identified as a process executing Go program-related tasks. In this case, the information indicating that the process to which the current thread belongs is a process executing Go program-related tasks can also be stored in the process-level cache corresponding to the current thread, that is, in the cache of the process to which the current thread belongs.

[0063] To improve the timeliness, stability and accuracy of identification, this disclosure further introduces a task status maintenance and recovery mechanism.

[0064] For example, as mentioned above, optionally, the current thread can be identified as a thread executing a Go program-related task only when there is an identifier in the thread-related information that matches the identifier of the current thread and a predetermined condition related to the thread-related information is met. This can be achieved, for example, by maintaining the task identification state of the current thread (hereinafter referred to as task state) through a state model. Figure 2 This is a schematic diagram illustrating an example of a state model according to an exemplary embodiment of the present disclosure.

[0065] like Figure 2As shown, task states can include an unidentified state (also known as the default task state), a candidate state, an acknowledged state, and an expired state. An unidentified state indicates that no matching identifier exists in the thread-related information, or that the current thread has not been identified as a thread executing a Go program-related task. A candidate state indicates that the current thread may be identified as a thread executing a Go program-related task. An acknowledged state indicates that the current thread has been identified as a thread executing a Go program-related task. An expired state indicates that the previous task state has expired.

[0066] like Figure 2 As shown, when a matching identifier is first found in the thread-related information (i.e., the current thread hits the Go runtime's critical path for the first time), the current thread's task state is determined to be a candidate state. If the number of times the critical path is hit in the candidate state exceeds a threshold, the task state is changed from candidate to confirmed. Only when the task state is confirmed is the current thread ultimately identified as the thread executing Go program-related tasks. However, even if a matching identifier is found in the thread-related information, if the current thread's task state remains in the candidate state for more than a preset time, or if the thread-related information is cleared while the current thread's task state is in the candidate state, the current thread's task state is changed from candidate to unidentified. Additionally, if the current thread exits or the process to which the current thread belongs exits in the confirmed state, the task state is changed from confirmed to unidentified. If the critical path is not hit again for a long time in the expired state, the current thread's task state is changed from confirmed to expired. When the critical path is hit again in the expired state, the task state is changed from expired to candidate. Figure 2 The state model shown can balance recognition sensitivity and stability, avoiding the permanent retention of erroneous records due to a single accidental hit.

[0067] Optionally, Figure 1 The thread identification method further includes: cleaning up the recorded thread-related information and saved identification results when at least one of the following conditions is met: the thread that hit the scheduling path exits or the process to which the thread belongs exits; the thread-related information has not been updated for a preset time; the storage space of the eBPF map reaches a preset threshold; the identification information of the process to which the thread belongs is used to identify the process corresponding to another program different from the Go program (e.g., a C program obtained through C programming). For example, if the identification information of the process to which the thread belongs is used to identify the process corresponding to another program different from the Go program, it indicates that the current thread-related information has become invalid or expired and can be cleaned up. For another example, such as... Figure 2As shown, if a thread-related information is not hit again for an extended period after initially hitting the critical path and remaining in the candidate state, thread-related information can be promptly cleaned up. This avoids using invalid or expired thread-related information for thread identification, thereby improving the timeliness, stability, and accuracy of thread identification. Alternatively, state freshness can be maintained through periodic scanning and a time window expiration mechanism.

[0068] Figure 3 This is a flowchart illustrating an example of a thread identification method according to an exemplary embodiment of the present disclosure. For a clearer understanding of the exemplary implementation of the present disclosure, reference is made below. Figure 3 An example of a thread identification method is described.

[0069] like Figure 3 As shown, in step S301, observation points can be deployed on the critical path of the Go runtime, for example, user-space hooks. In step S302, when the observation point deployed on the critical path is triggered (i.e., when the critical path is hit by a thread), information about the thread that hit the critical path is collected, such as tgid, tid, timestamp of the hit, and number of hits. In step S303, the collected information is written into the eBPF map to form thread-related information. In step S304, it is detected whether the kernel's target path is hit by the current thread, for example, by deploying observation points on the kernel's target path. In step S305, when the kernel's target path is hit by the current thread, the tid of the current thread is read. Subsequently, in step S306, it is queried in the eBPF map whether the tid of the current thread exists. If it does not exist (no), in step S307, the task state of the current thread is maintained as the default task state. If the conditions are met (yes), in step S308, determine whether the hit count and validity period satisfy the criteria, for example, whether the hit count exceeds a threshold and whether the thread-related information is within the validity period. If the thread-related information is within the validity period and the hit count does not exceed the threshold (no), then in step S309, continue to observe and keep the task status in the candidate state. If the thread-related information is within the validity period and the hit count exceeds the threshold, then in step S310, identify the current thread as a thread executing a Go program-related task. In step S311, write the identification result into the task_struct or the kernel map of the task type. In step S312, use the identification result to perform targeted optimization operations on threads belonging to Go program-related tasks.

[0070] According to an exemplary embodiment, the thread identification method described above can be implemented, for example, by the following eBPF pseudocode: struct go_tid_state { u32 tgid; u32 tid; u64 first_seen_ns; u64 last_seen_ns; u32 hit_cnt; u32 state; }; map go_tid_map; SEC("uprobe / go_runtime_key_path") int trace_go_runtime_event(struct pt_regs ctx) { u64 id = bpf_get_current_pid_tgid(); u32 tgid = id>>32; u32 tid = (u32)id; u64 now = bpf_ktime_get_ns(); struct go_tid_state old; struct go_tid_state val = {}; old = bpf_map_lookup_elem(&go_tid_map,&tid); if (old) { val = old; val.last_seen_ns = now; val.hit_cnt += 1; val.state = 1; } else { val.tgid = tgid; val.tid = tid; val.first_seen_ns = now; val.last_seen_ns = now; val.hit_cnt = 1; val.state = 1; } bpf_map_update_elem(&go_tid_map,&tid,&val, BPF_ANY); return 0; } SEC("kprobe / kernel_target_path") int identify_go_task(struct pt_regs ctx) { struct task_struct task u32 tid; struct go_tid_state state; task = (struct task_struct )bpf_get_current_task(); tid = BPF_CORE_READ(task, pid); state = bpf_map_lookup_elem(&go_tid_map,&tid); if (!state) return 0; if (state->hit_cnt>= GO_HIT_THRESHOLD) mark_current_task_as_go(task); return 0; } In the pseudocode above, `struct go_tid_state` defines the thread-related information recorded in the eBPF map, `trace_go_runtime_event()` is used to collect thread-related information when a thread hits a critical path in the Go runtime, `identify_go_task()` is used to identify the current thread in the kernel's target path, and `mark_current_task_as_go()` is used to save the identification result of the current thread in a kernel-consumable state. However, the pseudocode implementing the thread identification method of this disclosure is not limited to the above example. The above pseudocode is only used to help understand the thread identification method of this disclosure and is not intended to limit the thread identification method of this disclosure in any way.

[0071] The thread identification method disclosed herein can be applied to various scenarios, such as Go service runtime environment identification, performance analysis and profiling, security auditing and behavior tracking, and thread scheduling optimization. For example, in the Go service runtime environment identification scenario, it can identify which threads belong to Go program-related tasks in a large-scale service environment, and use the identification results for scheduling optimization and resource governance. For example, in the performance analysis and profiling scenario, it can identify which threads belong to Go program-related tasks, and perform specialized sampling, statistics, and performance analysis on the identified threads to reduce interference from irrelevant threads. For example, in the security auditing and behavior tracking scenario, it can identify which threads belong to Go program-related tasks, and establish specific audit rules for the identified threads to improve the accuracy of behavior observation. For example, in the thread scheduling optimization scenario, it can identify which threads are executing Go program-related tasks, classify the tasks executed by the threads, and perform differentiated scheduling for different types of threads.

[0072] Figure 4 This is a block diagram of a thread identification device according to an exemplary embodiment of the present disclosure. (Refer to...) Figure 4 The thread identification device 400 may include a thread-related information acquisition unit 410 and a thread identification unit 420. The thread-related information acquisition unit 410 may be configured to acquire thread-related information based on the scheduling path of the Go runtime when the Go program is executed. According to an exemplary embodiment, the scheduling path may be at least one key function called by the Go runtime during the execution of the Go program, and the thread-related information is information related to the thread hitting the scheduling path, and includes at least the thread's identification information. The thread identification unit 420 may be configured to acquire the identification information of the current thread based on the kernel's target path, and based on the current thread's identification information and thread-related information, identify whether the current thread is a thread executing a Go program-related task. According to an embodiment, the Go program-related task is a thread task related to the execution of the Go program.

[0073] Optionally, the thread-related information acquisition unit 410 can be configured to acquire thread-related information by: detecting whether a scheduling path is hit by a thread through at least one first observation point, wherein the at least one first observation point is deployed on the scheduling path based on eBPF; in response to detecting that the scheduling path is hit by a thread, running a first eBPF program to collect thread-related information and recording the thread-related information in the eBPF map.

[0074] Optionally, the thread-related information may also include at least one of the following: the identification information of the process to which the thread that hit the scheduling path belongs; the current timestamp when the scheduling path is hit by the thread; the number of times the scheduling path is hit by the thread; the time when the scheduling path is first hit; and the time when the scheduling path is last hit by the thread.

[0075] Optionally, the thread identification unit 420 can be configured to obtain the identification information of the current thread by: detecting whether the target path of the kernel is hit by the current thread through at least one second observation point, wherein the at least one second observation point is deployed on the target path of the kernel based on eBPF; and in response to detecting that the target path is hit by the current thread, running a second eBPF program to obtain the identification information of the current thread.

[0076] Optionally, the thread identification unit 420 can be configured to identify whether the current thread is a thread executing Go program-related tasks by: querying whether there is identification information matching the current thread's identification information in the thread-related information; identifying the current thread as not being a thread executing Go program-related tasks in response to the absence of identification information matching the current thread's identification information in the thread-related information; or identifying the current thread as a thread executing Go program-related tasks in response to the presence of identification information matching the current thread's identification information in the thread-related information, or in response to the presence of identification information matching the current thread's identification information in the thread-related information and the satisfaction of predetermined conditions related to the thread-related information. Optionally, the predetermined conditions may include at least one of the following: the number of times the scheduling path is hit by the current thread exceeds a threshold; the thread-related information is within its validity period.

[0077] Optionally, the thread identification device 400 may further include an identification result storage unit (not shown), wherein the identification result storage unit may be configured to save the identification result in a state that the kernel can read when it is identified that the current thread is a thread executing a Go program-related task. For example, the identification result may include information indicating that the current thread is a thread executing a Go program-related task or information indicating that the process to which the current thread belongs is a process executing a Go program-related task. As an example, the identification result storage unit may be configured to: save the identification result in a kernel-mode data structure, wherein the kernel-mode data structure includes the kernel's inherent task structure or extended task structure; save the identification result in a newly created kernel map of the task type; or save the identification result in the process-level cache corresponding to the current thread.

[0078] Optionally, the thread identification device 400 may further include a data cleaning unit (not shown), wherein the data cleaning unit is configured to clean the recorded thread-related information and the saved identification results when at least one of the following conditions is met: the thread that hits the scheduling path exits or the process to which the thread belongs exits; the thread-related information has not been updated for a preset time; the size of the storage space of the eBPF map reaches a preset threshold; the identification information of the process to which the thread belongs is used to identify the process corresponding to another program different from the Go program.

[0079] The thread identification device according to the embodiments of this disclosure can accurately and efficiently identify whether the current thread is a thread executing Go program-related tasks, thereby improving the thread identification effect.

[0080] The relevant examples of the operations performed by the thread identification device have already been described in the description of the thread identification method above, and will not be repeated here.

[0081] Figure 5 This is an example illustrating modules included in a thread identification device according to an exemplary embodiment of the present disclosure. Figure 5 In the example, the thread identification device may include an information acquisition module 501, an information storage module 502, a thread identification module 503, a task marking module 504, and a status maintenance and recycling module 505. For example... Figure 5 As shown, the information acquisition module 501 can acquire thread-related information (including at least the identification information of threads that hit the Go runtime's scheduling path) and write it to the information storage module 502. The information storage module 502 can store thread-related information. The thread identification module 503 can obtain the identification information of the current thread from the target path in the kernel and query the current thread's identification information in the thread-related information stored in the information storage module 502. If there is identification information in the thread-related information that matches the current thread's identification information, the thread identification module 503 can determine that the current thread is the thread executing a Go program-related task and send the identification result indicating that the current thread is the thread executing a Go program-related task to the task marking module 504. The task marking module 504 can save the identification result in a kernel-readable state. The state maintenance and recycling module 505 can clean up the thread-related information in the information storage module 502 and can also clean up invalid identification results in the task marking module 504.

[0082] although Figure 4 and Figure 5Different unit or module division methods of the thread identification device are shown. However, this disclosure does not limit the unit or module division method and different units or modules can be combined, or the units or modules can be further split, or other units or modules can be further added.

[0083] Figure 6 This is based on exemplary embodiments of the present disclosure. Figure 5 The diagram shows the interaction timing between the modules of the thread identification device. (This will be combined with...) Figure 6 describe Figure 5 Examples of operations performed by each module and the relationships between the modules.

[0084] like Figure 6 As shown, the information acquisition module 501 can collect thread-related information from critical functions or critical scheduling paths in the Go runtime and write it to the information storage module 502. For example, it can write the thread ID (tid), the process ID (tgid), timestamp, and hit count of the thread hitting the critical function or critical scheduling path to the information storage module 502. The information storage module 502 can store the thread-related information in the eBPF map. The thread identification module 503 can obtain the identification information (tid) of the current thread from the target path in the kernel and query the tid of the current thread in the stored thread-related information. If the tid of the current thread exists, the information storage module 502 can return a confirmed status, or it can return a candidate status or a confirmed status based on the hit count and / or timestamp. When the thread identification module 503 determines that the current thread has hit a critical function or critical scheduling path in the Go runtime, it sends the identification result to the task marking module 504. The task marking module 504 can save the identification result in a kernel-readable state and return an updated result, such as information indicating that the task status has been updated. The state maintenance and recycling module 505 can clean up timed-out or outdated records in the information storage module 502, or clean up records in the information storage module 502 when a thread or the process to which a thread belongs exits. In addition, the state maintenance and recycling module 505 can also clean up invalid identification results (i.e., task tags) in the task tagging module 504.

[0085] according to Figure 5 and Figure 6 The implementation not only accurately and efficiently identifies whether the current thread is executing Go program-related tasks, but also, by saving thread-related information and identification results in a kernel-consumable state, enables the kernel to perform thread identification more efficiently and execute targeted optimization operations on the identified threads. Furthermore, timely cleanup of thread-related information and identification results can improve the timeliness, stability, and accuracy of thread identification.

[0086] According to embodiments of this disclosure, an electronic device may also be provided. Figure 7 This is a block diagram of an electronic device according to embodiments of the present disclosure, such as... Figure 7 As shown, the electronic device 700 may include a memory 701 for storing instructions and a processor 702. The processor 702 may be configured to execute the instructions to implement the thread identification method according to this disclosure.

[0087] As an example, electronic device 700 may be a PC, tablet, personal digital assistant, smartphone, or other device capable of executing the aforementioned set of instructions. Here, electronic device 700 is not necessarily a single electronic device, but may be any collection of devices or circuits capable of executing the aforementioned instructions (or instruction sets) individually or in combination. Electronic device 700 may also be part of an integrated control system or system manager, or may be configured to interconnect with a portable electronic device locally or remotely (e.g., via wireless transmission) through an interface.

[0088] In electronic device 700, processor 702 may include a central processing unit (CPU), a graphics processing unit (GPU), a programmable logic device, a dedicated processor system, a microcontroller, or a microprocessor. By way of example and not limitation, processor 702 may also include analog processors, digital processors, microprocessors, multi-core processors, processor arrays, network processors, etc.

[0089] The processor 702 can execute instructions or code stored in memory, wherein memory 701 can also store data. Instructions and data can also be sent and received via a network through a network interface device, wherein the network interface device can employ any known transmission protocol.

[0090] The memory 701 can be integrated with the processor 702, for example, by placing RAM or flash memory within an integrated circuit microprocessor. Alternatively, the memory 701 can include a separate device, such as an external disk drive, a storage array, or other storage device usable by any database system. The memory 701 and the processor 702 can be operatively coupled, or can communicate with each other, for example, via I / O ports, network connections, etc., enabling the processor 702 to read files stored in the memory 701.

[0091] In addition, the electronic device 700 may also include a video display (such as a liquid crystal display) and a user interaction interface (such as a keyboard, mouse, touch input device, etc.). All components of the electronic device can be interconnected via a bus and / or network.

[0092] According to embodiments of the present disclosure, a computer-readable storage medium may also be provided, wherein when instructions in the computer-readable storage medium are executed by at least one processor, the at least one processor causes the at least one processor to perform a thread identification method according to the present disclosure. Examples of computer-readable storage media herein include: read-only memory (ROM), random access programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), flash memory, non-volatile memory, CD-ROM, CD-R, CD+R, CD-RW, CD+RW, DVD-ROM, DVD-R, DVD+R, DVD-RW, DVD+RW, DVD-RAM, BD-ROM, BD-R, BD-R LTH, BD-RE, Blu-ray or optical disc storage, hard disk drive (HDD), solid-state drive (SSD), card storage (such as multimedia cards, secure digital (SD) cards, or ultra-fast digital (XD) cards), magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, hard disk, solid-state drive, and any other device configured to store a computer program and any associated data, data files, and data structures in a non-transitory manner and to provide the computer program and any associated data, data files, and data structures to a processor or computer so that the processor or computer can execute the computer program. The computer program in the aforementioned computer-readable storage medium can run in an environment deployed in computer devices such as clients, hosts, agent devices, servers, etc. Furthermore, in one example, the computer program and any associated data, data files, and data structures are distributed across a networked computer system, such that the computer program and any associated data, data files, and data structures are stored, accessed, and executed in a distributed manner through one or more processors or computers.

[0093] According to an embodiment of this disclosure, a computer program product is provided, including computer instructions that, when executed by a processor, implement the thread identification method according to this disclosure.

[0094] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.

[0095] It should be understood that this disclosure is not limited to the examples described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A thread identification method, characterized in that, include: When a Go program is executed, thread-related information is obtained based on the scheduling path of the Go runtime. The scheduling path is at least one key function called by the Go runtime during the execution of the Go program. The thread-related information is information related to the thread that hits the scheduling path, and includes at least the identification information of the thread. The identifier information of the current thread is obtained based on the target path of the kernel, and based on the identifier information of the current thread and the thread-related information, it is identified whether the current thread is a thread executing Go program-related tasks, wherein the Go program-related tasks are thread tasks related to the execution of the Go program.

2. The thread identification method according to claim 1, characterized in that, The process of obtaining thread-related information based on the Go runtime's scheduling path includes: Whether the scheduling path is hit by a thread is detected by at least one first observation point, wherein the at least one first observation point is deployed on the scheduling path based on an extended Berkeley package filter; In response to the detection that the scheduling path has been hit by a thread, the first extended Berkeley package filter program is run to collect the thread-related information and record the thread-related information in the extended Berkeley package filter map.

3. The thread identification method according to claim 1, wherein, The process of obtaining the current thread's identifier information based on the kernel's target path includes: The kernel's target path is detected by at least one second observation point, wherein the at least one second observation point is deployed on the target path based on an extended Berkeley package filter; In response to the detection that the target path is hit by the current thread, a second extended Berkeley package filter program is run to obtain the identification information of the current thread.

4. The thread identification method according to any one of claims 1 to 3, characterized in that, The step of identifying whether the current thread is executing Go program-related tasks based on the current thread's identifier information and the thread-related information includes: In the thread-related information, query whether there is any identification information that matches the identification information of the current thread; In response to the absence of an identifier matching the identifier of the current thread in the thread-related information, the current thread is identified as not being a thread executing Go program-related tasks; In response to the existence of an identifier in the thread-related information that matches the identifier of the current thread, or in response to the existence of an identifier in the thread-related information that matches the identifier of the current thread and the satisfaction of a predetermined condition related to the thread-related information, the current thread is identified as a thread executing a Go program-related task.

5. The thread identification method according to claim 4, wherein, The predetermined conditions include at least one of the following: The number of times the current thread hits the scheduling path exceeds a threshold. The thread-related information is valid.

6. The thread identification method according to claim 2, characterized in that, The thread identification method further includes: If it is identified that the current thread is a thread executing Go program-related tasks, the identification result is saved in a state that the kernel can read. The identification result includes information indicating that the current thread is a thread executing Go program-related tasks or information indicating that the process to which the current thread belongs is a process executing Go program-related tasks. The step of saving the recognition results in a state that the kernel can read includes: The identification results are stored in a kernel-mode data structure, wherein the kernel-mode data structure includes the kernel's inherent task structure or extended task structure; The identification results are saved in the newly created kernel map of the task type; or... The recognition result is stored in the process-level cache corresponding to the current thread.

7. The thread identification method according to claim 1, characterized in that, The thread-related information also includes at least one of the following: The process identification information of the thread that hits the specified scheduling path; The current timestamp when the scheduling path is hit by a thread; The number of times the scheduling path is hit by the thread; The time when the scheduling path is first hit by the thread; The time when the scheduling path was last hit by the thread.

8. The thread identification method according to claim 6, characterized in that, The thread identification method further includes: The recorded thread-related information and the saved identification results shall be cleaned up if at least one of the following conditions is met: The thread that hits the scheduling path exits or the process to which the thread belongs exits; The thread-related information has not been updated for an extended period of time. The storage space of the extended Berkeley package filter map has reached a preset threshold. The process identification information of the thread is used to identify the process of another program that is different from the Go program.

9. A thread identification device, characterized in that, include: The thread-related information acquisition unit is configured to acquire thread-related information based on the scheduling path of the Go runtime when the Go program is executed, wherein the scheduling path is at least one key function called by the Go runtime during the execution of the Go program, and the thread-related information is information related to the thread that hits the scheduling path, and includes at least the identification information of the thread. The thread identification unit is configured to obtain the identification information of the current thread based on the target path of the kernel, and based on the identification information of the current thread and the thread-related information, identify whether the current thread is a thread executing Go program-related tasks, wherein the Go program-related tasks are thread tasks related to the execution of the Go program.

10. An electronic device, characterized in that, include: Memory used to store instructions; A processor, wherein the processor is configured to execute the instructions to implement the thread identification method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by at least one processor, the at least one processor causes the at least one processor to perform the thread identification method as described in any one of claims 1 to 8.

12. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the thread identification method as described in any one of claims 1 to 8.

Images