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

Today, I will talk to you about how to analyze the signal processing of Java open source tools on linux, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

When the java virtual machine starts, it starts many internal threads, which are mainly implemented in the body of the create_vm method in thread.cpp.

In thread.cpp, there are two main threads to deal with signal-related:

JvmtiExport::enter_live_phase (); / / Signal Dispatcher needs to be started before VMInit event is posted os::signal_init (); / / StartAttachListener if + StartAttachListener or it can't be started lazily if (! DisableAttachMechanism) {if (StartAttachListener | | AttachListener::init_at_startup ()) {AttachListener::init ();}}

1. Signal Dispatcher thread

In the signal_init () function in os.cpp, the signal dispatcher thread is started. For the signal dispather thread, it is mainly used to process the signal, wait for the signal and distribute the processing. You can see the signal_thread_entry method in detail:

Static void signal_thread_entry (JavaThread* thread, TRAPS) {os::set_priority (thread, NearMaxPriority); while (true) {int sig; {/ / FIXME: Currently we have not decieded what should be the status / / for this java thread blocked here. Once we decide about / / that we should fix this. Sig = os::signal_wait ();} if (sig = = os::sigexitnum_pd ()) {/ / Terminate the signal thread return;} switch (sig) {case SIGBREAK: {/ / Check if the signal is a trigger to start the Attach Listener-in that / / case don't print stack traces. If (! DisableAttachMechanism & & AttachListener::is_init_trigger ()) {continue;} / / Print stack traces / / Any SIGBREAK operations added here should make sure to flush / / the output stream (e.g. Tty- > flush () after output. See 4803766. / / Each module also prints an extra carriage return after its output. VM_PrintThreads op; VMThread::execute (& op); VM_PrintJNI jni_op; VMThread::execute (& jni_op); VM_FindDeadlocks op1 (tty); VMThread::execute (& op1); Universe::print_heap_at_SIGBREAK If (PrintClassHistogram) {VM_GC_HeapInspection op1 (gclog_or_tty, true / * force full GC before heap inspection * /, true / * need_prologue * /); VMThread::execute (& op1);} if (JvmtiExport::should_post_data_dump ()) {JvmtiExport::post_data_dump () } break;} default: {/ / Dispatch the signal to java HandleMark hm (THREAD); klassOop k = SystemDictionary::resolve_or_null (vmSymbolHandles::sun_misc_Signal (), THREAD); KlassHandle klass (THREAD, k); if (klass.not_null ()) {JavaValue result (T_VOID); JavaCallArguments args Args.push_int (sig); JavaCalls::call_static (& result, klass, vmSymbolHandles::dispatch_name (), vmSymbolHandles::int_void_signature (), & args, THREAD) } if (HAS_PENDING_EXCEPTION) {/ / tty is initialized early so we don't expect it to be null, but / / if it is we can't risk doing an initialization that might / / trigger additional out-of-memory conditions if (tty! = NULL) {char klass_name [256]; char tmp_sig_name [16] Const char* sig_name = "UNKNOWN"; instanceKlass::cast (PENDING_EXCEPTION- > klass ())-> name ()-> as_klass_external_name (klass_name, 256); if (os::exception_name (sig, tmp_sig_name, 16)! = NULL) sig_name = tmp_sig_name Warning ("Exception% s occurred dispatching signal% s to handler"- the VM may need to be forcibly terminated", klass_name, sig_name);} CLEAR_PENDING_EXCEPTION;}}

You can see that through os::signal_wait (); wait for the signal, but in linux it is achieved through sem_wait (). When you receive the SIGBREAK (QUIT in linux) signal (for signal processing, please refer to the author's other blog: the implementation of signal processing under linux in java), * * initialize the attach listener thread by calling AttachListener::is_init_trigger () for details, see 2.Attach Listener thread for details.

The first time a signal is received, initialization will begin, and if initialization succeeds, it will be returned directly, and no thread stack information will be returned (returned through the operation of socket file), and the second time it will no longer need initialization. If the initialization is not successful, the thread stack information is printed directly in the outputstream of the console.

The second time you receive a signal, if it has been initialized, the stack information of the thread will be printed directly in the console. If there is no initialization, continue to initialize and follow the same process as *.

2. Attach Listener thread

The Attach Listener thread is responsible for receiving the external command, executing the command and returning the result to the sender. When jvm starts, if + StartAttachListener is not specified, the thread will not start. We just discussed that after receiving the quit signal, we will call AttachListener::is_init_trigger () to start the AttachListener thread with AttachListener::init (), and initialize it under different operating systems, which is implemented in the attachListener_Linux.cpp file in linux.

If the file. Attach_pid#pid is found in linux, the attach listener thread will be started, and the socket file will be initialized, which is what jmap,jstack tool usually does. First create the attach_pid#pid file, and then send the quit signal to start the Attach Listener thread secretly in this way (see blog: http://blog.csdn.net/raintungli/article/details/7023092).

The implementation of threads is implemented in the body of the attach_listener_thread_entry method:

Static void attach_listener_thread_entry (JavaThread* thread, TRAPS) {os::set_priority (thread, NearMaxPriority); if (AttachListener::pd_init ()! = 0) {return;} AttachListener::set_initialized (); for (;;) {AttachOperation* op = AttachListener::dequeue (); if (op = = NULL) {return; / / dequeue failed or shutdown} ResourceMark rm BufferedStream st; jint res = JNI_OK; / / handle special detachall operation if (strcmp (op- > name (), AttachOperation::detachall_operation_name ()) = 0) {AttachListener::detachall ();} else {/ / find the function to dispatch too AttachOperationFunctionInfo* info = NULL; for (int item0; int [I] .name! = NULL; iTunes +) {const char* name = funcs.name Assert (strlen (name) name (), name) = 0) {info = & (funcs [I]); break;}} / / check for platform dependent attach operation if (info = = NULL) {info = AttachListener::pd_find_operation (op- > name ()) } if (info! = NULL) {/ / dispatch to the function that implements this operation res = (info- > func) (op, & st);} else {st.print ("Operation% s not recognized!", op- > name ()); res = JNI_ERR;}} / / operation complete-send result and output to client op- > complete (res, & st) }}

The implementation in AttachListener::dequeue (); liunx is to listen to the socket file just created. If there is a request, find the corresponding operation of the request, call the operation to get the result and write the result to the socket file. If you delete the socket file, jstack/jmap will have an error message unable to open socket file:..

We often use the operation of kill-3 pid to print out thread stack information, and we can see that the specific implementation is completed in the Signal Dispatcher thread, because the kill-3 pid does not create a .thread _ pid#pid file, so the initialization is not successful all the time, so the thread stack information is printed to the console.

After reading the above, do you have any further understanding of how to analyze the signal processing of Java open source tools on linux? If you want to know more knowledge or related content, 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.