JVM内存结构的原理

jvm内存结构
方法区：类
堆：Java对象
栈：局部变量、方法参数
程序计数器：代码执行行数

哪些部分会出现内存溢出
不会出现内存溢出的区域-程序计数器
————
出现OutOfMemoryError的情况
①堆内存耗尽-对象越来越多，又一直在使用，不能被垃圾回收
②方法区内存耗尽 -加载的类越来越多,很多框架都会在运行期间动态产生新的类
③虚拟机栈累积-每个线程最多会占用1 M内存，线程个数越来越多，而又长时间运行不销毁时
————
出现StackOverflowError的区域
①虚拟机栈内部-方法调用次数过多

jvm垃圾回收
过程：

1. 首先把字节码文件内容加载到方法区
2. 然后再根据类信息在堆区创建对象
3. 对象首先会分配在堆区中年轻代的Eden区，经过一次Minor GC后，对象如果存活，就会进入Suvivor区。在后续的每次Minor GC中，如果对象一直存活，就会在Suvivor区来回拷贝，每移动一次，年龄加1
4. 当年龄超过15后，对象依然存活，对象就会进入老年代
5. 如果经过Full GC，被标记为垃圾对象，那么就会被GC线程清理掉

目的：实现无用对象内存自动释放，减少内存碎片、加快分配速度

GC特点：
①回收区域是堆内存， 不包括虚拟机栈，在方法调用结束会自动释放方法占用内存
②判断无用对象, 使用可达性分析算法，三色标记法标记存活对象，回收未标记对象
③GC 具体的实现称为垃圾回收器
④GC 大都采用了分代回收思想，理论依据是大部分对象朝生夕灭，用完立刻就可以回收,另有少部分对象会长时间存活，每次很难回收，根据这两类对象的特性将回收区域分为新生代和老年代，不同区域应用不同的回收策略
⑤根据GC的规模可以分成Minor GC，Mixed GC, Full GC

哪些对象被根对象引用则标记，没有被标记的则进行垃圾回收
————
标记清除 会产生内存碎片
标记整理 解决了内存碎片 但是多了整理的动作导致效率会慢
标记复制 from板块 to板块（内存想等） 缺点就是占用了一块多的内存

垃圾回收器

JVM有哪些垃圾回收算法？

1. 标记清除算法：
   a. 标记阶段：把垃圾内存标记出来
   b. 清除阶段：直接将垃圾内存回收。
   c. 这种算法是比较简单的，但是有个很严重的问题，就是会产生大量的内存碎片。
2. 复制算法：为了解决标记清除算法的内存碎片问题，就产生了复制算法。复制算法将内存分为大小相等的两半，每次只使用其中一半。垃圾回收时，将当前这一块的存活对象全部拷贝到另一半，然后当前这一半内存就可以直接清除。这种算法没有内存碎片，但是他的问题就在于浪费空间。而且，他的效率跟存活对象的个数有关。

jvm调优处理

jvm调优涉及到两个很重要的概念：吞吐量和响应时间。jvm调优主要是针对他们进行调整优化，达到一个理想的目标，根据业务确定目标是吞吐量优先还是响应时间优先。

1.熟悉业务场景，了解当前业务系统的要求，是吞吐量优先还是响应时间优先；

2.选择合适的垃圾回收器组合，如果是吞吐量优先，则选择ps+po组合；如果是响应时间优先，在1.8以后选择G1，在1.8之前选择ParNew+CMS组合；
3.规划内存需求，只能进行大致的规划。
4.CPU选择，在预算之内性能越高越好；

类加载的过程
类加载过程分为三个阶段

1. 加载
   ①将类的字节码载入方法区， 并创建类.class对象
   ②如果此类的父类没有加载， 先加载父类
   ③加载是懒惰执行
   2.链接
   ①验证 -验证类是否符合Class规范，合法性、安全性检查
   ②准备- 为static变量分配空间，设置默认值
   ③解析- 将常量池的符号引用解析为直接引用
   3.初始化
   ①执行静态代码块 与非final 静态变量的赋值
   ②初始化是懒惰执行

双亲委派
所谓的双亲委派，就是指优先委派上级类加载器进行加载，如果上级类加载器
①能找到这个类， 由. 上级加载，加载后该类也对下级加载器可见
②找不到这个类，则下级类加载器才有资格执行加载

双亲委派的目的
①让上级类加载器中的类对下级共享(反之不行)，即能让你的类能依赖到jdk提供的核心类
②让类的加载有 优先次序，保证核心类优先加载

自己编写类加载器就能加载-一个假冒的java.lang.System吗?
不可以
————————
原因：
①假设你自己的类加载器用双亲委派，那么优先由启动类加载器加载真正的java.lang.System,自然不会加载假冒的
②假设你自己的类加载器不用双亲委派，那么你的类加载器加载假冒的java.lang.System时，它需要先加载父类java.lang.object,而你没有用委派，找不到java.lang.0bject所以加载会失败
③以上也仅仅是假设。实际操作你就会发现自定义类加载器加载以java.打头的类时，会抛安全异常，在jdk9以上版本这些特殊包名都与模块进行了绑定，更连编译都过不了

对象的引用类型

finalize
它是Object中的一一个方法，子类重写它，垃圾回收时此方法会被调用，可以在其中进行一些资源释放和清理工作，将资源释放和清理放在finalize方法中非常不好，非常影响性能，严重时甚至会引起00M

你们项目如何排查JVM问题
对于还在正常运行的系统：

1. 可以使用jmap来查看JVM中各个区域的使用情况
2. 可以通过jstack来查看线程的运行情况，比如哪些线程阻塞、是否出现了死锁
3. 可以通过jstat命令来查看垃圾回收的情况，特别是fullgc，如果发现fullgc比较频繁，那么就得进行调优了
4. 通过各个命令的结果，或者jvisualvm等工具来进行分析
5. 首先，初步猜测频繁发送fullgc的原因，如果频繁发生fullgc但是又一直没有出现内存溢出，那么表示fullgc实际上是回收了很多对象了，所以这些对象最好能在younggc过程中就直接回收掉，避免这些对象进入到老年代，对于这种情况，就要考虑这些存活时间不长的对象是不是比较大，导致年轻代放不下，直接进入到了老年代，尝试加大年轻代的大小，如果改完之后，fullgc减少，则证明修改有效
6. 同时，还可以找到占用CPU最多的线程，定位到具体的方法，优化这个方法的执行，看是否能避免某些对象的创建，从而节省内存

对于已经发生了OOM的系统：

1. 一般生产系统中都会设置当系统发生了OOM时，生成当时的dump文件（-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/base）
2. 我们可以利用jsisualvm等工具来分析dump文件
3. 根据dump文件找到异常的实例对象，和异常的线程（占用CPU高），定位到具体的代码
4. 然后再进行详细的分析和调试