CN113238915B - Processing method, device, device, storage medium and program for calling information - Google Patents

Abstract

The present disclosure provides a method, device, device, storage medium and program for processing invocation information, and relates to the technical field of invocation chains in computer technology. The specific implementation scheme is: when it is determined that the first thread is to call the second thread to execute the first object, an auxiliary object corresponding to the first object is generated, the life cycle of the first object and the auxiliary object are the same, and the auxiliary object includes the first invocation information, The first call information includes the identifier of the first object and the identifier of the first call node in the first thread that calls the second thread, and the first object and the auxiliary object are delivered to the second thread. When there is an object, the target call information is generated according to the first call information in the auxiliary object, and the first object is executed through the second thread. In the above process, on the one hand, the development efficiency is improved, and on the other hand, the security of the business system is guaranteed.

Description

Processing method, device, device, storage medium and program for calling information

technical field

The present disclosure relates to the technical field of call chains in computer technology, and in particular, to a method, apparatus, device, storage medium and program for processing call information.

Background technique

At present, many business systems use distributed systems. Multiple applications can be deployed in a distributed system, and multiple threads can be deployed within each application. In a distributed system, many cross-thread calls may be involved in the processing of a service request.

In some scenarios, the link tracking technology can be used to track and record the processing process of the business request in the business system, so as to perform troubleshooting based on the tracked call link information, or analyze the performance of the business system. In the related art, developers need to explicitly add monitoring code to the business system to implement link tracking. Specifically, monitoring code is added where the business system needs to make cross-thread calls, so that the business system can notify the link tracking system through the monitoring code before making cross-thread calls, so that the link tracking system records the cross-thread call information.

However, the above method needs to modify the code of the business system. On the one hand, the development efficiency is low, and on the other hand, it is intrusive to the business system, so that the security of the business system cannot be guaranteed.

SUMMARY OF THE INVENTION

The present disclosure provides a method, apparatus, device, storage medium and program for processing call information.

According to a first aspect of the present disclosure, a method for processing call information is provided, including:

When it is determined that the first thread is to call the second thread to execute the first object, an auxiliary object corresponding to the first object is generated, the life cycle of the first object and the auxiliary object are the same, and the auxiliary object includes the first object. call information, the first call information includes: the identifier of the first object and the identifier of the first calling node in the first thread that calls the second thread;

passing the first object and the helper object to the second thread;

When it is determined that the first object is to be executed by the second thread, target invocation information is generated according to the first invocation information in the auxiliary object, and the first object is executed by the second thread, the The target invocation information includes: an identifier of the first object, a cross-thread invocation indication, an identifier of the first invocation node, and an identifier of a parent invocation node of the first object in the second thread.

According to a second aspect of the present disclosure, there is provided a processing apparatus for calling information, including:

The first processing module is configured to generate an auxiliary object corresponding to the first object when it is determined that the first thread is to call the second thread to execute the first object, and the life cycle of the first object and the auxiliary object is the same, so The auxiliary object includes first call information, and the first call information includes: an identifier of the first object and an identifier of a first call node in the first thread that calls the second thread;

a delivery module, configured to deliver the first object and the auxiliary object to the second thread;

A second processing module, configured to generate target call information according to the first call information in the auxiliary object when it is determined that the first object is to be executed by the second thread, and execute the second thread through the second thread. The first object, the target call information includes: the identifier of the first object, the cross-thread call indication, the identifier of the first call node, the parent call node of the first object in the second thread 's identification.

According to a third aspect of the present disclosure, there is provided an electronic device, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein,

The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method of the first aspect.

According to a fourth aspect of the present disclosure, there is provided a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause the computer to perform the method of the first aspect.

According to a fifth aspect of the present disclosure, there is provided a computer program product, the computer program product comprising: a computer program stored in a readable storage medium, from which at least one processor of an electronic device can Reading the storage medium reads the computer program, and executing the computer program by the at least one processor causes the electronic device to perform the method of the first aspect.

It should be understood that what is described in this section is not intended to identify key or critical features of embodiments of the disclosure, nor is it intended to limit the scope of the disclosure. Other features of the present disclosure will become readily understood from the following description.

Description of drawings

The accompanying drawings are used for better understanding of the present solution, and do not constitute a limitation to the present disclosure. in:

1A is a schematic diagram of a calling process in a distributed business system;

1B is a schematic diagram of the call stack of each thread in an application;

2 is a schematic flowchart of a method for processing call information provided by an embodiment of the present disclosure;

3 is a schematic flowchart of another method for processing call information provided by an embodiment of the present disclosure;

4 is a schematic flowchart of another method for processing call information provided by an embodiment of the present disclosure;

FIG. 5 is a schematic flowchart of another method for processing call information provided by an embodiment of the present disclosure;

6 is a schematic flowchart of another method for processing call information provided by an embodiment of the present disclosure;

7 is a schematic diagram of a cross-thread calling scenario provided by an embodiment of the present disclosure;

8 is a schematic diagram of another cross-thread calling scenario provided by an embodiment of the present disclosure;

9 is a schematic diagram of yet another cross-thread calling scenario provided by an embodiment of the present disclosure;

FIG. 10 is a schematic structural diagram of an apparatus for processing call information according to an embodiment of the present disclosure;

FIG. 11 is a schematic structural diagram of an electronic device according to an embodiment of the present disclosure.

Detailed ways

Exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, which include various details of the embodiments of the present disclosure to facilitate understanding and should be considered as exemplary only. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present disclosure. Also, descriptions of well-known functions and constructions are omitted from the following description for clarity and conciseness.

With the development of Internet business, many business systems adopt distributed system architecture. FIG. 1A is a schematic diagram of a calling process in a distributed service system. Multiple applications can be deployed in a distributed business system. Different applications provide different services or responsibilities, and have different data processing capabilities.

Referring to FIG. 1A, exemplarily, it is assumed that three applications are deployed in the distributed service system, namely application A, application B, and application C. The processing process of a service request in the distributed service system may be as follows: Application B is called in application A, and application C is called in application B.

Among them, one or more threads can be deployed inside each application. In this way, in a distributed business system, the processing of a business request may involve more cross-thread calls. Continuing to refer to FIG. 1A , exemplarily, assuming that thread 1, thread 2 and thread 3 are deployed in application B, the specific processing process of the service request may be as follows: service A calls thread 1 in service B, and during the execution process of thread 1 , Thread 2 needs to be called, and service C needs to be called during the execution of thread 2.

In the calling process shown in FIG. 1A , for application B, the thread through which application B receives the service request from application A is thread 1 , and the thread through which application B calls application C is thread 3 . It can be seen that there is a behavior of cross-thread calling among multiple threads within application B.

