jvm|超赞！不愧是美团内部的JVM学习手册，从头到尾全是精华( 二 ) Java|生命周期|美团

打开我们保存的文件目录进行分析。
分析结果。
此时可以查看详情查看具体原因，当然这个原因也只是一种猜想。
五、JDK提供的一些工具
所有的工具都在jdk的安装bin目录下，比如我的在C:\\My Program Files\\Java\\jdk1.8.0_201\\bin 。
其中一般情况命令行在线上服务器上使用，可视化工具在本地使用，当然如果你的线上服务器允许远程的话也可以使用可视化工具。
六、GC调优1. GC调优重要参数
生产环境推荐开启
-XX:+HeapDumpOnOutOfMemoryError

输出内存溢出文件

-XX:HeapDumpPath=D:/oomDump/dump.hprof

内存溢出文件保存位置，此文件用于MAT分析

当然，一般Linux服务器可以设置为 ./java_pid<pid>.hprof 默认为Java进程启动位置

调优之前开始，调优之后关闭
-XX:+PrintGC

调试跟踪之打印简单的 GC 信息参数:

-XX:+PrintGCDetails和-XX:+PrintGCTimeStamps

打印详细的 GC 信息

-Xlogger:logpath:log/gc.log

设置 gc 的日志
路，将 gc.log 的路径设置到当前目录的 log 目录下. 应用场景：将 gc 的日志独立写入日志文件，将 GC 日志与系统业务日志进行了分离，方便开发人员进行追踪分析

考虑使用
-XX:+PrintHeapAtGC

打印
推信息，获取 Heap 在每次垃圾回收前后的使用状况

-XX:+TraceClassLoading

在系统控制台信息中看到 class 加载的过程和具体的 class 信息，可用以分析类的加载顺序以及是否可进行精简操作

-XX:+DisableExplicitGC

禁止在运行期显式地调用 System.gc()

2. GC调优的原则（很重要）

大多数的 java 应用不需要 GC 调优
大部分需要 GC 调优的的，不是参数问题，是代码问题
在实际使用中，分析 GC 情况优化代码比优化 GC 参数要多得多
GC 调优是最后的手段

调优的目的

GC 的时间够小
GC 的次数
够少发生
Full GC 的周期足够的长，时间合理，最好是不发生

注：如果满足下面的指标，则一般不需要进行 GC调优

Minor GC 执行时间不到 50ms
Minor GC 执行不频繁，约 10 秒一次
Full GC 执行时间不到 1s
Full GC 执行频率不算频繁，不低于 10 分钟 1 次

3. GC调优步骤
1、监控 GC 的状态使用各种 JVM 工具，查看当前日志，分析当前 JVM 参数设置，并且分析当前堆内存快照和 gc 日志，根据实际的各区域内存划分和 GC 执行时间，觉得是否进行优化。
2、分析结果，判断是否需要优化如果各项参数设置合理。
系统没有超时日志出现， GC 频率不高， GC 耗时不高，那么没有必要进行 GC 优化。
如果 GC 时间超过 1 秒，或者频繁 GC ，则必须优化。
3、调整 GC 类型和内存分配如果内存分配过大或过小，或者采用的 GC 收集器比较慢，则应该优先调整这些参数，并且先找 1 台或几台机器进行测试，然后比较优化过的机器和没有优化的机器的性能对比，并有针对性的做出最后选择。
4、不断的分析和调整通过不断的试验和试错，分析并找到最合适的参数5 ，全面应用参数如果找到了最合适的参数，则将这些参数应用到所有服务器，并进行后续跟踪。
分析GC日志
主要关注 MinorGC 和 FullGC 的回收效率（回收前大小和回收比较）、回收的时间。
1、-XX:+UseSerialGC

以参数-Xms5m -Xmx5m -XX:+PrintGCDetails -XX:+UseSerialGC 为例详细说明。
[DefNew: 1855K->1855K(1856K) 0.0000148 secs
[Tenured: 2815K->4095K(4096K) 0.0134819 secs
4671K 。
DefNew 指明了收集器类型，而且说明了收集发生在新生代。
1855K->1855K(1856K)表示，回收前新生代占用 1855K ，回收后占用 1855K ，新生代大小 1856K
0.0000148 secs 表明新生代回收耗时。
- 上一页
- 1
- 2
- 3
- 下一页