Common performance Debugging means

In the development process often have such a performance problem, people are very tangled, below I will list some common performance debugging methods to identify the corresponding performance problems of the cause

One, the CPU is too high
This is the most common problem that happens, CPU 100%, but what is the cause of it?
Using tools such as Jprofiler to see CPU problems and to list CPU-specific stacks, but one problem is that Jprofiler itself consumes a very high CPU, which can be very unreliable when using Jprofiler to view CPU problems.
Here are some simple ways to view the high CPU.
Start by looking at which threads consume the most CPU
(1) Ps-elo Pid,lwp,pcpu | grep <pid>|sort-nk 3
This method can find the CPU consumes the top 3 threads
(2) Top-h
This method can list those threads that occupy the highest
The above method can be used to know the PID of the problematic thread, and then change the thread number from 10 to 16 binary.
Next look at the thread stack
Jstack-l <pid>
This method hits all thread stacks of the process, looks for the 16-binary thread number, NID=0X17A1 this is the thread number position
Like what
"Felixstartlevel-sendthread (db-3.photo.163.org:2181)" Daemon prio=10 tid=0x00007fba6406a800 nid=0x17a1 runnable [ BIDW:0X000000004027C000]
Java.lang.Thread.State:RUNNABLE
At sun.nio.ch.EPollArrayWrapper.epollWait (Native Method)
At Sun.nio.ch.EPollArrayWrapper.poll (epollarraywrapper.java:228)
At Sun.nio.ch.EPollSelectorImpl.doSelect (epollselectorimpl.java:83)
At Sun.nio.ch.SelectorImpl.lockAndDoSelect (selectorimpl.java:87)
-Locked <0x00007fba7d9c2d80> (a sun.nio.ch.util$1)
-Locked <0x00007fba7d9c31c0> (a java.util.collections$unmodifiableset)
-Locked <0x00007fba7d9c2dd8> (a Sun.nio.ch.EPollSelectorImpl)
At Sun.nio.ch.SelectorImpl.select (selectorimpl.java:98)
At Org.apache.zookeeper.clientcnxn$sendthread.run (clientcnxn.java:1107)
Locked ownable Synchronizers:
-None
This jstack is just a sampling method to see where the front-thread executes.
But we can assume that in the case of cpu100%, you are basically sampling on the wrong statement. So the first row of this stack
At sun.nio.ch.EPollArrayWrapper.epollWait (Native Method)
Is where the CPU goes wrong. You can use Jstack to sample several times to see if all are in the same place.
This method is simple, has been tried, and does not need to install software, easy to use.

Second, Memory Oom

Memory Oom is a common problem, the online encounter oom do not panic, do not first remember to focus on the first step of the memory stack to print out
Jmap-dump:live,format=b,file=<filename>

If an oom problem often occurs on the line, you can also add-xx:+heapdumponoutofmemoryerror-xx:heapdumppath=<filepath> to the JVM parameter to automatically dump the memory stack when the process is oom.

With the memory stack is good, to introduce you a tool mat, I think the best memory analysis tool http://www.eclipse.org/mat/
Leak suspects helps you to analyze where memory leaks are possible, as I've seen above in the case of shutdownhook problems, overflow
But where the overflow object comes from, you can click the list objects-> Incoming in details references

will be able to see the reference source of the referenced object, so that it is clear where there is a leak
Third, handle leakage

This is a problem that most Java developers don't care about, and developers who write C programs are more likely to pay attention to this issue. It's easy to show up because I don't pay attention to it.
Most of the monitoring platform has CPU, memory, hard disk monitoring, but a lot of no handle monitoring. The last program occurred too many open files, but did not know.

Lsof-p 6022 
Java    6022   FS    1w   REG           & nbsp    8,8     5006   3014678/home/xxx/log.log
Java    6022   FS    2w & nbsp REG                8,8     5006   3014678/home/xxx/log.log
Need careful Check if the handle is having too many file code problems.

I have had a handle leak before. Also code write problem (third-party software internal source code did not study thoroughly), constantly repeated open fileinputstream without reuse, resulting in a handle leakage. Hey... It's a lot of work.
Performance problems are easy to meet, share some personal experience, to help you locate performance problems. Everyone has a better way to tell me.

Common performance Debugging means