jvm调优现场

jvm 内存查看

线程

1.输出该进程拥有的线程总数
ps -mp pid -o THREAD,tid,time | wc -l

2.输出占用cpu最大的前10线程
ps -mp pid -o THREAD,tid,time | sort -rn | head -10

3.查看进程中线程当前的的状态(thread dump)
jstack pid对于查找blocked线程比较有意义

"resin-port-9040-24" #24 daemon prio&＃61;5 os_prio&＃61;31 tid&＃61;0x00007ffbfc212000 nid&＃61;0x8503 runnable [0x0000700011cbb000]java.lang.Thread.State: RUNNABLEat java.net.PlainSocketImpl.socketAccept(Native Method)at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409)at java.net.ServerSocket.implAccept(ServerSocket.java:545)at java.net.ServerSocket.accept(ServerSocket.java:513)at com.caucho.vfs.QServerSocketWrapper.accept(QServerSocketWrapper.java:105)at com.caucho.network.listen.TcpPort.accept(TcpPort.java:1380)at com.caucho.network.listen.TcpSocketLink.accept(TcpSocketLink.java:1025)at com.caucho.network.listen.TcpSocketLink.handleAcceptTaskImpl(TcpSocketLink.java:975)at com.caucho.network.listen.ConnectionTask.runThread(ConnectionTask.java:117)at com.caucho.network.listen.ConnectionTask.run(ConnectionTask.java:93)at com.caucho.network.listen.SocketLinkThreadLauncher.handleTasks(SocketLinkThreadLauncher.java:169)at com.caucho.network.listen.TcpSocketAcceptThread.run(TcpSocketAcceptThread.java:61)at com.caucho.env.thread2.ResinThread2.runTasks(ResinThread2.java:173)at com.caucho.env.thread2.ResinThread2.run(ResinThread2.java:118)"resin-port-9040-launcher" #23 daemon prio&＃61;5 os_prio&＃61;31 tid&＃61;0x00007ffbfc211000 nid&＃61;0x8703 waiting on condition [0x0000700011c78000]java.lang.Thread.State: TIMED_WAITING (parking)at sun.misc.Unsafe.park(Native Method)at java.util.concurrent.locks.LockSupport.parkUntil(LockSupport.java:372)at com.caucho.env.thread2.AbstractTaskWorker2.run(AbstractTaskWorker2.java:270)at com.caucho.env.thread2.ResinThread2.runTasks(ResinThread2.java:173)at com.caucho.env.thread2.ResinThread2.run(ResinThread2.java:118)

更直观的统计:
jstack pid | grep &＃39;java.lang.Thread.State&＃39; | sort -n|uniq -c| sort -nr

14 java.lang.Thread.State: RUNNABLE12 java.lang.Thread.State: TIMED_WAITING (parking)2 java.lang.Thread.State: WAITING (on object monitor)1 java.lang.Thread.State: TIMED_WAITING (on object monitor)

堆栈dump

1.导出当前堆中存活的对象到文件中
jmap -dump:live,format&＃61;b,file&＃61;heap-dump.hprof

2.查看堆文件
jhat
也可以使用jdk自带的jvisualvm工具查看堆文件.
也可以使用IBM Heap Analyzer工具分析堆文件.IBM的HeapAnalyzer看到的更详细,对象的全部信息都能查看到.

jvm内存查看

1.查看内存当前各个区域占用的大小
jstat -gcutil pid

S0 S1 E O M CCS YGC YGCT FGC FGCT GCT0.00 0.00 10.13 12.93 96.09 92.68 35 6.568 3 7.159 13.727

或者使用
jmap -heap pid

