从字节码角度解析synchronized和反射实现原理

 更新时间:2023年08月15日 09:01:01   作者:悦  
这篇文章主要介绍了从字节码角度解析synchronized和反射的实现原理,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪

引言

前几天,关于字节码技术,我们讲了字节码的基础, 常见的字节码框架以及在软件破解和APM链路监控方面的一些应用.

今天我们回到Java本身, 看下我们常用的synchronized关键字和反射在字节码层面是如何实现的.

synchronized

代码块级别的 synchronized

如下方法的内部使用了synchronized关键字

private Object lock = new Object();
public void foo() {
    synchronized (lock) {
        bar();
    }
}
public void bar() { }

编译成字节码如下

public void foo();
    Code:
       0: aload_0
       1: getfield      #3                  // Field lock:Ljava/lang/Object;
       4: dup
       5: astore_1
       6: monitorenter
       7: aload_0
       8: invokevirtual #4                  // Method bar:()V
      11: aload_1
      12: monitorexit
      13: goto          21
      16: astore_2
      17: aload_1
      18: monitorexit
      19: aload_2
      20: athrow
      21: return
    Exception table:
       from    to  target type
           7    13    16   any
          16    19    16   any

Java 虚拟机中代码块的同步是通过 monitorenter 和 monitorexit 两个支持 synchronized 关键字语意的。比如上面的字节码

  • 0 ~ 5:将 lock 对象入栈,使用 dup 指令复制栈顶元素,并将它存入局部变量表位置 1 的地方,现在栈上还剩下一个 lock 对象
  • 6:以栈顶元素 lock 做为锁,使用 monitorenter 开始同步
  • 7 ~ 8:调用 bar() 方法
  • 11 ~ 12:将 lock 对象入栈,调用 monitorexit 释放锁

monitorenter 对操作数栈的影响如下

  • 16 ~ 20:执行异常处理,我们代码中本来没有 try-catch 的代码,为什么字节码会帮忙加上这段逻辑呢?
    因为编译器必须保证,无论同步代码块中的代码以何种方式结束(正常 return 或者异常退出),代码中每次调用 monitorenter 必须执行对应的 monitorexit 指令。为了保证这一点,编译器会自动生成一个异常处理器,这个异常处理器的目的就是为了同步代码块抛出异常时能执行 monitorexit。这也是字节码中,只有一个 monitorenter 却有两个 monitorexit 的原因

可理解为这样的一段 Java 代码

public void _foo() throws Throwable {
    monitorenter(lock);
    try {
        bar();
    } finally {
        monitorexit(lock);
    }
}

根据我们之前介绍的 try-catch-finally 的字节码实现原理,复制 finally 语句块到所有可能函数退出的地方,上面的代码等价于

public void _foo() throws Throwable {
    monitorenter(lock);
    try {
        bar();
        monitorexit(lock);
    } catch (Throwable e) {
        monitorexit(lock);
        throw e;
    }
}

方法级的 synchronized

方法级的同步与上述有所不同,它是由常量池中方法的 ACC_SYNCHRONIZED 标志来隐式实现的。

synchronized public void testMe() {
}
对应字节码
public synchronized void testMe();
descriptor: ()V
flags: ACC_PUBLIC, ACC_SYNCHRONIZED

JVM 不会使用特殊的字节码来调用同步方法,当 JVM 解析方法的符号引用时,它会判断方法是不是同步的(检查方法 ACC_SYNCHRONIZED 是否被设置)。如果是,执行线程会先尝试获取锁。如果是实例方法,JVM 会尝试获取实例对象的锁,如果是类方法,JVM 会尝试获取类锁。在同步方法完成以后,不管是正常返回还是异常返回,都会释放锁.

反射

在 Java 中反射随处可见,它底层的原也比较有意思,这篇文章来详细介绍反射背后的原理。

先来看下面这个例子:

public class ReflectionTest {
    private static int count = 0;
    public static void foo() {
        new Exception("test#" + (count++)).printStackTrace();
    }
    public static void main(String[] args) throws Exception {
        Class<?> clz = Class.forName("ReflectionTest");
        Method method = clz.getMethod("foo");
        for (int i = 0; i < 20; i++) {
            method.invoke(null);
        }
    }
}

