JVM调优参数、方法、工具以及案例总结

开发 后端
本文主要用来总结梳理便于以后翻阅,主要围绕四个大的方面展开,分别是JVM调优参数、JVM调优方法(流程)、JVM调优工具、JVM调优案例,调优案例目前正在分析,会在将来补上。

 这种文章挺难写的,一是JVM参数巨多,二是内容枯燥乏味,但是想理解JVM调优又是没法避开的环节,本文主要用来总结梳理便于以后翻阅,主要围绕四个大的方面展开,分别是JVM调优参数、JVM调优方法(流程)、JVM调优工具、JVM调优案例,调优案例目前正在分析,会在将来补上。

垃圾回收有关参数

参数部分,这儿只是做一个总结,更详细更新的内容请参考Oracle官网:JVM的命令行参数参考

处理器组合参数

关于JVM垃圾处理器区别,参考:JVM调优之垃圾定位、垃圾回收算法、垃圾处理器对比

-XX:+UseSerialGC = Serial New (DefNew) + Serial Old

适用于小型程序。默认情况下不会是这种选项,HotSpot会根据计算及配置和JDK版本自动选择收集器

-XX:+UseParNewGC = ParNew + SerialOld

这个组合已经很少用(在某些版本中已经废弃),详情参考:Why Remove support for ParNew+SerialOld and DefNew+CMS in the future?

-XX:+UseConc(urrent)MarkSweepGC = ParNew + CMS + Serial Old

-XX:+UseParallelGC = Parallel Scavenge + Parallel Old (1.8默认) 【PS + SerialOld】

-XX:+UseParallelOldGC = Parallel Scavenge + Parallel Old

-XX:+UseG1GC = G1

Linux中没找到默认GC的查看方法,而windows中会打印UseParallelGC

  •  java +XX:+PrintCommandLineFlags -version
  •  通过GC的日志来分辨

Linux下1.8版本默认的垃圾回收器到底是什么?

  •  1.8.0_181 默认(看不出来)Copy MarkCompact
  •  1.8.0_222 默认 PS + PO

虚拟机参数

并行收集器相关参数

CMS处理器参数设置

JVM辅助信息参数设置

JVM GC垃圾回收器参数设置

JVM给出了3种选择:串行收集器、并行收集器、并发收集器。串行收集器只适用于小数据量的情况,所以生产环境的选择主要是并行收集器和并发收集器。默认情况下JDK5.0以前都是使用串行收集器,如果想使用其他收集器需要在启动时加入相应参数。JDK5.0以后,JVM会根据当前系统配置进行智能判断。

串行收集器-XX:+UseSerialGC:设置串行收集器。

并行收集器(吞吐量优先)-XX:+UseParallelGC:设置为并行收集器。此配置仅对年轻代有效。即年轻代使用并行收集,而年老代仍使用串行收集。

-XX:ParallelGCThreads=20:配置并行收集器的线程数,即:同时有多少个线程一起进行垃圾回收。此值建议配置与CPU数目相等。

-XX:+UseParallelOldGC:配置年老代垃圾收集方式为并行收集。JDK6.0开始支持对年老代并行收集。

-XX:MaxGCPauseMillis=100:设置每次年轻代垃圾回收的最长时间(单位毫秒)。如果无法满足此时间,JVM会自动调整年轻代大小,以满足此时间。

-XX:+UseAdaptiveSizePolicy:设置此选项后,并行收集器会自动调整年轻代Eden区大小和Survivor区大小的比例,以达成目标系统规定的最低响应时间或者收集频率等指标。此参数建议在使用并行收集器时,一直打开。并发收集器(响应时间优先)

并行收集器

-XX:+UseConcMarkSweepGC:即CMS收集,设置年老代为并发收集。CMS收集是JDK1.4后期版本开始引入的新GC算法。它的主要适合场景是对响应时间的重要性需求大于对吞吐量的需求,能够承受垃圾回收线程和应用线程共享CPU资源,并且应用中存在比较多的长生命周期对象。CMS收集的目标是尽量减少应用的暂停时间,减少Full GC发生的几率,利用和应用程序线程并发的垃圾回收线程来标记清除年老代内存。

