Find out the problem of excessive cpu usage in java code
When a java Process occupies too much CPU, it may be a logical problem. How to troubleshoot the problem?
1. Use the top tool to list all processes, and use shitf + p to list processes with high CPU usage
2. Locate the problematic process number and use top-H-p pid to list all threads of the process
3. shift + p then sort by CPU usage
4. Locate the problem process number and print its hexadecimal value in python, print ("0x" % ppid), for example: 76a3
5. jstack pid> t. dat records the thread stack. vi opens the thread number 76a3 and locates the problem based on the source code.
Here is an example of an endless loop:
2015-07-26 19:52:04Full thread dump OpenJDK 64-Bit Server VM (20.0-b11 mixed mode):"Attach Listener" daemon prio=10 tid=0x00007fa04c001000 nid=0x7ac9 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE"DestroyJavaVM" prio=10 tid=0x00007fa070007000 nid=0x7697 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE"ttwo" prio=10 tid=0x00007fa0700b2000 nid=0x76a3 runnable [0x00007fa074260000] java.lang.Thread.State: RUNNABLEat Main$T2.run(Main.java:31)at java.lang.Thread.run(Thread.java:679)"tone" prio=10 tid=0x00007fa0700b0000 nid=0x76a2 waiting on condition [0x00007fa074361000] java.lang.Thread.State: TIMED_WAITING (sleeping)at java.lang.Thread.sleep(Native Method)at Main$T1.run(Main.java:19)at java.lang.Thread.run(Thread.java:679)"Low Memory Detector" daemon prio=10 tid=0x00007fa070098800 nid=0x76a0 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE"C2 CompilerThread1" daemon prio=10 tid=0x00007fa070096000 nid=0x769f waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE"C2 CompilerThread0" daemon prio=10 tid=0x00007fa070093800 nid=0x769e waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE"Signal Dispatcher" daemon prio=10 tid=0x00007fa070085000 nid=0x769d runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE"Finalizer" daemon prio=10 tid=0x00007fa070073000 nid=0x769c in Object.wait() [0x00007fa074973000] java.lang.Thread.State: WAITING (on object monitor)at java.lang.Object.wait(Native Method)- waiting on <0x00000000ec0b1310> (a java.lang.ref.ReferenceQueue$Lock)at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:133)- locked <0x00000000ec0b1310> (a java.lang.ref.ReferenceQueue$Lock)at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:149)at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:177)"Reference Handler" daemon prio=10 tid=0x00007fa070071000 nid=0x769b in Object.wait() [0x00007fa074a74000] java.lang.Thread.State: WAITING (on object monitor)at java.lang.Object.wait(Native Method)- waiting on <0x00000000ec0b11e8> (a java.lang.ref.Reference$Lock)at java.lang.Object.wait(Object.java:502)at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)- locked <0x00000000ec0b11e8> (a java.lang.ref.Reference$Lock)"VM Thread" prio=10 tid=0x00007fa07006a800 nid=0x769a runnable "GC task thread#0 (ParallelGC)" prio=10 tid=0x00007fa070011800 nid=0x7698 runnable "GC task thread#1 (ParallelGC)" prio=10 tid=0x00007fa070013800 nid=0x7699 runnable "VM Periodic Task Thread" prio=10 tid=0x00007fa07009b000 nid=0x76a1 waiting on condition JNI global references: 865
The above code starts two threads. Thread T1 occupies a small amount of CPU, and thread T2 occupies a full CPU.
First, we use top to list processes and sort them by cpu usage (shift + p)
The problematic process number is 30358.
Use top-H-p 30358 to get the following result, and then use shitf + p to sort by cpu usage
Here we can see that the thread is 30371 occupying too much CPU. This thread is faulty.
Next, use jstack 30358> t. dat to record the thread stack.
Print the hexadecimal value of 30371 using python (print ("0x" % 30371 is 76a3
Find the 76a3 process in the thread stack and view the stack information carefully.
Here we can see that the ttwo thread name runs to 31 lines of Main. At this time, we will carefully check the nearby logic in the source code, and the problem is clear at a glance.