Heap Configuration:MinHeapFreeRatio &＃61; 40MaxHeapFreeRatio &＃61; 70MaxHeapSize &＃61; 2147483648 (2048.0MB)NewSize &＃61; 786432000 (750.0MB)MaxNewSize &＃61; 786432000 (750.0MB)OldSize &＃61; 1361051648 (1298.0MB)NewRatio &＃61; 2SurvivorRatio &＃61; 8MetaspaceSize &＃61; 134217728 (128.0MB)CompressedClassSpaceSize &＃61; 1073741824 (1024.0MB)MaxMetaspaceSize &＃61; 134217728 (128.0MB)G1HeapRegionSize &＃61; 0 (0.0MB)Heap Usage:
New Generation (Eden &＃43; 1 Survivor Space):capacity &＃61; 707788800 (675.0MB)used &＃61; 414354616 (395.1593551635742MB)free &＃61; 293434184 (279.8406448364258MB)58.542126690899885% used
Eden Space:capacity &＃61; 629145600 (600.0MB)used &＃61; 352045688 (335.73693084716797MB)free &＃61; 277099912 (264.26306915283203MB)55.956155141194664% used
From Space:capacity &＃61; 78643200 (75.0MB)used &＃61; 62308928 (59.42242431640625MB)free &＃61; 16334272 (15.57757568359375MB)79.22989908854167% used
To Space:capacity &＃61; 78643200 (75.0MB)used &＃61; 0 (0.0MB)free &＃61; 78643200 (75.0MB)0.0% used
concurrent mark-sweep generation:capacity &＃61; 1361051648 (1298.0MB)used &＃61; 418792640 (399.39178466796875MB)free &＃61; 942259008 (898.6082153320312MB)30.76978310230884% used

2.查看内存gc的情况
jstat -gc pid

S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT
76800.0 76800.0 0.0 0.0 614400.0 53387.9 1329152.0 171834.9 82048.0 78841.9 8832.0 8185.6 35 6.568 3 7.159 13.727

3.当前存活的对象
jmap -histo:live pid

4.查看当前配置jvm配置信息
jinfo pid

3951: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.DecimalDV
3952: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.DoubleDV
3953: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.DurationDV
3954: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.EntityDV
3955: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.FloatDV
3956: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.HexBinaryDV
3957: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.IDDV
3958: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.IDREFDV
3959: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.IntegerDV
3960: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.ListDV
3961: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.MonthDV
3962: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.MonthDayDV
3963: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.PrecisionDecimalDV
3964: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.StringDV
3965: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.TimeDV
3966: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.UnionDV
3967: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.XSSimpleTypeDecl$1
3968: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.XSSimpleTypeDecl$4

jvm 调优

jvm参数说明&＃xff1a;

• -server 一定要作为第一个参数&＃xff0c;启用JDK的server版本&＃xff0c;在多个CPU时性能佳.默认是client模式.
• -Xms2304M Java堆最小值
• -Xmx2304M 最大值,不可超过物理内存。
• -Xmn1024M 年轻代堆大小&＃xff0c;一般设置为Xmx的3/8。
• -XX:PermSize&＃61;64m 设定内存的永久保存区初始大小&＃xff0c;缺省值为64M。jdk1.8后没有改参数了.
• -XX:MaxPermSize&＃61;128m 设定内存的永久保存区最大大小&＃xff0c;缺省值为64M。
• -XX:SurvivorRatio&＃61;8 新生代比例大小
• -XX:NewSize&＃61;2M 新生成的池的初始大小。 缺省值为2M。
• -XX:MaxNewSize&＃61;32M 新生成的池的最大大小。 缺省值为32M。
• -Xss 每个线程的Stack大小
• -XX:MetaspaceSize&＃61;128m 替换1.8之前的PermGen(永久区),jdk1.8之后的使用元空间来做
• -XX:MaxMetaspaceSize&＃61;256m 元空间最大值
• -XX:MaxTenuringThreshold&＃61;6 指定调用gc间隔时间,gc6次后对象进入老年代,默认是15次

cms收集器的配置

• -XX:&＃43;UseConcMarkSweepGC 该标志首先是激活CMS收集器,表示老年代开启CMS收集器,&＃43;表示开启,-表示关闭
• -XX:CMSInitiatingOccupancyFraction&＃61;75 永久代回收峰值设定,如果老年代超过75%将执行cms回收期