In some scenarios, the link tracking technology can be used to track and record the processing process of the business request in the business system, so as to perform troubleshooting based on the tracked call link information, or analyze the performance of the business system. In the related art, developers need to explicitly add monitoring code to the business system to implement link tracking. Specifically, monitoring code is added where the business system needs to make cross-thread calls, so that the business system can notify the link tracking system through the monitoring code before making cross-thread calls, so that the link tracking system records the cross-thread call information.

However, the above method needs to modify the code of the business system. On the one hand, the development efficiency is low, and on the other hand, it is intrusive to the business system, so that the security of the business system cannot be guaranteed.

In order to solve at least one of the above technical problems, the present disclosure provides a method, apparatus, device, storage medium and program for processing invocation information, which are applied to the technical field of invocation chains in computer technology.

In the technical solution of the present disclosure, instead of modifying the code of the business system, a probe program can be integrated in the business system, and the operation of the business system can be monitored through the probe program. Thread, the probe program intercepts the calling behavior, and transfers the calling information from the first thread to the second thread. In the above process, since there is no need to modify the code of the business system, the development efficiency is improved on the one hand, and the security of the business system is guaranteed on the other hand. In addition, by using the auxiliary object to transmit the first invocation information, the first object does not need to be modified, thereby further ensuring the security of the execution process of the business system.

For ease of understanding, concepts or terms involved in the embodiments of the present disclosure are explained below.

Call chain (Trace): A distributed call chain is a trace with a unique traceId. This embodiment discusses the problem of cross-thread tracing within a single application in a distributed system, and Trace represents a call stack in an application .

Span: Each function call will generate a Span with a unique SpanId. For the link monitoring program, it is not necessary to establish a span on each function, but only on the key functions that need to be paid attention to by the business.

Scope: A Scope wraps a Span, and the same Span can be wrapped in any Scope. A Trace contains several Scopes, and multiple Scopes are linked to the parent Scope through the parentScope field to form a chain stack. The Span contained in the Scope at the top of the stack represents the position of the call stack where the current thread is located. In a link monitoring system that usually conforms to the OpenTracing standard, the Scope contains the following: (Span, parentScope). Where Span is the wrapped Span, and parentScope is the parent Scope.

Call stack: It can also be called the Scope stack. An application contains several threads, each thread independently maintains a Scope stack, and each stack frame in the Scope stack corresponds to a call node. Each call node has a Scope, and the Scope wraps a Span, which represents a stack frame in the call stack. FIG. 1B is a schematic diagram of a call stack of each thread in an application. As shown in Figure 1B, without considering the scenario of cross-thread calling, each thread is independent of each other. Every time a new function is called, a new calling node may be created, that is, a new Span and a Scope that wraps the Span may be created. Push the stack into the Scope stack of the current thread. Therefore, the Span sequence stored in the Scope stack is the call stack of the call chain in this application.

The technical solutions of the present disclosure will be described in detail below with reference to several specific embodiments. The following embodiments may be combined with each other, and the same or similar content may not be described repeatedly in some embodiments.

FIG. 2 is a schematic flowchart of a method for processing call information provided by an embodiment of the present disclosure. The method of this embodiment may be executed by an electronic device in which each application of the distributed system is deployed. As shown in Figure 2, the method of this embodiment includes:

S201: When it is determined that the first thread is to call the second thread to execute the first object, generate an auxiliary object corresponding to the first object, the first object and the auxiliary object have the same life cycle, and the auxiliary object includes First call information, where the first call information includes an identifier of the first object and an identifier of a first call node in the first thread that calls the second thread.

Specifically, a probe program can be integrated into the application of the distributed system, and when the application is started, the probe program starts to run and monitors the running process of the application. The probe program can monitor the behavior of cross-thread calls in the application. Exemplarily, the probe program can monitor the calling behavior of the first thread to the second thread, and intercept the calling behavior.

In this embodiment, a scenario in which the first thread calls the second thread to execute the first object is used as an example for description. The first thread may be referred to as a parent thread, and the second thread may be referred to as a child thread. The first object refers to a task object that the first thread needs to call the second thread to execute. For example, the first object may be a code fragment that needs to be executed by the second thread.

It should be understood that when the business system adopts different programming languages, the first object may be an object in different forms. Exemplarily, in a business system based on the Java language, the first object may be a runnable object. A runnable is a mechanism for passing task objects from a parent thread to a child thread.

In some examples, task objects can be passed to child threads through a thread pool. For example, the parent thread delivers the task object to be executed to the thread pool, and the thread pool assigns a child thread to the task object, thereby realizing the transfer of the task object from the parent thread to the child thread. In this way, the behavior of executor.execute(runnable) of the thread pool can be monitored. When the behavior of executor.execute(runnable) of the thread pool is monitored, it means that the behavior of cross-thread calling is intercepted. Among them, executor.execute(runnable) is a method in the Java programming language for delivering runnable objects to the thread pool.

In other examples, when the parent thread needs to execute the task object by the child thread, it can create a new child thread and pass the task object to the newly created child thread. In this way, the behavior of the newly created child thread new Thread(runnable) can be monitored. When the behavior of the newly created child thread new Thread(runnable) is monitored, it means that the cross-thread calling behavior is intercepted. Among them, new Thread(runnable) is a method for creating a new child thread in the Java programming language.

It should be noted that, in the above example, the interception method of the cross-thread calling behavior is illustrated by taking the Java language as an example. For different programming languages, different interception methods may be adopted, which are not limited in this embodiment. It should be understood that, regardless of the programming language, the behavior of cross-thread calls can be intercepted.

In this embodiment, when the first thread calls the second thread, a first call node is generated in the call stack of the first thread. For the convenience of description, in this embodiment, the scope (Scope) of each call node in the call stack is referred to as the identifier of the call node. The first call information may include the identifier of the first object and the identifier of the first call node. For example, the identifier of the first calling node is the Scope of the first calling node, and the identifier of the first object may be the Span wrapped by the Scope.

In this embodiment, when it is determined that the first thread is to call the second thread to execute the first object (that is, the cross-thread calling behavior is intercepted), an auxiliary object corresponding to the first object is generated, and the auxiliary object has the same life cycle as the first object, And, the auxiliary object includes the first call information.

Illustratively, taking the Java programming language as an example, the auxiliary object may be a companion object. For example, a companion object may be created for the first object, and the life cycle of the companion object is bound to the life cycle of the first object, so that the companion object has the same life cycle as the first object.

S202: Transfer the first object and the auxiliary object to the second thread.

In this embodiment, by carrying the first call information in the auxiliary object, the first call information can be transmitted from the first thread to the second thread through the auxiliary object without modifying the first object. Since the first object does not need to be modified, the security of the first object is guaranteed.

S203: when it is determined that the first object is to be executed by the second thread, generate target invocation information according to the first invocation information in the auxiliary object, and execute the first object through the second thread, The target call information includes: an identifier of the first object, a cross-thread call indication, an identifier of the first call node, and an identifier of a parent call node of the first object in the second thread.

