这几种常见的JVM调优场景你知道吗？

假定你已经了解了运行时的数据区域和常用的垃圾回收算法，也了解了Hotspot支持的垃圾回收器。一、cpu占用过高一、cpu占用过高cpu占用过高要分情况讨论，是不是业务上在搞活动，突然有大批的流量进来，而且活动结束后cpu占用率就下降了，如果是这种情况其实可以不用太关心，因为请求越多，需要处理的线程数越多，这是正常的现象。话说回来，如果你的服务器配置本身就差，cpu也只有一个核心，这种情况，稍微多一点流量就真的能够把你的cpu资源耗尽，这时应该考虑先把配置提升吧。第二种情况，cpu占用率长期过高，这种情况下可能是你的程序有那种循环次数超级多的代码，甚至是出现死循环了。排查步骤如下：（1）用top命令查看cpu占用情况（1）用top命令查看cpu占用情况这样就可以定位出cpu过高的进程。在linux下，top命令获得的进程号和jps工具获得的vmid是相同的：（2）用top-Hp命令查看线程的情况（2）用top-Hp命令查看线程的情况可以看到是线程id为7287这个线程一直在占用cpu（3）把线程号转换为16进制（3）把线程号转换为16进制rootlocalhost#printf%x 7287c771记下这个16进制的数字，下面我们要用（4）用jstack工具查看线程栈情况（4）用jstack工具查看线程栈情况rootlocalhost#jstack grep 1c77 A 7268|-10#daemon prio os_prio tid nidhttp-nio-8080-exec-216=5=0=0 x00007fb66ce81000=0 x1c77 runnable 0 x00007fb639ab9000 java lang.Thread.State:RUNNABLE at com spareyaya jvm servicejava.EndlessLoopService.service(EndlessLoopService.:19)at com spareyaya jvm controllerjava.JVMController.endlessLoop(JVMController.:30)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at sunjava.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.:62)at sunjava.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.:43)at java langjava.reflect.Method.invoke(Method.:498)at org springframework web method support.InvocableHandlerMethod.doInvoke(InvocablejavaHandlerMethod.:190)at org springframework web method support.InvocableHandlerMethod.invokeForRequest(IjavanvocableHandlerMethod.:138)at org springframework web servlet mvc method annotation.ServletInvocableHandlerMetjavahod.invokeAndHandle(ServletInvocableHandlerMethod.:105)通过jstack工具输出现在的线程栈，再通过grep命令结合上一步拿到的线程16进制的id定位到这个线程的运行情况，其中jstack后面的7268是第（1）步定位到的进程号，grep后面的是（2）、（3）步定位到的线程号。从输出结果可以看到这个线程处于运行状态，在执行com.spareyaya.jvm.service.这个方法，代码行号是19行，这样就可以去到代码的19行，找到其EndlessLoopService.service所在的代码块，看看是不是处于循环中，这样就定位到了问题。二、死锁二、死锁死锁并没有第一种场景那么明显，web应用肯定是多线程的程序，它服务于多个请求，程序发生死锁后，死锁的线程处于等待状态（或），等待状态的线程不占用cpu，消耗WAITINGTIMED_WAITING的内存也很有限，而表现上可能是请求没法进行，最后超时了。在死锁情况不多的时候，这种情况不容易被发现。可以使用jstack工具来查看（1）jps查看java进程（1）jps查看java进程rootlocalhost#jps-l8737 sun.tools.jps.Jps8682 jvm-0.0.1-SNAPSHOT.jar（2）jstack查看死锁问题（2）jstack查看死锁问题由于web应用往往会有很多工作线程，特别是在高并发的情况下线程数更多，于是这个命令的输出内容会十分多。jstack最大的好处就是会把产生死锁的信息（包含是什么线程产生的）输出到最后，所以我们只需要看最后的内容就行了Java stack information for the threads listed above:=Thread-4:at com.spareyaya.jvm.service.DeadLockService.service2(DeadLockService.java:35)-waiting to lock (a java.lang.Object)-locked (a java.lang.Object)at com.spareyaya.jvm.controller.JVMController.lambda$deadLock$1(JVMController.java:41)at com.spareyaya.jvm.controller.JVMController$Lambda$457/1776922136.run(Unknown Source)at java.lang.Thread.run(Thread.java:748)Thread-3:at com.spareyaya.jvm.service.DeadLockService.service1(DeadLockService.java:27)-waiting to lock (a java.lang.Object)-locked (a java.lang.Object)at com.spareyaya.jvm.controller.JVMController.lambda$deadLock$0(JVMController.java:37)at com.spareyaya.jvm.controller.JVMController$Lambda$456/474286897.run(Unknown Source)at java.lang.Thread.run(Thread.java:748)Found 1 deadlock.发现了一个死锁，原因也一目了然。三、内存泄漏三、内存泄漏我们都知道，java和c+的最大区别是前者会自动收回不再使用的内存，后者需要程序员手动释放。在c+中，如果我们忘记释放内存就会发生内存泄漏。但是，不要以为jvm帮我们回收了内存就不会出现内存泄漏。程序发生内存泄漏后，进程的可用内存会慢慢变少，最后的结果就是抛出OOM错误。发生OOM错误后可能会想到是内存不够大，于是把-Xmx参数调大，然后重启应用。这么做的结果就是，过了一段时间后，OOM依然会出现。最后无法再调大最大堆内存了，结果就是只能每隔一段时间重启一下应用。内存泄漏的另一个可能的表现是请求的响应时间变长了。这是因为频繁发生的GC会暂停其它所有线程（）造成的。Stop The World为了模拟这个场景，使用了以下的程序import java util concurrent ExecutorService.;import java util concurrent Executors.;public class Main String args public static void main()Main main =new Main();while(true)try Thread.sleep(1);InterruptedException e catch()e.printStackTrace();main.run();private void run()ExecutorService executorService Executors=.newCachedThreadPool();i i i for(int=0;/do something.);运行参数是，把可用内存调小一点，并且在发生gc时输出信息，-Xms20m-Xmx20m-XX:+PrintGC运行结果如下GC Allocation Failure 12776K-18432K 0.0309510 secs()10840K(),GC Allocation Failure 13400K-18432K 0.0333385 secs()11520K(),GC Allocation Failure 14080K-18432K 0.0332409 secs()12168K(),GC Allocation Failure 14728K-18432K 0.0370435 secs()12832K(),Full GC Ergonomics 12832K-18432K 0.1942141 secs()12363K(),Full GC Ergonomics 14923K-18432K 0.1607221 secs()12951K(),Full GC Ergonomics 15511K-18432K 0.1956311 secs()13542K(),.Full GC Ergonomics 16382K-18432K 0.1734902 secs()16381K(),Full GC Ergonomics 16383K-18432K 0.1922607 secs()16383K(),Full GC Ergonomics 16383K-18432K 0.1824278 secs()16383K(),Full GC Allocation Failure 16383K-18432K 0.1710382 secs()16383K(),Full GC Ergonomics 16383K-18432K 0.1829138 secs()16382K(),Full GC Ergonomics Exception in thread 16383K-18432K 0.1406222()main16382K(),secsFull GC Allocation Failure 16382K-18432K 0.1392928 secs()16382K(),Full GC Ergonomics 16383K-18432K 0.1546243 secs()16382K(),Full GC Ergonomics 16383K-18432K 0.1755271 secs()16382K(),Full GC Ergonomics 16383K-18432K 0.1699080 secs()16382K(),Full GC Allocation Failure 16382K-18432K 0.1697982 secs()16382K(),Full GC Ergonomics 16383K-18432K 0.1851136 secs()16382K(),Full GC Allocation Failure 16382K-18432K 0.1655088 secs()16382K