一句话总结：从问题现象为入口，归结为3类问题进行定位分析：内存满、CPU高、线程阻塞。

首先先介绍下jVisualvm这款jdk自带的性能工具。通常我们要定位哪块代码性能差，耗时久，最原始的办法就是在各个方法前后日志打印时间戳并计算耗时，这种方法很繁琐，通常要加很多日志多次部署才能定位到，我一开始也是这么搞的。而使用jvisuaLVM工具则可以直接查看整个业务代码调用链中各个方法的耗时及占比，直接就能定界出是哪个方法性能差，耗时久。

操作步骤：点击抽样器页签，点击CPU抽样，前台操作触发代码执行，操作完点击停止，再点击快照。在快照页点击搜索按钮，输入代码入口方法名搜索，结果见下图。

我们来分析下下图，RegionNorthbound.createRegion是北向入口方法，总耗时见右侧5.298秒，其调用了RegionServiceimpl.createRegion方法，耗时4.093秒，那么相减就是RegionNorthbound.createRegion方法本身的耗时。

RegionServiceImpl.createRegion方法调用了CommonDAO.saveEntITy和RegionServiceImpl.checkRePEat方法，分别耗时0.998秒和0.094秒。可以直观查看是调用的哪个方法耗时久，性能差。整个方法调用链的耗时均可查看。

当然jvisualvm除了查看代码调用链耗时，实时监控CPU、内存、线程数，线程dump、内存dump等功能都非常好用。

下面开始按问题分类进行定位分析。

一：内存问题

问题现象：后台报错，前台提示异常或500错误。

定位：后台报错的定位思路很明确了，查看日志，这里分两类异常：一、java.lang.OutOfMemoryError: PermGen space异常，此为方法区内存溢出，方法区用来存放class代码，通常解决办法就是调大jvm permSize参数值；二、java.lang.OutOfMemoryError: heap space异常，比较常见的堆内存溢出。当然也可以调大jvm参数来解决，但若是不恰当代码引起的，首先检查下自己写的代码，看哪里创建了大量对象。若检查不出来，则使用jmap或jvisualvm导出内存快照。

分析下图heap dump，这里又分两种情况，若左侧占内存大的类名为com.**.User这种自己定义的业务对象，那在代码中搜索下此类名就能定位到哪里创建了大量此对象。若为String、Integer这种基本类型的对象，则可以使用Eclipse Memory Analyer此类工具进一步分析，可以查看内存大对象的线程堆栈，即可查看代码调用方法。

二：CPU问题

问题现象：前台显示卡顿，响应时间长，linux top查看cpu使用率非常高

定位步骤：

1、使用top查看进程pid，java系统通常进程名就叫java

2、使用top -H -p pid查看进程中各线程的CPU使用情况，找出最占CPU的线程pid，注意这里其实就是tid

3、通过步骤2我们知道是哪个线程占CPU了，使用jstack pid打印线程堆栈，查看该线程的代码调用方法

4、将步骤2线程tid转换为16进制，因为jstack打印出来的threaddump中tid为16进制，然后在threaddump中搜索，即可找到线程堆栈，这里30725转换为16进制就是7805

这里有个情况要特别说明，如果步骤4查看的占用CPU的线程为java gc线程，通常是由于内存快满才导致jvm频繁gc，进而导致CPU高。固此种情况得按上面提到的内存问题去定位解决。Java架构交流学习圈：874811168 面向1-3年经验 Java开发人员 帮助突破瓶颈 提升思维能力

三：线程问题

问题现象1：请求响应时间长，性能测试TPS/QPS上不去，查看CPU占用又不高

问题现象2：请求响应直接超时，后台线程相互死锁

定位：线程问题通常打印一次threaddump是看不出问题的，要多打印几次对比才能看出问题。建议使用jvisualvm线程页签实时查看线程状态。查看指定业务线程状态，若长时间处于wait或block状态，则可确认该问题是由于线程阻塞引起的。查看线程堆栈可查看是调用哪个方法时阻塞的。死锁问题也是类似定位，线程堆栈里会提示在等待哪个线程释放lock，而有两个线程互相等待即会死锁。

备忘：

jvisualvm连接远程jvm，远程jvm添加启动参数：