Shulou(Shulou.com)06/03 Report--

How to achieve a complete interpretation of the jvm JAttach mechanism, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

What is Attach?

Before we talk about this, let's start with something that we all know. When we feel that the thread has been stuck somewhere and want to know where the card is, the first thing that comes to mind is to dump the thread, and the commonly used command is jstack. We can see the following thread stack.

Have you noticed the two threads circled above, "Attach Listener" and "Signal Dispatcher"? these two threads are the key to the Attach mechanism we are going to talk about this time. First of all, secretly tell you that in fact, the thread Attach Listener may not be available when jvm is up, which will be explained in more detail later.

What is the Attach mechanism? To put it simply, jvm provides the ability of jvm inter-process communication, which allows one process to pass commands to another process and make it perform some internal operations. For example, in order to get another jvm process to dump the thread, we run a jstack process, and then pass a pid parameter to tell it which process to thread dump. Since it is two processes, it must involve inter-process communication. And the definition of the transport protocol, such as what operations to be performed and what parameters are passed, etc.

What can Attach do?

To sum up, such as memory dump, thread dump, class information statistics (such as loaded classes and size and the number of instances, etc.), dynamically loading agent (those who have used btrace should be no stranger), dynamically setting vm flag (but not all flag can be set, because some flag is used in the jvm startup process, is one-time), print vm flag, get system properties, etc., the corresponding source code (AttachListener.cpp) is as follows

Static AttachOperationFunctionInfo funcs [] = {{"agentProperties", get_agent_properties}, {"datadump", data_dump}, {"dumpheap", dump_heap}, {"load", JvmtiExport::load_agent_library}, {"properties", get_system_properties}, {"threaddump", thread_dump}, {"inspectheap", heap_inspection} {"setflag", set_flag}, {printflag ", print_flag}, {" jcmd ", jcmd}, {NULL, NULL}}

This is followed by the corresponding handler for the command.

How to implement Attach in jvm

Creation of Attach Listener thread

As mentioned earlier, jvm may not start the thread Attach Listener during startup. You can start it with the parameter jvm. The code (Threads::create_vm) is as follows:

If (! DisableAttachMechanism) {if (StartAttachListener | | AttachListener::init_at_startup ()) {AttachListener::init ();}} ool AttachListener::init_at_startup () {if (ReduceSignalUsage) {return true;} else {return false;}

DisableAttachMechanism,StartAttachListener and ReduceSignalUsage are false (globals.hpp) by default.

Product (bool, DisableAttachMechanism, false, "Disable mechanism that allows tools to Attach to this VM") product (bool, StartAttachListener, false, "Always start AttachListener at VM startup") product (bool, ReduceSignalUsage, false, "Reduce the use of OS signals in Java and/or the VM")

So AttachListener::init () is not executed, and the AttachListener thread is created in this method

Since this thread will not be created at startup, how is the thread we saw above created? this should focus on another thread, "Signal Dispatcher", which, as its name implies, handles signals. This thread is created when jvm starts, not to mention the specific code.

The following is the implementation of jstack to illustrate the process of triggering Attach. The implementation of the jstack command is actually a class called JStack.java. After looking at the jstack code, you will go to the following method

Please note VirtualMachine.Attach (pid); this line of code, the key to triggering Attach pid, if it is under linux, it will go to the following constructor

To explain the code here, we first see that the createAttachFile method is called to create a file / proc//cwd/.Attach_pid under the cwd directory of the target process, which will be taken out to make a judgment in the later signal processing (for the sake of safety). In addition, we know that threads are implemented by processes under linux, and many threads are created during jvm startup, such as the signal thread above That is, you will see a lot of pid (it should be LWP), so how to find this signal processing thread? from the above implementation, it is to find the parent process of the pid that we passed in, and then send a SIGQUIT signal to all its child processes. In jvm, except for the signal thread, all the other threads set up a mask to this signal, so they can't receive the signal, so the signal is sent to "Signal Dispatcher". After passing, do a poll and wait to see whether the target process has created a file. The default timeout of AttachTimeout is 5000ms, which can be specified by setting the system variable sun.tools.Attach.AttachTimeout. The following is the entry implementation of the Signal Dispatcher thread

When the signal is SIGBREAK (# define is actually SIGQUIT in jvm), it will trigger.

Execution of AttachListener::is_init_trigger ()

At first, it will determine whether there is a .attach _ pid file in the current process directory (mentioned earlier). If not, a / tmp/.Attach_pid will be created under / tmp, and the init method will be called when the uid of that file is consistent with its own uid (for security).

At this point, you can see that a thread has been created and named Attach Listener. Then take a look at the init method of its subclass LinuxAttachListener

See that it creates a listening socket and creates a file / tmp/.java_pid, which is the file that the client has been polling and waiting for. With the generation of this file, the Attach process is successfully completed.

Attach listener receives request

Take a look at its entry implementation Attach_listener_thread_entry

From the point of view of the code, we constantly fetch the AttachOperation from the queue, and then find the corresponding method to execute the request command, such as the jstack command we said at the beginning, find the mapping of {"threaddump", thread_dump}, and then execute the thread_dump method.

Let's take a look at the AttachListener::dequeue () to be called.

AttachOperation* AttachListener::dequeue () {JavaThread* thread = JavaThread::current (); ThreadBlockInVM tbivm (thread); thread- > set_suspend_equivalent (); / / cleared by handle_special_suspend_equivalent_condition () or / / java_suspend_self () via check_and_wait_while_suspended () AttachOperation* op = LinuxAttachListener::dequeue (); / / were we externally suspended while we were waiting? Thread- > check_and_wait_while_suspended (); return op;}

The final call is LinuxAttachListener::dequeue ()

We see that if there is no request, the accept will always be there, and when the request comes, it will create a socket, read the data, build the LinuxAttachOperation return and execute it.

This is the whole process, from the Attach thread creation to receiving the request, processing the request.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.