运行结果如下

可以看到同一段代码,运行的堆栈结果与执行次数有关系,在 0 ~ 15 次调用方式为sun.reflect.NativeMethodAccessorImpl.invoke0,从第 16 次开始调用方式变为了sun.reflect.GeneratedMethodAccessor1.invoke。原因是什么呢?继续往下看。

反射方法源码分析

Method.invoke 源码如下:

可以最终调用了MethodAccessor.invoke方法,MethodAccessor 是一个接口

public interface MethodAccessor {
    public Object invoke(Object obj, Object[] args)
        throws IllegalArgumentException, InvocationTargetException;
}

从输出的堆栈可以看到 MethodAccessor 的实现类是委托类DelegatingMethodAccessorImpl,它的 invoke 函数非常简单,就是把调用委托给了真正的实现类。

class DelegatingMethodAccessorImpl extends MethodAccessorImpl {
    private MethodAccessorImpl delegate;
    public Object invoke(Object obj, Object[] args)
        throws IllegalArgumentException, InvocationTargetException
    {
        return delegate.invoke(obj, args);
    }

通过堆栈可以看到在第 0 ~ 15 次调用中,实现类是 NativeMethodAccessorImpl,从第 16 次调用开始实现类是 GeneratedMethodAccessor1,为什么是这样呢?玄机就在 NativeMethodAccessorImpl 的 invoke 方法中

前 0 ~ 15 次都会调用到invoke0,这是一个 native 的函数。

private static native Object invoke0(Method m, Object obj, Object[] args);

有兴趣的同学可以去看一下 Hotspot 的源码,依次跟踪下面的代码和函数:

./jdk/src/share/native/sun/reflect/NativeAccessors.c
JNIEXPORT jobject JNICALL Java_sun_reflect_NativeMethodAccessorImpl_invoke0
(JNIEnv *env, jclass unused, jobject m, jobject obj, jobjectArray args)
./hotspot/src/share/vm/prims/jvm.cpp
JVM_ENTRY(jobject, JVM_InvokeMethod(JNIEnv *env, jobject method, jobject obj, jobjectArray args0))
./hotspot/src/share/vm/runtime/reflection.cpp
oop Reflection::invoke_method(oop method_mirror, Handle receiver, objArrayHandle args, TRAPS)

这里不详细展开 native 实现的细节。
15 次以后会走新的逻辑,使用 GeneratedMethodAccessor1 来调用反射的方法。MethodAccessorGenerator 的作用是通过 ASM 生成新的类 sun.reflect.GeneratedMethodAccessor1。为了查看整个类的内容,可以使用阿里的 arthas 工具。修改上面的代码,在 main 函数的最后加上System.in.read();让 JVM 进程不要退出。 执行 arthas 工具中的./as.sh,会要求输入 JVM 进程

选择在运行的 ReflectionTest 进程号 7 就进入到了 arthas 交互性界面。执行 dump sun.reflect.GeneratedMethodAccessor1文件就保存到了本地。

来看下这个类的字节码

翻译一下这个字节码,忽略掉异常处理以后的代码如下

public class GeneratedMethodAccessor1 extends MethodAccessorImpl {
    @Override
    public Object invoke(Object obj, Object[] args)
            throws IllegalArgumentException, InvocationTargetException {
        ReflectionTest.foo();
        return null;
    }
}

那为什么要采用 0 ~ 15 次使用 native 方式来调用,15 次以后使用 ASM 新生成的类来处理反射的调用呢?

一切都是基于性能的考虑。JNI native 调用的方式要比动态生成类调用的方式慢 20 倍,但是又由于第一次字节码生成的过程比较慢。如果反射仅调用一次的话,采用生成字节码的方式反而比 native 调用的方式慢 3 ~ 4 倍。

inflation 机制

因为很多情况下,反射只会调用一次,因此 JVM 想了一招,设置了 15 这个 sun.reflect.inflationThreshold 阈值,反射方法调用超过 15 次时(从 0 开始),采用 ASM 生成新的类,保证后面的调用比 native 要快。如果小于 15 次的情况下,还不如生成直接 native 来的简单直接,还不造成额外类的生成、校验、加载。这种方式被称为 「inflation 机制」。inflation 这个单词也比较有意思,它的字面意思是「膨胀;通货膨胀」。

JVM 与 inflation 相关的属性有两个,一个是刚提到的阈值 sun.reflect.inflationThreshold,还有一个是是否禁用 inflation的属性 sun.reflect.noInflation,默认值为 false。如果把这个值设置成true 的话,从第 0 次开始就使用动态生成类的方式来调用反射方法了,不会使用 native 的方式。

增加 noInflation 属性重新执行上述 Java 代码

java -cp . -Dsun.reflect.noInflation=true ReflectionTest

输出结果为

java.lang.Exception: test#0
        at ReflectionTest.foo(ReflectionTest.java:10)
        at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at ReflectionTest.main(ReflectionTest.java:18)
java.lang.Exception: test#1
        at ReflectionTest.foo(ReflectionTest.java:10)
        at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at ReflectionTest.main(ReflectionTest.java:18)

可以看到,从第 0 次开始就已经没有使用 native 方法来调用反射方法了。

小结

这篇文章主要从字节码角度看了Java中的synchronized和射调用底层的原理,当然还有一些其他比较有意思的语法比如lambda, switch等, 感兴趣的小伙伴也可以从字节码角度去了解一下, 相信你会有很多不一样的收获,更多关于字节码解析synchronized反射的资料请关注脚本之家其它相关文章!

相关文章