-XX:+UseParNewGC:设置年轻代为并发收集。可与CMS收集同时使用。JDK5.0以上,JVM会根据系统配置自行设置,所以无需再设置此参数。

-XX:CMSFullGCsBeforeCompaction=0:由于并发收集器不对内存空间进行压缩和整理,所以运行一段时间并行收集以后会产生内存碎片,内存使用效率降低。此参数设置运行0次Full GC后对内存空间进行压缩和整理,即每次Full GC后立刻开始压缩和整理内存。

-XX:+UseCMSCompactAtFullCollection:打开内存空间的压缩和整理,在Full GC后执行。可能会影响性能,但可以消除内存碎片。

-XX:+CMSIncrementalMode:设置为增量收集模式。一般适用于单CPU情况。

-XX:CMSInitiatingOccupancyFraction=70:表示年老代内存空间使用到70%时就开始执行CMS收集,以确保年老代有足够的空间接纳来自年轻代的对象,避免Full GC的发生。

其它垃圾回收参数

-XX:+ScavengeBeforeFullGC:年轻代GC优于Full GC执行。

-XX:-DisableExplicitGC:不响应 System.gc() 代码。

-XX:+UseThreadPriorities:启用本地线程优先级API。即使 java.lang.Thread.setPriority() 生效,不启用则无效。

-XX:SoftRefLRUPolicyMSPerMB=0:软引用对象在最后一次被访问后能存活0毫秒(JVM默认为1000毫秒)。

-XX:TargetSurvivorRatio=90:允许90%的Survivor区被占用(JVM默认为50%)。提高对于Survivor区的使用率。

JVM参数优先级

-Xmn,-XX:NewSize/-XX:MaxNewSize,-XX:NewRatio 3组参数都可以影响年轻代的大小,混合使用的情况下,优先级是什么?

答案如下:

高优先级:-XX:NewSize/-XX:MaxNewSize 中优先级:-Xmn(默认等效 -Xmn=-XX:NewSize=-XX:MaxNewSize=?) 低优先级:-XX:NewRatio

推荐使用-Xmn参数,原因是这个参数简洁,相当于一次设定 NewSize/MaxNewSIze,而且两者相等,适用于生产环境。-Xmn 配合 -Xms/-Xmx,即可将堆内存布局完成。

-Xmn参数是在JDK 1.4 开始支持。

下面用一些小案例加深理解:

