JVM优化

Java编码执行流程图

在这里插入图片描述

a.java
->javac（前端编译器，javac属于其中一种）
->a.class
和java类库
->classloader->
Java解释器(一行行解释并运行)
或即时编译器JIT(Just In Time，属于后端编译器)JIT可以将一个方法（热点代码）中所有的字节码编译成机器码，放在缓存中，然后需要的时候拿出来直接用		   
判断热点代码的方式是：热点探测JDK:jre+development kit
JRE:jvm+core lib
JVM

JVM实现

hotspot1.8以后收费,开源版openJDK
jrockit,被oracle收购，合并于hotspot
taobaoJVM

JVM内存

JVM内存：
1，虚拟机栈：每个线程有一个私有的栈，随着线程的创建而创建。每个方法会创建一个栈帧，栈帧中存放了局部变量表（基本数据类型和对象引用）、操作数栈、方法出口等
栈的大小可以固定也可以动态扩展。
当栈调用深度大于JVM允许的范围，会抛出StackOverflowError
2，本地方法栈
3，PC寄存器：记录当前程序执行到哪一步
4，堆：存放所有的对象和数组。
分为新生代（伊甸园、存活区）占1/3堆空间、老年代占2/3堆空间
5，方法区：所有线程共享。用于存储类的信息、常量池、方法数据、方法代码等。
方法区逻辑上属于堆的一部分，但是为了与堆区分，又叫“非堆”
JDK1.8之前方法区的实现是永久代，JDK1.8之后分方法区的实现是元空间(元空间本地存储)

永久代、元空间？

元空间和永久代概念？
元空间和永久代类似，都是JVM规范中方法区的实现
永久代是JVM虚拟机中一块内存空间，可以设置大小，在内存不够时会触发FullGC，也就是和老年代同时垃圾回收
元空间不属于JVM内存，而是使用本地内存，默认是可以无限制使用本地内存，也可以通过参数限制内存使用大小
元空间为什么代替了永久代？
1，字符串存在永久代中，容易出现性能问题和内存溢出。
2，类及方法的信息比较难确定其大小，永久代大小指定比较困难，太小容易出现永久代溢出，太大容易造成老年代溢出
3，永久代会为GC带来不必要的复杂度，并且回收效率偏低。

string声明的字面量数据都放在字符串常量池中
jdk1.6中字符串常量池存放在方法区（永久代中）
jdk1.7及以后字符串常量池存放在堆空间

intern()
如果不是用双引号声明的String对象，可以使用String提供的intern方法。
intern 方法会从字符串常量池中查询当前字符串是否存在，若不存在就会将当前字符串放入常量池中

String str1 = new String("hello");
//将字符串放在常量池中
String intern = string.intern();
//直接从常量池获取
String str2 = "hello";//字面量赋值
System.out.println(str1==str2);//false
System.out.println(intern==str2);//true

堆栈？

栈：方法调用（自动释放）、变量名
堆：new出的对象
在这里插入图片描述

为什么不把基本数据类型放在堆中？

1，栈比堆运算效率快，但是堆空间比栈空间大
2，将复杂的数据类型放在堆中目的是不影响栈运行效率，通过引用的方式去堆中找。
3，基本数据类型占用内存少，放在栈空间中，能够提高效率。

GC

垃圾回收算法：mark-sweep标记清除、copying拷贝、mark-compact标记压缩
在这里插入图片描述
Java1.8默认PS+PO，Java1.9默认G1

内存模型

分代模型：

新生代1/3：coping算法，比例为8:1:1，eden（伊甸区8）：survivor1：survivor1

新生代采用coping算法，
比如先给eden区new10个对象，然后回收9个对象，将剩余的1个放到survivor，这时eden区又为空
然后在eden区new10个对象，再回收时，回收eden区和第一个survivor区，将不需要回收的对象放在第二个survivor区

