java编译优化和语法糖

• 早期编译优化
  • 第一步：
    • -------词法分析：
    • -------语法分析（注意实际上只是生成一个语法树，还没做语法的校验）：
    • -------填充符号表：
  • 第二步：
    • -------注解处理器：
  • 第三步：
    • -------语义分析：
    • -------解语法糖:
    • -------字节码生成：
  • java语法糖
    • 泛型擦除:
    • Signature:
    • 自动装箱拆箱、循环
    • 条件编译：
• 晚期编译优化
  • 解释器Interperter
  • 编译器
• 晚期优化的一些常见措施(即运行中才会做优化的步骤）
  • ----热点代码
  • —冗余访问消除:
  • ----公共子表达式消除
  • —数组边界检查：
  • —隐式异常处理：
  • ----方法内联:
  • ----逃逸分析：
  • ----java和C++， 即时编译和静态编译的区别：
• 编译优化问答题
  • 早期编译过程
  • 晚期编译优化

[toc]

早期编译优化#

编译过程大致分为3类：

1. 解析与填充符号表
2. 注解处理
3. 分析与字节码生成

源码JavaCompiler里的关键过程：
第一步：

第二步语法分析、词法分析

第三步:

第四步：
执行注解处理

接着就是语义分析及字节码生成

以上的关键点:

• 词法语法解析是第一步，生成符号
• 注解处理是第二步
• 然后语法糖、字节码都是第三步的事情。

---

上述步骤的详细解释：

第一步：#

-------词法分析：#

就是代码转成token标记。
例如int a=b+2 转成 Int \a=\b+\2 这6个token。

-------语法分析（注意实际上只是生成一个语法树，还没做语法的校验）：#

根据生成的token，构造一个抽象语法树。

-------填充符号表：#

生成一个符号地址和符号信息构成的表格。
(后面第三步的阶段会用于语义分析中的标注检查， 比如名字的使用是否和说明一致，也会用于产生中间代码）
符号表是目标代码生成时的地址分配的依据

第二步：#

-------注解处理器：#

注解处理器会扫描抽象语法树中带注解的元素， 并进行语法树的更新。
更新之后我们会重新走回解析与填充的过程，重新处理。
这个处理器是一种插件，我们可以自己不断往其中去添加。

注意，上面这2步只是简单去对源文件做转换， 还不涉及任何语法相关的规则。

第三步：#

-------语义分析：#

判断语法树是否正确。分为2种检查：

1. 标注检查： 检查变量是否已被声明、 赋值、等式的数据类型是否匹配
   标注检查中会进行常量折叠， 把a=1+2折叠成3
   标注检查的范围比较小，不会有太多上下文依赖。

2. 数据及控制流分析
   对程序上下文逻辑更进一步验证
   这里会涉及很多交互的上下文交互依赖
   比如 带返回值的方法是否全路径都包含了返回、 受检异常是否被外部处理、局部变量使用前是否被赋值。

final 局部变量（或者final参数）和非final局部变量，生成的class文件没有区别。
因为局部变量不会在常量池中持有符号引用， 所以不会有acesses_flasg信息。
所以class文件不知道局部变量是不是final， 因此final局部对运行期没有任何影响， 只会在编译期去校验。

-------解语法糖:#

虚拟机本身不支持这种语法， 但是会在编译阶段 把这些语法糖转为 普通的语法结构（换句话说做了把语法糖代码变成了普通代码， 例如自动装拆箱，可能就是转成了包装方法的特定调用）

-------字节码生成：#

对象的初始化顺序， 实际上会在字节码生成阶段， 收敛到一个方法中。 即init中控制了那些成员、以及构造方法的调用顺序
类初始化同理，也是收敛到一个 中
PS： 注意，默认构造器是在填充符号表阶段完成的。
字符串的替换（+操作转成sb） 是在字节码阶段生成的。
完成了对语法树的遍历之后，会把最终的符号表交给ClassWRITE类，设计概念从一个字节码和文件

---

java语法糖#

Q: java语法糖属于早期优化还是晚期优化？
A: 属于早期优化。

泛型擦除:#

java中的泛型只在 程序源码中存在， 在编译后的字节码文件中已经替换为原生类型， 并会插入一些强制转换的代码。
即

T f(T  t) {
    T a = T.getA();
    return a
}
实际上是

T  f(Object t) {
    Object a = （T）t.getA();
    return (T)a;
}

即只在会方法的入口 和方法的出口处，做强制转换， 而实际上传入的都是原生类型，可以理解为object

神奇的例子：

public static void method(List<Integer> list) {
    System.out.println("inoke method(List<Integer> list)");
}

public static void method(List<String> list) {
    System.out.println("inoke method(List<String> list)");
}

这个编译会报错，认为有2种相同的方法， 因为编译后被擦除了。

然后下面这个例子却是tm能ok的：

public static Integer method(List<Integer> list) {
    System.out.println("inoke method(List<Integer> list)");
}

public static String method(List<String> list) {
    System.out.println("inoke method(List<String> list)");
}

public static void main(){
    method(new ArrayList<String>());
    method(new ArrayList<Integer>());
}

解释:
返回值不参与重载的选择，但是因为返回值作为描述符不一致，以至于可以在一个class文件中共存。
必须用Sun JDK1.6才能编译通过

Signature:#

用于解决泛型歹来的参数类型的识别问题。
可存储字节码层面的特征签名。
字节码层面： 方法名称、参数顺序、参数类型、 返回值、受检查异常， 这5个决定了1个字节码层面的方法是否唯一。
如果是java语法层面， 则签名只受方法名称、参数顺序、参数类型这3个的影响。

他会保存参数化类型的信息， 即虽然code里都转成了object， 但是其参数化类型还是通过signature保存到了元数据区， 可以通过反射获取参数化类型。

自动装箱拆箱、循环#

自动装箱拆箱: 就是在编译后， 自动把装拆箱的地方加上 Integer.valueOf() 或者 包装类型.intValue()

可变参数：被优化成一个数组
Arrays.asList(“1”,“2”,“3”,“4”) => Arrays.asList(new String[]{ “1”, “2”, “3”, “4”})

带iterator接口的 for循环：
for(String str : listStr) {
}
被优化成

for(Interator it = list.iterator(); it.hasNext()) {
    xxx   it.next xxx...
}

Integer a = 1;
Integer b = 2;
Integer c = 3;
Integer d = 3;
Integer e = 321;
Integer f = 321;
Long g = 3L;

// true, 小于128，用常量池里的常量比较
System.out.println(c == d);
// false,非常量池，用各自不同的地址比较
System.out.println(e == f );
// true， 同1
System.out.println(c == (a+b));
// true， Integer
System.out.println(c.equals(a+b));
// true， 这个为什么==是可以的，是因为Long小于128时，也会用常量池的值吗
System.out.println(g == (a+b));
// false , equals不处理数据转型的关系。
System.out.println(g.equals(a+b));

条件编译：#

if(true) {
xxx
} else {
    yyy
}

被优化成了

xxx

因为编译器很明确只能走xxx这个分支。
只能用于if+常量

使用常量与其他带有条件判断能力的语句搭配，则会报错

while(false) {
    xxx
}

这个会报错unreachable statement code

因为系统检测到这句代码是永远无法到达的分支，直接给你禁掉了

晚期编译优化#

HotSpot中， 解释器与编译器共存。
当程序刚启动时，会先马上使用解释器发挥作用。
在程序运行后， 编译器逐步发挥作用，把还没用到的代码逐步编译。
内存资源比较少的情况下，可以用解释器来跑程序，减少编译生成的文件。
如果编译器的优化出现bug，可以通过“逆优化”回退到最初的解释器模式来运行

解释器Interperter#

编译器#

有两种编译器

• Client Compiler ——C1编译器, 更高的编译速度

• Server Compiler——C2编译器， 更好的编译质量
  即选择了-client或者-server时会用到。

• 默认混合模式： 解释器和编译器共存， 即MixedMode。

关于这2种编译器的参数：

• -Xint参数： 强制使用解释模式
• -Xcomp参数： 强制使用编译模式（ 但是如果编译无法进行时， 解释会介入）

---

混合模式中， 解释器需要收集性能信息，提供给编译阶段判断和优化， 这个性能信息有点浪费
因此JDK7引入了分层编译策略：

• 第0层： 解释执行。 不开启性能监控。
• 第1层： C1编译， 把字节码编译为本地代码， 进行一些简单优化， 加入性能监控
• 第2层： C2编译， 启动耗时较长的优化， 根据性能监控信息进行激进优化

---

CC和SC编译过程的区别：

• client Compiler 编译过程：
  前端字节码-》 方法内联/常量传播（基础优化）-》 HIR（高级中间代码）-》 空值检查消除/范围检查消除
  -》 后端把HIR转成LLR（低级中间代码）-》 线性扫描算法分配寄存器-》窥孔优化-》机器码生成-》本地代码生成
  都是一些不需要运行期信息就能做优化的操作

• serverCompiler编译过程：
  会执行所有的经典优化动作
  会根据cc或者解释器提供的监控信息，进行激进的优化
  寄存器分配器是一个全局图着色分配器

---

晚期优化的一些常见措施(即运行中才会做优化的步骤）#

----热点代码#

1. 被多次调用的方法。 会触发JIT编译
2. 被多次执行的循环体， 会触发OSR编译（栈上替换）， 发生在方法执行过程中， 所以是在栈上编译并切换方法。

HotSpot 使用 计数器的热点探测法确定热点代码。
* 给每个方法建立方法计数器， 在一个周期中如果超过阈值， 就触发JIT编译，编译后替换方法入口。
* 如果一个周期内没超过，则计数器/2（半衰）
* 如果没有触发时， 都是用解释方式 按照字节码内容死板地运行。

该计数器的相关参数
-XX:-UserCounterDecay 关闭热度衰减
-XX: CounterHalfLifeTime 设置半衰期-XX:CompileThreshold 设置方法编译阈值

回边计数器就是计算循环次数的计数器
* 没有半衰
* 但是当触发OSR编译时，会把计数器降低，避免还在运行时重复触发。
* 会溢出， 并且会把方法计数器也调整到溢出。
* clint模式和server模式中， OSR的阈值计算公式不同， clint= CompileThredshold * osr比率， server= CompileThredshold * (osr比率 - 解释器监控比率）

—冗余访问消除:#

如果已经拿到了 a.value， 该方法内a.value一定不会变的话， 那么后续用到时就不再从a中取value了
复写传播：

y=b.value
z=y
c = z + y

变成

y = b.value
y = y
c = y + y

无用代码消除：
去掉上面的Y=y

----公共子表达式消除#

就是对一些比较长的计算公式做化简
a+（a+b）2
会优化成
a3+b*2
尽可能减少计算次数

—数组边界检查：#

如果能确定某个for循环里的数组取值操作一定不会超出数组范围，那么在做[]取值操作时，不会做数组边界检查。

—隐式异常处理：#

if(a == null) {
xxx
}
else{
throw Exception
}
优化成
try {
xxx
} catch(Exception e) {
throw e
}

为什么隐式异常处理不能放在早期优化？

----方法内联:#

不能被继承重写的方法，比如私有、构造器、静态之类的方法，可以直接在早期优化中做内联优化。
而其他会被抽象继承实现的方法在编译器无法做内联，因为他不知道实际是用哪一段代码。

• final方法并不是非虚方法（为什么呢）
• 类型继承关系分析CHA： 如果发现虚方法，CHA会查一下当前虚拟机内该方法是否有多个实现， 如果发现只有这一种实现，那么就可以直接内联。
• 如果后续有其他的class动态加载进来后，该方法有多个实现了，并且被使用到了，那么就会抛弃已编译的内联代码，回退到解释状态执行。
• 内联缓存： 即使程序中发现该方法有多个实现， 依然对第一个使用的那个方法做内联，除非有其他重写方法被调用（即虽然你定义了，但是你很可能不用，所以我一直使用你的第一个方法，除非你真的用了多种重写方法去跑。

----逃逸分析：#

分析new 出来的对象是否不会逃逸到方法外， 如果确认只在方法内使用，外部不会有人引用他， 那么就会做优化，比如：
* 不把new出来的对象放到堆，而是放到方法栈上，方法结束了对象直接消失。
* 不需要对这种对象做加锁、同步操作了
* 标量替换: 把这个对象里的最小基本类型成员拆出来作为局部变量使用。

----java和C++， 即时编译和静态编译的区别：#

1. 即时编译可能会影响用户体验，如果在运行中出现较大影响的延迟的话
   2.
   java中虚方法比C要多， 因为做各种内联分析消耗的检查和优化的就越多越大
   3.
   java中总是要做安全检查， C中不做，出错了我就直接崩溃了越界了
   4.
   C中内存释放让用户控制， 无需后台弄一个垃圾回收器总是去检查和操作
   5.
   java好处： 即时编译能够以运行期的性能监控进行优化，这个是C无法做到的。

https://blog.csdn.net/qq_40925525/article/details/98363179

---

编译优化问答题#

@[toc]
首先提出一个问题，为什么C++的编译速度会比java慢很多？二者运行程序的速度差异子啊那？ 了解了java的早期和晚期过程，就能理解这个问题了。

这里会提15个问题确认是否真的理解，如果完全没这方面的概念，则好好看一下前面的早期和晚期编译优化读书笔记

早期编译过程#

---

Q: java早期编译过程分为哪3步？
A:

1. 词法语法解析、填充符号表
2. 注解处理
3. 语义分析与字节码生成。

---

Q: 上面的步骤中， 符号表是干吗的？
A:
符号表是符号地址和符号信息构成的表格。

• 用于后面阶段做语法检查时，从表里取出信息进行对比。
• 符号表是目标代码生成时的地址分配的依据

---

Q: 注解处理器做的什么事情？
A: 注解处理器会扫描抽象语法树中带注解的元素， 并进行语法树的更新。
重点就是他是基于语法树做更新。
更新之后我们会重新走回解析与填充的过程，重新处理。

APT可以用来在编译时扫描和处理注解。
通过APT可以获取到注解和被注解对象的相关信息，在拿到这些信息后我们可以根据需求来自动的生成一些代码，省去了手动编写。 例如@Setter
注意，获取注解及生成代码都是在代码编译时候完成的，相比反射在运行时处理注解大大提高了程序性能。

---

---

Q: 上面的3个步骤中， 解语法糖是哪一步？
A:
是第三步，在生成字节码的时候才做的语法糖处理。

---

Q: 什么是解语法糖？大概有哪些？
A:

• 虚拟机本身不支持这种语法， 但是会在编译阶段 把这些语法糖转为 普通的语法结构。
• 包含自动装拆箱、 泛型强转应用。

---

Q: 生成字节码class文件的时候， final和非final的局部变量， 会有区别不？
A:
没有区别。
局部变量不会在常量池中持有符号引用， 所以不会有acesses_flasg信息。
** 因此final局部变量在运行期没有任何作用， 只会在编译期去校验。**

---

Q: a= 1 + 2会在什么阶段进行优化？
A: 会在早期编译过程的语义分析过程中，进行常量折叠， 变成a=3
同理， 字符串+号优化成stringBuilder.append()这个动作也是该阶段优化的。

---

Q: 类对象加载的过程有一堆顺序（具体见类初始化顺序， 这个顺序在字节码中体现的吗？还是运行的时候再判断顺序？
A:
字节码中体现的。

• 在字节码生成时， 编译器针对对象new的过程，会生成了一个方法，里面写明了成员、构造方法的调用顺序。
• 类静态成员的调用顺序同理封装在中。

---

晚期编译优化#

Q:
早期编译优化和晚期编译优化的区别？
A:

• 早期编译优化， 是把 java文件转成字节码，转字节码的过程中做一些简单优化和语法糖处理。
• 晚期编译优化，是将字节码转机器码执行的过程中，结合一些信息进行动态优化，或者应用上很多的机器码优化措施。

---

Q: java程序运行的时候，是直接全部转成优化后的机器码再运行吗？
A:
错误。

• 当程序刚启动时，会先马上使用解释器发挥作用，这时候没做太多优化，直接解释执行。
• 在程序运行后， 编译器逐步发挥作用，把还没用到的代码逐步编译成机器码。

注意这里的编译器和之前提到的编译器的区别，一个是编译成字节码，另一个是编译成机器码。

---

---

Q: JIT是什么？
A:
为了提高执行速度，便引入了 JIT 技术。
当JVM发现某个方法或代码块运行特别频繁的时候，就会认为这是“热点代码”（Hot Spot Code)。然后JIT会把部分“热点代码”编译成本地机器相关的机器码，并进行优化，然后再把编译后的机器码缓存起来，以备下次使用。

---

Q: 有两种晚期优化编译器

• Client Compiler ——C1编译器
• Server Compiler——C2编译器
  他们二者的区别是什么？

A:

• 速度和质量的区别：
  C1编译器, 更高的编译速度，编译质量一般。
  C2编译器， 更好的编译质量，但是速度慢。
• 优化特性的区别
  C1编译器都是一些不需要运行期信息就能做优化的操作。
  C2编译器则会根据解释器提供的监控信息，进行激进且动态的优化

---

Q: java中怎么区分用C1还是C2？
A:
关于这2种编译器的参数：

• -Xint参数： 强制使用解释模式
• -Xcomp参数： 强制使用编译模式（ 但是如果编译无法进行时， 解释会介入）
• 选择编译模式时，有-client、-server还有MixedMode(混合模式）可以选择

混合模式中， JDK7引入了分层编译策略：
第0层： 解释执行。 不开启性能监控。
第1层： C1编译， 把字节码编译为本地代码， 进行一些简单优化， 加入性能监控
第2层： C2编译， 启动耗时较长的优化， 根据性能监控信息进行激进优化

---

Q: 分层优化中，如果正在运行，jvm是怎么知道需要对哪些代码做JIT或者OSR优化？
A:

1. 被多次调用的方法。 会触发JIT编译（热点代码计数器）
2. 被多次执行的循环体， 会触发OSR编译（栈上替换）， 发生在方法执行过程中， 所以是在栈上编译并切换方法。（使用回边计数器）

---

Q: 哪些方法会在早期优化中做内联，哪些方法会在晚期优化中做内联？
A:

• 不能被继承重写的方法，比如私有、构造器、静态之类的方法，可以直接在早期优化中做内联优化。
• 其他会被抽象继承实现的方法在早期无法做内联，因为他不知道实际是用哪一段代码.
• 晚期优化中可以根据一些运行信息，判断是否总是只用某个子类方法跑，是的话做一下尝试内联，如果后面来了其他的子类就切回去。

---

Q: java数组一般都会自动做边界检查，不满足就抛异常。 什么情况下会优化掉这个自动检查？
A:
运行期，发现传入的参数放到数组中用的时候， 肯定不会超出边界，则会优化掉这个检查动作。

---

看完上面的，就可以给出C++和java编译和运行速度差距的原因了：

1. java即时编译可能会影响用户体验，如果在运行中出现较大影响的延迟的话。
2. java中虚方法比C++要多， 因为做各种内联分析消耗的检查和优化的就越多越大
3. java中总是要做安全检查， C++中不做，出错了我就直接崩溃了越界了
4. C++中内存释放让用户控制， 无需后台弄一个垃圾回收器总是去检查和操作
5. java好处： 即时编译能够以运行期的性能监控进行优化，这个是C++无法做到的