【JVM】深入了解java反射机制

已于 2024-06-27 11:39:00 修改
阅读量629 收藏 26
点赞数 27
文章标签： java jvm 开发语言
于 2024-06-27 10:54:48 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43567361/article/details/140000604
版权

(注：文章总结自极客时间郑雨迪老师的《深入拆解java虚拟机》课程，且自己做了一些测试和修正)

反射是 Java 语言中一个相当重要的特性，它允许正在运行的 Java 程序观测，甚至是修改程序的动态行为。

1 常用反射API简介

1.1 获取class对象

  1. Class.forName(“类名”)
  2. 对象.getClass() 方法
  3. 类名.class
  4. 对于基本类型来说，它们的包装类型拥有一个名为“TYPE”的 final 静态字段，指向该基本类型对应的 Class 对象。例如，Integer.TYPE 指向 int.class

1.2 类对象的的常用api

  1. 类对象. newInstance()，生成一个该类的实例。它要求该类中拥有一个无参数的构造器。
  2. 类对象.isInstance(Object)，判断一个对象是否该类的实例。
  3. Array.newInstance(Class,int)，构造该类型的数组。
  4. getFields()/getConstructors()/getMethods()，访问该类的成员。

注：类对象的方法中，方法名中带 Declared 的不会返回父类的成员，但是会返回私有成员；而不带 Declared 的则相反。

1.3 类成员的常用api

  1. Constructor/Field/Method.setAccessible(true) ，绕开 Java 语言的访问限制。
  2. Constructor.newInstance(Object[])，生成该类的实例。
  3. Field.get/set(Object)，访问字段的值。
  4. Method.invoke(Object, Object[])，调用方法。

2 反射调用的实现

每个 Method 实例的第一次反射调用都会生成一个委派实现，它所委派的具体实现便是一个本地实现。本地实现非常容易理解。当进入了 Java 虚拟机内部之后，我们便拥有了 Method 实例所指向方法的具体地址。这时候，反射调用无非就是将传入的参数准备好，然后调用进入目标方法。

import java.lang.reflect.Method;

public class Main {
    public static void test(int i) {
        new Exception("#" + i).printStackTrace();
    }

    public static void main(String[] args) throws Exception {
        Class<?> clazz = Class.forName("Main");
        Method method = clazz.getMethod("test", int.class);
        method.invoke(null, 0);
    }
}

运行结果

java.lang.Exception: #0
	at Main.test(Main.java:8)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at Main.main(Main.java:14)

可以看到，反射调用先是调用了 Method.invoke，然后进入委派实现（DelegatingMethodAccessorImpl），再然后进入本地实现（NativeMethodAccessorImpl），最后到达目标方法。

为什么要先进入委派实现才调用本地实现呢？

java 反射机制中有另一种动态生成字节码的实现，直接使用invoke指令来调用目标方法。之所以采用委派实现，是为了能够在本地实现和动态生成自己吗实现中切换。

动态生成字节码实现比起本地实现来说，运行效率快20倍左右，这是因为动态实现无需经过Java到C++再到Java的转换，但是因为生成字节码的过程很好使，所以仅调用一次的时候，反而是本地实现更快，快3-4倍左右。

这时候，java虚拟机的机制介入了，java虚拟机设置了一个阈值可以通过 -Dsun.reflect.inflationThreshold= 来调整），当某个反射调用的调用次数在15次以下的时候，只采用本地实现，当达到15次时，开始动态生成字节码，并将委派实现和委派对象切换至动态实现，这个过程我们成为Inflation。

我们来做个测试看下堆栈的不同

import java.lang.reflect.Method;

public class Main {
    public static void test(int i) {
        new Exception("#" + i).printStackTrace();
    }

    public static void main(String[] args) throws Exception {
        Class<?> clazz = Class.forName("Main");
        Method method = clazz.getMethod("test", int.class);
        for (int i = 1; i <= 20; i++) {
            method.invoke(null, i);
        }
    }
}

使用java -verbose:class Main.java运行结果

java.lang.Exception: #15
        at Main.test(Main.java:9)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at Main.main(Main.java:16)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at jdk.compiler/com.sun.tools.javac.launcher.Main.execute(Main.java:404)
        at jdk.compiler/com.sun.tools.javac.launcher.Main.run(Main.java:179)
        at jdk.compiler/com.sun.tools.javac.launcher.Main.main(Main.java:119)
