一、jvm简单结构图
1.1 、类加载子系统与方法区：
类加载子系统负责从文件系统或者网络中加载 Class 信息，加载的类信息存放于一块称为方法区的内存空间。除了类的信息外，方法区中可能还会存放运行时常量池信息，包括字符串字面量和数字常量（这部分常量信息是 Class 文件中常量池部分的内存映射）。
1.2、Java 堆
java 堆在虚拟机启动的时候建立，它是 java 程序最主要的内存工作区域。几乎所有的java 对象实例都存放在 java 堆中。堆空间是所有线程共享的，这是一块与 java 应用密切相关的内存空间。
1.3、直接内存
java 的 NIO 库允许 java 程序使用直接内存。直接内存是在 java 堆外的、直接向系统申请的内存空间。通常访问直接内存的速度会优于 java 堆。因此出于性能的考虑，读写频繁的场合可能会考虑使用直接内存。由于直接内存在 java 堆外，因此它的大小不会直接受限于 Xmx 指定的最大堆大小，但是系统内存是有限的，java 堆和直接内存的总和依然受限于操作系统能给出的最大内存。
1.4 、垃圾回收系统
垃圾回收系统是 java 虚拟机的重要组成部分，垃圾回收器可以对方法区、java 堆和直接内存进行回收。其中，java 堆是垃圾收集器的工作重点。和 C/C++不同，java 中所有的对象空间释放都是隐式的，也就是说，java 中没有类似 free()或者 delete()这样的函数释放指定的内存区域。对于不再使用的垃圾对象，垃圾回收系统会在后台默默工作，默默查找、标识并释放垃圾对象，完成包括 java 堆、方法区和直接内存中的全自动化管理。
1.5、Java 栈
每一个 java 虚拟机线程都有一个私有的 java 栈，一个线程的 java 栈在线程创建的时候被创建，java 栈中保存着帧信息，java 栈中保存着局部变量、方法参数，同时和 java 方法的调用、返回密切相关。
1.6、本地方法栈
本地方法栈和 java 栈非常类似，最大的不同在于 java 栈用于方法的调用，而本地方法栈则用于本地方法的调用，作为对 java 虚拟机的重要扩展，java 虚拟机允许 java 直接调用本地方法（通常使用 C 编写）
1.7、PC 寄存器
PC（Program Counter）寄存器也是每一个线程私有的空间，java 虚拟机会为每一个 java线程创建 PC 寄存器。在任意时刻，一个 java 线程总是在执行一个方法，这个正在被执行的方法称为当前方法。如果当前方法不是本地方法，PC 寄存器就会指向当前正在被执行的指令。如果当前方法是本地方法，那么 PC 寄存器的值就是 undefined
1.8 、执行引擎
执行引擎是 java 虚拟机的最核心组件之一，它负责执行虚拟机的字节码，现代虚拟机为了提高执行效率，会使用即时编译(just in time)技术将方法编译成机器码后再执行。
Java HotSpot Client VM(-client)，为在客户端环境中减少启动时间而优化的执行引擎；本地应用开发使用。（如：eclipse） Java HotSpot Server VM(-server)，为在服务器环境中最大化程序执行速度而设计的执行引擎。应用在服务端程序。（如：tomcat）
Java HotSpot Client 模式和 Server 模式的区别
当虚拟机运行在-client 模式的时候,使用的是一个代号为 C1 的轻量级编译器, 而-server模式启动的虚拟机采用相对重量级,代号为 C2 的编译器. C2 比 C1 编译器编译的相对彻底,服务起来之后,性能更高JDK 安装目录/jre/lib/（x86、i386、amd32、amd64）/jvm.cfg文件中的内容，-server 和-client 哪一个配置在上，执行引擎就是哪一个。如果是 JDK1.5版本且是 64 位系统应用时，-client 无效。
--64 位系统内容 -server KNOWN -client IGNORE
--32 位系统内容 -server KNOWN -client KNOWN
注意 ：在部分 JDK1.6 版本和后续的 JDK 版本 (64 位系统 ) 中， -client 参数已经不起作用了， Server 模式成为唯一
2、堆结构及对象分代
2.1、什么是分代，分代的必要性是什么
Java 虚拟机根据对象存活的周期不同，把堆内存划分为几块，一般分为新生代、老年代和永久代（对 HotSpot 虚拟机而言），这就是 JVM 的内存分代策略。堆内存是虚拟机管理的内存中最大的一块，也是垃圾回收最频繁的一块区域，我们程序所有的对象实例都存放在堆内存中。给堆内存分代是为了提高对象内存分配和垃圾回收的效率。试想一下，如果堆内存没有区域划分，所有的新创建的对象和生命周期很长的对象放在一起，随着程序的执行，堆内存需要频繁进行垃圾收集，而每次回收都要遍历所有的对象，遍历这些对象所花费的时间代价是巨大的，会严重影响我们的 GC 效率。
率。试想一下，如果堆内存没有区域划分，所有的新创建的对象和生命周期很长的对象放在 一起，随着程序的执行，堆内存需要频繁进行垃圾收集，而每次回收都要遍历所有的对象， 遍历这些对象所花费的时间代价是巨大的，会严重影响我们的 GC 效率。
有了内存分代，情况就不同了，新创建的对象会在新生代中分配内存，经过多次回收仍然存活下来的对象存放在老年代中，静态属性、类信息等存放在永久代中，新生代中的对象存活时间短，只需要在新生代区域中频繁进行 GC，老年代中对象生命周期长，内存回收的频率相对较低，不需要频繁进行回收，永久代中回收效果太差，一般不进行垃圾回收，还可以根据不同年代的特点采用合适的垃圾收集算法。分代收集大大提升了收集效率，这些都是 内存分代带来的好处
2.2、分代的划分
Java 虚拟机将堆内存划分为 新生代、老年代和永久代 ，永久代是 HotSpot 虚拟机特有的概念（JDK1.8 之后为 metaspace 替代永久代），它采用永久代的方式来实现方法区，其他的虚拟机实现没有这一概念，而且 HotSpot 也有取消永久代的趋势，在 JDK 1.7 中 HotSpot 已经开始了“去永久化”，把原本放在永久代的字符串常量池移出。永久代主要存放常量、类信息、静态变量等数据，与垃圾回收关系不大，新生代和老年代是垃圾回收的主要区域。 内存简图如下：
2.2.1 、新生代（Young Generation ）
新生成的对象优先存放在新生代中，新生代对象朝生夕死，存活率很低，在新生代中，常规应用进行一次垃圾收集一般可以回收 70% ~ 95% 的空间，回收效率很高。
HotSpot 将新生代划分为三块，一块较大的 Eden（伊甸）空间和两块较小的 Survivor（幸存者）空间，默认比为8：1：1。划分的目的是因为 HotSpot 采用复制算法来回收新生代，设置这个比例是为了充分利用内存空间，减少浪费。新生成的对象在 Eden 区分配（大对象除外，大对象直接进入老年代），当 Eden 区没有足够的空间进行分配时，虚拟机将发起一次Minor GC。
GC 开始时，对象只会存在于 Eden 区和 From Survivor 区，To Survivor 区是空的（作为保留区域）。GC 进行时，Eden 区中所有存活的对象都会被复制到 To Survivor 区，而在 FromSurvivor 区中，仍存活的对象会根据它们的年龄值决定去向，年龄值达到年龄阀值（默认为15，新生代中的对象每熬过一轮垃圾回收，年龄值就加 1，GC 分代年龄存储在对象的 header中）的对象会被移到老年代中，没有达到阀值的对象会被复制到 To Survivor 区。接着清空Eden 区和 From Survivor 区，新生代中存活的对象都在 To Survivor 区。接着， From Survivor 区和 To Survivor 区会交换它们的角色，也就是新的 To Survivor 区就是上次 GC 清空的 FromSurvivor 区，新的 From Survivor 区就是上次 GC 的 To Survivor 区，总之，不管怎样都会保证To Survivor 区在一轮 GC 后是空的。GC 时当 To Survivor 区没有足够的空间存放上一次新生代收集下来的存活对象时，需要依赖老年代进行分配担保，将这些对象存放在老年代中。
2.2.2 、老年代（Old Generationn ）
在新生代中经历了多次（具体看虚拟机配置的阀值）GC 后仍然存活下来的对象会进入老年代中。老年代中的对象生命周期较长，存活率比较高，在老年代中进行 GC 的频率相对而言较低，而且回收的速度也比较慢。
2.2.3 、永久代（Permanent Generationn ）
永久代存储类信息、常量、静态变量、即时编译器编译后的代码等数据，对这一区域而言，Java 虚拟机规范指出可以不进行垃圾收集，一般而言不会进行垃圾回收。
3、垃圾回收算法及分代垃圾
3.1、垃圾收集器的分类
3.1.1、次收集器
Scavenge GC，指发生在新生代的 GC，因为新生代的 Java 对象大多都是朝生夕死，所以Scavenge GC 非常频繁，一般回收速度也比较快。当 Eden 空间不足以为对象分配内存时，会触发 Scavenge GC。
一般情况下，当新对象生成，并且在 Eden 申请空间失败时，就会触发 Scavenge GC，对Eden 区域进行 GC，清除非存活对象，并且把尚且存活的对象移动到 Survivor 区。然后整理Survivor 的两个区。这种方式的 GC 是对年轻代的 Eden 区进行，不会影响到年老代。因为大部分对象都是从 Eden 区开始的，同时 Eden 区不会分配的很大，所以 Eden 区的 GC 会频繁进行。因而，一般在这里需要使用速度快、效率高的算法，使 Eden 去能尽快空闲出来。
当年轻代堆空间紧张时会被触发
相对于全收集而言，收集间隔较短
3.1.2 、全收集器
Full GC，指发生在老年代的 GC，出现了 Full GC 一般会伴随着至少一次的 Minor GC（老年代的对象大部分是 Scavenge GC 过程中从新生代进入老年代），比如：分配担保失败。FullGC 的速度一般会比 Scavenge GC 慢 10 倍以上。当老年代内存不足或者显式调用 System.gc()方法时，会触发 Full GC。
当老年代或者持久代堆空间满了，会触发全收集操作 可以使用 System.gc()方法来显式的启动全收集 全收集一般根据堆大小的不同，需要的时间不尽相同，但一般会比较长。
3.1.3、垃圾回收器的常规匹配
3.2 、常见垃圾回收算法
3.2.1、引用计数 （Reference Counting ）
比较古老的回收算法。原理是此对象有一个引用，即增加一个计数，删除一个引用则减少一个计数。垃圾回收时，只用收集计数为 0 的对象。此算法最致命的是无法处理循环引用的问题。
3.2.2 、复制（Copying ）
此算法把内存空间划为两个相等的区域，每次只使用其中一个区域。垃圾回收时，遍历当前使用区域，把正在使用中的对象复制到另外一个区域中。此算法每次只处理正在使用中的对象，因此复制成本比较小，同时复制过去以后还能进行相应的内存整理，不会出现“碎片”问题。当然，此算法的缺点也是很明显的，就是需要两倍内存空间。简图如下：
3.2.3 、标记- 清除（Mark-Sweep ）
此算法执行分两阶段。第一阶段从引用根节点开始标记所有被引用的对象，第二阶段遍历整个堆，把未标记的对象清除。此算法需要暂停整个应用，同时，会产生内存碎片。简图如下：
3.2.4 、标记- 整理（Mark-Compact ）
此算法结合了**“标记-清除”和“复制”**两个算法的优点。也是分两阶段，第一阶段从根节点开始标记所有被引用对象，第二阶段遍历整个堆，把清除未标记对象并且把存活对象“压缩”到堆的其中一块，按顺序排放。此算法避免了“标记-清除”的碎片问题，同时也避免了“复制”算法的空间问题。简图如下：
3.3、分代垃圾收集器
3.3.1 、串行收集器（Serial ）
Serial 收集器是 Hotspot 运行在 Client 模式下的默认新生代收集器, 它的特点是：只用一个 CPU（计算核心）/一条收集线程去完成 GC 工作, 且在进行垃圾收集时必须暂停其他所有的工作线程(“Stop The World” -后面简称 STW)。可以使用-XX:+UseSerialGC 打开。
虽然是单线程收集, 但它却简单而高效, 在 VM 管理内存不大的情况下(收集几十 M~一两百 M 的新生代), 停顿时间完全可以控制在几十毫秒~一百多毫秒内。
3.3.2 、并行收集器（ParNew ）
ParNew 收集器其实是前面 Serial 的多线程版本, 除使用多条线程进行 GC外, 包括 Serial可用的所有控制参数、收集算法、STW、对象分配规则、回收策略等都与 Serial 完全一样(也是 VM 启用 CMS 收集器-XX: +UseConcMarkSweepGC 的默认新生代收集器)。
由于存在线程切换的开销, ParNew 在单 CPU 的环境中比不上 Serial, 且在通过超线程技术实现的两个 CPU 的环境中也不能 100%保证能超越 Serial. 但随着可用的 CPU 数量的增加,收集效率肯定也会大大增加(ParNew 收集线程数与 CPU 的数量相同, 因此在 CPU 数量过大的环境中, 可用-XX:ParallelGCThreads=参数控制 GC 线程数)。
3.3.3、Parallel Scavenge 收集器
与 ParNew 类似, Parallel Scavenge 也是使用复制算法, 也是并行多线程收集器. 但与其他收集器关注尽可能缩短垃圾收集时间不同, Parallel Scavenge 更关注系统吞吐量:
系统吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)
停顿时间越短就越适用于用户交互的程序-良好的响应速度能提升用户的体验;而高吞吐量则适用于后台运算而不需要太多交互的任务-可以最高效率地利用CPU时间,尽快地完成程序的运算任务. Parallel Scavenge 提供了如下参数设置系统吞吐量:
3.3.4、Serial Old 收集器
Serial Old 是 Serial 收集器的老年代版本, 同样是单线程收集器,使用“标记-整理”算法
3.3.5、Parallel Old 收集器
Parallel Old 是 Parallel Scavenge 收集器的老年代版本, 使用多线程和“标记－整理”算法, 吞吐量优先, 主要与 Parallel Scavenge 配合在注重吞吐量及 CPU 资源敏感系统内使用；
3.3.6、CMS 收集器 （Concurrent Mark Sweep）
CMS(Concurrent Mark Sweep)收集器是一款具有划时代意义的收集器, 一款真正意义上的并发收集器, 虽然现在已经有了理论意义上表现更好的 G1 收集器, 但现在主流互联网企业线上选用的仍是 CMS(如 Taobao、微店).
CMS是一种以获取最短回收停顿时间为目标的收集器(CMS又称多并发低暂停的收集器),基于”标记-清除”算法实现, 整个 GC 过程分为以下 4 个步骤:
- 初始标记(CMS initial mark)
- 并发标记(CMS concurrent mark: GC Roots Tracing 过程)
- 重新标记(CMS remark)
- 并发清除(CMS concurrent sweep: 已死对象将会就地释放, 注意:此处没有压缩)
其中 1，3 两个步骤(初始标记、重新标记)仍需 STW. 但初始标记仅只标记一下 GC Roots能直接关联到的对象, 速度很快; 而重新标记则是为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录, 虽然一般比初始标记阶段稍长, 但要远小于并发标记时间.
CMS 特点：
- CMS 默认启动的回收线程数=(CPU 数目+3)4 当 CPU 数>4 时, GC线程一般占用不超过 25%的 CPU 资源, 但是当 CPU 数<=4 时, GC线程可能就会过多的占用用户 CPU 资源, 从而导致应用程序变慢, 总吞吐量降低.
- 无法处理浮动垃圾, 可能出现 Promotion Failure、Concurrent Mode Failure 而导致另一次 Full GC 的产生: 浮动垃圾是指在 CMS 并发清理阶段用户线程运行而产生的新垃圾. 由于在 GC 阶段用户线程还需运行, 因此还需要预留足够的内存空间给用户线程使用, 导致 CMS不 能 像 其 他收 集 器那 样 等到 老 年 代几 乎 填满 了 再进 行 收 集. 因此 CMS 提 供 了-XX:CMSInitiatingOccupancyFraction 参 数 来 设 置 GC 的 触 发 百 分 比 ( 以 及-XX:+UseCMSInitiatingOccupancyOnly 来启用该触发百分比), 当老年代的使用空间超过该比例后 CMS 就会被触发(JDK 1.6 之后默认 92%). 但当 CMS 运行期间预留的内存无法满足程序需要, 就会出现上述 Promotion Failure 等失败, 这时 VM 将启动后备预案: 临时启用 Serial Old收集器来重新执行Full GC(CMS通常配合大内存使用, 一旦大内存转入串行的Serial GC, 那停顿的时间就是大家都不愿看到的了).
- 最后, 由于 CMS 采用”标记-清除”算法实现, 可能会产生大量内存碎片. 内存碎片过多 可 能 会 导 致 无 法 分 配 大 对 象 而 提 前 触 发 Full GC. 因 此 CMS 提 供 了-XX:+UseCMSCompactAtFullCollection 开关参数, 用于在 Full GC 后再执行一个碎片整理过程.但内存整理是无法并发的, 内存碎片问题虽然没有了, 但停顿时间也因此变长了, 因此 CMS还提供了另外一个参数-XX:CMSFullGCsBeforeCompaction 用于设置在执行 N 次不进行内存整理的 Full GC 后, 跟着来一次带整理的(默认为 0: 每次进入 Full GC 时都进行碎片整理).
3.3.7 、分区收集- G1
G1(Garbage-First)是一款面向服务端应用的收集器, 主要目标用于配备多颗 CPU 的服务器治理大内存. -G1 is planned as the long term replacement for the Concurrent Mark-Sweep Collector(CMS).
-XX:+UseG1GC 启用 G1 收集器.
与其他基于分代的收集器不同, G1 将整个 Java 堆划分为多个大小相等的独立区域(Region), 虽然还保留有新生代和老年代的概念, 但新生代和老年代不再是物理隔离的了,它们都是一部分 Region(不需要连续)的集合.如：
每块区域既有可能属于 O 区、也有可能是 Y 区, 因此不需要一次就对整个老年代/新生代回收. 而是当线程并发寻找可回收的对象时, 有些区块包含可回收的对象要比其他区块多很多. 虽然在清理这些区块时 G1 仍然需要暂停应用线程, 但可以用相对较少的时间优先回收垃圾较多的 Region. 这种方式保证了 G1 可以在有限的时间内获取尽可能高的收集效率.
G1的新生代收集跟ParNew类似: 存活的对象被转移到一个/多个Survivor Regions. 如果存活时间达到阀值, 这部分对象就会被提升到老年代.如图：
G1 老年代 GC 特点如下 : 并发标记阶段 1 在与应用程序并发执行的过程中会计算活跃度信息 . 2 这些活跃度信息标识出那些 regions 最适合在 STW 期间回收 (which regions will be best to reclaim during an evacuation pause).
3 不像 CMS 有清理阶段 .
再次标记阶段
1 使用 Snapshot-at-the-Beginning(SATB) 算法比 CMS 快得多 .
2 空 region 直接被回收 .
拷贝 / 清理阶段 (Copying/Cleanup Phase)
1 年轻代与老年代同时回收 .
2 老年代内存回收会基于他的活跃度信息
4、JVM 优化
4.1、JDK 常用jvm优化相关命令
4.1.1、jps
jps - l 显示线程 id 和执行线程的主类名 jps -v 显示线程 id 和执行线程的主类名和 JVM 配置信息
4.1.2 、stat
jstat -参数 线程 id 执行时间（单位毫秒） 执行次数 jstat -gc 4488 30 10
SXC - survivor 初始空间大小，单位字节。 SXU - survivor 使用空间大小， 单位字节。 EC - eden 初始空间大小 EU - eden 使用空间大小 OC - old 初始空间大小 OU - old 使用空间大小 PC - permanent 初始空间大小 PU - permanent 使用空间大小 YGC - youngGC 收集次数 YGCT - youngGC 收集使用时长， 单位秒 FGC - fullGC 收集次数 FGCT - fullGC 收集使用时长 GCT - 总计收集使用总时长 YGCT+FGCT
4.1.3、jvisualvm
一个 JDK 内置的图形化 VM 监视管理工具
4.1.4 、visualgc 插件
重启 jvisualvm 工具
