java虚拟机个人心得

一、虚拟机版本

在JDK不同的版本的时候，jvm的版是不同的，JDK 1.4之后，就是 HotSpot VM（目前使用范围最广的Java 虚拟机），

查看JDK版本和虚拟机的内在构造情况，使用的命令是java -version

查看虚拟机的垃圾回收版本是那个？

java -XX:+PrintCommandLineFlags -version

二、运行时数据区域

1.定义：
Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域：

1. 线程私有区域：

• 程序计数器
• 虚拟机栈
• 本地方法栈

2. 线程公共区域：

• Java堆
• 方法区（运行时常量池）
• 直接内存

三、各个区域的作用

1. 线程私有区域：

• 程序计数器（唯一没有内存溢出的区域）
  较小的内存空间，当前线程执行的字节 码的行号指示器；各线程之间独立存储，互不影响；
  每个线程都有自己的程序计数器。倘若当前执行的是 JVM 的方法，则该寄存器中保存当前执行指令的地址；倘若执行的是native 方法，则PC寄存器中为空。
• 虚拟机栈
  线程私有，生命周期同线程生命周期一样，栈里面存着的是一种叫“栈帧”的东西，每个方法会创建一个栈帧，栈帧中存放了局部变量表（基本数据类型和对象引用）、操作数栈、方法出口等信息。栈的大小可以固定也可以动态扩展。当栈调用深度大于JVM所允许的范围，会抛出StackOverflowError的错误，不过这个深度范围不是一个恒定的值（要是想要明白的话，就需要深入到 JVM 的源码中才能探讨）；
  还有一个是需要注意的：虚拟机栈除了上述错误外，还有另一种错误，那就是当申请不到空间时，会抛出 OutOfMemoryError。这里有一个小细节需要注意，catch 捕获的是 Throwable，而不是 Exception。因为 StackOverflowError 和 OutOfMemoryError 都不属于 Exception 的子类。
• 本地方法栈
  本地方法栈保存的是native方法的信息， 当一个JVM创建的线程调用native方法后，JVM不再为 其在虚拟机栈中创建栈帧，JVM只是简单地动态链接 并直接调用native方法；

2. 线程共享区域：

• 堆

• 方法区（非堆、元空间）（JDK >= 8:元空间 ；JDK<=7 方法区）
  　　从上述结果可以看出，JDK 1.6下，会出现“PermGen Space”的内存溢出，而在 JDK 1.7和 JDK 1.8 中，会出现堆内存溢出，并且 JDK 1.8中 PermSize 和 MaxPermGen 已经无效。因此，可以大致验证 JDK 1.7 和 1.8 将字符串常量由永久代转移到堆中，并且 JDK 1.8 中已经不存在永久代的结论。现在我们看看元空间到底是一个什么东西？
  　　元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制，但可以通过以下参数来指定元空间的大小：
  　　-XX:MetaspaceSize，初始空间大小，达到该值就会触发垃圾收集进行类型卸载，同时GC会对该值进行调整：如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提高该值。
  　　 -XX:MaxMetaspaceSize，最大空间，默认是没有限制的。
  除了上面两个指定大小的选项以外，还有两个与 GC 相关的属性：
  　　-XX:MinMetaspaceFreeRatio，在GC之后，最小的Metaspace剩余空间容量的百分比，减少为分配空间所导致的垃圾收集
  　　-XX:MaxMetaspaceFreeRatio，在GC之后，最大的Metaspace剩余空间容量的百分比，减少为释放空间所导致的垃圾收集

• 总结方法区和元空间的：
  　　通过上面分析，大家应该大致了解了 JVM 的内存划分，也清楚了 JDK 8 中永久代向元空间的转换。不过大家应该都有一个疑问，就是为什么要做这个转换？所以，最后给大家总结以下几点原因：
  　　1、字符串存在永久代中，容易出现性能问题和内存溢出。
  　　2、类及方法的信息等比较难确定其大小，因此对于永久代的大小指定比较困难，太小容易出现永久代溢出，太大则容易导致老年代溢出。
  　　3、永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。
  　　4、Oracle 可能会将HotSpot 与 JRockit 合二为一。

四、虚拟机中的对象

