===============
1.监控 GC 的状态
使用各种 JVM 工具，查看当前日志，分析当前 JVM 参数设置，并且分析当前堆内存快照和 gc 日志，根据实际的各区域内存划分和 GC 执行时间，觉得是否进行优化。
举一个例子： 系统崩溃前的一些现象：
-
每次垃圾回收的时间越来越长，由之前的 10ms 延长到 50ms 左右，FullGC 的时间也有之前的 0.5s 延长到 4、5s
-
FullGC 的次数越来越多，最频繁时隔不到 1 分钟就进行一次 FullGC
-
年老代的内存越来越大并且每次 FullGC 后年老代没有内存被释放
之后系统会无法响应新的请求，逐渐到达 OutOfMemoryError 的临界值，这个时候就需要分析 JVM 内存快照 dump。
2.生成堆的 dump 文件
通过 JMX 的 MBean 生成当前的 Heap 信息，大小为一个 3G（整个堆的大小）的 hprof 文件，如果没有启动 JMX 可以通过 Java 的 jmap 命令来生成该文件。
3.分析 dump 文件
打开这个 3G 的堆信息文件，显然一般的 Window 系统没有这么大的内存，必须借助高配置的 Linux，几种工具打开该文件：
-
Visual VM
-
IBM HeapAnalyzer
-
JDK 自带的 Hprof 工具
-
Mat(Eclipse 专门的静态内存分析工具)推荐使用
备注：文件太大，建议使用 Eclipse 专门的静态内存分析工具 Mat 打开分析。
4.分析结果，判断是否需要优化
如果各项参数设置合理，系统没有超时日志出现，GC 频率不高，GC 耗时不高，那么没有必要进行 GC 优化，如果 GC 时间超过 1-3 秒，或者频繁 GC，则必须优化。
注：如果满足下面的指标，则一般不需要进行 GC：
-
Minor GC 执行时间不到 50ms；
-
Minor GC 执行不频繁，约 10 秒一次；
-
Full GC 执行时间不到 1s；
-
Full GC 执行频率不算频繁，不低于 10 分钟 1 次；
5.调整 GC 类型和内存分配
如果内存分配过大或过小，或者采用的 GC 收集器比较慢，则应该优先调整这些参数，并且先找 1 台或几台机器进行 beta，然后比较优化过的机器和没有优化的机器的性能对比，并有针对性的做出最后选择。
6.不断的分析和调整
通过不断的试验和试错，分析并找到最合适的参数，如果找到了最合适的参数，则将这些参数应用到所有服务器。
三，阿里关于 jvm 性能调优的面试真题：
=====================
-
java 类加载过程
-
java 内存分配
-
描述一下 jvm 加载 class 文件的原理机制？
-
GC 是什么？为什么要有 GC？
-
如何判断一个对象是否存活？
-
垃圾回收的优点和原理。并考虑两种回收机制。
-
java 中会存在内存泄漏吗，请简单阐述
-
JVM 的永久带中会发生垃圾回收吗？
-
java 中垃圾收集的方法有哪些
解析不在这里一一给大家展示出来了，为了 《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》无偿开源 威信搜索公众号【编程进阶路】 准备面试收集了很多大厂的面试真题，包括有性能优化，微服务，并发编程，开源框架，分布式等专题。
jvm 性能调优学习笔记：
=============