[0.392s][info][class,load] jdk.internal.reflect.ClassFileConstants source: jrt:/java.base
[0.392s][info][class,load] jdk.internal.reflect.AccessorGenerator source: jrt:/java.base
[0.392s][info][class,load] jdk.internal.reflect.MethodAccessorGenerator source: jrt:/java.base
[0.392s][info][class,load] jdk.internal.reflect.ByteVectorFactory source: jrt:/java.base
[0.392s][info][class,load] jdk.internal.reflect.ByteVector source: jrt:/java.base
[0.392s][info][class,load] jdk.internal.reflect.ByteVectorImpl source: jrt:/java.base
[0.393s][info][class,load] jdk.internal.reflect.ClassFileAssembler source: jrt:/java.base
[0.393s][info][class,load] jdk.internal.reflect.UTF8 source: jrt:/java.base
[0.393s][info][class,load] jdk.internal.reflect.Label source: jrt:/java.base
[0.393s][info][class,load] jdk.internal.reflect.Label$PatchInfo source: jrt:/java.base
[0.393s][info][class,load] jdk.internal.reflect.MethodAccessorGenerator$1 source: jrt:/java.base
[0.393s][info][class,load] jdk.internal.reflect.ClassDefiner source: jrt:/java.base
[0.393s][info][class,load] jdk.internal.reflect.ClassDefiner$1 source: jrt:/java.base
[0.394s][info][class,load] jdk.internal.reflect.GeneratedMethodAccessor1 source: __JVM_DefineClass__
java.lang.Exception: #16
        at Main.test(Main.java:9)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at Main.main(Main.java:16)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at jdk.compiler/com.sun.tools.javac.launcher.Main.execute(Main.java:404)
        at jdk.compiler/com.sun.tools.javac.launcher.Main.run(Main.java:179)
        at jdk.compiler/com.sun.tools.javac.launcher.Main.main(Main.java:119)
java.lang.Exception: #17
        at Main.test(Main.java:9)
        at jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at Main.main(Main.java:16)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at jdk.compiler/com.sun.tools.javac.launcher.Main.execute(Main.java:404)
        at jdk.compiler/com.sun.tools.javac.launcher.Main.run(Main.java:179)
        at jdk.compiler/com.sun.tools.javac.launcher.Main.main(Main.java:119)

从结果可以看出，在第16次开始动态生成字节码，且jvm额外加载了很多类，但第16次调用过程还是本地调用，从第17次开始切换到动态实现。
Inflation 机制是可以通过参数（-Dsun.reflect.noInflation=true）来关闭的。这样一来，在反射调用一开始便会直接生成动态实现，而不会使用委派实现或者本地实现。

3 反射调用开销

首先，我们对一个空方法，使用反射调用的方式进行循环20亿次测试耗时，他会在每跑1亿数据打印一次耗时，这里采取将最后五个耗时取平均值的方式作为预热后的峰值性能。

import java.lang.reflect.Method;

public class Main {
    public static void test(int i) {

    }

    public static void main(String[] args) throws Exception {
        Class<?> clazz = Class.forName("Main");
        Method method = clazz.getMethod("test", int.class);
        long current = System.currentTimeMillis();
        for (int i = 1; i <= 2_000_000_000; i++) {
            if (i % 100_000_000 == 0) {
                long temp = System.currentTimeMillis(); 
                System.out.println(temp - current); current = temp;
            }
            method.invoke(null, 0);
        }

    }
}

打印结果:

160
231
188
187
191
186
194
188
193
188
184
186
211
184
185
188
184
183
183
184

最后五次取平均值约为184ms，将此值作为基准值。

因为方法接受的是个int类型的参数，这时候如果我将invoke方法的参数传为128，以上边同样的方式执行耗时为 383ms，约为基准值的2倍，为什么呢？

我们看下字节码

63: aload_2				// 加载Method对象
64: aconst_null
65: iconst_1
66: anewarray     #13	//Object   // 生成一个数组
69: dup
70: iconst_0
71: sipush        128	
74: invokestatic  #14	//Integer.valueOf	// 将128自动装箱为Integer           
77: aastore				// 放入生成的数组中      
78: invokevirtual #15   // 反射调用
  1. 由于 Method.invoke 是一个变长参数方法，在字节码层面它的最后一个参数会是 Object 数组（感兴趣的同学私下可以用 javap 查看）。Java 编译器会在方法调用处生成一个长度为传入参数数量的 Object 数组，并将传入参数一一存储进该数组中。
  2. 由于 Object 数组不能存储基本类型，Java 编译器会对传入的基本类型参数进行自动装箱。

这两个操作除了带来性能开销外，还可能占用堆内存，使得 GC 更加频繁。

另外，关于第二个自动装箱，Java 缓存了[-128, 127]中所有整数所对应的 Integer 对象。当需要自动装箱的整数在这个范围之内时，便返回缓存的 Integer，否则需要新建一个 Integer 对象。