• 第一部分用于存储对象自身的运行时数据，如哈希码（HashCode）、GC 分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳、对象分代年龄，这部分信息称为“Mark Word”；Mark Word 被设计成一个非固定的数据结构以便在极小的空间内存储尽量多的信息，它会根据自己的状态复用自己的存储空间。
• 第二部分是类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例；
• 如果对象是一个 Java 数组，那在对象头中还必须有一块用于记录数组长度的数据。因为虚拟机可以通过普通 Java 对象的元数据信息确定 Java 对象的大小，但是从数组的元数据中无法确定数组的大小。
• 实例数据部分是对象真正存储的有效信息，也是在程序代码中所定义的各种类型的字段内容。
• 对齐填充不是必然存在的，没有特别的含义，它仅起到占位符的作用。
  由于 HotSpot VM 的自动内存管理系统要求对象起始地址必须是 8 字节的整数倍，也就是说对象的大小必须是 8 字节的整数倍。对象头部分是 8 字节的倍数，所以当对象实例数据部分没有对齐时，就需要通过对齐填充来补全。
  

五、垃圾收集器与内存分配策略

1. 判断对象的存活

• 引用计数算法（看该对象有没有被其他的对象引用）
• 可达性分析
  在Java, 可作为GC Roots的对象包括:
  1.方法区: 类静态属性引用的对象;
  2.方法区: 常量引用的对象;
  3.虚拟机栈(本地变量表)中引用的对象.
  4.本地方法栈JNI(Native方法)中引用 的对象。

2. 对象的各种引用

• 强引用
  一般的Object obj = new Object() ，就属于强引用。
• 软引用 SoftReference
  一些有用但是并非必需，用软引用关联的对象，系统将要发生OOM之前，这些对象就会被回收。参见代码：
  
  运行结果
  
• 弱引用 WeakReference
  一些有用（程度比软引用更低）但是并非必需，用弱引用关联的对象，只能生存到下一次垃圾回收之前，GC发生时，不管内存够不够，都会被回收。
  参看代码：
  
  
• 虚引用 PhantomReferenc
  幽灵引用，最弱，被垃圾回收的时候收到一个通知

注意 ：软引用 SoftReference和弱引用 WeakReference，可以用在内存资源紧张的情况下以及创建不是很重要的数据缓存。当系统内存不足的时候，缓存中的内容是可以被释放的。
例如，一个程序用来处理用户提供的图片。如果将所有图片读入内存，这样虽然可以很快的打开图片，但内存空间使用巨大，一些使用较少的图片浪费内存空间，需要手动从内存中移除。如果每次打开图片都从磁盘文件中读取到内存再显示出来，虽然内存占用较少，但一些经常使用的图片每次打开都要访问磁盘，代价巨大。这个时候就可以用软引用构建缓存。

3. 垃圾回收的各种算法

• 复制算法（Copying） — 新生代
  将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为了原
  来的一半。
• 标记-清除算法（Mark-Sweep） — 老年代
  算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。
  它的主要不足空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
• 标记-整理算法（Mark-Compact） — 老年代
  首先标记出所有需要回收的对象，在标记完成后，后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

4. 垃圾收集器

5. 垃圾回收器列表

收集器	收集对象和算法	收集器类型	说明	适用场景
Serial	新生代，复制算法	单线程	进行垃圾收集时， 必须暂停所有工 作线程，直到完 成；(stop the world)	简单高效； 适合内存不大的情 况；
ParNew	新生代，复制算法	并行的多线程 收集器	ParNew垃圾收集 器是Serial收集器 的多线程版本	搭配CMS垃圾回收 器的首选
Parallel Scavenge 吞吐量优先收集 器	新生代，复制算法	并行的多线程 收集器	类似ParNew，更 加关注吞吐量， 达到一个可控制 的吞吐量；	本身是Server级别 多CPU机器上的默 认GC方式，主要适 合后台运算不需要 太多交互的任务；
Serial Old	老年代，标记整 理算法	单线程	dk7/8默认的老生代垃圾 回收器	Client模式下虚拟 机使用
Parallel Old	老年代，标记整 理算法	并行的多线程 收集器	Parallel Scavenge收集 器的老年代版本，为了配 合Parallel Scavenge的 面向吞吐量的特性而开发 的对应组合；	在注重吞吐量以及 CPU资源敏感的场 合采用
CMS	老年代，标记清 除算法	并行与并发收 集器	尽可能的缩短垃圾收集时 用户线程停止时间；缺点 在于： 1.内存碎片 2.需要更多cpu资源 3.浮动垃圾问题，需要更 大的堆空间	重视服务的响应速 度、系统停顿时间 和用户体验的互联 网网站或者B/S系 统。互联网后端目 前cms是主流的垃 圾回收器；
G1	跨新生代和老年 代；标记整理 + 化整为零	并行与并发收 集器	JDK1.7才正式引入，采 用分区回收的思维，基本 不牺牲吞吐量的前提下完 成低停顿的内存回收；可 预测的停顿是其最大的优 势；	面向服务端应用的 垃圾回收器，目标 为取代CMS