HelloGC是java代码编译后的一个class文件,代码: 

  1. public class T01_HelloGC {  
  2.     public static void main(String[] args) {  
  3.         for(int i=0; i<10000; i++) {  
  4.             byte[] b = new byte[1024 * 1024];  
  5.         }  
  6.     }  

    1.  java -XX:+PrintCommandLineFlags HelloGC 

  1. [root@localhost courage]# java -XX:+PrintCommandLineFlags T01_HelloGC  
  2.   -XX:InitialHeapSize=61780800 -XX:MaxHeapSize=988492800 -XX:+PrintCommandLineFlags -XX  
  3.   :+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC  

2. 

  1. java -Xmn10M -Xms40M -Xmx60M -XX:+PrintCommandLineFlags -XX:+PrintGC  HelloGC  
  2. PrintGCDetails PrintGCTimeStamps PrintGCCauses 

结果: 

  1. -XX:InitialHeapSize=41943040 -XX:MaxHeapSize=62914560 -XX:MaxNewSize=10485760 -XX:NewSize=10485760 -XX:+PrintCommandLineFlags -XX:+PrintGC -XX:+UseCompressedClassPointers -XX:+UseCompressedOops  
  2. -XX:+UseParallelGC[GC (Allocation Failure)  7839K->392K(39936K), 0.0015452 secs]  
  3. [GC (Allocation Failure)  7720K->336K(39936K), 0.0005439 secs]  
  4. [GC (Allocation Failure)  7656K->336K(39936K), 0.0005749 secs]  
  5. [GC (Allocation Failure)  7659K->368K(39936K), 0.0005095 secs]  
  6. [GC (Allocation Failure)  7693K->336K(39936K), 0.0004385 secs]  
  7. [GC (Allocation Failure)  7662K->304K(40448K), 0.0028468 secs]  
  8. ...... 

命令解释:

 java:表示使用java执行器执行 -Xmn10M :表示设置年轻代值为10M -Xms40M :表示设置堆内存的最小Heap值为40M -Xmx60M :表示设置堆内存的最大Heap值为60M -XX:+PrintCommandLineFlags:打印显式隐式参数,就是结果前三行 -XX:+PrintGC : 打印垃圾回收有关信息 HelloGC :这是需要执行的启动类 PrintGCDetails :打印GC详细信息 PrintGCTimeStamps :打印GC时间戳 PrintGCCauses :打印GC产生的原因

结果解释:

    3.  java -XX:+UseConcMarkSweepGC -XX:+PrintCommandLineFlags HelloGC

表示使用CMS垃圾收集器,同时打印参数 打印结果: 

  1. -XX:InitialHeapSize=61780800   
  2.   -XX:MaxHeapSize=988492800   
  3.   -XX:MaxNewSize=329252864   
  4.   -XX:MaxTenuringThreshold=6   
  5.   -XX:OldPLABSize=16   
  6.   -XX:+PrintCommandLineFlags   
  7.   -XX:+UseCompressedClassPointers   
  8.   -XX:+UseCompressedOops   
  9.   -XX:+UseConcMarkSweepGC   
  10.   -XX:+UseParNewGC 

    4.  java -XX:+PrintFlagsInitial 默认参数值

    5.   java -XX:+PrintFlagsFinal 最终参数值

    6.  java -XX:+PrintFlagsFinal | grep xxx 找到对应的参数

    7.  java -XX:+PrintFlagsFinal -version |grep GC

JVM调优流程

JVM调优,设计到三个大的方面,在服务器出现问题之前要先根据业务场景选择合适的垃圾处理器,设置不同的虚拟机参数,运行中观察GC日志,分析性能,分析问题定位问题,虚拟机排错等内容,如果服务器挂掉了,要及时生成日志文件便于找到问题所在。

调优前的基础概念

目前的垃圾处理器中,一类是以吞吐量优先,一类是以响应时间优先:

吞吐量=用户代码执行时间用户代码执行时间+垃圾回收执行时间吞吐量=用户代码执行时间用户代码执行时间+垃圾回收执行时间

响应时间:STW越短,响应时间越好

对吞吐量、响应时间、QPS、并发数相关概念可以参考:吞吐量(TPS)、QPS、并发数、响应时间(RT)概念

所谓调优,首先确定追求什么,是吞吐量? 还是追求响应时间?还是在满足一定的响应时间的情况下,要求达到多大的吞吐量,等等。一般情况下追求吞吐量的有以下领域:科学计算、数据挖掘等。吞吐量优先的垃圾处理器组合一般为:Parallel Scavenge + Parallel Old (PS + PO)。

而追求响应时间的业务有:网站相关 (JDK 1.8之后 G1,之前可以ParNew + CMS + Serial Old)

什么是调优?

  1.  根据需求进行JVM规划和预调优
  2.  优化运行JVM运行环境(慢,卡顿)
  3.  解决JVM运行过程中出现的各种问题(OOM)

调优之前的规划

  •  调优,从业务场景开始,没有业务场景的调优都是耍流氓
  •  无监控(压力测试,能看到结果),不调优
  •  步骤:

        1.

        2.  或者每天产生一个日志文件

        1.  响应时间、停顿时间 [CMS G1 ZGC] (需要给用户作响应)

        2.  吞吐量 = 用户时间 /( 用户时间 + GC时间) [PS+PO]

        1.  熟悉业务场景(没有最好的垃圾回收器,只有最合适的垃圾回收器)

        2.  选择回收器组合

        3.  计算内存需求(经验值 1.5G 16G)

        4.  选定CPU(越高越好)

        5.  设定年代大小、升级年龄

        6.  设定日志参数     

  1. -Xloggc:/opt/xxx/logs/xxx-xxx-gc-%t.log   
  2.      -XX:+UseGCLogFileRotation   
  3.      -XX:NumberOfGCLogFiles=5   
  4.      -XX:GCLogFileSize=20M   
  5.      -XX:+PrintGCDetails   
  6.      -XX:+PrintGCDateStamps   
  7.      -XX:+PrintGCCause 

日志参数解释说明:

/opt/xxx/logs/xxx-xxx-gc-%t.log 中XXX表示路径,%t表示时间戳,意思是给日志文件添加一个时间标记,如果不添加的话,也就意味着每次虚拟机启动都会使用原来的日志名,那么会被重写。

Rotation中文意思是循环、轮流,意味着这个GC日志会循环写

GCLogFileSize=20M 指定一个日志大小为20M,太大了不利于分析,太小又会产生过多的日志文件

NumberOfGCLogFiles=5 : 指定生成的日志数目

PrintGCDateStamps :PrintGCDateStamps会打印具体的时间,而PrintGCTimeStamps

主要打印针对JVM启动的时候的相对时间,相对来说前者更消耗内存。

    7.  观察日志情况 日志有分析工具,可视化分析工具有GCeasy和GCViewer。

CPU高负荷排查流程

    1.  系统CPU经常100%,如何调优?(面试高频) CPU100%那么一定有线程在占用系统资源,

        a.  找出哪个进程cpu高(top)

        b.  该进程中的哪个线程cpu高(top -Hp)

        c.  导出该线程的堆栈 (jstack)

        d.  查找哪个方法(栈帧)消耗时间 (jstack)

        e.  工作线程占比高 | 垃圾回收线程占比高

    2.  系统内存飙高,如何查找问题?(面试高频)

        a.  导出堆内存 (jmap)

        b.  分析 (jhat jvisualvm mat jprofiler ... )

    3.  如何监控JVM

        a.  jstat jvisualvm jprofiler arthas top...

CPU高负荷排查案例

    1.  测试代码:   

  1. import java.math.BigDecimal;  
  2.    import java.util.ArrayList;  
  3.    import java.util.Date;  
  4.    import java.util.List;  
  5.    import java.util.concurrent.ScheduledThreadPoolExecutor;  
  6.    import java.util.concurrent.ThreadPoolExecutor;  
  7.    import java.util.concurrent.TimeUnit;  
  8.    /**  
  9.     * 从数据库中读取信用数据,套用模型,并把结果进行记录和传输 
  10.     */  
  11.    public class T15_FullGC_Problem01 {  
  12.        private static class CardInfo {  
  13.            BigDecimal price = new BigDecimal(0.0);  
  14.            String name = "张三" 
  15.            int age = 5 
  16.            Date birthdate = new Date();  
  17.            public void m() {}  
  18.        }  
  19.        private static ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(50,  
  20.                new ThreadPoolExecutor.DiscardOldestPolicy());  
  21.        public static void main(String[] args) throws Exception {  
  22.            executor.setMaximumPoolSize(50);  
  23.            for (;;){  
  24.                modelFit();  
  25.                Thread.sleep(100);  
  26.            }  
  27.        }  
  28.        private static void modelFit(){  
  29.            List<CardInfo> taskList = getAllCardInfo();  
  30.            taskList.forEach(info -> {  
  31.                // do something  
  32.                executor.scheduleWithFixedDelay(() -> {  
  33.                    //do sth with info  
  34.                    info.m();  
  35.                }, 2, 3, TimeUnit.SECONDS);  
  36.            });  
  37.        }  
  38.        private static List<CardInfo> getAllCardInfo(){  
  39.            List<CardInfo> taskList = new ArrayList<>();  
  40.            for (int i = 0; i < 100; i++) {  
  41.                CardInfo ci = new CardInfo();  
  42.                taskList.add(ci); 
  43.            }  
  44.            return taskList;  
  45.        }  
  46.    } 

    2.  java -Xms200M -Xmx200M -XX:+PrintGC com.courage.jvm.gc.T15_FullGC_Problem01

    3.  收到CPU报警信息(CPU Memory)

    4.  top命令观察到问题:内存不断增长 CPU占用率居高不下 

  1. [root@localhost ~]# top  
  2.   top - 22:03:18 up 40 min,  5 users,  load average: 0.09, 0.16, 0.34  
  3.   Tasks: 210 total,   1 running, 209 sleeping,   0 stopped,   0 zombie  
  4.   %Cpu(s):  0.2 us,  3.0 sy,  0.0 ni, 96.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st  
  5.   KiB Mem :  3861300 total,  2355260 free,   904588 used,   601452 buff/cache  
  6.   KiB Swap:  4063228 total,  4063228 free,        0 used.  2716336 avail Mem   
  7.      PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND              
  8.      3751 root      20   0 3780976  93864  11816 S  42.2  2.4   0:21.00 java  
  9.     1868 mysql     20   0 1907600 357452  14744 S   0.7  9.3   0:17.40 mysqld  
  10.     3816 root      20   0  162124   2352   1580 R   0.3  0.1   0:00.12 top 

    5.  top -Hp 观察进程中的线程,哪个线程CPU和内存占比高   

  1. [root@localhost ~]# top -Hp 3751  
  2.    top - 22:03:15 up 40 min,  5 users,  load average: 0.09, 0.16, 0.34  
  3.    Threads:  66 total,   0 running,  66 sleeping,   0 stopped,   0 zombie  
  4.    %Cpu(s):  0.0 us,  2.5 sy,  0.0 ni, 97.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st  
  5.    KiB Mem :  3861300 total,  2354800 free,   905048 used,   601452 buff/cache  
  6.    KiB Swap:  4063228 total,  4063228 free,        0 used.  2715876 avail Mem   
  7.       PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND            
  8.       3801 root      20   0 3780976  93864  11816 S  1.3  2.4   0:00.40 java  
  9.      3766 root      20   0 3780976  93864  11816 S  1.0  2.4   0:00.37 java  
  10.      3768 root      20   0 3780976  93864  11816 S  1.0  2.4   0:00.36 java  
  11.      3770 root      20   0 3780976  93864  11816 S  1.0  2.4   0:00.39 java 

   6.   jps定位具体java进程,jstack 定位线程状况 

  1. [root@localhost ~]# jstack 3751  
  2.   2021-02-07 22:03:03  
  3.   Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.271-b09 mixed mode):  
  4.   "Attach Listener" #59 daemon prio=9 os_prio=0 tid=0x00007f66bc002800 nid=0xf10 waiting on condition [0x0000000000000000]  
  5.      java.lang.Thread.State: RUNNABLE  
  6.   "pool-1-thread-50" #58 prio=5 os_prio=0 tid=0x00007f66fc1de800 nid=0xee7 waiting on condition [0x00007f66e4ecd000]  
  7.      java.lang.Thread.State: WAITING (parking)  
  8.    at sun.misc.Unsafe.park(Native Method)  
  9.    - parking to wait for  <0x00000000ff0083a0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)  
  10.   ...... 

