JVM思维导图

Eden区

Survivor（from）区  设置survivor是为了减少送到老年代的对象

Survivor（to）区  设置两个Survivor区是为了解决碎片问题

eden:survovir:survivor=8:1:1

运行时常常量池

静态变量

final类型量

类信息

栈帧

异常

如果程序执行的是Java方法，则指当前线程执行的字节码的行数

此内存区域是唯一一个不会出现OutOfMemoryError情况的区域

如果正在执行的是Natvie方法，这个计算器值则为空

和虚拟机栈类似，这里主要是为使用到的Native方法服务的

堆内存大小

堆内存最大大小

年轻代大小

Java虚拟机栈大小

永久代大小   JDK1.8后变为-XX:MetaspaceSize

永久代最大大小  JDK1.8后变为-XX:MaxMetaspaceSize

设置大对象的最大值，超过该值，直接进入老年代

设置年龄阈值

新生代使用的垃圾回收算法

老年代使用的垃圾回收算法

设置ParNew垃圾回收线程数量(一般不要动)

老年代对象占多少时就是垃圾回收

默认打开

经过对少次Full GC就会进行一次碎片整理，默认是5

这个参数会在CMS垃圾回收器的“初始标记”阶段开启多线程并发执行。

这个参数会在CMS的重新标记阶段之前，先尽量执行一次Young GC。
这样做有什么作用呢？
其实大家都记得，CMS的重新标记也是会Stop the World的，所以所以如果在重新标记之前，先执行一次Young GC，就会回收掉一些年轻代里没有人引用的对象。
所以如果先提前回收掉一些对象，那么在CMS的重新标记阶段就可以少扫描一些对象，此时就可以提升CMS的重新标记阶段的性能，减少他的耗时。

Eden区占比

-XX:+UseG1Gc

-XX:MaxGCPauseMills

-XX:G1HeapRegionSize

年轻代先关的参数

老年代相关的参数 

-XX:G1MixedGCCountTarget

-XX:G1HeapWastePercent

-XX:G1MixedGCLive ThresholdPercent

打印详细的Gc日志

打印每次的gc的时间

将gc日志写入一个磁盘文件

分别打印GC前后的堆内存的情况

追踪类的加载和类的卸载

不允许通过代码来触发GC（System.gc()）

-XX:+HeapDumpOnOutOfMemoryError 

-XX:HeapDumpPath=/usr/local/app/oom

追踪磊的加载和类的卸载的情况，他会通过日志打印出来JVM中加载了哪些类卸载了哪些类

jstat -gc PID

jstat -gccapacity PID

jstat -gcnew PID

jstat -gccnewcapacity PID

jstat -gcold PID

jstat -gcoldcapacity PID

jmap -heap PID

jmap -histo PID

jmap -dump:live,format=b,file=dump.hprof PID

jhat dump.hprof -port 8080

尽量让每次Young GC后的存活对象小于Survivor区域的50%，都留存在年轻代里。机娘别让对象进入老年代。尽量减少Full GC的频率，避免频繁Full GC对JVM性能的影响

JVM自己垃圾回收时也是尽量能不进入老年代就不进入老年代

-XX:+UseCMSCompactAtFullCollection

-XX:CMSFullGCsBeforeCompaction=0

-Xms4096M -Xmx4096M -Xmn3072M -Xss1M -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m -XX:SurvivorRatio=8 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=10 -XX:PretenureSizeThreshold=2M -XX:CMSInitiatingOccupancyFaction=92 -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSParallelInitialMarkEnabled -XX:+CMSScavengeBeforeRemark -XX:+DisableExplicitGC -XX:+PrintGCDetails  -XX:+PrintGCTimeStamps -Xloggc:./gclog/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/app/oom

MateSpace空间满了导致频繁的发生Full gc

system.gc()

内存分配不合理，导致对象频繁进入老年代，进而引发频繁的FullGC

存在内存泄漏等问题，就是内存里驻留了大量的对象塞满了老年代，导致稍微有一些对象进入老年代就会引发Full GC

-Xms4096M -Xmx4096M -Xmn3072M -Xss1M -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m -XX:SurvivorRatio=8 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=10 -XX:PretenureSizeThreshold=2M -XX:CMSInitiatingOccupancyFaction=92 -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSParallelInitialMarkEnabled -XX:+CMSScavengeBeforeRemark -XX:+DisableExplicitGC -XX:+PrintGCDetails  -XX:+PrintGCTimeStamps -Xloggc:./gclog/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/app/oom