• -XX:&＃43;UseCMSInitiatingOccupancyOnly JVM不基于运行时收集的数据来启动CMS垃圾收集周期。而是&＃xff0c;当该标志被开启时&＃xff0c;JVM通过CMSInitiatingOccupancyFraction 的值进行每一次CMS收集&＃xff0c;而不仅仅是第一次。然而&＃xff0c;请记住大多数情况下&＃xff0c;JVM比我们自己能作出更好的垃圾收集决策。因此&＃xff0c;只有当我们充足的理由(比如测试)并且对应用程序产生的对象的生命周期有深刻的认知时&＃xff0c;才应该使用该标志。

• -XX:&＃43;ExplicitGCInvokesConcurrent and
  -XX:&＃43;ExplicitGCInvokesConcurrentAndUnloadsClasses
  如今,被广泛接受的最佳实践是避免显式地调用GC(所谓的“系统GC”)&＃xff0c;即在应用程序中调用system.gc()。然而&＃xff0c;这个建议是不管使用的GC算法的&＃xff0c;值得一提的是&＃xff0c;当使用CMS收集器时&＃xff0c;系统GC将是一件很不幸的事&＃xff0c;因为它默认会触发一次Full GC。幸运的是&＃xff0c;有一种方式可以改变默认设置。标志-XX:&＃43;ExplicitGCInvokesConcurrent命令JVM无论什么时候调用系统GC&＃xff0c;都执行CMS GC&＃xff0c;而不是Full GC。第二个标志-XX:&＃43;ExplicitGCInvokesConcurrentAndUnloadsClasses保证当有系统GC调用时&＃xff0c;永久代也被包括进CMS垃圾回收的范围内。因此&＃xff0c;通过使用这些标志&＃xff0c;我们可以防止出现意料之外的”stop-the-world”的系统GC。

• -XX:&＃43;ParallelRefProcEnabled 如果应用有大量的引用或者finalizable对象需要处理&＃xff0c;指定下面这个选项可以减少垃圾回收的时间:
  他会是用多个的引用处理线程&＃xff0c;而不是单个线程。这个选项不会启用多线程运行方法的finalizer。他会使用很多线程去发现需要排队通知的finalizable对象。

• -XX:&＃43;UseParNewGC ParNew收集器器是许多运⾏行行在Server模式下的虚拟机中⾸首选的新⽣生代收集器器。除去性能因素&＃xff0c;很重要的原因是 除了了Serial收集器器外&＃xff0c;⽬目前只有它能与CMS收集器器配合⼯工作。

吞吐量收集器

• -XX:&＃43;UseSerialGC 我们使用该标志来激活串行垃圾收集器&＃xff0c;例如单线程面向吞吐量垃圾收集器。 无论年轻代还是年老代都将只有一个线程执行垃圾收集。 该标志被推荐用于只有单个可用处理器核心的JVM。 在这种情况下&＃xff0c;使用多个垃圾收集线程甚至会适得其反&＃xff0c;因为这些线程将争用CPU资源&＃xff0c;造成同步开销&＃xff0c;却从未真正并行运行。

• -XX:&＃43;UseParallelGC 有了这个标志&＃xff0c;我们告诉JVM使用多线程并行执行年轻代垃圾收集。 在我看来&＃xff0c;Java 6中不应该使用该标志因为-XX:&＃43;UseParallelOldGC显然更合适。 需要注意的是Java 7中该情况改变了一点(详见本概述)&＃xff0c;就是-XX:&＃43;UseParallelGC能达到-XX:&＃43;UseParallelOldGC一样的效果。

• -XX:&＃43;UseParallelOldGC 该标志的命名有点不巧&＃xff0c;因为”老”听起来像”过时”。 然而&＃xff0c;”老”实际上是指年老代&＃xff0c;这也解释了为什么-XX:&＃43;UseParallelOldGC要优于-XX:&＃43;UseParallelGC&＃xff1a;除了激活年轻代并行垃圾收集&＃xff0c;也激活了年老代并行垃圾收集。 当期望高吞吐量&＃xff0c;并且JVM有两个或更多可用处理器核心时&＃xff0c;我建议使用该标志。
  作为旁注&＃xff0c;HotSpot的并行面向吞吐量垃圾收集算法通常称为”吞吐量收集器”&＃xff0c;因为它们旨在通过并行执行来提高吞吐量。