因此，我们可以将这个缓存的范围扩大至覆盖 128（对应参数-Djava.lang.Integer.IntegerCache.high=128），便可以避免需要新建 Integer 对象的场景。

或者，我们可以在循环外缓存 128 自动装箱得到的 Integer 对象，并且直接传入反射调用中。这两种方法测得的结果差不多，耗时约为196毫秒，为基准的 1.06倍。

然后我们反过来看低一点，每次循环都会因为变长参数生成Object数组，既然我们这段程序中每次反射调用的参数个数是固定的，那个我们可以在循环外去建立一个Object数组，设置好参数，并交给反射调用。

import java.lang.reflect.Method;

public class Main {
    public static void test(int i) {

    }

    public static void main(String[] args) throws Exception {
        Class<?> clazz = Class.forName("Main");
        Method method = clazz.getMethod("test", int.class);

        Object[] arg = new Object[1];
        arg[0] = 128;
        long current = System.currentTimeMillis();
        for (int i = 1; i <= 2_000_000_000; i++) {
            if (i % 100_000_000 == 0) {
                long temp = System.currentTimeMillis();
                System.out.println(temp - current); current = temp;
            }
            method.invoke(null, arg);
        }

    }
}

测试结果耗时约为247ms，约为集中的1.34倍，比之前更糟糕了，为什么呢？

这是因为如果在循环外新建数组，即时编译器无法确定这个数组会不会中途被更改，因此无法优化掉访问数组的操作，可谓是得不偿失。

我们再尝试去优化上一段代码：

  1. 关闭Inflation机制
  2. 关闭每次调用方法的检查权限

我们得到以下代码

import java.lang.reflect.Method;

public class Main {
    public static void test(int i) {

    }

    public static void main(String[] args) throws Exception {
        Class<?> clazz = Class.forName("Main");
        Method method = clazz.getMethod("test", int.class);
        method.setAccessible(true);

        long current = System.currentTimeMillis();
        for (int i = 1; i <= 2_000_000_000; i++) {
            if (i % 100_000_000 == 0) {
                long temp = System.currentTimeMillis();
                System.out.println(temp - current); current = temp;
            }
            method.invoke(null, 128);
        }

    }
}

运行结果耗时为 154ms，为基准的0.83

至此基本榨干了反射调用的水分。

在这个例子中，之所以反射调用能够变得这么快，主要是因为即时编译器中的方法内联。在关闭了 Inflation 的情况下，内联的瓶颈在于 Method.invoke 方法中对 MethodAccessor.invoke 方法的调用。

在生产环境中，我们往往拥有多个不同的反射调用，对应多个 GeneratedMethodAccessor，也就是动态实现。

由于 Java 虚拟机的关于上述调用点的类型 profile（注：对于 invokevirtual 或者 invokeinterface，Java 虚拟机会记录下调用者的具体类型，我们称之为类型 profile）无法同时记录这么多个类，因此可能造成所测试的反射调用没有被内联的情况。

接下来我们修改一下代码污染一下Method.invoke方法的类型profile

import java.lang.reflect.Method;

public class Main {
    public static void test(int i) {

    }

    public static void main(String[] args) throws Exception {
        Class<?> clazz = Class.forName("Main");
        Method method = clazz.getMethod("test", int.class);
        method.setAccessible(true);
        polluteProfile();

        long current = System.currentTimeMillis();
        for (int i = 1; i <= 2_000_000_000; i++) {
            if (i % 100_000_000 == 0) {
                long temp = System.currentTimeMillis();
                System.out.println(temp - current); current = temp;
            }
            method.invoke(null, 128);
        }

    }

    public static void polluteProfile() throws Exception {
        Method method1 = Main.class.getMethod("pollute1", int.class);
        Method method2 = Main.class.getMethod("pollute2", int.class);
        for (int i = 0; i < 2000; i++) {
            method1.invoke(null, 0);
            method2.invoke(null, 0); }
    }
    public static void pollute1(int i) { }
    public static void pollute2(int i) { }

}

我们在之前循环之前调用下polluteProfile方法，该方法中循环反射调用另外两个方法，此程序再用之前的耗时计算方式计算为425ms， 是基准的2.3倍。

之所以这么慢，除了没有内联之外，另外一个原因是逃逸分析不再起效。这时候，我们便可以采用刚才 在循环外构造参数数组，并直接传递给反射调用。这样子测得的结果约为基准的 1.7 倍。