初始标记的时候开启多线程
初始标记阶段，是会进行Stop the World的，会导致系统停顿，所以这个阶段开启多线程并发之后，可以尽可能优化这个阶段的性能，减少Stop the World的时间。

CMS的重新标记阶段之前，先尽量执行一次Young GC
先提前回收掉一些对象，那么在CMS的重新标记阶段就可以少扫描一些对象，此时就可以提升CMS的重新标记阶段的性能，减少他的耗时。

当观察到每次minor gc之后进入老年代中的对象并不是非常多，但是多一段时间就发有一个非常大的队形进入老年代，导致频繁的Full GC。将大对象进入老年代时进行内存导出并进行分析，发现有一个sql语句是select * from table。导致产生一个大对象，直接进入了老年代。解决方法   ：1.修改sql语句2.增加年轻代大小

如果一个对象在Eden区中，并且在一次Minor GC后仍然存活，也没有进入老年代中。被复制到一个Survivor中，那么它的年龄被记为1，以后每经历过一轮的Minor GC，年龄就增长一岁。达到一定年龄后就会进入老年代    

如果survivor中年龄一岁+年龄两岁的对象占比超过survivor空间的百分之50，则两岁及以上的所有对象统统进入老年代

动态年龄判断参与计算的对象时Survivor中的所有的对象，不管它是否已经失去了引用。但失去引用的部分并不会进入老年代

在发生Minor GC之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor GC可以确保是安全的。如果不成立，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次Minor GC，尽管这次Minor GC是有风险的，如果担保失败则会进行一次Full GC；如果小于，或者HandlePromotionFailure设置不允许冒险，那这时也要改为进行一次Full GC。

链接

Minor GC 之后如果Survivor无法放下，则直接进入老年代

年轻代

老年代

程序在申请内存后，无法释放已申请的内存空间

原因

内存泄漏的时候使用mat分析  ，完美

程序申请内存时，剩余的内存空间不足

原因

使用的时候加载

检查加载进来的.class文件是否符合JVM规范

分配内存空间，给静态变量分配默认值

把符号引用替换为直接引用

将静态变量赋值

加载 JAVA_HOME/lib下的内容

加载JAVA_HOME/lib/ext下的内容

加载CLASSPATH下的内容，大致是用户写的内容

根据用户需求自己定义，也需要继承ClassLoader类

如果一个类加载器接受到一个类加载的请求，它先不会自己去尝试加载，而是去把请求委派给它的父类加载器去加载。当父类加载器找不到类的时候，会抛出ClassNotFoundExcception，然后子类加载器才会自己去尝试加载

首先检查类是否已经被加载

把加载请求委派给父类进行加载

如果父类抛出ClassNotFoundException异常，表示父类加载器无法加载，则当前类加载器调用findClass尝试进行加载

如果能加载，则直接返回类

保证Java类库中的类不受用户类的影响，防止用户自定义一个类库中的同名类，引起问题

new一个对象时

调用一个类的静态方法

直接操作一个类的static属性

存放类信息

给对象添加上一个引用计数器，当对象增加一个引用时就加1，当一个引用失效时就减1，当引用计数为0时，该对象就可以被回收

缺陷：如果循环引用，就可能导致内存泄漏

对每个对象，都分析一下谁引用了它，然后一层一层分析，看最终是否有GC Roots引用了它

GC Roots

1.找到GC Roots不可达的对象，看其是否重写了finalize()方法或者调用了finalize()方法，如果都没有就放入F-Queue中

2.再次进行标记，如果这些对象还没有与GC Roots建立连接，则直接回收

垃圾回收器绝对不会回收它，宁愿自己抛出OOM，使得程序异常停止，也不会回收它

正常情况下垃圾回收器是不会回收软引用的，当垃圾回收之后，内存还是不足，才会回收软引用的对象

软引用特别适合创建缓存，当内存充足的时候不会回收，当内存不足的时候回收

当垃圾回收时，弱引用的对象，不管内存是否充足，都会被回收

将所有待回收的对象标记出来，然后一起清理

缺陷

复制算法是将堆内存分为两个相等的区域，每次只使用其中的一块，当其中一块区域满的时候，就会将存活的对象复制到另一个区域，然后将该区域清理

新生代使用的就是复制算法

优点：简单高效，不会存在内存碎片问题

