JVM——类加载与字节码技术—类加载器+运行期优化

5.类加载器

jdk的类加载器具有层级关系。

启动类加载器》扩展类加载器》应用程序类加载器》自定义类加载器

 对应类加载器只会负责加载对应目录的类。

双亲委派上级机制

应用程序类加载器加载一个类之前会先查询上级加载器是否已经加载过了该类。然后再让上级询问上上级。都没有时才轮到应用程序类加载器加载。

5.1 启动类加载器

使用启动类加载器命令行加载类。 

 启动类加载器是c++代码编写，不能直接返回。打印出时null说明是启动类加载器。

通过替换启动类加载器的类路径使用启动类加载器加载指定类。

5.2 扩展类加载器

 

在默认情况下都是应用程序类加载器。

在扩展类加载器路径下放一个同名类，扩展类加载器下的类必须是以jar包的方式存在的，所以先打包一份。

jar -cvf 包名.jar  类路径 

复制到扩展类加载器对应目录 

 再次运行测试类

 得到加载的是扩展路径下的G，说明G被扩展类加载器加载了，这里是应用程序类加载器委派了扩展类加载器来加载G

5.3 双亲委派模式

 

5.4 线程上下文类加载器

 

 原本是应该用启动类加载器完成相关联的类的加载，这里却使用了应用程序类加载器

jdk找不到对应类，所以才用了应用程序类加载器。

 按照约定设计jar，配合spi根据接口找到实现类加以实例化。达到解耦效果。

 与spring相似根据接口得到实现类的实例对象。

 线程上下文类加载器是在每个线程启动时由jvm把应用程序类加载器赋值给当前线程，将来线程对调用getContextClassLoader()可以拿到应用程序类加载器。

 所以java  manager本身是启动类加载器加载器的，但是ServiceLoader内存用的是线程上下文类加载器，也是破坏了双亲委派机制，没有用启动类加载器找mysql驱动。

5.5自定义类加载器

使用场景

定义类加载器

 测试类

 使用不同类加载器加载同一个类，两个类比较不仅要包名类名相同，还要类加载器对象相同才能确定是同一个类。

6.运行期优化

6.1即时编译

分层编译

 该例中有两层循环，外层循环对内存循环进行计时统计，内层循环会创建1000个对象

可以看见运行速度有两次明显的下降

 

 原因

即时编译发挥了作用，热点代码

当某个字节码被反复调用，会启用编译器，进行编译执行。有两种_c1和c2即时编译器。

即时编译器会将反复执行的代码编译成机器码存在codecash代码缓存中，下一次直接把编译好的机器码拿出来用。

c1做基本优化，c2做彻底优化，c1多了信息统计的工作。

 

c2编译器发现new Object()的操作未逃逸，外层不会用到，所以直接不创建了，用了别的字节码替换了这部分代码。

关闭逃逸分析再运行发现后一次下降已经没了

方法内联

 

内存循环反复调用方法，外层循环统计时间。

 

 可以看见运行时间也有两次大优化，最后到0是因为jvm认为是常量，直接不变了

通过设置参数进行内联情况打印

循环了多次之后直接打成了热点代码，进行了内联。

 禁用内联的参数

直接指定一个方法，不让其内联

 

字段优化

针对（静态）成员变量读写进行优化。

第一个注解:预热，让编译器对代码进行优化

第二个注解: 进行多少轮测试 

 三种循环方式进行累加。

dosum上的注解用于控制是否进行方法内联。

第一个是直接循环原数组累加，第二个是用别的数组变量接收原数组累加，第三个是foreach原数组累加。

看到了三个循环的得分，误差，每秒吞吐量单位

得分越高越好，现在三个得分都相差不多

 禁止方法内联之后

 允许方法内联之后会直接把doSum内的方法拷贝放到调用者位置。

第一个的:

 第二个的：

通过一次手动优化就不用每次都去class里面找，直接本地变量表回去长度和地址

在方法内联时第一个方法会由虚拟机进行优化，和第二个的效果一样。

第三个的:

转换后的代码和第二个等价，效果一样。

 第一个是运行期间优化，第二个是手动优化，第三个是编译期间优化。

就是之前test1中，编译器针对方法是否内联进行了读取方面相关的优化，首次读取，后续简化

6.2 反射优化

反射是java提供的一个重要功能，可以在运行时检查类、接口、方法和变量等信息，无需知道类的名字，方法名等。还可以在运行时实例化新对象，调用方法以及设置和获取变量值。

反射非常强大和有用，很多java框架中都有反射的影子，例如spring、mybatis等等，

JDBC利用反射将数据库的表字段映射到java对象的getter/setter方法。

Jackson, GSON, Boon等类库也是利用反射将JSON文件的属性映射到java对的象getter/setter方法。

可见，只要使用java，反射就无处不在。

上面代码中有一个静态方法，main方法内通过类对象获得了方法对象，进行了17次调用，

通过invoke执行方法对象的反射调用。前16次调用性能较低，最后一次性能较高。

 

 

 invoke方法里面通过一个方法访问器接口进去，进去第一个实现后调用了第三个实现本地方法访问器。

本地方法访问器里面有调用一个native本地方法。效率较低。

 但是这里面会记录调用次数，和一个膨胀阈值进行比较，默认是15。

 大于15次之后会把本地方法访问器替换成一个运行期间动态生成的新的方法访问器。

用该工具查看运行期间动态生产的字节码

 

在新生成的方法访问器里面的invoke里通过Reflect1类调用了foo()静态方法，已经不是反射调用了。

jvm在第17次将反射调用变成了正常的方法调用。