具体说明：
当前商业虚拟机的垃圾收集都采用“分代收集”（Generational Collection）算法，这种算法并没有什么新的思想，只是根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。
专门研究表明，新生代中的对象98%是“朝生夕死”的，所以并不需要按照1:1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor[1]。当回收时，将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8:1，也就是每次新生代中可用内存空间为整个新生代容量的90%（80%+10%），只有10%的内存会被“浪费”。当然，98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion）。
在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记—清理”或者“标记—整理”算法来进行回收。

Serial/Serial Old
最古老的，单线程，独占式，成熟，适合单CPU 服务器
-XX:+UseSerialGC 新生代和老年代都用串行收集器
-XX:+UseParNewGC 新生代使用ParNew，老年代使用Serial Old
-XX:+UseParallelGC 新生代使用ParallerGC，老年代使用Serial Old

ParNew
和Serial基本没区别，唯一的区别：多线程，多CPU的，停顿时间比Serial少
-XX:+UseParNewGC 新生代使用ParNew，老年代使用Serial Old

Parallel Scavenge（ParallerGC）/Parallel Old
关注吞吐量的垃圾收集器，高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。
所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。
-XX:+UseParallerOldGC：新生代使用ParallerGC，老年代使用Parallel Old
-XX:MaxGCPauseMills ：参数允许的值是一个大于0的毫秒数，收集器将尽可能地保证内存回收花费的时间不超过设定值。不过大家不要认为如果把这个参数的值设置得稍小一点就能使得系统的垃圾收集速度变得更快，GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的：系统把新生代调小一些，收集300MB新生代肯定比收集500MB快吧，这也直接导致垃圾收集发生得更频繁一些，原来10秒收集一次、每次停顿100毫秒，现在变成5秒收集一次、每次停顿70毫秒。停顿时间的确在下降，但吞吐量也降下来了。
-XX:GCTimeRatio参数的值应当是一个大于0且小于100的整数，也就是垃圾收集时间占总时间的比率，相当于是吞吐量的倒数。如果把此参数设置为19，那允许的最大GC时间就占总时间的5%（即1/（1+19）），默认值为99，就是允许最大1%（即1/（1+99））的垃圾收集时间。
-XX:+UseAdaptiveSizePolicy 当这个参数打开之后，就不需要手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX：SurvivorRatio）、晋升老年代对象年龄（-XX：PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种调节方式称为GC自适应的调节策略。
如果对于收集器运作原来不太了解，手工优化存在困难的时候，使用Parallel Scavenge收集器配合自适应调节策略，把内存管理的调优任务交给虚拟机去完成将是一个不错的选择。只需要把基本的内存数据设置好（如-Xmx设置最大堆），然后使用MaxGCPauseMillis参数（更关注最大停顿时间）或GCTimeRatio（更关注吞吐量）参数给虚拟机设立一个优化目标，那具体细节参数的调节工作就由虚拟机完成了。自适应调节策略也是Parallel Scavenge收集器与ParNew收集器的一个重要区别。

Concurrent Mark Sweep （CMS）
收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。
从名字（包含“Mark Sweep”）上就可以看出，CMS收集器是基于“标记—清除”算法实现的，它的运作过程相对于前面几种收集器来说更复杂一些，整个过程分为4个步骤，包括：
初始标记-短暂，仅仅只是标记一下GC Roots能直接关联到的对象，速度很快。
并发标记-和用户的应用程序同时进行，进行GC RootsTracing的过程
重新标记-短暂，为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。
并发清除
由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。
-XX:+UseConcMarkSweepGC ，表示新生代使用ParNew，老年代的用CMS