In this embodiment, since the auxiliary object carries the first invocation information, after the auxiliary object is passed to the second thread, the target invocation information can be generated according to the first invocation information in the auxiliary object. The target invocation information represents the related information of the first object in the second thread.

The target invocation information includes: an identifier of the first object, a cross-thread invocation indication, an identifier of the first invocation node, and an identifier of a parent invocation node of the first object in the second thread. The cross-thread call indication is used to indicate that the first object is passed from another thread to this thread through a cross-thread call.

The method for processing call information provided by this embodiment includes: when it is determined that a first thread is to call a second thread to execute a first object, generating an auxiliary object corresponding to the first object, the first object and the auxiliary object The life cycle is the same, the auxiliary object includes the first call information, the first call information includes the identification of the first object and the identification of the first calling node in the first thread that calls the second thread, and the first object and the auxiliary object are combined. It is passed to the second thread, and when it is determined that the first object is to be executed by the second thread, target invocation information is generated according to the first invocation information in the auxiliary object, and the first object is executed by the second thread. In the above process, since there is no need to modify the code of the business system, the link tracking of cross-thread calls can be realized, which improves the development efficiency on the one hand, and ensures the security of the business system on the other hand. In addition, by using the auxiliary object to transmit the first invocation information, the first object does not need to be modified, which further ensures the security of the execution process of the business system.

On the basis of the above embodiment, the technical solution of the present disclosure will be described in more detail below with reference to a more specific embodiment.

FIG. 3 is a schematic flowchart of another method for processing call information provided by an embodiment of the present disclosure. As shown in Figure 3, the method of this embodiment includes:

S301: Monitor cross-thread calling behavior.

For example, in the Java programming language, the behavior of exec is monitored. When the exec behavior is detected, it is determined that a cross-thread call is required.

S302: Obtain the first object when it is determined that the first thread is to call the second thread to execute the first object.

S303: Create an auxiliary object.

S304: Bind the life cycle of the auxiliary object with the life cycle of the first object.

For example, in the Java programming language, the first object may be a runnable object. A runnable object can be an ordinary class object. Auxiliary objects can be companion objects. A weak reference mechanism can be used to implement the life cycle binding relationship between the auxiliary object and the first object.

S305: Generate first call information.

The first call information includes the identifier of the first object and the identifier of the first call node in the first thread that calls the second thread.

S306: Add the first call information to the auxiliary object.

S307: Pass the first object and the auxiliary object to the second thread through the first thread.

S308: Monitor the execution behavior of the second thread on the first object.

S309: When it is determined that the second thread is to execute the first object, acquire an auxiliary object corresponding to the first object.

S310: Generate target invocation information according to the first invocation information in the auxiliary object.

Wherein, the target call information includes: the identifier of the first object, the cross-thread call indication, the identifier of the first call node, and the identifier of the parent call node of the first object in the second thread.

S311: Execute the first object through the second thread.

S312: After the execution of the first object ends, clear the target call information.

For example, you can monitor the run() behavior of the runnable object. When the runnable.run() behavior is detected, it indicates that the second thread starts to execute the first object. In the Java programming language, interception of runnable.run() behavior can be achieved using Java agent bytecode enhancement techniques. When the runnable.run() behavior is intercepted, the companion object is taken out, the target call information is generated according to the first call information carried in the companion companion object, and then the runnable.run() behavior is actually executed through the second thread, and the runnable. After the execution of the run() behavior is complete, clean up the target invocation information to restore the state before the runnable.run() behavior.

S313: The life cycle of the first object ends, the first object is destroyed, and the auxiliary object is destroyed accordingly.

The transmission method of the call information provided by this embodiment between different threads does not change the first object itself, but uses the life cycle binding technology to combine the first object (for example, the runnable object) and the auxiliary object (for example, the companion object). The life cycle is bound, and the first call information is stored in the auxiliary object, and the auxiliary object carrying the first call information is delivered to the second thread along with the first object. In this way, it is logically considered that the first object (for example, the runnable object) carries the first invocation information without modifying the first object, thereby ensuring the execution security of the first object and thus the execution security of the business system. In addition, since there is no need to modify the code of the business system, the development efficiency will not be affected, and all cross-thread calling behaviors in the business system can be recorded.

In the embodiments shown in FIG. 2 and FIG. 3 , it is described that the first invocation information is transmitted using the auxiliary object mode. In the auxiliary object mode, the execution behavior of the first object (for example, the runnable.run() behavior) needs to be intercepted, and in some scenarios, the execution behavior of some objects may not be intercepted. For example, in the Java programming language, only existing classes can use Java Agent technology to intercept methods. For some dynamically generated object types such as lambda expressions, interception may not be possible. In this embodiment of the present disclosure, for a scenario where the execution behavior of the first object cannot be intercepted, the first invocation information may be transmitted in a wrapper object mode. The following description will be made with reference to FIG. 4 .

FIG. 4 is a schematic flowchart of another method for processing call information provided by an embodiment of the present disclosure. As shown in Figure 4, the method of this embodiment includes:

S401: When it is determined that the first thread is to call the second thread to execute the first object, obtain the type of the first object, the type of the first object is the first type or the second type, and the execution behavior of the object of the first type can be intercepted , the execution behavior of objects of the second type cannot be intercepted.

In this embodiment, objects can be divided into two types, namely the first type and the second type, according to whether the execution behavior of the object can be intercepted. The execution behavior of the object of the first type can be intercepted, and the execution behavior of the object of the second type cannot be intercepted.

The following takes the Java programming language as an example for illustration. In the Java programming language, runnable objects generated by lambda expressions are not suitable for interception for the following reasons:

(1) The Java language dynamically generates a lambda expression class for each execution of a lambda expression. Bytecode enhancements to each lambda expression class would incur excessive overhead.

(2) The Java language stipulates that the lambda expression class is not managed by the Instrumentation interface, so it cannot be intercepted using the bytecode enhancement technology. Instrumentation refers to agents that can be independent of applications.

For the above reasons, in the Java programming language, the types of objects of the lambda expression class can be recognized as the second type, and the types of objects of other classes other than the lambda expression class can be recognized as the first type.

S402: If the type of the first object is the first type, use the auxiliary object mode to transmit the first call information to the second thread.

It should be understood that for the specific implementation of S402, reference may be made to the detailed description of the embodiment shown in FIG. 2 or FIG. 3 , which is not repeated here.

S403: If the type of the first object is the second type, the first call information is transmitted to the second thread by adopting the wrapping object mode.

In this embodiment, the wrapping object mode is another way of transferring call information between different threads. In this manner, the first object and the first call information are packaged to obtain a packaged object, and the packaged object is delivered to the second thread. The wrapper object is then executed by the second thread.