这里JVM受到-XX:TypeProfileWidth（类型轮廓）限制能够记录的类型数目，默认值为 2，用户无法设置，所以我们就需要尽量在程序结构避免出现这种情况。

瘦子由
关注
  • 27
    点赞
  • 踩
  • 26
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
java的自省机制_深入理解Java反射机制
weixin_35006125的博客
03-02 1014
前言最近在接触 Android 的组件化原理的时候，发现自己对 Java 反射的机制理解并不是很深，只能利用周末的时间把 Java 反射机制回炉重铸。什么是Java反射反射机制是 Java 语言提供的一种基础功能，赋予了 Java 程序在运行时的自省(introspect，官方用语)的能力。通过 Java 的反射机制，程序员可以在 Java 程序在运行态的时候操作任意的类或者对象的属性、方法。利用...
Java反射机制
新征程的博客
10-26 1115
一、Java反射机制是什么？1、Java反射机制（）是Java语言中一种动态（运行时）访问、检测 & 修改它本身的能力，主要作用是动态（运行时）获取类的完整结构信息 & 调用对象的方法~获取该对象的成员变量 & 赋值调用该对象的方法（含构造方法，有参/无参）判断该对象所属的类2、更通俗点的说，我们使用某个类，都会知道这个类，以及要用它来做什么，可以直接通过new实例化创建对象，然后使用这个对象对类进行操作，这个就属于正射~3、而反射则是一开始并不知道要初始化的是什么类，无法使用new。
Java 中的反射机制（两万字超全详解）
林二月的博客
09-08 2万+
文章目录一、反射概述1. 什么是反射？2. 反射机制原理3. 反射优点和缺点4. 类加载概述5. 类加载各阶段完成的功能5.1 加载阶段5.2 连接阶段——验证5.3 连接阶段——准备5.4 连接阶段——解析5.5 初始化阶段二、Class 类1. 动态加载2. 小结三、访问字段1. 获取字段值2. 设置字段值3. 小结四、调用方法1. 调用方法2. 调用静态方法3. 调用非 public方法4. 多态5. 小结五、调用构造方法六、获取继承方法1. 获取父类的Class2. 获取interface3. 继承
深入了解java反射原理,java反射原理简单介绍
weixin_39612720的博客
03-27 233
我们深入java反射的使用前，应该对其原理有一个深入的了解。我们知道，class类是反射过程中比较重要的操作，对于它的获取也是反射中必学的知识点。这里我们先梳理出调用反射的流程，然后就class类的获取进行详细的实例展示，相信大家在经过使用反射获取class类后，加深对调用的原理理解。1.调用反射的流程(1)准备阶段：编译期装载所有的类，将每个类的元信息保存至Class类对象中，每一个类对应一个C...
深入理解Java的反射机制
一个搬砖工人
03-17 1352
首先我们需要先了解程序的运行过程：从源文件创建到程序运行，Java程序要经过两大步骤：编译，运行；1、源文件由编译器编译成字节码（ByteCode）； 2、字节码由java虚拟机解释运行。 第一步(编译): 创建完源文件之后，程序会先被编译为.class文件。Java编译一个类时，如果这个类所依赖的类还没有被编译，编译器就会先编译这个被依赖的类，然后引用，否则直接引用。如果java编译器在指定目录下找不到该类所其依赖的类的.class文件或者.java源文件的话，编译器话报“cant find symbol
深入理解JAVA反射（详解）
weixin_44825912的博客
03-09 1064
反射 (Reflection) 是 Java 的特征之一，它允许运行中的 Java 程序获取自身的信息，并且可以操作类或对象的内部属性。
深入理解Java类型信息(Class对象)与反射机制
热门推荐
zejian的博客
05-01 16万+
【版权申明】未经博主同意，谢绝转载！（请尊重原创，博主保留追究权） http://blog.csdn.net/javazejian/article/details/70768369 出自【zejian的博客】 关联文章： 深入理解Java类型信息(Class对象)与反射机制 深入理解Java枚举类型(enum) 深入理解Java注解类型(@Annotation) 深入理解
Java 反射机制与动态代理
fengbaobaola的博客
08-16 1611
反射机制
JVM系列之：JVM是如何实现反射的
Herishwater的博客
03-06 1043
简介 Java 反射机制是在运行状态中，对于任意一个类，都能够知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意一个方法和属性；这种动态获取信息以及动态调用对象的方法的功能称为 Java 语言的反射机制。 在 Java 环境中运行时，对于任意一个类，能否知道这个类有哪些属性和方法。对于任意一个对象，能否调用它的任意一个方法。 Java 反射机制主要提供了以下功能： 在运行时判断任意一个对象所属的类。 在运行时构造任意一个类的对象。 在运行时判断任意一个类所具有的成员变量和方法。 在运行时调用
java 反射机制详解_java反射机制原理详解
weixin_31669073的博客
03-07 2108
反射机制:所谓的反射机制就是java语言在运行时拥有一项自观的能力。通过这种能力可以彻底的了解自身的情况为下一步的动作做准备。下面具体介绍一下java的反射机制。这里你将颠覆原来对java的理解。Java的反射机制的实现要借助于4个类：class，Constructor，Field，Method；其中class代表的时类对象，Constructor－类的构造器对象，Field－类的属性对象，Met...
redis+spring面试题
github_36510643的博客
07-21 177
redis+spring面试题
Java-Lambda
最新发布
lizhiwei21的博客
07-21 154
lambda表达式可以理解为对匿名内部类的一种简化 , 但是本质是有区别的面向对象思想 :强调的是用对象去完成某些功能函数式编程思想 :强调的是结果 , 而不是怎么去做。
Promise 详解（原理篇）
山重水复疑无路，柳暗花明又一村。
07-20 490
Promise 是一种异步编程的解决方案。在异步操作中，callback 会导致回调地狱的问题，Promise 解决了这个问题。一个 Promise对象有以下三种状态:pending：初始状态，既不是成功，也不是失败状态。：意味着操作成功完成。rejected：意味着操作失败。当 new Promise() 被实例化后，即表示 Promise 进入 pending 初始化状态，准备就绪，等待运行。
JVM-垃圾回收与内存分配
m0_50846237的博客
07-19 1130
JVM-垃圾回收与内存分配
接口防刷！利用redisson快速实现自定义限流注解
架构师小吴的博客
07-18 1153
如登录接口，当用户使用手机号+验证码登录时，一般我们会生成6位数的随机验证码，并将验证码有效期设置为1-3分钟，如果对登录接口不加以限制，理论上，通过技术手段，快速重试100000次，即可将验证码穷举出来。解决思路：对登录接口加上限流操作，如限制一分钟内最多登录5次，登录次数过多，就返回失败提示，或者将账号锁定一段时间。在日常开发中，一些重要的对外接口，需要加上访问频率限制，以免造成资��损失。ok，通过以上两步，即可完成我们的限流注解了，下面通过一个接口验证下效果。
【Java算法】前缀和 下
2302_79806056的博客
07-18 1059
这段代码实现了一个寻找数组中具有相等数量的0和1的最长子数组长度的算法。具体来说，它使用了前缀和（prefix sum）的概念以及哈希映射（HashMap）来优化查找过程。初始化哈希映射：计算前缀和：检查相等数量的0和1：更新哈希映射：返回结果：这种方法的时间复杂度为O(n)，因为我们只遍历数组一次，并且对每个元素执行常数时间的操作。空间复杂度也是O(n)，最坏情况下需要存储n个前缀和值。 初始化阶段:开始遍历数组:继续
华为OD机试 - 分披萨 - 递归（Java 2024 D卷 200分）
学Java，找哪吒
07-21 507
递归算法通过函数调用自身解决问题，每次递归调用都处理问题的一个子部分，直到达到基准条件，从而构建最终解。
【Java并发编程之美 | 第三篇】Java 并发包中锁原理剖析之AQS、ReentrantLock独占可重入锁
踢桃的成长之路
07-21 542
Java 并发包中锁原理剖析之AQS、ReentrantLock独占可重入锁
对androidTestDebug 产物进行重新签名
shuizhizhiyin的专栏
07-19 476
在运行 gradle assembleAndroidTestDebug 任务后，自定义的 reSignAndroidTestDebug 任务将会被执行，并对子模块的 androidTestDebug 产物进行重新签名。your_keystore_path.jks、your_keystore_password、your_key_alias 和 your_key_password 需要替换为你的实际路径和密码。如果需要对其他子模块的产物进行重新签名，可以根据需要创建不同的自定义任务。// 设置密钥库密码。
每 日练 习
m0_67187271的博客
07-19 1023
正确答案：C 解析：是正确的，这是最基本的类定义形式，没有继承任何类，也没有实现任何接口。也是正确的，这里定义了一个名为x的类，它继承了名为y的类。同样是正确的，这里定义了一个公共类x，它继承了Applet类，这在Java中是合法的，尤其是在创建GUI应用程序时常见。是不正确的，因为在Java中，我们不能使用static关键字来修饰一个类的定义。static关键字只能用于类的方法、变量或者是内部类（即嵌套类），但不能用于顶级类（非嵌套类）。所以，这个选项是错误的。因此，正确答案是C。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值