Scene
After the system on-line, often encounter operations of the classmate ran to say: "This edition, CPU thread utilization to a field, to 100%." Don't panic at this time, you can use a heap dump to analyze exactly which thread is causing it.
Find the culprit
[[email protected]_mofei_01 test]# topmem:16333644k Total, 9472968k used, 6860676k free, 165616k buffersswap: 0k Total, 0k used, 0k free, 6665292k cached PID USER PR NI VIRT RES SHR S%cpu%MEM time + COMMAND 17850 Root 0 7588m 112m 11m S 100.7 0.7 47:53.80 Java 1552 Root 0 121m 13m 8 524 S 0.7 0.1 14:37.75 Aliyundun 3581 Root 20 0 9750m 2.0g 13m S 0.7 12.9 298:30.20 Java 1 root 20 0 19360 1612 1 308 S 0.0 0.0 0:00.81 Init 2 Root 20 0 0 0 0 S 0.0 0.0 0:00.00 Kthreadd 3 root RT 0 0 0 0 S 0.0 0.0 0:00.14 migration/0
Discovery of pid=17850 process thread utilization 100%, which thread in the query process caused the problem
[[email protected]_mofei_01 test]# top-h-P 17850top-17:43:15 up 5 days, 7:31, 1 user, load average:0.99, 0.97 , 0.91tasks:32 Total, 1 running, sleeping, 0 stopped, 0 zombiecpu (s): 3.7%us, 8.9%sy, 0.0%ni, 87.4%id, 0.0 %wa, 0.0%hi, 0.0%si, 0.0%stmem:16333644k total, 9592504k used, 6741140k free, 165700k buffersswap:0k Tota L, 0k used, 0k free, 6781620k cached PID USER PR NI VIRT RES SHR S%cpu%MEM time+ COMMAND 17880 Root 0 7588m 112m 11m R 99.9 0.7 50:47.43 Java 17856 Root 0 7588m 112m 11m S 0.3 0 .7 0:02.08 Java 17850 Root 0 7588m 112m 11m S 0.0 0.7 0:00.00 Java 17851 Root 0 7588m 112m 11m S 0.0 0 .7 0:00.23 Java 17852 Root 0 7588m 112m 1 1m S 0.0 0.7 0:02.09 java 17853 Root 20 0 7 588m 112m 11m S 0.0 0.7 0:02.12 Java 17854 Root 0 7588m 112m 1 1m S 0.0 0.7 0:02.07 java 17855 Root 20 0 7 588m 112m 11m S 0.0 0.7 0:02.06 java 17857 Root 0 7588m 112m 11m S 0.0 0.7 0:02.07 java 17858 Root 20 0 7588m 112m 11m S 0.0 0.7 0:02.08 java 17859 Root 0 7588m 112m 11m S 0.0 0.7 0:02.04 java 17860 Root 0 7588m 112m 11m S 0.0 0.7 0:02.05 java 17861 Root 0 7588m 112m 11m S 0.0 0.7 0:00.00 java17862 Root 0 7588m 112m 11m S 0.0 0.7 0:00.00 java 17863 Root 0 7588m 112m 11m S 0.0 0.7 0:00.00 java 17864 Root 0 7588m 112m 11m S 0.0 0.7 0:00.10 java 17865 Root 0 7588m 112m 11m S 0.0 0.7 0:00.12 java 17866 Root 0 7588m 112m 11m S 0.0 0.7 0:00.09 java 17867 Root 0 7588m 112m 11m S 0.0 0.7 0:00.12 java 17868 Root 0 7588m 112m 11m S 0.0 0.7 0:00.00 java 17869 Root 0 7588m 112m 11m S 0.0 0.7 0:01.04 J Ava 17870 Root 0 7588m 112m 11m S 0.0 0.7 0:00.00 java 17871 Root 0 7588m 112m 11m S 0.0 0.7 0:00.00 J Ava 17872 Root 0 7588m 112m 11m S 0.0 0.7 0:00.00 Java 17873 Root 0 7588m 112m 11m S 0.0 0.7 0:00.00 java 17874 Root 0 7588m 112m 11m S 0.0 0.7 0:00.00 Java 17875 Root 0 7588m 112m 11m S 0.0 0.7 0:00.00 java 17876 Root 20 0 758 8m 112m 11m S 0.0 0.7 0:00.00 java 17877 Root 0 7588m 112m 11m S 0.0 0.7 0:00.00 java 17878 Root 20 0 758 8m 112m 11m S 0.0 0.7 0:00.00 java 17879 Root 0 7588m 112m 11m S 0.0 0.7 0:00.00 java 17 946 Root 0 7588m 112m 11m S 0.0 0.7 0:00.00 java
17880 of threads were found to cause the CPU to soar high.
Viewing thread information through Jstack
[[email protected]_mofei_01 test]# printf "%x\n" 17880 45d8[[email protected]_mofei_01 test]# jstack 17 850|grep 45d8-a "pool-1-thread-11" #20 prio=5 os_prio=0 tid=0x00007fc860352800 nid=0x45d8 runnable [ 0X00007FC8417D2000] Java.lang.Thread.State:RUNNABLE at Java.io.FileOutputStream.writeBytes (Native Method) At Java.io.FileOutputStream.write (fileoutputstream.java:326) at Java.io.BufferedOutputStream.flushBuffer (Buffered outputstream.java:82) at Java.io.BufferedOutputStream.flush (bufferedoutputstream.java:140)-Locked <0x00 000006c6c2e708> (a Java.io.BufferedOutputStream) at Java.io.PrintStream.write (printstream.java:482)-Loc Ked <0x00000006c6c10178> (a java.io.PrintStream) at Sun.nio.cs.StreamEncoder.writeBytes (streamencoder.java:22 1) at Sun.nio.cs.StreamEncoder.implFlushBuffer (streamencoder.java:291) at Sun.nio.cs.StreamEncoder.flushBuff ER (streamencoder.java:104)-Locked ≪0x00000006c6c26620> (a java.io.OutputStreamWriter) at Java.io.OutputStreamWriter.flushBuffer (Outputstreamwri ter.java:185) at Java.io.PrintStream.write (printstream.java:527)-Eliminated <0x00000006c6c10178> (a Java.io.PrintStream) at Java.io.PrintStream.print (printstream.java:597) at Java.io.PrintStream.println (print stream.java:736)-Locked <0x00000006c6c10178> (a java.io.PrintStream) at Com.demo.guava.HardTask.call (hardtask.java:18) at Com.demo.guava.HardTask.call (Hardtask.java:9) at Java.util.concurrent.FutureTask.run (F uturetask.java:266) at Java.util.concurrent.ThreadPoolExecutor.runWorker (threadpoolexecutor.java:1142) at Ja Va.util.concurrent.threadpoolexecutor$worker.run (threadpoolexecutor.java:617) at Java.lang.Thread.run ( thread.java:745) "pool-1-thread-10" #19 prio=5 os_prio=0 tid=0x00007fc860345000 nid=0x45d7 waiting on condition [ 0X00007FC8418D3000] Java.lang.Thread.State:WAIting (parking) at Sun.misc.Unsafe.park (Native Method)-Parking to wait for <0x00000006c6c14178> (a Java.util.concurrent.locks.abstractqueuedsynchronizer$conditionobject) at Java.util.concurrent.locks.LockSupport.park (locksupport.java:175)
- First turn the PID 17880 into a 16 binary
- Querying heap information
- Found Hardtask (source at the end) line 18th may be problematic source code
public class HardTask implements Callable<String> { @Override public String call() throws Exception { while(true){ int a=100; int b=100; int rs=a+b/100-b; System.out.println(rs); } }}public class SimpleTask implements Callable<String> { @Override public String call() throws Exception { Thread.sleep(300); //什么都不做 return null; }}public class CpuTest { public static void main(String[] args){ ExecutorService executorService=Executors.newFixedThreadPool(11); for (int i = 0; i < 10; i++) { executorService.submit(new SimpleTask()); } executorService.submit(new HardTask()); }}
The source code is very simple, is created 2 kinds of thread hardtask and Simpletask. It is then started by Cputest.
Jstack application-Find out why the CPU is racing high