The packaging object mode in the embodiment shown in FIG. 4 will be described in detail below with reference to a specific embodiment.

FIG. 5 is a schematic flowchart of another method for processing call information provided by an embodiment of the present disclosure. As shown in Figure 5, the method of this embodiment includes:

S501: Monitor cross-thread calling behavior.

For example, in the Java programming language, the behavior of exec is monitored. When the exec behavior is detected, it is determined that a cross-thread call is required.

S502: Obtain the first object when it is determined that the first thread is to call the second thread to execute the first object.

S503: Create a packaging object.

S504: Use the wrapping object to wrap the first object.

S505: Generate first call information.

Wherein, the first calling information includes: the identifier of the first object and the identifier of the first calling node in the first thread that calls the second thread.

S506: Add the first call information to the packaging object.

S507: Pass the packaging object to the second thread through the first thread.

S508: Execute the execution behavior of the packaging object through the second thread.

S509: Obtain the first call information in the packaging object.

S510: Generate target invocation information according to the first invocation information in the packaging object.

The target call information includes: the identifier of the first object, the cross-thread call indication, the identifier of the first call node, and the identifier of the parent call node of the first object in the second thread.

S511: Execute the first object through the second thread.

S512: After the execution of the first object ends, clear the target call information.

S513: After the execution of the packaging object ends, the life cycle of the packaging object ends, the packaging object is destroyed, and the first object is destroyed accordingly.

For example, taking the Java programming language as an example, an object of the TracedRunnable class that implements the runnable interface can be used to wrap the runnable object with the TracedRunnable wrapper object, and the first call information is carried in the TracedRunnable wrapper object. Pass the TracedRunnable wrapper object to the second thread. Execute the TracedRunnable.run() behavior in the second thread, take out the first call information carried in the TracedRunnable, generate the target call information according to the first call information, and then actually execute the runnable.run() behavior through the second thread, and execute the runnable.run() behavior in the runnable After the execution of the .run() behavior is complete, clean up the target invocation information to restore the state before the runnable.run() behavior.

In practical applications, there is a hidden danger in the wrapping mechanism of the runnable object by the TraceRunnable wrapper object, because the TraceRunnable wrapper object only wraps the run behavior of the runnable object, and other behaviors except the run behavior will be erased. In this way, if there are other behaviors other than the run behavior in the runnable object, for example, the thread pool uses the priority queue to sort the task objects (compare), then because the TraceRunnable wrapper object will erase the runnable object during the wrapping process The compare behavior will cause the business code to throw an exception, making the application unavailable.

In the embodiment of the present disclosure, based on the above considerations, in the embodiment shown in FIG. 4, not all scenarios adopt the wrapper object mode, but the auxiliary object mode is used to transmit call information in the case that the run behavior of the first object can be intercepted , only when the run behavior of the first object cannot be intercepted, the wrapper object mode is used to transfer the call information, thereby ensuring the security of the business system to the greatest extent.

In the Java programming language, since only the run behavior of an object of the lambda expression class cannot be intercepted, when the first object is an object of the lambda expression class, the wrapping object mode can be used to transfer the calling information. For objects other than the lambda expression class, the auxiliary object pattern can be used to pass the call information.

Further, the direct parent class of the lambda expression is the Java.lang.Object class, and there are no other types in the middle, so there is no possibility of other behaviors being erased. Moreover, the type of the lambda expression itself is automatically generated and transparent to the user, and it is impossible for the user to call other behaviors other than run() on the runnable object generated by the lambda expression. It can be seen from the above analysis that the object of the lambda expression class only has the run behavior, but no other behavior. Therefore, in the Java language, the security of the business system can be guaranteed even if the wrapper object pattern is adopted for the objects of the lambda expression class.

The above-mentioned embodiments focus on describing the way in which the call information is transmitted between the first thread and the second thread. The following describes the process of arranging and processing the call information by the first thread and the second thread with reference to this embodiment.

In this embodiment, in the scenario of cross-thread calling, since the Scope stack is maintained independently by each thread, it is necessary to design a cross-thread Scope and Span orchestration mechanism. The cross-thread orchestration mechanism needs to meet the following characteristics:

(1) Correctly add and delete spans from this thread.

(2) Correctly add and delete spans from the parent thread when the cross-thread calling behavior occurs.

(3) During the period when the parent thread Scope stack holds a Span, it is necessary to ensure that the Span is readable and writable to the parent thread and readable to the child thread.

(4) After the parent thread's Scope stack cancels a reference to a Span, and there is still a child thread's Scope stack holding a reference to the Span, at least ensure that the Span is readable by the child thread.

(5) After the Scope stack of the parent thread and the last child thread both cancel the reference to a Span, there is no need to guarantee the accessibility of the Span.

(6) At any time when a Span can be accessed, it is necessary to ensure that any parent Span can be accessed through the Span. But there is no guarantee that any of its child spans can be accessed through a span at any time.

Based on the above analysis, in this embodiment, the data structure of Span can be set as follows:

class Span{

String traceId;

String spanId;

//other required fields

}

The traceId is the globally unique identifier corresponding to the calling link, and the spanId is the globally unique identifier corresponding to the Span.

In this embodiment, the data structure of the Scope can be set as follows:

class Scope{

span span;

boolean isExternal;

Scope localParent;

Scope externalParent;

}

Among them, Span is the Span wrapped by the Scope, and isExternal represents whether the Span is created in this thread or passed to this thread by the parent thread. localParent represents the parent Scope in this thread, and externalParent represents the Scope at the top of the stack when the parent thread has cross-thread calling behavior.

Based on the above data structures of Span and Scope, the process of arranging the first call information in the first thread and the process of arranging target call information in the second thread will be described in detail below with reference to FIG. 6 .

FIG. 6 is a schematic flowchart of another method for processing call information provided by an embodiment of the present disclosure. As shown in FIG. 6 , the method of this embodiment may include:

S601: Monitor cross-thread calling behavior.

S602: When it is determined that the first thread is to call the second thread to execute the first object, obtain a first call stack corresponding to the first thread.

The first call stack is used to store the call node corresponding to the first thread.

S603: Generate first call information according to the top call node in the first call stack.

Specifically, the top call node of the first call stack is the first call node. The identifier of the call node on the top of the stack in the first call stack (for example, the scope on the top of the stack) is determined as the identifier of the first call node, and the span wrapped by the call node on the top of the stack in the first call stack is the identifier of the first object. In this way, the first call information includes the identifier of the first object and the identifier of the first call node.

S604: Transfer the first call information and the first object to the second thread.

For example, it is assumed that the top call node of the first call stack is Scope1, and Span1 is wrapped in Scope1. Then, Scope1 wrapped with Span1 is passed to the second thread as the first call information.