需要注意的是,jstack与top -Hp Port导出的栈端口号存在十六进制转换关系,例如jstack导出的" nid=0xf10 "对应"3801"。对于上面打印的信息,重点关注跟Waiting有关的,看看在等待什么,例如: 

  1. WAITING BLOCKED eg. waiting on <0x0000000088ca3310> (a java.lang.Object)  

假如有一个进程中100个线程,很多线程都在waiting on ,一定要找到是哪个线程持有这把锁,怎么找?搜索jstack dump的信息,看哪个线程持有这把锁RUNNABLE。

如果仅仅是看JAVA线程,可以使用jps命令重点关注: 

  1. [root@localhost ~]# jps  
  2. 4818 Jps  
  3. 4746 T15_FullGC_Problem01 

    7.  为什么阿里规范里规定,线程的名称(尤其是线程池)都要写有意义的名称 怎么样自定义线程池里的线程名称?(自定义ThreadFactory)

    8.  jinfo pid 进程详细信息 

  1. [root@localhost ~]# jinfo 6741  
  2. Attaching to process ID 6741, please wait...  
  3. Debugger attached successfully.  
  4. Server compiler detected.  
  5. JVM version is 25.271-b09  
  6. Java System Properties:  
  7. java.runtime.name = Java(TM) SE Runtime Environment  
  8. java.vm.version = 25.271-b09 
  9. sun.boot.library.path = /usr/local/java/jdk1.8.0_271/jre/lib/amd64  
  10. java.vendor.url = http://java.oracle.com/  
  11. java.vm.vendor = Oracle Corporation  
  12. path.separator = :  
  13. file.encoding.pkg = sun.io  
  14. java.vm.name = Java HotSpot(TM) 64-Bit Server VM  
  15. sun.os.patch.level = unknown  
  16. sun.java.launcher = SUN_STANDARD  
  17. user.country = CN  
  18. user.dir = /usr/courage/gc/com/courage  
  19. java.vm.specification.name = Java Virtual Machine Specification  
  20. java.runtime.version = 1.8.0_271-b09 
  21. java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment  
  22. os.arch = amd64  
  23. java.endorsed.dirs = /usr/local/java/jdk1.8.0_271/jre/lib/endorsed  
  24. java.io.tmpdir = /tmp  
  25. line.separator =  
  26. java.vm.specification.vendor = Oracle Corporation  
  27. os.name = Linux  
  28. sun.jnu.encoding = UTF-8  
  29. java.library.path = /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/  
  30. libjava.specification.name = Java Platform API Specification  
  31. java.class.version = 52.0  
  32. sun.management.compiler = HotSpot 64-Bit Tiered Compilers  
  33. os.version = 3.10.0-1127.el7.x86_64  
  34. user.home = /root  
  35. user.timezone =   
  36. java.awt.printerjob = sun.print.PSPrinterJob  
  37. file.encoding = UTF-8  
  38. java.specification.version = 1.8  
  39. user.name = root  
  40. java.class.path = .  
  41. java.vm.specification.version = 1.8  
  42. sun.arch.data.model = 64  
  43. sun.java.command = T15_FullGC_Problem01  
  44. java.home = /usr/local/java/jdk1.8.0_271/jre  
  45. user.language = zh  
  46. java.specification.vendor = Oracle Corporation  
  47. awt.toolkit = sun.awt.X11.XToolkit  
  48. java.vm.info = mixed mode  
  49. java.version = 1.8.0_271  
  50. java.ext.dirs = /usr/local/java/jdk1.8.0_271/jre/lib/ext:/usr/java/packages/l  
  51. ib/extsun.boot.class.path = /usr/local/java/jdk1.8.0_271/jre/lib/resources.jar:/usr  
  52. /local/java/jdk1.8.0_271/jre/lib/rt.jar:/usr/local/java/jdk1.8.0_271/jre/lib/sunrsasign.jar:/usr/local/java/jdk1.8.0_271/jre/lib/jsse.jar:/usr/local/java/jdk1.8.0_271/jre/lib/jce.jar:/usr/local/java/jdk1.8.0_271/jre/lib/charsets.jar:/usr/local/java/jdk1.8.0_271/jre/lib/jfr.jar:/usr/local/java/jdk1.8.0_271/jre/classesjava.vendor = Oracle Corporation 
  53.  file.separator = /  
  54. java.vendor.url.bug = http://bugreport.sun.com/bugreport/  
  55. sun.io.unicode.encoding = UnicodeLittle  
  56. sun.cpu.endian = little  
  57. sun.cpu.isalist =   
  58. VM Flags:  
  59. Non-default VM flags: -XX:CICompilerCount=3 -XX:InitialHeapSize=209715200 -XX 
  60. :MaxHeapSize=209715200 -XX:MaxNewSize=69730304 -XX:MinHeapDeltaBytes=524288 -XX:NewSize=69730304 -XX:OldSize=139984896 -XX:+PrintGC -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps -XX:+UseParallelGC Command line:  -Xms200M -Xmx200M -XX:+PrintGC 

    9.  jstat -gc 动态观察gc情况 / 阅读GC日志发现频繁GC / arthas观察 / jconsole/jvisualVM/ Jprofiler(最好用)