缺点：内存利用率低

和复制算法一样，将所有的存活对象标记出来，然后将所有的对象移动到内存的一端

老年代使用的就是标记-整理算法

缺陷：需要移动大量的对象，效率不高

根据不同的年代选取不同的垃圾回收算法

年轻代使用复制算法

老年代使用标记-清除算法或者标记-整理算法

分代

串行单线程垃圾收集器

特点

ParNew 是 Serial 的多线程版本，也是工作在新生代，能与 CMS 配合使用。
在多 CPU 的情况下，由于 ParNew 的多线程回收特性，毫无疑问垃圾收集会更快，也能有效地减少 STW 的时间，提升应用的响应速度。

Serial？还是ParNew？

特点

Serial Old 是工作于老年代的单线程收集器。

作用：

特点：

GC 期间，只有垃圾回收器线程在工作，其他工作线程则被挂起。年轻代和老年代垃圾回收的时候，都会停止程序的执行，来进行垃圾的回收

在 java 程序中引用关系是不断会变化的，那么就会有很多种情况来导致垃圾标识出错。
想想一下如果一个对象 A 当前是个垃圾，GC 把它标记为垃圾，但是在清除前又有其他引用指向了 A，那么此刻又不是垃圾了。
那么，如果没有 STW 的话，就要去无限维护这种关系来去采集正确的信息，显然是不可取的。

CMS 可以说是一款具有"跨时代"意义的垃圾回收器，如果应用很重视服务的响应速度，希望给用户最好的体验，则 CMS 收集器是非常合适的，它是以获取最短回收停顿时间为目标的收集器！

使用的是标记-清理算法

回收的过程

缺陷

-XX:CMSInitiatingOccupancyFaction

-XX:+UseCMSCompactAtFullCollection

-XX:CMSFullGCsBeforeCompaction

STW

G1垃圾收集器将堆内存中的对象分为多个大小相等的区域（Region）,年轻代和老年代之间不在进行隔离（G1垃圾收集器有逻辑上的年轻代和老年代）

每个Region不会固定分配给老年代还是年轻代，按需分配

设计思想：用最少的时间，回收最多的对象.停顿时间可控

G1收集器和ParNew+CMS的区别

垃圾收集过程

回收失败时

混合回收触发条件

特点

G1相关参数

特点:

该问题是在进行Minor GC时，Survivor Space放不下，对象只能放入老年代，而此时老年代也放不下造成的。（promotion failed时老年代CMS还没有机会进行回收，又放不下转移到老年代的对象，因此会出现下一个问题concurrent mode failure，需要stop-the-wold 降级为GC-Serail Old）。

这一步主要是，进行年轻代垃圾回收的尝试，但是失败了，然后就会触发老年代的垃圾回收

该问题是在执行CMS GC的过程中同时业务线程将对象放入老年代，而此时老年代空间不足，或者在做Minor GC的时候，新生代Survivor空间放不下，需要放入老年代，而老年代也放不下而产生的。Serial Old

如果没有 Survivor 区，Eden 区每进行一次 Minor GC，存活的对象就会被送到老年代，老年代很快就会被填满。而有很多对象虽然一次 Minor GC 没有消灭，但其实或许第二次，第三次就需要被清除。

这种机制最大的好处就是可以解决内存碎片化，整个过程中，永远有一个 Survivor 区是空的，另一个非空的 Survivor 区是无碎片的。 假设只有一个 Survivor 区。 Minor GC 执行后，Eden 区被清空了，存活的对象放到了 Survivor 区，而之前 Survivor 区中的对象，可能也有一些是需要被清除的。 那么问题来了，这时候我们怎么清除它们？ 在这种场景下，我们只能标记清除，而我们知道标记清除最大的问题就是内存碎片，在新生代这种经常会消亡的区域，采用标记清除必然会让内存产生严重的碎片化。 因为 Survivor 有 2 个区域，所以每次 Minor GC，会将之前 Eden 区和 From 区中的存活对象复制到 To 区域。第二次 Minor GC 时，To 区 到 From 区 ，以此反复。

老年代占据着 2/3 的堆内存空间，只有在 Major GC 的时候才会进行清理，每次 GC 都会触发“Stop-The-World”。内存越大，STW 的时间也越长，所以内存也不仅仅是越大就越好。 由于复制算法在对象存活率较高的老年代会进行很多次的复制操作，效率很低，所以在这里老年代采用的是标记整理算法。