• -XX:ParallelGCThreads 通过-XX:ParallelGCThreads&＃61;我们可以指定并行垃圾收集的线程数量。 例如&＃xff0c;-XX:ParallelGCThreads&＃61;6表示每次并行垃圾收集将有6个线程执行。 如果不明确设置该标志&＃xff0c;虚拟机将使用基于可用(虚拟)处理器数量计算的默认值。 决定因素是由Java Runtime。availableProcessors()方法的返回值N&＃xff0c;如果N<&＃61;8&＃xff0c;并行垃圾收集器将使用N个垃圾收集线程&＃xff0c;如果N>8个可用处理器&＃xff0c;垃圾收集线程数量应为3&＃43;5N/8。
  当JVM独占地使用系统和处理器时使用默认设置更有意义。 但是&＃xff0c;如果有多个JVM(或其他耗CPU的系统)在同一台机器上运行&＃xff0c;我们应该使用-XX:ParallelGCThreads来减少垃圾收集线程数到一个适当的值。 例如&＃xff0c;如果4个以服务器方式运行的JVM同时跑在在一个具有16核处理器的机器上&＃xff0c;设置-XX:ParallelGCThreads&＃61;4是明智的&＃xff0c;它能使不同JVM的垃圾收集器不会相互干扰。

• -XX:-UseAdaptiveSizePolicy 吞吐量垃圾收集器提供了一个有趣的(但常见&＃xff0c;至少在现代JVM上)机制以提高垃圾收集配置的用户友好性。 这种机制被看做是HotSpot在Java 5中引入的”人体工程学”概念的一部分。 通过人体工程学&＃xff0c;垃圾收集器能将堆大小动态变动像GC设置一样应用到不同的堆区域&＃xff0c;只要有证据表明这些变动将能提高GC性能。 “提高GC性能”的确切含义可以由用户通过-XX:GCTimeRatio和-XX:MaxGCPauseMillis(见下文)标记来指定。
  重要的是要知道人体工程学是默认激活的。 这很好&＃xff0c;因为自适应行为是JVM最大优势之一。 不过&＃xff0c;有时我们需要非常清楚对于特定应用什么样的设置是最合适的&＃xff0c;在这些情况下&＃xff0c;我们可能不希望JVM混乱我们的设置。 每当我们发现处于这种情况时&＃xff0c;我们可以考虑通过-XX:-UseAdaptiveSizePolicy停用一些人体工程学。

• -XX:GCTimeRatio 通过-XX:GCTimeRatio&＃61;我们告诉JVM吞吐量要达到的目标值。 更准确地说&＃xff0c;-XX:GCTimeRatio&＃61;N指定目标应用程序线程的执行时间(与总的程序执行时间)达到N/(N&＃43;1)的目标比值。 例如&＃xff0c;通过-XX:GCTimeRatio&＃61;9我们要求应用程序线程在整个执行时间中至少9/10是活动的(因此&＃xff0c;GC线程占用其余1/10)。 基于运行时的测量&＃xff0c;JVM将会尝试修改堆和GC设置以期达到目标吞吐量。 -XX:GCTimeRatio的默认值是99&＃xff0c;也就是说&＃xff0c;应用程序线程应该运行至少99%的总执行时间。

• -XX:MaxGCPauseMillis 通过-XX:GCTimeRatio&＃61;告诉JVM最大暂停时间的目标值(以毫秒为单位)。 在运行时&＃xff0c;吞吐量收集器计算在暂停期间观察到的统计数据(加权平均和标准偏差)。 如果统计表明正在经历的暂停其时间存在超过目标值的风险时&＃xff0c;JVM会修改堆和GC设置以降低它们。 需要注意的是&＃xff0c;年轻代和年老代垃圾收集的统计数据是分开计算的&＃xff0c;还要注意&＃xff0c;默认情况下&＃xff0c;最大暂停时间没有被设置。
  如果最大暂停时间和最小吞吐量同时设置了目标值&＃xff0c;实现最大暂停时间目标具有更高的优先级。 当然&＃xff0c;无法保证JVM将一定能达到任一目标&＃xff0c;即使它会努力去做。 最后&＃xff0c;一切都取决于手头应用程序的行为。