jstat gc 4655 500 : 每500毫秒打印端口4655的GC的情况

 

  •  **S0C:**第一个幸存区的大小
  •  **S1C:**第二个幸存区的大小
  •  **S0U:**第一个幸存区的使用大小
  •  **S1U:**第二个幸存区的使用大小
  •  **EC:**伊甸园区的大小
  •  **EU:**伊甸园区的使用大小
  •  **OC:**老年代大小
  •  **OU:**老年代使用大小
  •  **MC:**方法区大小
  •  **MU:**方法区使用大小
  •  **CCSC:**压缩类空间大小
  •  **CCSU:**压缩类空间使用大小
  •  **YGC:**年轻代垃圾回收次数
  •  **YGCT:**年轻代垃圾回收消耗时间
  •  **FGC:**老年代垃圾回收次数
  •  **FGCT:**老年代垃圾回收消耗时间
  •  **GCT:**垃圾回收消耗总时间

如果面试官问你是怎么定位OOM问题的?能否用图形界面(不能!因为图形界面会影响服务器性能) 1:已经上线的系统不用图形界面用什么?(cmdline arthas) 2:图形界面到底用在什么地方?测试!测试的时候进行监控!(压测观察)

    10.  jmap -histo 6892 | head -10,查找有多少对象产生

 

  1. 这明显能看出来是1对应的类创造的实例instances太多了,反过来追踪代码 

   11.   jmap -dump:format=b,file=xxx pid :