  • SSM框架下如何实现数据从后台传输到前台

    SSM框架下如何实现数据从后台传输到前台

    这篇文章主要介绍了SSM框架下如何实现数据从后台传输到前台,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教
    2022-05-05
  • Java中Swing类实例讲解

    Java中Swing类实例讲解

    这篇文章主要介绍了Java中Swing类实例讲解,文中用代码实例讲解的很清楚,有需要的同学可以研究下
    2021-02-02
  • java不同线程解读以及线程池的使用方式

    java不同线程解读以及线程池的使用方式

    这篇文章主要介绍了java不同线程解读以及线程池的使用方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
    2024-08-08
  • Springboot2.x+Quartz分布式集群的实现

    Springboot2.x+Quartz分布式集群的实现

    这篇文章主要介绍了Springboot2.x+Quartz分布式集群的实现,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
    2020-09-09
  • java增强for循环的实现方法

    java增强for循环的实现方法

    下面小编就为大家带来一篇java增强for循环的实现方法。小编觉得挺不错的,现在就分享给大家,也给大家做个参考。一起跟随小编过来看看吧
    2016-09-09
  • Java java.lang.InstantiationException异常案例详解

    Java java.lang.InstantiationException异常案例详解

    这篇文章主要介绍了Java java.lang.InstantiationException异常案例详解,本篇文章通过简要的案例,讲解了该项技术的了解与使用,以下就是详细内容,需要的朋友可以参考下
    2021-08-08
  • 如何解决创建maven工程时,产生“找不到插件的错误”问题

    如何解决创建maven工程时,产生“找不到插件的错误”问题

    这篇文章主要介绍了如何解决创建maven工程时,产生“找不到插件的错误”问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
    2023-12-12
  • java中的常用集合类整理

    java中的常用集合类整理

    在本篇文章里小编给大家整理的是关于java中的常用集合类的相关知识点内容,有兴趣的朋友们学习下。
    2019-12-12
  • idea 自动生成类注释和方法注释的实现步骤

    idea 自动生成类注释和方法注释的实现步骤

    这篇文章主要介绍了idea 自动生成类注释和方法注释的实现步骤,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
    2019-12-12
  • Spring Boot 配置随机数的技巧代码详解

    Spring Boot 配置随机数的技巧代码详解

    这篇文章主要介绍了Spring Boot 配置随机数技巧,spring boot 支持在系统加载的时候配置随机数,具体实例代码大家参考下本文
    2018-05-05

最新评论