It should be understood that, in S604, the way of transmitting the first call information and the first object to the second thread may be transmitted in an auxiliary object mode or in a packaged object mode, which is not limited in this embodiment. For details, refer to the detailed description of the foregoing embodiments.

S605: any number of function calls.

S606: Pop the call node at the top of the stack from the first call stack.

For example, when the life cycle of Scope1 ends, the Scope1 wrapped with Span1 is popped from the first call stack.

S607: Acquire the identifier of the first object in the first calling information and the identifier of the first calling node.

Exemplarily, after receiving the first call information, the second thread can obtain Scope1 from the first thread from the first call information, and take out Span1 wrapped in Scope1.

S608: Acquire a second call stack corresponding to the second thread, where the second call stack is used to store a call node corresponding to the second thread.

In this way, the target call information can be generated according to the first call information and the second call stack. For a possible implementation, see S609 to S610.

S609: Determine, according to the second call stack, the identifier of the parent call node of the first call node in the second thread.

If the second call stack is empty, determine that the identifier of the parent calling node of the first object in the second thread is empty; or,

If the second call stack is not empty, the identifier of the call node at the top of the stack in the second call stack is determined as the identifier of the parent call node of the first object in the second thread.

S610: Determine the target invocation information including: a cross-thread invocation indication, first invocation information, and an identifier of a parent invocation node of the first invocation node in the second thread.

In this way, the target invocation information can be generated according to the cross-thread invocation indication, the first invocation information, and the identifier of the parent invocation node of the first invocation node in the second thread. That is, the target call information includes: the identifier of the first call node, the cross-thread call indication, the identifier of the parent call node of the first call node in the second thread, and the identifier of the first call node in the first thread.

S611: Generate a second invocation node according to the target invocation information.

S612: Update the second call node to the top of the second call stack.

For example, the top Scope of the stack is obtained from the second call stack corresponding to the second thread, and denoted as Scope2. If the second call stack is empty, then Scope2=null.

Create a new Scope, denoted as Scope3, use Scope3 to wrap Span1, set Scope3.localParent=Scope2, Scope3.externalParent=Scope1. Point the top-of-the-stack pointer of the second call stack to Scope3.

S613: Execute the first object through the second thread.

S614: After the execution of the first object is completed, pop the second call node from the second call stack.

For example, Scope3 is popped from the second call stack, and the stack top pointer of the second call stack is pointed to Scope3.localParent=Scope2. The second call stack is restored to the state before execution.

In this embodiment, Span is cross-threaded, and as different threads are passed, Scope belongs to a single thread, and is not at any time during the running process of the first thread (parent thread) and the second thread (child thread). Scope stacks should be modified mutually. When the parent thread has a cross-thread calling behavior, the Scope stack of the parent thread is not modified, and only the top Scope of the stack is passed to the child thread. After the parent thread completes the transfer, it does not need to wait for the child thread to complete the task. The Scope of the parent thread stack can be popped up at any time, and the Span can be popped up. When the child thread receives the Scope from the parent thread, it needs to create a new Scope to wrap the Span wrapped by the Scope on the top of the stack of the parent thread, and link the localParent of the new Scope to the Scope on the top of the thread's stack, and the externalParent to the Scope on the top of the stack of the parent thread, and then Push the new Scope onto the top of this thread's Scope stack. After the execution of the runnable task corresponding to the Span is completed, the sub-thread pops the Scope and the Span, and the sub-thread Scope stack returns to the state before execution.

On the basis of the embodiment shown in FIG. 6 , Span backtracking can also be supported. Assume that the top call node in the call stack of the child thread is ScopeC, which wraps SpanC and goes back to the entry SpanA. Among them, SpanA is in the call stack of the parent thread.

When backtracking, determine whether the parent thread's top Scope (ie externalParent field) is empty when the cross-thread call corresponding to ScopeC is empty. If the externalParent field is not empty, continue to search recursively along the externalParent field until the externalParent field is empty. , the Span wrapped by the current Scope is the entry Span.

This embodiment reasonably arranges the Scope data structure of each call node in the call stack, so that each call node in the call chain supports cross-thread backtracking, which can be applied to a link tracking scenario with backtracking requirements. Backtracking requirements widely exist in egress traffic monitoring scenarios such as Structured Query Language (SQL), cache (cache), and Remote Procedure Call (RPC).

On the basis of any of the above-mentioned embodiments, several specific cross-thread calling scenarios are used as examples to illustrate the processing process of calling information in the embodiments of the present disclosure with reference to FIGS. 7 to 9 .

In the following several cross-thread call scenarios, the following assumptions are made: (1) The parent thread makes cross-thread calls through the cross-thread transfer method and the call stack arrangement mechanism in the above embodiment. (2) Suppose that after the parent thread puts the Runnable into the child thread, the parent thread immediately executes other arbitrary functions to generate SpanC. (3) When Runnable is executed, SpanD will be generated.

FIG. 7 is a schematic diagram of a cross-thread calling scenario provided by an embodiment of the present disclosure. As shown in Figure 7, thread 1 (parent thread) passes the first object (take Runnable object as an example) to thread 2 (child thread) for execution. This is a normal cross-thread call scenario.

(1). In the initial state, it is assumed that the call stacks of thread 1 and thread 2 are as follows:

Call stack of thread 1: [ScpoeA1(SpanA)]

Call stack for thread 2: []

(2). Thread 1 needs to call and execute the Runnable object across threads during the execution of SpanA. Thread 1 puts the Runnable object into the thread pool, and the call stacks of thread 1 and thread 2 are as follows:

Call stack of thread 1: [ScpoeA1(SpanA), ScopeA2(SpanB)]

Call stack for thread 2: []

(3). After thread 1 puts the Runnable object into the thread pool, ScopeA2 (SpanB) pops up, thread 1 executes SpanC, and the call stacks of thread 1 and thread 2 are as follows:

Call stack of thread 1: [ScopeA1(SpanA),ScopeA3(SpanC)]

Call stack for thread 2: []

(4). When thread 2 starts to execute the Runnable object, it triggers the creation of ScopeB1 (SpanB), and generates SpanD during the execution of SpanB. The call stacks of thread 1 and thread 2 are as follows:

Call stack of thread 1: [ScopeA1(SpanA),ScopeA3(SpanC)]

Call stack of thread 2: [ScopeB1(SpanB),ScopeB2(SpanD)]

(5). After thread 2 executes the Runnable object, ScopeB1(SpanB) and ScopeB2(SpanD) are popped up, and the call stacks of thread 1 and thread 2 are as follows:

Call stack of thread 1: [ScopeA1(SpanA),ScopeA3(SpanC)]

Call stack for thread 2: []

(6) The SpanC execution of thread 1 ends, and the call stacks of thread 1 and thread 2 are as follows:

Call stack of thread 1: [ScopeA1(SpanA)]

Call stack for thread 2: []

In the cross-thread call scenario shown in Figure 7, the final call chain is formed as follows:

SpanA→SpanB→SpanD

→SpanC

That is, the parent node of SpanB is SpanA, the parent node of SpanD is SpanB, and the parent node of SpanC is SpanA.

FIG. 8 is a schematic diagram of another cross-thread calling scenario provided by an embodiment of the present disclosure. As shown in Figure 8, in this scenario, thread 1 may itself be a thread pool thread. Thread 1 puts the first object (take the Runnable object as an example) into the thread pool, and then thread 1 is scheduled to continue executing the Runnable object. For example, ScheduledExecutorService in Java language, ForkJoinPool fits this scenario. Among them, ScheduledExecutorService is a scheduled task class based on thread pool design, and ForkJoinPool is a fork/combined framework class.

(1). In the initial state, assume that the call stack of thread 1 is as follows:

[ScopeA1(SpanB)]

(2). Thread 1 puts the Runnable object into the thread pool, and the call stack of thread 1 is as follows:

[ScopeA1(SpanB)]

(3). After thread 1 puts the Runnable object into the thread pool, ScopeA1 (SpanB) pops up, thread 1 executes SpanC, and the call stack of thread 1 is as follows:

[ScopeA2(SpanC)]

(4). When thread 1 starts to execute the Runnable object, it triggers the creation of ScopeA3 (SpanB), and generates SpanD during the execution of SpanB: The call stack of thread 1 is as follows:

[ScopeA3(SpanB),ScopeA4(SpanD)]

(5). After thread 1 executes the Runnable object, the call stack of thread 1 is as follows:

[]

(6). At the end, the call stack of thread 1 is as follows:

[]

In the cross-thread call scenario shown in Figure 8, the final call chain is formed as follows:

SpanB→SpanD

That is, the parent node of SpanD is SpanB.

FIG. 9 is a schematic diagram of yet another cross-thread calling scenario provided by an embodiment of the present disclosure. As shown in Figure 9, thread 1 (parent thread) passes the first object (take the Runnable object as an example) to thread 2 (child thread) for execution, thread 2 executes the Runnable object, and passes the Runnable object to the thread in some way 1. Thread 1 executes the Runnable object again. This is an extreme cross-thread call scenario.

(1). In the initial state, it is assumed that the call stacks of thread 1 and thread 2 are as follows:

Call stack of thread 1: [ScopeA1(SpanA)]

Call stack for thread 2: []

(2). Thread 1 needs to call and execute the Runnable object across threads during the execution of SpanA. Thread 1 puts the Runnable object into the thread pool, and the call stacks of thread 1 and thread 2 are as follows:

Call stack of thread 1: [ScopeA1(SpanA), ScopeA2(SpanB)]

Call stack for thread 2: []

(3). After thread 1 puts the Runnable object into the thread pool, ScopeA2 (SpanB) pops up, thread 1 executes SpanC, and the call stacks of thread 1 and thread 2 are as follows:

Call stack of thread 1: [ScopeA1(SpanA),ScopeA3(SpanC)]

Call stack for thread 2: []

(4). When thread 2 starts to execute the Runnable object, it triggers the creation of ScopeB1 (SpanB), and generates SpanD during the execution of SpanB. The call stacks of thread 1 and thread 2 are as follows:

Call stack of thread 1: [ScopeA1(SpanA),ScopeA3(SpanC)]

Call stack of thread 2: [ScopeB1(SpanB),ScopeB2(SpanD)]

(5). After thread 2 finishes running (and returns the Runnable object to thread 1), the call stacks of thread 1 and thread 2 are as follows:

Call stack of thread 1: [ScopeA1(SpanA),ScopeA3(SpanC)]

Call stack for thread 2: []

(6). Thread 1 starts to execute the Runnable object, triggers the creation of ScopeA4 (SpanB), and generates SpanD during the execution of SpanB. The call stacks of thread 1 and thread 2 are as follows:

Call stack of thread 1: [ScopeA1(SpanA), ScopeA3(SpanC), ScopeA4(SpanB), ScopeA5(SpanD)]

Call stack for thread 2: []

(7). After thread 1 runs, the call stacks of thread 1 and thread 2 are as follows:

Call stack of thread 1: [ScopeA1(SpanA),ScopeA3(SpanC)]

Call stack for thread 2: []

(8). At the end, the call stacks of thread 1 and thread 2 are as follows:

Call stack of thread 1: [ScopeA1(SpanA)]

Call stack for thread 2: []

In the cross-thread call scenario shown in Figure 9, the final call chain is formed as follows:

SpanA→SpanC

→SpanB→SpanD

→SpanD

That is, the parent node of SpanC is SpanA, the parent node of SpanB is SpanA, and the parent node of SpanD is SpanB.

In the cross-thread calling scenario shown in Figure 9, in step (6), the top of the stack referenced by thread 1 is SpanD, the reference link is SpanD→SpanB→SpanA, and the link of Scope is ScopeA5→ScopeA4→ScopeA3 →ScopeA1. Therefore, at the end of step (6), when SpanD and SpanB are popped up, SpanB can be correctly linked to ScopeA1 (SpanA) through the externalParent relationship of ScopeA4, and the Scope of thread 1 can also be restored to the state before running Runnable (step (5)) ). Without a mechanism for externalParent, SpanB would incorrectly link to SpanC. Therefore, the two link mechanisms of externalParent and localParent are essential.

FIG. 10 is a schematic structural diagram of an apparatus for processing call information according to an embodiment of the present disclosure. The apparatus of this embodiment may be in the form of software and/or hardware. As shown in FIG. 10 , the apparatus 1000 for processing invocation information provided in this embodiment includes: a first processing module 1001 , a transfer module 1002 , and a second processing module 1003 .

The first processing module 1001 is configured to generate an auxiliary object corresponding to the first object when it is determined that the first thread is to call the second thread to execute the first object, the life cycle of the first object and the auxiliary object Similarly, the auxiliary object includes first call information, and the first call information includes: the identifier of the first object and the identifier of the first call node in the first thread that calls the second thread;

a delivery module 1002, configured to deliver the first object and the auxiliary object to the second thread;

The second processing module 1003 is configured to, when it is determined that the second thread is to execute the first object, generate target invocation information according to the first invocation information in the auxiliary object, and execute the execution through the second thread For the first object, the target call information includes: the identifier of the first object, the cross-thread call indication, the identifier of the first call node, and the parent call of the first object in the second thread The ID of the node.

In a possible implementation manner, the first processing module 1001 includes:

A creation unit, configured to create the auxiliary object, and bind the life cycle of the auxiliary object to the life cycle of the first object;

a first generating unit, configured to generate the first invocation information;

An adding unit is configured to add the first call information to the auxiliary object.

In a possible implementation manner, the first generating unit includes:

an acquisition subunit, configured to acquire a first call stack corresponding to the first thread, where the first call stack is used to store a call node corresponding to the first thread;