线上系统,内存特别大,jmap执行期间会对进程产生很大影响,甚至卡顿(电商不适合) 1:设定了参数HeapDump,OOM的时候会自动产生堆转储文件 2:很多服务器备份(高可用),停掉这台服务器对其他服务器不影响 3:在线定位(一般小点儿公司用不到) 

  1. [root@localhost ~]# jmap -dump:format=b,file=2021_2_8.dump 6892 
  2. Dumping heap to /root/2021_2_8.dump ... 
  3.  Heap dump file created 

dump文件存放位置:

 

   12.   java -Xms20M -Xmx20M -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError com.courage.jvm.gc.T15_FullGC_Problem01 上面的意思是当发生内存溢出时自动生成堆转储文件,需要注意的是,如果生成了这个文件先不要重启服务器,将这个文件保存好之后再重启。

    13.  使用MAT / jhat /jvisualvm 进行dump文件分析 

  1. [root@localhost ~]# jhat -J-Xmx512M 2021_2_8.dump 

报错:

原因是设置的堆最大值太小了,将512M设置成1024M重新启动即可: 

  1. ```shell  
  2. [root@localhost ~]# jhat -J-Xmx1024M 2021_2_8.dump  
  3. Reading from 2021_2_8.dump...  
  4. Dump file created Mon Feb 08 09:00:56 CST 2021  
  5. Snapshot read, resolving... 
  6. Resolving 4609885 objects...  
  7. Chasing references, expect 921 dots.......................................................... 
  8. .........................................................................................Eliminating duplicate references............................................................. 
  9. ......................................................................................Snapshot resolved. 
  10. Started HTTP server on port 7000  
  11. Server is ready.  
  12. ``` 
  13. 浏览器输入请求http://192.168.182.130:7000 即可查看,拉到最后:找到对应链接 可以使用OQL查找特定问题对象 