老年代2/3：随着在新生代中年龄增长（PS+PO:15次,CMS:6次）放到老年代中
Full GC（Full Garbage Collection）：当老年代的空间占用达到一定阈值时，JVM 可能会触发 Full GC 来对整个堆（包括新生代和老年代）进行回收。Full GC 会扫描整个堆内存，包括老年代，以释放未被使用的对象占用的内存。
CMS GC（Concurrent Mark-Sweep Garbage Collection）：在使用 CMS 垃圾收集器时，老年代的回收通常是通过 CMS 的并发标记清除算法来实现的。这种方式允许在应用程序运行的同时进行老年代的回收操作，以减少停顿时间。
G1 GC（Garbage-First Garbage Collection）：G1 垃圾收集器通过划分堆内存为多个区域来管理内存，其中包括老年代。G1 GC 会根据堆内存的使用情况动态地选择哪些区域进行垃圾回收，而不是简单地依赖于年龄或者固定的老年代回收阈值。
在这里插入图片描述

分区模型：

JVM内存分成不同区域region

serial单线程+serial old垃圾回收组合

serial：a stop-the-world,copying collector which use a single GC thread
serial old：a stop-the-world,mark-sweep-compact collector what use a single GC thread

内存几十兆时：
serial单线程stw（stop the world）垃圾回收
serial采用copying拷贝算法，
serial old采用mark-sweep标记清除、mark-compact标记压缩

parallel并行 scavenge+parallel old垃圾回收组合

parallel scavenge: a stop-the-world,copying collector which use a multiple GC thread
parallel old: a stop-the-world,mark-sweep-compact collector that use a multiple GC thread

parallel并行（其实就是多线程同时垃圾回收）
内存几百兆~1G时：
并行多线程
PS+PO组合
JDK1.8默认垃圾回收线程
在需要垃圾回收时，多个线程同时干活
但是不能无限增加垃圾回收线程数量，因为线程切换需要花费时间

CMS+ParNew垃圾回收组合

CMS：concurrent-mark-sweep并发标记清除
内存：20G
Concurrent GC 并发垃圾回收
并发：指GC线程和业务线程同时进行
CMS适用于老年代

在这里插入图片描述

三色标记算法

黑色标记对象A：对象A和子属性都已完成标记
灰色标记对象B：对象B已完成标记，但是子属性没有完成
白色标记对象D：对象D和子属性都没有完成标记

incremental update增量更新

当A的子属性是B，B的子属性是D时，如果BD之间断开关联，AD之间增加关联时，
需要将黑色标记对象A，改成灰色。这称为CMS解决方案incremental update增量更新

incremental update增量更新bug

但是CMS存在bug，
当垃圾回收线程t1标记完成对象A、子属性A1并且正在标记子属性A2时，
切换至业务线程t2，t2给对象A将子属性A1指向白色对象，
切换至垃圾回收线程t3，把对象A标记为灰色
切换回垃圾回收线程t1继续标记完子属性A2时，就会把A标记成黑色。
导致对象D漏标
需要在重新标记Remark时STW，浪费时间

G1

内存：上百G
垃圾处理时间号称200ms
G1:garbage first首先回收垃圾特别多的区域
是一个老年代和新生代共用的垃圾回收器
G1采用局部收集的回收思想。将Java堆内存划分成多个相同大小的独立region区域。
物理上不分代，但是分区，逻辑上分代
G1分region回收，优先回收花费时间少，垃圾比例高的region
新老年代比例一般不用手动指定G1也采用三色标记，但是将incremental update增量更新升级为SATB(snopshot at the begining)

SATB(snopshot at the begining)

SATB(snopshot at the begining)
在起始时做一个快照，当B->D消失时，要把这个引用推到GC的堆栈，保证D还能被GC扫描到，
配合Rset(remember set记忆集，region分区有10~15%区域用于记录哪些分区有引用当前分区)，
只用扫描哪些region引用到了D这个region，如果全部不指向D，那么D就是垃圾。
如果有别的对象指向D，D就保留下来