• -verbose:gc
• -XX:&＃43;PrintGCDetails
  输出形式&＃xff1a;[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs]
  [GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
• -XX:&＃43;PrintGCTimeStamps 可与上面的混合使用,输出形式:11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]
• -XX:&＃43;PrintGCDateStamps 和上面的timestamps混合使用,打印出日期2014-01-03T12:08:38.102-0100: [GC 66048K->53077K(251392K), 0.0959470 secs]
• XX:&＃43;PrintFlagsInitial表示打印出所有XX选项的默认值&＃xff0c;-XX:&＃43;PrintFlagsFinal表示打印出XX选项在运行程序时生效的值
• -Xloggc:/logs/gc.log 指定gc文件
• -XX:&＃43;PrintTenuringDistribution让JVM在每次MinorGC后打印出Survivor空间中的对象的年龄分布

OutofMemory&＃xff08;OOM&＃xff09;相关的选项
如果程序发生了OOM后&＃xff0c;JVM可以配置一些选项来做些善后工作&＃xff0c;比如把内存给dump下来&＃xff0c;或者自动采取一些别的动作。

• -XX:&＃43;HeapDumpOnOutOfMemoryError 表示在内存出现OOM的时候&＃xff0c;把Heap转存(Dump)到文件以便后续分析&＃xff0c;文件名通常是java_pid.hprof&＃xff0c;其中pid为该程序的进程号。
• -XX:HeapDumpPath&＃61;: 用来指定heap转存文件的存储路径&＃xff0c;需要指定的路径下有足够的空间来保存转存文件。
• -XX:OnOutOfMemoryError 用来指定一个可行性程序或者脚本的路径&＃xff0c;当发生OOM的时候&＃xff0c;去执行这个脚本。
  $ java -XX:&＃43;HeapDumpOnOutOfMemoryError -XX:HeapDumpPath&＃61;/tmp/heapdump.hprof -XX:OnOutOfMemoryError &＃61;"sh ~/start.sh" myserver

开启远程jmx监控,这是个组合,一起用就行了.开启了远程jmx监控后,就可以在本地启动jconsole,等一些内存分析工具对服务器内存进行分析了.一般测试环境用,正式环境慎用.

• -Dcom.sun.management.jmxremote
• -Dcom.sun.management.jmxremote.port&＃61;8088
• -Dcom.sun.management.jmxremote.ssl&＃61;false
• -Dcom.sun.management.jmxremote.authenticate&＃61;false

实战配置

-server //开启服务模式
-Xmn750M //年轻代配置xmx的3/8
-Xmx2048M //堆的最大值
-Xms2048M //堆的最小值
-XX:MetaspaceSize&＃61;128m //元数据区
-XX:MaxMetaspaceSize&＃61;128m
-Xss256k //一个线程占用的栈大小
-XX:SurvivorRatio&＃61;8
-XX:&＃43;UseConcMarkSweepGC //激活cms收集器
-XX:MaxTenuringThreshold&＃61;8 //最大gc次数后进入老年代.默认15
-XX:ParallelGCThreads&＃61;24 //cms收集时,开启多少线程
-XX:&＃43;ParallelRefProcEnabled //finalizable多线程回收
-XX:&＃43;UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction&＃61;75 //老年代超过75%,开始cms回收
-XX:&＃43;ExplicitGCInvokesConcurrent //JVM无论什么时候调用系统GC&＃xff0c;都执行CMS GC
-verbose:gc -XX:&＃43;PrintGCDetails -XX:&＃43;PrintGCTimeStamps -XX:&＃43;PrintGCDateStamps -XX:&＃43;PrintFlagsFinal -XX:&＃43;UseParNewGC //多线程新生代收集器-Xloggc:/logs/gc.log

解说:由于系统对吞吐量要求不高,所以主要是对响应方面的内存优化,防止频繁FULL GC和频繁gc.

参考地址

上面文章也是大量参考网友的,自己再重新整合,修改,添加了一些东西.但是忘记记录地址了,这里说声对比起,如有发现原文抄袭的情况,请联系我,我贴上转载地址.