JVM系列之:从汇编角度分析NullCheck

简介: JVM系列之:从汇编角度分析NullCheck

目录



简介



之前我们在讲Virtual call的时候有提到,virtual call方法会根据传递的参数实例的不同而进行优化,从而优化成为classic call,从而提升执行效率。


今天我们考虑一下,在virtual call中执行nullcheck的时候,如果已经知道传递的参数是非空的。JIT会对代码进行优化吗?


一起来看看吧。


一个普通的virtual call



我们来分析一下在方法中调用list.add方法的例子:


public class TestNull {
    public static void main(String[] args) throws InterruptedException {
        List<String> list= new ArrayList();
      list.add("www.flydean.com");
        for (int i = 0; i < 10000; i++)
        {
            testMethod(list);
        }
        Thread.sleep(1000);
    }
    private static void testMethod(List<String> list)
    {
        list.get(0);
    }
}


代码很简单,我们在循环中调用testMethod方法,而这个方法里面又调用了list.get(0)方法,来获取list的第一个参数。


单纯的看testMethod,这个方法是有可能抛出NullPointerException的,但是从整体运行的角度来看,因为我们的list是有值的, 所以不会抛出异常。


使用JIT Watcher看看运行结果:


image.png


先看第二个和第三个红框,我们可以看到代码先做了参数类型的比较,然后对testMethod进行了优化,这里还可以看到get方法是内联到testMethod中的。


代码优化的部分我们找到了,那么异常处理呢?如果list为空,应该怎么处理异常呢?


第一个红框,大家可以看到是一个隐式的异常处理,它重定向到1152b4f01这个地址。


第四个红框就是这地址,表示的是异常处理的代码。


普通方法中的null check



我们在上面的普通方法里面加上一个null check:


public class TestNull1 {
    public static void main(String[] args) throws InterruptedException {
        List<String> list= new ArrayList();
        list.add("www.flydean.com");
        for (int i = 0; i < 10000; i++)
        {
            testMethod(list);
        }
        Thread.sleep(1000);
    }
    private static void testMethod(List<String> list)
    {
        if(list !=null ){
            list.get(0);
        }
    }
}


上面我们添加了一个list !=null的判断。


运行看下结果:


image.png



相比较而言,我们可以看到,代码其实没有太多的变化,说明JIT在代码优化的过程中,将null check优化掉了。


那么null check到底在什么地方呢? 看我标红的第二个框,这里是之前的异常处理区域,我们可以看到里面有一个ifnull,表明这里做了null check。


反优化的例子



上面的两个例子,我们可以看出在virtual method中,JIT对null check进行了优化。接下来我们再看一个例子,在这个例子中,我们显示的传递一个null给testMethod,然后再次循环testMethod,如下所示。


for (int i = 0; i < 10000; i++)
        {
            testMethod(list);
        }
        Thread.sleep(1000);
        testMethod(null);
for (int i = 0; i < 10000; i++)
        {
            testMethod(list);
        }


我们看下JIT的结果:


image.png


看下结果有什么不同呢?


第一,ifnull现在是显示调用的,并不包含在隐式异常中。


第二,隐式异常也不见了,因为使用显示的ifnull。


总结



JIT会根据不同的情况,对代码进行不同程度的优化,希望大家能够喜欢。

相关文章
|
26天前
|
监控 算法 Java
jvm-48-java 变更导致压测应用性能下降,如何分析定位原因?
【11月更文挑战第17天】当JVM相关变更导致压测应用性能下降时,可通过检查变更内容(如JVM参数、Java版本、代码变更)、收集性能监控数据(使用JVM监控工具、应用性能监控工具、系统资源监控)、分析垃圾回收情况(GC日志分析、内存泄漏检查)、分析线程和锁(线程状态分析、锁竞争分析)及分析代码执行路径(使用代码性能分析工具、代码审查)等步骤来定位和解决问题。
|
6月前
|
缓存 Java
《JVM由浅入深学习九】 2024-01-15》JVM由简入深学习提升分(生产项目内存飙升分析)
《JVM由浅入深学习九】 2024-01-15》JVM由简入深学习提升分(生产项目内存飙升分析)
57 0
|
2月前
|
小程序 Oracle Java
JVM知识体系学习一:JVM了解基础、java编译后class文件的类结构详解,class分析工具 javap 和 jclasslib 的使用
这篇文章是关于JVM基础知识的介绍,包括JVM的跨平台和跨语言特性、Class文件格式的详细解析,以及如何使用javap和jclasslib工具来分析Class文件。
59 0
JVM知识体系学习一:JVM了解基础、java编译后class文件的类结构详解,class分析工具 javap 和 jclasslib 的使用
|
2月前
|
存储 Java PHP
【JVM】垃圾回收机制(GC)之引用计数和可达性分析
【JVM】垃圾回收机制(GC)之引用计数和可达性分析
85 0
|
5月前
|
Java
jmap 查看jvm内存大小并进行dump文件内存分析
jmap 查看jvm内存大小并进行dump文件内存分析
126 3
|
5月前
|
运维 监控 Java
(十)JVM成神路之线上故障排查、性能监控工具分析及各线上问题排错实战
经过前述九章的JVM知识学习后,咱们对于JVM的整体知识体系已经有了全面的认知。但前面的章节中,更多的是停留在理论上进行阐述,而本章节中则更多的会分析JVM的实战操作。
133 1
|
5月前
|
Arthas 监控 Java
JVM内存问题之使用gperftools分析JNI Memory泄漏的具体步骤是什么
JVM内存问题之使用gperftools分析JNI Memory泄漏的具体步骤是什么
136 2
|
4月前
|
监控 JavaScript Java
JVM源码级别分析G1发生FullGC元凶的是什么
线上系统遭遇频繁Old GC问题,监控显示出现多次“to-space exhausted”日志,这表明垃圾回收过程中因年轻代 Survivor 区或老年代空间不足导致对象晋升失败。通过 JVM 源码分析,此问题源于对象转移至老年代失败时,JVM 无法找到足够的空间存放存活对象。进一步排查发现大对象分配占用了预留空间,加剧了空间不足的情况。使用 JFR 分析工具定位到定期报表序列化导致大量大对象生成,通过改用堆外内存进行序列化输出,最终解决了频繁 Old GC 问题。
151 0
|
5月前
|
监控 Java 开发者
Java面试题:如何使用JVM工具(如jconsole, jstack, jmap)来分析内存使用情况?
Java面试题:如何使用JVM工具(如jconsole, jstack, jmap)来分析内存使用情况?
232 2
|
5月前
|
人工智能 Java
JVM内存问题之当老年代缓慢增加且Full GC无法清除时,应如何使用MAT进行分析
JVM内存问题之当老年代缓慢增加且Full GC无法清除时,应如何使用MAT进行分析
270 0