开发过程中,后台的参数校验是必不可少的,本文关于 spring-boot-starter-validation
的学习笔记。
规则引擎Drools模板编译
规则引擎 Drools 模板编译
1.模板编译
1.1依赖
1 | <dependency> |
1.2建立模板
新建模板文件 test.drt
1 | template header |
说明
规则模板主要由两部分构成:
Template header 定义了在模板中使用的变量。
模板中以 “template name” 开头, 以”end template” 结尾, 中间定义了模板的内容。变量占位符使用 @{variable_name} .
@{row.rowNumber}是一个特殊的变量, 每次会按顺序生成一个行号, 可用于区分规则名。
1.3 渲染模板生成规则文件
渲染模板的流程,先将数据封装为 DataProvider,然后通过 DataProviderCompiler 使用 DataProvider 将模板编译为 DRL。
Drools支持数组类型的DataProvider, ArrayDataProvider实现了DataProvider, 示例
1 | InputStream templateStream = DataDrivenTemplateExample.class.getResourceAsStream("/rules/SimpleTemplateExample.drt"); |
1.4 编译规则
在模板渲染、编译成规则文件后,就可以正常的编译DRL规则文件, 新建会话等。
KieHelper 是 Drools提供的工具类, 可用于编译DRL规则文件, 新建会话等。
ps: 也可以使用其他的方式编译,这里只是为了简单
1 | KieHelper helper = new KieHelper(); |
1.5 模板编译示例
1.5.1 DRT模板文件 template.drt
1 | template header |
1.5.2 单元测试
1 | public class Demo { |
1.5.3 输出
-----模板DRT渲染后的DRL-----
package template
rule "test_0"
when
String(this == "规则条件")
then
System.out.println("规则动作");
end
-----模板DRT渲染后的DRL-----
规则动作
2 本地加载与远程加载
2.1 创建本地DRL文件
创建远程的DRL文件,地址为 E:\native.drl
1 | package rules.native; |
2.2 创建远程DRL文件
创建远程的DRL文件,地址为 http://localhost:8761/remote.drl
1 | package rules.remote; |
2.3 单元测试
1 | public class Demo { |
2.4 输出
远程加载成功
本地加载成功
3 总结
关键API:
Resource: 资源类,规则文件的加载
KnowledgeBuilder: 收集编译已经编写好的规则文件(drl)
从整体的收集、编译、执行上看,远程加载与本地加载大同小异,无非就是在使用Resource时加载规则文件上的不同。使用模板则在此基础上,需要将模板(drt)编译成规则(drl)。
文章标题
文章摘要写在前面,支持markdown左右语法。
JVM-内存结构
JVM-类加载机制
1.2 类加载机制
1.2.1 编译
1 | javac JVMTest1.java |
结果产生了两个 class 文件,如下所示:
JVMTest1.class
1 | // |
Demo.class
1 | // |
反编译
1 | javap -v -p Demo > a.txt |
反编译结果如下:
1 | // 描述信息 |
指令参考:https://docs.oracle.com/javase/specs/jvms/se8/html/index.html
1.2.2 加载
JVM 是如何加载 class 文件的呢?
当一个类被创建实例或者被引用到的时候, 如果虚拟机发现之前没有加载过这个类,就会通过类加载器(也就是 ClassLoader )把 class 文件加载到内存。
在加载的过程中主要做了 3 件事:
- 读取类的二进制流。
- 把二进制流转为方法区数据结构,并存放到方法区。
- 最后,在 Java 堆中产生 java.lang.Class 对象。
1.2.3 链接
class 文件加载完成后,会进入“链接”这个步骤,链接这个步骤又可以分为“验证”、“准备”和“解析”。
1.2.3.1 验证
验证——顾名思义,就是验证 class 文件是不是符合规范,这里面包含了多个层次的验证,包括:
文件格式的验证
- 是否以
0xCAFEBABE
开头(可以用 16 进制编辑器打开查看) - 版本好是否合理
- 是否以
元数据验证
- 是否有父类
- 是否继承了 final 类(final 类是不能被继承的,如果继承了,那就是有问题)
- 非抽象类是否实现了所有抽象方法(没有,那就是有问题)
字节码验证
字节码的验证是非常复杂的,一个 class 文件能够通过字节码验证并不代表它没有问题,但是如果它没有通过字节码验证,那就一定有问题。
- 运行检查
- 栈数据类型和操作码操作参数吻合(比如栈空间只有 2 字节,但其实却需要大于 2 字节,此时就认为这个字节码是有问题的)
- 跳转指令是不是指向合理的位置
符号引用验证
- 常量池中描述类是否存在
- 访问的方法或字段是否存在且有足够的权限
如果事先已经确认代码是安全无误的可以在启动的时候用
-Xverify:none
关闭验证。
1.2.3.2 准备
如果通过验证发现没有问题的话,就会进入准备环节。
准备环节的作用:
- 为类的静态变量分配内存,初始化为系统的初始值
- final static 修饰的变量:直接赋值为用户定义的值,比如
private final static int value =123
,直接赋值 123。 - 但是
private static int value = 123
, 该阶段的值依然是 0。
- final static 修饰的变量:直接赋值为用户定义的值,比如
1.2.3.3 解析
“准备”完成后,就可以进入解析了。
解析的作用:把符号引用转换成直接引用。
什么是符号引用?
符号引用(Symbolic References):符号引用以一组符号来描述所引用的目标,符号可以是任何形式的字面量,只要使用时能够无歧义的定位到目标即可。例如,在Class文件中它以CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等类型的常量出现。符号引用与虚拟机的内存布局无关,引用的目标并不一定加载到内存中。在Java中,一个java类将会编译成一个class文件。在编译时,java类并不知道所引用的类的实际地址,因此只能使用符号引用来代替。比如org.simple.People类引用了org.simple.Language类,在编译时People类并不知道Language类的实际内存地址,因此只能使用符号org.simple.Language(假设是这个,当然实际中是由类似于CONSTANT_Class_info的常量来表示的)来表示Language类的地址。各种虚拟机实现的内存布局可能有所不同,但是它们能接受的符号引用都是一致的,因为符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中。
什么是直接引用?
可以是
- 直接指向目标的指针(比如,指向“类型”【Class对象】、类变量、类方法的直接引用可能是指向方法区的指针)
- 相对偏移量(比如,指向实例变量、实例方法的直接引用都是偏移量)
- 一个能间接定位到目标的句柄
直接引用是和虚拟机的布局相关的,同一个符号引用在不同的虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用,那引用的目标必定已经被加载入内存中了。
1.2.4 初始化
解析完成之后,就会进入初始化这个阶段。在这个阶段,JVM首先会执行
- 初始化的顺序和源文件中的顺序一致
- 子类的
被调用前,会先调用父类的 - JVM 会保证 clinit 方法的线程安全性
示例1:
1 | public class JVMTest2 { |
执行结果:
1 | JVMTest2 静态块 |
示例2:
1 | public class JVMTest3 { |
执行结果:
1 | JVMTest3 静态块 |
1.2.5 使用
初始化完成之后就可以使用这个类了。
1.2.6 卸载
但不使用这个类的话,可以把它卸载掉。
1.2.7 小节
章节 1.2 的图表示的是一般的类加载流程,而事实上类加载的时候并不一定完全按照这个流程走。例如,解析不一定在初始化之前,也有可能在初始化之后去做。
1.3 编译器优化
1.3.1 字节码是如何运行的?
解释执行:由解释器一行一行翻译执行
- 优势在于没有编译的等待时间
- 性能相对差一些
编译执行:把字节码编译成机器码,直接执行机器码
- 运行效率会高很多,一般认为比解释执行快一个数量级
- 带来了额外的开销
那么如何查看自己的java是解释执行还是编译执行呢?
1 | $ java -version |
mixed mode 代表混合执行,部分解释执行、部分编译执行。
-Xint:设置JVM的执行模式为解释执行模式
1
2
3
4$ java -Xint -version
java version "1.8.0_251"
Java(TM) SE Runtime Environment (build 1.8.0_251-b08)
Java HotSpot(TM) 64-Bit Server VM (build 25.251-b08, interpreted mode)-Xcomp:JVM优先以编译模式运行,不能编译的,以解释模式运行
1
2
3
4$ java -Xcomp -version
java version "1.8.0_251"
Java(TM) SE Runtime Environment (build 1.8.0_251-b08)
Java HotSpot(TM) 64-Bit Server VM (build 25.251-b08, compiled mode)-Xmixed:以混合模式运行
一般情况下,我们的代码一开始一般由解释器解释执行。但是当虚拟机发现某个方法或代码块的运行特别频繁的时候,就会认为这些代码是热点代码(如何定位?)。为了提高热点代码的执行效率,会用即使编译器(也就是JIT)把这些热点代码编译城与本地平台相关的机器码,并进行各层次的优化(操作系统的不同、CPU架构的不同)
1.3.2 Hotspot 的即时编译器 C1
- 是一个简单快速的编译器
- 主要关注局部性的优化
- 适用于执行时间较短或启动性能有要求的程序。例如。GUI应用对界面启动速度就有一定要求。、
- 也被称为 Client Compiler
1.3.3 Htospot 的即时编译器 C2
- 是为长期运行的服务器端应用程序做性能调优的编译器
- 适用于执行时间较长或对峰值性能有要求的程序
- 也被称为是 Server Compiler
1.3.4 分层编译
从JDK7开始,正式引入了分层编译的概念,可以细分为 5 种编译级别:
- 解释执行
- 简单 C1 编译:会用 C1 编译器进行一些简单的优化,不开启 Profiling(JVM性能监控)
- 受限的 C1 编译:仅执行带方法调用次数以及循环回边执行次数Profiling的 C1 编译
- 完全C1编译:会执行带有所有Profiling的C1代码
- C2 编译:使用C2编译器进行优化,该级别会启用一些编译耗时较长的优化,一些情况下会根据性能监控信息进行一些非常激进的性能优化
级别越高,应用启动越慢,优化的开销越高,峰值性能也越高。
1.3.5 分层编译- JVM参数配置示例
- 只想开启 C2:-XX:-TieredCompilation(禁用中间编译层(123层))
- 只想开启 C1:-XX:+TieredCompilation -XX:TieredStopAtLevel=1
1.3.6 如何找到热点代码?思路?
基于采样的热点探测
周期性检查各个线程的栈顶,如果发现某一些方法总是出现在各个栈顶,那就说明是热点代码。
基于计数器的热点探测
大致思路是为每一个方法甚至是代码块建立计数器,然后统计执行的次数,如果超过一定的阈值,那就说明它是热点代码。Hotspot虚拟机采用的就是基于计数器的热点探测。
1.3.7 Hotspot 内置的两类计数器
方法调用计数器(Invocation Counter)
用于统计方法被调用的次数,在不开启分层编译的情况下,在 C1 编译器下的默认阈值是 1500 次,在 C2 模式下是 10000次。也可以哦那个 -XX:CompileThreshold=X 指定阈值
回边计数器(Back Edge Counter)
- 用于统计一个方法中循环体代码执行的次数,在字节码中遇到控制流向后跳转的指令称为“回边”(Back Edge)。在不开启分层编译的情况下,C1 编译器心爱的默认阈值 13995,C2 默认为 10700,可使用 -XX:OnStackReplacePercentage=X指定阈值
- 建立回边计数器的主要目的是为了触发 OSR (OnStackReplacement)编译,参考文档(https://www.zhihu.com/question/45910849/answer/100636125)
当开启分层编译时,JVM会根据当前编译的方法数以及编译线程数来动态调整阈值,-XX:CompileThreshold、-XX:OnStackReplacePercentage 都会失效。
1.3.8 方法调用计数器流程
如果不做任何设置,方法调用次数统计的并不是方法被调用的绝对次数,而是一个相对的执行频,即一段时间之内方法被调用的次数。当超过一定的时间限度,如果方法的调用次数荏苒不足以让它提交给及时编译器编译,那这个方法的调用计数器就会减少一半,这个过程称为方法调用计数器热度的衰减,而这段时间就称为此方法统计的半衰周期。进行热度衰减的动作是在虚拟机进行垃圾手机是顺便进行的,可以使用虚拟机参数-XX:-UseCounterDecay来关闭热度衰减,让方法计数器统计方法调用的绝对次数,这样,只要系统运行时间足够长,绝大部分方法都会被编译成本地代码。另外,可以使用-XX:CounterHalfLifeTime参数设置半衰周期的时间,单位是秒。
1.3.9 回边计数器流程
1.3.10 方法内联
什么事方法内联?示例?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16package com.example;
public class InlineTest1 {
private static int add1(int x1, int x2, int x3, int x4) {
return add2(x1, x2) + add2(x3, x4);
}
public static int add2(int x1, int x2) {
return x1 + x3;
}
// 内联后
private static int addInline(int x1, int x2, int x3, int x4) {
return x1 + x2 + x3 + x4;
}
}方法内联的条件 -1