其他可以参考:白灰——软件测试

    14.  最后找到代码的问题

JVM调优工具

jconsole远程连接

    1.  程序启动加入参数:     

  1. java -Djava.rmi.server.hostname=192.168.182.130   
  2. -Dcom.sun.management.jmxremote   
  3. -Dcom.sun.management.jmxremote.port=11111   
  4. -Dcom.sun.management.jmxremote.authenticate=false  
  5. -Dcom.sun.management.jmxremote.ssl=false XXX 

    2.  如果遭遇 Local host name unknown:XXX的错误,修改/etc/hosts文件,把XXX加入进去   

  1. 192.168.182.130 basic localhost localhost.localdomain localhost4 localhost4.localdomain4  
  2. ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6 

    3.  关闭linux防火墙(实战中应该打开对应端口) 

  1. service iptables stop  
  2. chkconfig iptables off #永久关闭 

    4.  windows上打开 jconsole远程连接 192.168.182.130:11111

jvisualvm远程连接

这个软件在JDK8以后版本中移除了,使用的话需要额外下载,并且要在etc/visualvm.conf中修改默认的JDK_Home地址。参考:使用jvisualvm的jstatd方式远程监控Java程序

阿里巴巴Arthas

这个直接看官网就行了,纯中文:Arthas 用户文档

