关于jvm的常识介绍
1.关于jvm的组成（只介绍1.8，以前的版本不多介绍）
vm stack,native method stack,program counter register,heap,metaspace
2.关于jvm各个区域介绍
1..vm stack:是为每个线程私有，生命周期与线程相同，其中stack frame是用与支持虚拟机进行方法调用和方法执行的数据结构
栈帧存储了方法的局部变量表、操作数栈、动态连接和方法返回地址等信息。每一个方法从调用至执行完成的过程，都对应着一个栈帧在虚拟机栈里从入栈到出栈的过程。
2.native method stack:与vm stack作用相似,区别是它底层实现用于其他语言实现的。
3.program counter register:为线程私有，占用内存小，程序计数器的作用可以看做是当前线程所执行的字节码的行号指示器，字节码解释器工作时就是通过改变计数器的值来选取下一条字节码指令。其中，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖计数器来完成。
4.heap:由新生代和老年代组成，其中新生代由eden,from survivor(s0),to survivor(s1)组成,是主要存储java对象的地方
5，metaspace:主要取代以前java版本中的方法区：且元空间不在与堆相连,而是直接存在与本地内存.
为什么永久代会被元空间取代：表面上看是为了避免OOM异常。因为通常使用PermSize和MaxPermSize设置永久代的大小就决定了永久代的上限，但是不是总能知道应该设置为多大合适, 如果使用默认值很容易遇到OOM错误。
当使用元空间时，可以加载多少类的元数据就不再由MaxPermSize控制, 而由系统的实际可用空间来控制。
其实是：更深层的原因还是要合并HotSpot和JRockit的代码，JRockit从来没有所谓的永久代，也不需要开发运维人员设置永久代的大小，
但是运行良好。同时也不用担心运行性能问题了,在覆盖到的测试中, 程序启动和运行速度降低不超过1%，但是这点性能损失换来了更大的安全保障。其实是一种综合方面考虑优化。
3.关于jvm一些参数介绍
其实vm的参数主要分为3中：-,-x,-xx,标参，非标，非stable参数。
标参：主要是每种jvm都必须实现的参数功能，且向后兼容，
其实有很多，eg：java -version ，java -jar，
主要介绍：
-client
以client模式启动JVM，这种方式启动速度快，但运行时性能和内存管理效率不高，适合客户端程序或者开发调试。
-server
以server模式启动JVM，与client情况恰好相反。适合生产环境，适用于服务器。64位的JVM自动以server模式启动。
-verbose
查询GC问题最常用的命令之一，参数如下：
java -verbose:gc(输出每次gc的相关情况)
java -verbose:class(输出JVM载入类的相关信息，当JVM报告说找不到类或者类冲突时可此进行诊断。)
非标：（默认jvm实现这些参数功能，但不保证所有jvm都实现，且不保证向后兼容）
-Xmn:新生代内存大小的最大值，包括E区和两个S区的总和。eg -Xmn1g
-Xms:初始堆的大小，也是堆大小的最小值，默认值是总共的物理内存/64（且小于1G）。默认情况下，当堆中可用内存小于40%，堆内存会开始增加，一直增加到-Xmx的大小。
-Xmx:堆的最大值，默认值是总共的物理内存/64（且小于1G），默认情况下，当堆中可用内存大于70%，堆内存会开始减少，一直减小到-Xms的大小。
因此，为了避免这种浮动，所以在设置-Xms和-Xmx参数时，一般会设置成一样的，能够提高性能。
官方默认配置old:young=2:1,-XX:New-Ratio可以设置老年代与新生代的比例，eg：-XX:NewRatio=4
-Xss：设置每个线程的栈内存，默认1M，一般来说是不需要改的。
-Xprof:跟踪正运行的程序，并将跟踪数据在标准输出输出；适合于开发环境调试。
-Xnoclassgc:禁用类垃圾收集,关闭针对class的gc功能；因为其阻止内存回收，所以可能会导致OutOfMemoryError错误，慎用。
-Xloggc:file:与-verbose:gc功能类似，只是将每次GC事件的相关情况记录到一个文件中，文件的位置最好在本地，以避免网络的潜在问题。
若与verbose命令同时出现在命令行中，则以-Xloggc为准。
非stable参数:此类参数各个JVM实现会有所不同，将来可能会随时取消，需要慎重使用。
这类参数你一看官网以为不能使用呢，官网给你的建议就是这些参数不稳定，慎用，其实这主要的原因还是因为每个公司的实现都是不一样的，所以就是导致不稳定。但是呢，在实际的使用中却是非常的多的，而且这部分的参数很重要。
主要是：Performance Options，Behavioral Options，Debugging Options3类参数
由于sun官方文档中对各参数的描述也都非常少（大多只有一句话），而且大多涉及OS层面的东西，很难描述清楚，所以以下是挑选了一些我们开发中可能会用得比较多的配置项，若需要查看所有参数列表，可以点击HotSpot VM Specific Options.查看原文；
| 参数及其默认值 | 描述 |
| -XX:-DisableExplicitGC | 禁止调用System.gc()；但jvm的gc仍然有效 |
| -XX:+MaxFDLimit | 最大化文件描述符的数量限制 |
| -XX:+ScavengeBeforeFullGC | 新生代GC优先于Full GC执行 |
| -XX:+UseGCOverheadLimit | 在抛出OOM之前限制jvm耗费在GC上的时间比例 |
| -XX:-UseConcMarkSweepGC | 对老生代采用并发标记交换算法进行GC |
| -XX:-UseParallelGC | 启用并行GC |
| -XX:-UseParallelOldGC | 对Full GC启用并行，当-XX:-UseParallelGC启用时该项自动启用 |
| -XX:-UseSerialGC | 启用串行GC |
| -XX:+UseThreadPriorities | 启用本地线程优先级 |
性能调优参数列表：
| 参数及其默认值 | 描述 |
| -XX:LargePageSizeInBytes=4m | 设置用于Java堆的大页面尺寸 |
| -XX:MaxHeapFreeRatio=70 | GC后java堆中空闲量占的最大比例 |
| -XX:MaxNewSize=size | 新生成对象能占用内存的最大值 |
| -XX:MaxPermSize=64m | 老生代对象能占用内存的最大值 |
| -XX:MinHeapFreeRatio=40 | GC后java堆中空闲量占的最小比例 |
| -XX:NewRatio=2 | 新生代内存容量与老生代内存容量的比例 |
| -XX:NewSize=2.125m | 新生代对象生成时占用内存的默认值 |
| -XX:ReservedCodeCacheSize=32m | 保留代码占用的内存容量 |
| -XX:ThreadStackSize=512 | 设置线程栈大小，若为0则使用系统默认值 |
| -XX:+UseLargePages | 使用大页面内存 |
调试参数列表：
| 参数及其默认值 | 描述 |
| -XX:-CITime | 打印消耗在JIT编译的时间 |
| -XX:ErrorFile=./hs_err_pid<pid>.log | 保存错误日志或者数据到文件中 |
| -XX:-ExtendedDTraceProbes | 开启solaris特有的dtrace探针 |
| -XX:HeapDumpPath=./java_pid<pid>.hprof | 指定导出堆信息时的路径或文件名 |
| -XX:-HeapDumpOnOutOfMemoryError | 当首次遭遇OOM时导出此时堆中相关信息 |
| -XX:OnError="<cmd args>;<cmd args>" | 出现致命ERROR之后运行自定义命令 |
| -XX:OnOutOfMemoryError="<cmd args>;<cmd args>" | 当首次遭遇OOM时执行自定义命令 |
| -XX:-PrintClassHistogram | 遇到Ctrl-Break后打印类实例的柱状信息，与jmap -histo功能相同 |
| -XX:-PrintConcurrentLocks | 遇到Ctrl-Break后打印并发锁的相关信息，与jstack -l功能相同 |
| -XX:-PrintCommandLineFlags | 打印在命令行中出现过的标记 |
| -XX:-PrintCompilation | 当一个方法被编译时打印相关信息 |
| -XX:-PrintGC | 每次GC时打印相关信息 |
| -XX:-PrintGC Details | 每次GC时打印详细信息 |
| -XX:-PrintGCTimeStamps | 打印每次GC的时间戳 |
| -XX:-TraceClassLoading | 跟踪类的加载信息 |
| -XX:-TraceClassLoadingPreorder | 跟踪被引用到的所有类的加载信息 |
| -XX:-TraceClassResolution | 跟踪常量池 |
| -XX:-TraceClassUnloading | 跟踪类的卸载信息 |
| -XX:-TraceLoaderConstraints | 跟踪类加载器约束的相关信息 |
4.简单一些jvm优化处理
不废话：
第一步，肯定要打印相关日志，不然都是白扯
第二步：根据相关jvm监测工具，查看jvm内存的变化情况，，最好将服务器log打印到文件，然后下载到本地。
第三部: 根据文件分析,在结合代码分析。该加内存加内存，该优化就优化。该单例的单例，需要关闭流的关闭等等。
5.关于一些方便查看jvm内存使用情况的工具，及其简单介绍。
这个讲的不错，适合入门https://www.cnblogs.com/dhcn/p/7120717.html
