189 8069 5689
这期内容当中小编将会给大家带来有关怎样进行JVM性能监控和调优，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
创新互联公司主营城区网站建设的网络公司,主营网站建设方案,app软件定制开发,城区h5成都微信小程序搭建,城区网站营销推广欢迎城区等地区企业咨询
JVM调优是Java中比较重要的知识点，尤其是分析JVM和监控JVM运行状态。
1、定位系统问题
依据
GC日志
堆转储快照（heapdump/hprof文件）
线程快照（threaddump/javacore文件）
运行日志
异常堆栈
分析依据的工具
jps：显示指定系统内的所有JVM进程
jstat：收集JVM各方面的运行数据
jinfo：显示JVM配置信息
jmap：形成堆转储快照（heapdump文件）
jhat：分析heapdump文件
jstack：显示JVM的线程快照
jconsole
visualVM
说明：后边两种是具有图形化界面的。
2、jps（是其他所有命令的基础）
作用：列出所有的JVM虚拟机进程。
格式：jps -l
3、jstat（是没有GUI界面的情况下，在运行期定位JVM性能问题的首选）
作用：查看gc数据和类加载卸载数据
格式：jstat option PID interval count
意义：每隔interval毫秒做一次option，一共做count次
说明：加载了3683个类，总共占有4355.3字节；卸载了0个类，卸载的类的字节数为0，类的加载与卸载共花销3.16秒
更多的jstat的使用，参看http://my.oschina.net/skyline520/blog/304805
4、jinfo
作用：查看和运行期修改JVM的配置参数
格式：jinfo -flag parameter PID
说明：修改3732进程下的MaxTenuringThreshold参数值，但是windows下失败。
5、jmap
作用：生成堆转储快照和查看最占内存的元素，用于分析内存泄露问题
格式（生成堆转储快照）：jmap -dump:format=b,file=文件名 PID
说明：结果自己去看，太多了
6、jhat
作用：分析堆转储快照（与jmap配合）
格式：jhat 文件名
注意：该工具是万不得已才用的。
推出命令使用"ctrl+c"
7、jstack
作用：生成线程快照，定位线程长时间卡顿的原因（线程间死锁、死循环、请求外部资源导致的长时间等待）
格式：jstack -l PID
说明：查看3732进程中的所有线程的堆栈信息
《深入理解Java虚拟机》的作者提供了一个工具jsp页面，使得我们可以在程序运行时，随时运行该jsp页面，来查看线程堆栈信息，代码如下：
1 <%@ page language="java">注意：代码中我注释掉一段，是因为想也查出当前线程的堆栈信息，作者并没有这个注释。 总结：JVM性能相关的6个常用的JDK命令jps：查询JVM中的所有进程，找出将要操作的PID，是所有命令的基础jstat：查看相应JVM进程的gc、类加载卸载信息，是没有GUI界面查看JVM运行数据的首选jinfo：查看和在运行期动态修改JVM配置参数jmap：生成堆转储快照和比较占内存的对象jhat：配合jmap分析堆转储日志，除非没有其他工具可做这个事儿，否则就不用该工具jstack：生成线程快照，定位线程长时间卡顿的原因（线程间死锁、死循环、请求外部资源导致的长时间等待）输出gc信息到控制台-XX:+PrintGCDetails：输出GC的详细信息-XX:+PrintGCTimeStamps：输出GC的时间信息-XX:+PrintGCApplicatonStoppedTime：GC造成的应用暂停的时间输出gc信息到文件以上三个参数在这里依旧适用-Xloggc:文件路径/gc.log：输出到文件 图形化的JVM性能监控 1、图像化的故障处理工具JconsolevisualVM2、Jconsole进入"E:\Java\jdk1.6\bin"，双击"jconsole.exe"，弹出如下框：说明：这里列出了所有的JVM进程，一个Jconsole进程，一个eclipse（PID：4684），这相当于jps命令。选中其中一个PID，假设选中了eclipse，双击，出现下图：（注：之后的各个叶签，都是每4秒刷新一次）"内存"：相当于jstat -gc，在上图中的详细信息部分，该部分对应的信息就是头部图表部分所写的参数（这里是"整个堆"的情况），同时对应的也是右下角部分柱状图所选中的柱子（这里是"堆"），对于"非堆"指的就是"方法区"（或者称为"永久代"）。当然，这里也可以选择时间范围来查看相应的信息。"类"：相当于jstat -class，列出了装载类和卸载类的相关信息。"线程"：相当于jstack，折线图显示了线程数目的变化情况，包括峰值线程数量、活动线程数量；左下角展示了所有线程名称。双击相应的线程名称"VM摘要"：相当于jinfo最后，测试一下线程死锁的现象。代码如下： View Code执行main()方法，之后去查看"线程"标签，点击"检测死锁"，如下：发现线程Thread-95和Thread-106死锁（彼此拥有对方想要的锁）分析：1）Integer缓存机制Integer.valueOf(int xxx)，该方法为了减少对象的创建，节省内存，会将xxx转化成的Integer对象缓存起来，之后只要是相同的xxx，那么这个方法都会直接从缓存中取出对象来。假设代码中的Integer.valueOf(1)生成的对象是java.lang.Integer@987197，而Integer.valueOf(2)生成的对象是java.lang.Integer@15e293a，那么之后无论调用多少次Integer.valueOf(1)，也无论是哪一个线程去调用该方法，返回的都只是同一个对象java.lang.Integer@987197。也就是说上边的这段代码中的Integer.valueOf(i)只会生成两个不同的对象，就是java.lang.Integer@987197和java.lang.Integer@15e293a，而这两个对象也就是我们的锁对象。2）死锁发生的时机假设线程"Thread-95"执行到其第一个synchronized块中时（假设刚刚获取了锁对象java.lang.Integer@987197），这时候CPU时间片切换给了线程"Thread-106"，而"Thread-106"执行其第一个synchronized块（获取了锁对象java.lang.Integer@15e293a），之后"Thread-106"要执行第二个synchronized块儿来获取锁对象java.lang.Integer@987197，这时候就获取不到了，因为这个锁对象正被"Thread-95"所持有，于是"Thread-106"就阻塞在java.lang.Integer@987197这个锁对象上，这时，假设CPU时间片又切换给了"Thread-95"，该线程要执行第二个synchronized块来获取java.lang.Integer@15e293a，就获取不到了，因为该锁对象已被"Thread-106"所持有3）结果"Thread-95"持有锁对象java.lang.Integer@987197，阻塞在锁对象java.lang.Integer@15e293a；"Thread-106"持有锁对象java.lang.Integer@15e293a，阻塞在锁对象java.lang.Integer@987197 3、visualVM是一块更加全面的GUI监视工具，包含很多插件（需要自己下载），具体的见《深入理解Java虚拟机（第二版）》 JVM调优 1、JVM的调优主要是内存的调优，主要调两个方面：各个代的大小垃圾收集器选择2、各个代的大小常用的调节参数-Xmx-Xms-Xmn-XX:SurvivorRatio-XX:MaxTenuringThreshold-XX:PermSize-XX:MaxPermSize原则在实际开发中，前台不要使用jsp，使用velocity等模板引擎技术不要引入无关的jar-XX:SurvivorRatio过大：对象在年轻代的存活时间变长，可能在年轻代就被回收掉而不必进入年老代，但是相应的复制的时候survivor区就会被占用更多的空间。-XX:SurvivorRatio过大：对象在年轻代的存活时间变短，可能会早早进入年老代而失去在年轻代被回收的机会，但是相应的复制的时候survivor区也就有更多内存了，这样可能会避免部分大对象直接进入年老代-XX:SurvivorRatio过大：Eden变大，Survivor变小，minor GC可能减少，但是由于suvivor减小了，所以如果minor GC存活下来的对象大于suvivor，则会直接进入年老代-XX:SurvivorRatio过小：Eden变小，Survivor变大，minor GC可能增多，但是由于suvivor变大了，能够存储更多存活下来的对象，进入年老代的对象可能会减少 调节时机：minor GC太频繁-Xmn过小：minor GC太频繁；小对象可能也会直接进入年老代，提前导致Full GC-Xmn过大：年轻代大了，minor GC的时间变长了；年老代变小了，Full GC会频繁调节策略：若-Xmx可调大，则调大，且保持-Xmn==-Xmx/4~-Xmx/3；若-Xmx不可调大，在保持-Xmn==-Xmx/4~-Xmx/3的范围内增大-Xmn，若-Xmn也不可调了，则试着调大-XX:SurvivorRatio来看看情况-Xmx==-Xms：防止堆内存频繁进行调整，调整的时机见《第一章 JVM内存结构》-Xmn：通常设为-Xmx/4（这是我在企业中实习时的设置方式，系统运行正常、平稳、速度也快），林昊推荐的是-Xmx/3，所以-Xmn==-Xmx/4~-Xmx/3-XX:SurvivorRatio：默认8-XX:MaxTenuringThreshold：默认为15-XX:MaxPermSize==-XX:PermSize3、垃圾收集器选择企业中最常用的两个组合：（这里由于大部分大型企业用的还是JDK1.6，所以G1不说）关于下边两组垃圾收集器的详细原理见：第五章 JVM垃圾收集器（1）Parallel Scavenge/Parallel Old注重吞吐量（吞吐量越大，说明CPU利用率越高）主要用于处理很多的CPU计算任务而用户交互任务较少的情况也用于让JVM自动调优而我们袖手旁观的情况（-XX:+UseParallelOldGC，-XX:GCTimeRatio，-Xmx，-XX:+UseAdaptiveSizePolicy）-XX:+UseParallelOldGC：指定使用该组合ParNew/CMS注重STW的缩短（该时间越短，用户体验越好，而且会减少部分请求的请求超时问题）-XX:+UseConcMarkSweepGC：指定使用该组合-XX:CMSInitiatingOccupancyFraction：来指定当年老代空间满了多少后（百分比）进行垃圾回收关于上边两种组合的说明一般而言，在企业中，机器的CPU数量都比较多，且CPU的计算能力也不会成为瓶颈，所以对于CMS的并发标记与并发清除阶段，会占用CPU资源的问题，其实不是大事儿；而对于Parallel的注重吞吐量的问题也就不是什么大事儿了，毕竟CPU是强大的所以，ParNew/CMS是首选（在G1不能用的情况下），Parallel Scavenge/Parallel Old只在想让JVM自动管理内存的情况下使用注意：在实际调优过程中，可以使用jstat、jconsole、visualVM或GC日志的检测数据来调，具体的示例见《深入理解java虚拟机（第二版）》p142对eclipse运行速度的调优。关于GC日志的参数含义与每一种垃圾收集器的GC日志的格式，查看《深入理解Java虚拟机（第二版）》的P89和《深入分析java web技术内幕（修订版）》的P224
上述就是小编为大家分享的怎样进行JVM性能监控和调优了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注创新互联行业资讯频道。