JVM调优案例

参数设置之承受海量访问的动态Web应用

服务器配置:8 核 CPU, 8G MEM, JDK 1.6.X

参数方案:-server -Xmx3550m -Xms3550m -Xmn1256m -Xss128k -XX:SurvivorRatio=6 -XX:MaxPermSize=256m -XX:ParallelGCThreads=8 -XX:MaxTenuringThreshold=0 -XX:+UseConcMarkSweepGC

调优说明:-Xmx 与 -Xms 相同以避免JVM反复重新申请内存。-Xmx 的大小约等于系统内存大小的一半,即充分利用系统资源,又给予系统安全运行的空间。-Xmn1256m 设置年轻代大小为1256MB。此值对系统性能影响较大,Sun官方推荐配置年轻代大小为整个堆的3/8。-Xss128k 设置较小的线程栈以支持创建更多的线程,支持海量访问,并提升系统性能。-XX:SurvivorRatio=6 设置年轻代中Eden区与Survivor区的比值。系统默认是8,根据经验设置为6,则2个Survivor区与1个Eden区的比值为2:6,一个Survivor区占整个年轻代的1/8。-XX:ParallelGCThreads=8 配置并行收集器的线程数,即同时8个线程一起进行垃圾回收。此值一般配置为与CPU数目相等。-XX:MaxTenuringThreshold=0 设置垃圾最大年龄(在年轻代的存活次数)。如果设置为0的话,则年轻代对象不经过Survivor区直接进入年老代。对于年老代比较多的应用,可以提高效率;如果将此值设置为一个较大值,则年轻代对象会在Survivor区进行多次复制,这样可以增加对象再年轻代的存活时间,增加在年轻代即被回收的概率。根据被海量访问的动态Web应用之特点,其内存要么被缓存起来以减少直接访问DB,要么被快速回收以支持高并发海量请求,因此其内存对象在年轻代存活多次意义不大,可以直接进入年老代,根据实际应用效果,在这里设置此值为0。-XX:+UseConcMarkSweepGC 设置年老代为并发收集。CMS(ConcMarkSweepGC)收集的目标是尽量减少应用的暂停时间,减少Full GC发生的几率,利用和应用程序线程并发的垃圾回收线程来标记清除年老代内存,适用于应用中存在比较多的长生命周期对象的情况。

参数设置之内部集成构建服务器

高性能数据处理的工具应用 服务器配置:1 核 CPU, 4G MEM, JDK 1.6.X 参数方案:-server -XX:PermSize=196m -XX:MaxPermSize=196m -Xmn320m -Xms768m -Xmx1024m 调优说明:-XX:PermSize=196m -XX:MaxPermSize=196m 根据集成构建的特点,大规模的系统编译可能需要加载大量的Java类到内存中,所以预先分配好大量的持久代内存是高效和必要的。-Xmn320m 遵循年轻代大小为整个堆的3/8原则。-Xms768m -Xmx1024m 根据系统大致能够承受的堆内存大小设置即可。 

 

责任编辑:庞桂玉 来源: java版web项目
相关推荐

2012-01-10 14:35:08

JavaJVM

2010-09-25 13:05:07

JVM参数

2010-09-26 13:48:51

JVM调优

2012-01-10 15:13:56

JavaJVM

2017-10-13 15:16:38

Java服务GC参数

2023-11-10 11:23:20

JVM内存

2010-03-04 10:56:52

JVM参数

2017-10-17 14:02:30

jvm调优工具

2019-12-20 14:21:26

JVM调优垃圾回收

2012-01-10 14:18:40

JavaJVM

2010-09-17 17:02:24

JVM参数

2012-01-09 16:02:19

JavaJVM

2012-01-09 16:53:36

JavaJVM

2017-07-21 08:55:13

TomcatJVM容器

2019-11-01 08:49:07

JVM监控性能

2023-02-10 09:28:23

优化工具

2023-11-11 19:07:23

JVMJava

2021-09-06 11:02:17

JVM架构调优

2012-01-09 17:06:16

JavaJVM

2012-01-10 11:19:35

JavaJVM
点赞
收藏

51CTO技术栈公众号