JVM双亲委派机制+对象分配过程

最近看了一些关于JVM的视频之类的，对于一些知识有了更充分地认识，现在和大家分享下。
以下的顺序没有什么特别的含义，有些知识点也是跳跃性的，中间有很多东西没讲，只是挑一些印象深刻的分享了。
（如果下面有什么讲的不对的地方，大家可以批评指出，我还是个小菜鸡）

1. 双亲委派机制

   首先先简单说明一下3个最常见的类加载器：

启动类加载器（引导类加载器，Bootstrap ClassLoader）：
由C/C++实现；加载Java核心类库；不继承自java.lang.ClassLoader，没有父加载器；
扩展类加载器（Extension ClassLoader）：
Java实现，派生于ClassLoader类，父类加载器为启动类加载器；
应用程序类加载器（系统类加载器，Application ClassLoader）：
Java实现，派生于ClassLoader类，父类加载器为扩展类加载器，该类是程序中默认的类加载器，一般来说，Java应用的类都是由它来加载完成。

JVM加载类的Class文件时，采用的是双亲委派机制，即把请求交给父类处理，它是一种任务委派模式。
原理：
1）如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行;
2）如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归,请求最终将到达顶层的启动类加载器;
3）如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式。

举个别人讲的例子（这是我听过最好的例子，再也忘不掉）：
就像是你有一个苹果，你看你妈在，就先问你妈吃不吃，你妈看你姥姥在，就问你姥姥吃不吃，如果你姥姥吃了，你和你妈就没得吃了。你姥姥不想啃，不吃，就还给你妈，你妈要是吃了你就没得吃了，要是你妈也不吃，才轮到你吃。

优势：

• 避免类的重复加载
• 保护程序安全，防止核心API被随意篡改
  举个例子，比如你自己定义了一个String类，且包名设置为java.lang，那就和我们常用的字符串类java.lang.String一样了，但是此时你运行发现String类是不会加载你写的这一个，而是加载系统的String类，就是因为使用双亲委派机制，当系统类加载器收到加载String类的请求时，先传给扩展类加载器，然后扩展类加载器又传给引导类加载器，引导类加载器发现String类属于自己加载的范畴，就加载了系统的String类。

2.对象分配过程


默认情况下：
年轻代：老年代=1:2
Eden:S0:S1= 8:1:1

1）new的对象先放伊甸园区（Eden）。此区有大小限制；
2）当伊甸园的空间填满时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC)，将伊甸园区中的不再被其他对象所引用的对象进行销毁。再加载新的对象放到伊甸园区；
3）然后将伊甸园中的剩余对象移动到幸存者0区（S0）。
4）如果再次触发垃圾回收，此时上次幸存下来的放到幸存者0区的，如果没有回收，就会放到幸存者1区（S1）。
5）如果再次经历垃圾回收，此时会重新放回幸存者0区，接着再去幸存者1区。
6）啥时候能去老年代呢?可以设置次数。默认是15次（从Eden移动到S0区或者S1区算移动一次，从S0区移动到S1区也算一次，从S1区移动到S0区也算一次，所以只要经过过移动都算做一次。当一个对算经历过15次的移动还没被销毁，就放到老年代）。
7）在老年代，很少进行垃圾回收。当老年代内存不足时，触发Major Gc，进行老年代的内存清理。
8）若老年代执行了Major Gc之后发现依然无法进行对象的保存，就会产生ooM异常。

垃圾回收频繁发生在年轻代，很少在老年代，几乎不在永久代（java7及以前）/元空间（java8及以后）收集。

对象分配到老年代不一定要经历15次的移动，有些特殊情况下可以更快或者跳过Eden区直接分配到老年代，上图：

先粗略地分享这么多吧，要是工作空闲了，会继续来分享的，也当做自己看了资料过后的总结吧。