面试回忆录（一） - jvm

就这样默默地被面试了好多家现在做一下jvm的面试总结内容如下：

 1、内存模型

        程序计数器 - 线程运行时行号指示器，唯一没有oom的地方；

        堆 - 用来存储对象实例，容易出现oom，线程间共享的内存区域，包括字符串常量池

        本地方法栈 - 为虚拟机使用到的Native方法服务

        虚拟机栈 - 方法执行时创建栈针，存储局部变量、方法返回地址、操作数、动态链接        

        方法区 - （jdk8中不存在）用于存储已经被虚拟机加载的类信息，常量，静态变量等

        元空间 - （jdk8中添加）元空间属于本地内存，原来属于方法区的运行时常量池就属于元空间了

2、class加载机制

        加载、验证、准备、解析、初始化、使用、销毁

3、常用的垃圾回收器

        CMS - 

        G1 - 

4、回收

        判断是否死亡： 引用计数，可达性分析

        回收算法： 标记清除、复制、标记整理、分代收集

5、分代收集详细介绍

HotSpot JVM把年轻代分为了三部分：1个Eden区和2个Survivor区（分别叫from和to）。默认比例为8：1,为啥默认会是这个比例，接下来我们会聊到。一般情况下，新创建的对象都会被分配到Eden区(一些大对象特殊处理),这些对象经过第一次Minor GC后，如果仍然存活，将会被移到Survivor区。对象在Survivor区中每熬过一次Minor GC，年龄就会增加1岁，当它的年龄增加到一定程度时，就会被移动到年老代中。

　　因为年轻代中的对象基本都是朝生夕死的(80%以上)，所以在年轻代的垃圾回收算法使用的是复制算法，复制算法的基本思想就是将内存分为两块，每次只用其中一块，当这一块内存用完，就将还活着的对象复制到另外一块上面。复制算法不会产生内存碎片。

　　在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。紧接着进行GC，Eden区中所有存活的对象都会被复制到“To”，而在“From”区中，仍存活的对象会根据他们的年龄值来决定去向。年龄达到一定值(年龄阈值，可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中，没有达到阈值的对象会被复制到“To”区域。经过这次GC后，Eden区和From区已经被清空。这个时候，“From”和“To”会交换他们的角色，也就是新的“To”就是上次GC前的“From”，新的“From”就是上次GC前的“To”。不管怎样，都会保证名为To的Survivor区域是空的。Minor GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满之后，会将所有对象移动到年老代中

        老年代中进行标记是：标记 - 整理算法。（先标记清除后进行锁片整理）。

6、发生OOM如何定位？ 无非“本身资源不够”“申请资源太多”“资源耗尽”几个原因

  某Java服务（假设PID=10765）出现了OOM，最常见的原因为： 

  有可能是内存分配确实过小，而正常业务使用了大量内存

  某一个对象被频繁申请，却没有释放，内存不断泄漏，导致内存耗尽

  某一个资源被频繁申请，系统资源耗尽，例如：不断创建线程，不断发起网络连接

具体解决办法：https://blog.youkuaiyun.com/shenjian58/article/details/102814013

https://zhuanlan.zhihu.com/p/58919881 二者结合

7、虚拟将到底创建了几个对象？

        https://blog.youkuaiyun.com/weixin_42509964/article/details/112190942

（有问题请留言，一起学习共同进步）