A generating subunit is configured to generate the first call information according to the top call node in the first call stack.

In a possible implementation manner, the second processing module 1003 includes:

a first obtaining unit, configured to obtain the first invocation information in the auxiliary object;

a second obtaining unit, configured to obtain a second call stack corresponding to the second thread, where the second call stack is configured to store a call node corresponding to the second thread;

A second generating unit, configured to generate the target call information according to the first call information and the second call stack.

In a possible implementation manner, the second generating unit includes:

a first determining subunit, configured to determine, according to the second call stack, the identifier of the parent calling node of the first object in the second thread;

A second determination subunit, configured to determine that the target call information includes the cross-thread call indication, the first call information, and the identifier of the parent call node of the first call node in the second thread.

In a possible implementation manner, the first determination subunit is specifically used for:

If the second call stack is empty, determine that the identifier of the parent calling node of the first object in the second thread is empty; or,

If the second call stack is not empty, the identifier of the call node at the top of the stack in the second call stack is determined as the identifier of the parent call node of the first object in the second thread.

In a possible implementation manner, the second processing module 1003 further includes:

a third generating unit, configured to generate a second calling node according to the target calling information;

An update unit, configured to update the second call node to the top of the second call stack.

In a possible implementation manner, the first processing module 1001 is specifically used for:

Obtain the type of the first object, the type of the first object is the first type or the second type, the execution behavior of the first type object can be intercepted, and the execution behavior of the second type object cannot be intercepted;

If the type of the first object is the first type, an auxiliary object corresponding to the first object is generated.

In a possible implementation manner, the first processing module 1001 is further configured to: if the type of the first object is the second type, wrap the first object and the first call information get the wrapper object;

The delivery module 1002 is further configured to: deliver the wrapper object to the second thread;

The second processing module 1003 is further configured to: execute the wrapper object through the second thread.

The apparatus for processing invocation information provided in this embodiment can be used to execute the technical solutions in any of the above method embodiments, and the implementation principles and technical effects thereof are similar, and will not be repeated here.

According to an embodiment of the present disclosure, the present disclosure also provides an electronic device and a readable storage medium.

According to an embodiment of the present disclosure, the present disclosure also provides a computer program product, the computer program product includes: a computer program, the computer program is stored in a readable storage medium, and at least one processor of the electronic device can read from the readable storage medium A computer program is taken, and at least one processor executes the computer program so that the electronic device executes the solution provided by any of the foregoing embodiments.

11 shows a schematic block diagram of an example electronic device 1100 that may be used to implement embodiments of the present disclosure. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are by way of example only, and are not intended to limit implementations of the disclosure described and/or claimed herein.

As shown in FIG. 11 , the electronic device 1100 includes a computing unit 1101 that can be generated according to a computer program stored in a read only memory (ROM) 1102 or a computer program loaded from a storage unit 1108 into a random access memory (RAM) 1103 Various appropriate actions and processes are performed. In the RAM 1103, various programs and data necessary for the operation of the device 1100 can also be stored. The computing unit 1101 , the ROM 1102 , and the RAM 1103 are connected to each other through a bus 1104 . An input/output (I/O) interface 1105 is also connected to the bus 1104 .

Various components in the device 1100 are connected to the I/O interface 1105, including: an input unit 1106, such as a keyboard, mouse, etc.; an output unit 1107, such as various types of displays, speakers, etc.; a storage unit 1108, such as a magnetic disk, an optical disk, etc. ; and a communication unit 1109, such as a network card, a modem, a wireless communication transceiver, and the like. The communication unit 1109 allows the device 1100 to exchange information/data with other devices through a computer network such as the Internet and/or various telecommunication networks.

Computing unit 1101 may be various general-purpose and/or special-purpose processing components with processing and computing capabilities. Some examples of computing units 1101 include, but are not limited to, central processing units (CPUs), graphics processing units (GPUs), various specialized artificial intelligence (AI) computing chips, various computing units that run machine learning model algorithms, digital signal processing processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1101 executes the various methods and processes described above, such as a processing method of calling information. For example, in some embodiments, the processing method of invoking information may be implemented as a computer software program tangibly embodied on a machine-readable medium, such as storage unit 1108 . In some embodiments, part or all of the computer program may be loaded and/or installed on device 1100 via ROM 1102 and/or communication unit 1109 . When the computer program is loaded into the RAM 1103 and executed by the computing unit 1101, one or more steps of the above-described method of processing call information may be performed. Alternatively, in other embodiments, the computing unit 1101 may be configured to execute the processing method of invoking information by any other suitable means (eg, by means of firmware).

Various implementations of the systems and techniques described herein above may be implemented in digital electronic circuitry, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips system (SOC), load programmable logic device (CPLD), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include being implemented in one or more computer programs executable and/or interpretable on a programmable system including at least one programmable processor that The processor, which may be a special purpose or general-purpose programmable processor, may receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device an output device.

Program code for implementing the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer or other programmable data processing apparatus, such that the program code, when executed by the processor or controller, performs the functions/functions specified in the flowcharts and/or block diagrams. Action is implemented. The program code may execute entirely on the machine, partly on the machine, partly on the machine and partly on a remote machine as a stand-alone software package or entirely on the remote machine or server.

In the context of the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in connection with the instruction execution system, apparatus or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media may include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media would include one or more wire-based electrical connections, portable computer disks, hard disks, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory), fiber optics, compact disk read only memory (CD-ROM), optical storage, magnetic storage, or any suitable combination of the foregoing.

To provide interaction with a user, the systems and techniques described herein may be implemented on a computer having a display device (eg, a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user ); and a keyboard and pointing device (eg, a mouse or trackball) through which a user can provide input to the computer. Other kinds of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (eg, visual feedback, auditory feedback, or tactile feedback); and can be in any form (including acoustic input, voice input, or tactile input) to receive input from the user.

