Thread __linux in Linux Java lookup process

Here is a summary of the search steps for the thread resource footprint of the Linux, Sun (Oracle) JDK; In a Linux environment, when the Java process is found to be high in CPU resources and want to further identify which Java thread is consuming CPU resources, Follow these steps to find: (a): see what threads of Java processes are running through "top-p12377-h"; and generate dump details for Java threads via "Jstack 12377 > Stack.log";First, use the top command to find the resource-intensive Java process ID, as shown in the image above, the Java process ID is ' 52554′, followed by a separate monitoring of all threads in the process with the upper command:

1	top-p52554-h # Top view inside you can use the shortcut keys in order B, x highlight the top column to find the required threads, the default CPU sort,shift+<,shift+> can move the highlighted column around;

Figure: (This shows which Java thread CPU high, which thread memory for more)
As shown in the figure above, all Java internal threads in Linux, in fact, correspond to a process ID, which means that the Sun JVM on Linux maps the threads in the Java program for the operating system process; We see that the process ID that consumes the highest CPU resources is ' 15417′, This process ID corresponds to the ' Nid ' (' n ' stands for ' native ') in Java thread information; (1) to find out exactly which section of the code occupies so much resources, first use Jstack to play the current stack information into a file, such as stack.log:python-c "Print hex (9757)" and then remember the binary number of cat stack.log| grep binary number

1	jstack 52554 > Stack.log

Then use the ' jtgrep ' script to grab the Java thread of the process number ' 9757′ in the Stack.log:

1	Jtgrep 9757 Stack.log

Among them, ' Jtgrep ' is a shell script that he writes casually:

1

#!/bin/sh

3	Nid= ' python-c ' Print hex ($)

4	Grep-i $nid $

The reason is very simple, is to convert ' 9757′ into 16, directly grep stack.log; you can see that the nid=0x3c39 of the thread that is being grep is exactly the 16-binary representation of the 15417.