G1
-XX:+UseG1GC

1. 并行与并发：
   G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。
2. 分代收集：与其他收集器一样，分代概念在G1中依然得以保留。虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。
3. 空间整合：与CMS的“标记—清理”算法不同，G1从整体来看是基于“标记—整理”算法实现的收集器，从局部（两个Region之间）上来看是基于“复制”算法实现的，但无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。
4. 内存布局：在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。
   新生代GC
   回收Eden区和survivor区，回收后，所有eden区被清空，存在一个survivor区保存了部分数据。老年代区域会增多，因为部分新生代的对象会晋升到老年代。
   并发标记周期
   初始标记：短暂，仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，产生一个全局停顿，都伴随有一次新生代的GC。
   根区域扫描：扫描survivor区可以直接到达的老年代区域。
   并发标记阶段：扫描和查找整个堆的存活对象，并标记。
   重新标记：会产生全局停顿，对并发标记阶段的结果进行修正。
   独占清理：会产生全局停顿，对GC回收比例进行排序，供混合收集阶段使用
   并发清理：识别并清理完全空闲的区域，并发进行
   混合收集
   对含有垃圾比例较高的Region进行回收。
   G1当出现内存不足的的情况，也可能进行的FullGC回收。
   G1中重要的参数：
   -XX:MaxGCPauseMillis 指定目标的最大停顿时间，G1尝试调整新生代和老年代的比例，堆大小，晋升年龄来达到这个目标时间。
   -XX:ParallerGCThreads：设置GC的工作线程数量
   未来的垃圾回收
   ZGC通过技术手段把stw的情况控制在仅有一次，就是第一次的初始标记才会发生，这样也就不难理解为什么GC停顿时间不随着堆增大而上升了，再大我也是通过并发的时间去回收了
   关键技术
   1.有色指针（Colored Pointers）
   加载屏障（Load Barrier）

6.内存分配与回收策略

1. 对象优先在Eden分配，如果说Eden内存空间不足，就会发生Minor GC
2. 大对象直接进入老年代，大对象：需要大量连续内存空间的Java对象，比如很长的字符串和大型数组，
   1、导致内存有空间，还是需要提前进行垃圾回收获取连续空间来放他们，2、会进行大量的内存复制。
   -XX:PretenureSizeThreshold 参数 ，大于这个数量直接在老年代分配，缺省为0 ，表示绝不会直接分配在老年代。
3. 长期存活的对象将进入老年代，默认15岁，-XX:MaxTenuringThreshold调整
4. 动态对象年龄判定，为了能更好地适应不同程序的内存状况，虚拟机并不是永远地要求对象的年龄必须达到了MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄
5. 空间分配担保：新生代中有大量的对象存活，survivor空间不够，当出现大量对象在MinorGC后仍然存活的情况（最极端的情况就是内存回收后新生代中所有对象都存活），就需要老年代进行分配担保，把Survivor无法容纳的对象直接进入老年代.只要老年代的连续空间大于新生代对象的总大小或者历次晋升的平均大小，就进行Minor GC，否则FullGC。

7.新生代配置
新生代大小配置参数的优先级：
高：-XX:NewSize/MaxNewSize
中间 -Xmn （NewSize= MaxNewSize）
低：-XX:NewRatio 表示比例，例如=2，表示 新生代：老年代 = 1:2

-XX:SurvivorRatio 表示Eden和Survivor的比值，
缺省为8 表示 Eden:FromSurvivor:ToSurvivor= 8:1:1

同样的代码情况下：
-Xms20M -Xmx20M -XX:+PrintGCDetails –Xmn2m -XX:SurvivorRatio=2
没有垃圾回收
数组都在老年代

-Xms20M -Xmx20M -XX:+PrintGCDetails -Xmn7m -XX:SurvivorRatio=2
发生了垃圾回收
新生代存了部分数组，老年代也保存了部分数组，发生了晋升现象

-Xms20M -Xmx20M -XX:+PrintGCDetails -Xmn15m -XX:SurvivorRatio=8
新生代可以放下所有的数组
老年代没放

-Xms20M -Xmx20M -XX:+PrintGCDetails -XX:NewRatio=2
发生了垃圾回收
出现了空间分配担保，而且发生了FullGC