The systems and techniques described herein may be implemented on a computing system that includes back-end components (eg, as a data server), or a computing system that includes middleware components (eg, an application server), or a computing system that includes front-end components (eg, a user's computer having a graphical user interface or web browser through which a user may interact with implementations of the systems and techniques described herein), or including such backend components, middleware components, Or any combination of front-end components in a computing system. The components of the system may be interconnected by any form or medium of digital data communication (eg, a communication network). Examples of communication networks include: Local Area Networks (LANs), Wide Area Networks (WANs), and the Internet.

A computer system can include clients and servers. Clients and servers are generally remote from each other and usually interact through a communication network. The relationship of client and server arises by computer programs running on the respective computers and having a client-server relationship to each other. The server can be a cloud server, also known as a cloud computing server or a cloud host. It is a host product in the cloud computing service system to solve the traditional physical host and VPS service ("Virtual Private Server", or "VPS" for short). , there are the defects of difficult management and weak business expansion. The server can also be a server of a distributed system, or a server combined with a blockchain.

It should be understood that steps may be reordered, added or deleted using the various forms of flow shown above. For example, the steps described in the present application can be executed in parallel, sequentially or in different orders, and as long as the desired results of the technical solutions disclosed in the present disclosure can be achieved, no limitation is imposed herein.

The above-mentioned specific embodiments do not constitute a limitation on the protection scope of the present disclosure. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modifications, equivalent replacements, and improvements made within the spirit and principles of the present disclosure should be included within the protection scope of the present disclosure.

Claims (18)

1. A processing method of call information is applied to electronic equipment with a distributed system, a probe program is integrated in the distributed system, the probe program is used for monitoring cross-thread call behavior of application in the distributed system, when monitoring that a first thread waits to call a second thread, the call behavior is intercepted, and call information is transmitted to the second thread from the first thread; the method comprises the following steps:

When it is determined that the first thread is to call the second thread to execute a first object, acquiring the type of the first object, wherein the type of the first object is a first type or a second type, the execution behavior of the object of the first type can be intercepted, and the execution behavior of the object of the second type cannot be intercepted;

if the type of the first object is the first type, generating an auxiliary object corresponding to the first object, where the life cycles of the first object and the auxiliary object are the same, the auxiliary object includes first call information, and the first call information includes: the identification of the first object and the identification of a first calling node calling the second thread in the first thread;

passing the first object and the auxiliary object to the second thread;

when the second thread is determined to be used for executing the first object, generating target calling information according to the first calling information in the auxiliary object, and executing the first object through the second thread, wherein the target calling information comprises: the identification of the first object, cross-thread calling indication, the identification of the first calling node, and the identification of a father calling node of the first object in the second thread.

2. The method of claim 1, wherein generating an auxiliary object corresponding to the first object comprises:

creating the auxiliary object and binding the life cycle of the auxiliary object with the life cycle of the first object;

generating the first calling information;

and adding the first calling information into the auxiliary object.

3. The method of claim 2, wherein generating the first invocation information includes:

acquiring a first call stack corresponding to the first thread, wherein the first call stack is used for storing a call node corresponding to the first thread;

and generating the first calling information according to a stack top calling node in the first calling stack.

4. The method of any of claims 1 to 3, wherein generating target invocation information from the first invocation information in the auxiliary object comprises:

acquiring the first calling information in the auxiliary object;

acquiring a second call stack corresponding to the second thread, wherein the second call stack is used for storing a call node corresponding to the second thread;

and generating the target calling information according to the first calling information and the second calling stack.

5. The method of claim 4, wherein generating the target call information from the first call information and the second call stack comprises:

determining the identification of a parent calling node of the first object in the second thread according to the second call stack;

determining that the target call information includes the cross-thread call indication, the first call information, and an identification of a parent call node of the first object in the second thread.

6. The method of claim 5, wherein determining, from the second call stack, an identification of a parent calling node of the first object in the second thread comprises:

if the second call stack is empty, determining that the identifier of the parent call node of the first object in the second thread is empty; or,

and if the second call stack is not empty, determining the identifier of the top call node in the second call stack as the identifier of the father call node of the first object in the second thread.

7. The method of claim 4, further comprising:

generating a second calling node according to the target calling information;

and updating the second calling node to be the stack top of the second calling stack.

8. The method of claim 1, further comprising:

if the type of the first object is the second type, packaging the first object and the first calling information to obtain a packaged object;

passing the wrapper object to the second thread;

executing the wrapper object by the second thread.

9. A processing device for calling information is arranged on an electronic device with a distributed system, a probe program is integrated in the distributed system, the probe program is used for monitoring cross-thread calling behaviors of applications in the distributed system, intercepting the calling behaviors when a first thread is monitored to call a second thread, and transmitting calling information from the first thread to the second thread; the device comprises:

the first processing module is used for acquiring the type of a first object when the first thread is determined to call a second thread to execute the first object, wherein the type of the first object is a first type or a second type, the execution behavior of the first type of object can be intercepted, and the execution behavior of the second type of object cannot be intercepted;

If the type of the first object is the first type, generating an auxiliary object corresponding to the first object, where the life cycles of the first object and the auxiliary object are the same, the auxiliary object includes first call information, and the first call information includes: the identification of the first object and the identification of a first calling node calling the second thread in the first thread;

a transfer module to transfer the first object and the auxiliary object to the second thread;

a second processing module, configured to, when it is determined that the first object is to be executed by the second thread, generate target call information according to the first call information in the auxiliary object, and execute the first object by the second thread, where the target call information includes: the identification of the first object, cross-thread calling indication, the identification of the first calling node, and the identification of a father calling node of the first object in the second thread.

10. The apparatus of claim 9, wherein the first processing module comprises:

the creating unit is used for creating the auxiliary object and binding the life cycle of the auxiliary object with the life cycle of the first object;

A first generation unit configured to generate the first call information;

and the adding unit is used for adding the first calling information into the auxiliary object.

11. The apparatus of claim 10, wherein the first generating unit comprises:

the obtaining subunit is configured to obtain a first call stack corresponding to the first thread, where the first call stack is used to store a call node corresponding to the first thread;

and the generating subunit is configured to generate the first call information according to a stack top call node in the first call stack.

12. The apparatus of any of claims 9 to 11, wherein the second processing module comprises:

a first obtaining unit, configured to obtain the first calling information in the auxiliary object;

a second obtaining unit, configured to obtain a second call stack corresponding to the second thread, where the second call stack is used to store a call node corresponding to the second thread;

and the second generation unit is used for generating the target calling information according to the first calling information and the second calling stack.

13. The apparatus of claim 12, wherein the second generating means comprises:

A first determining subunit, configured to determine, according to the second call stack, an identifier of a parent call node of the first object in the second thread;

a second determining subunit, configured to determine that the target call information includes the cross-thread call indication, the first call information, and an identifier of a parent call node of the first object in the second thread.

14. The apparatus of claim 13, wherein the first determining subunit is specifically configured to:

if the second call stack is empty, determining that the identifier of the parent call node of the first object in the second thread is empty; or,

and if the second call stack is not empty, determining the identifier of the top call node in the second call stack as the identifier of the father call node of the first object in the second thread.

15. The apparatus of claim 12, the second processing module further comprising:

the third generation unit is used for generating a second calling node according to the target calling information;

and the updating unit is used for updating the second calling node to the stack top of the second calling stack.

16. The apparatus of claim 9, the first processing module further to: if the type of the first object is the second type, packaging the first object and the first calling information to obtain a packaged object;

The transfer module is further configured to: passing the wrapper object to the second thread;

the second processing module is further configured to: executing, by the second thread, the wrapper object.

17. An electronic device, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

18. A non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform the method of any one of claims 1-8.

Images