深入理解Java反射机制

需积分: 7 77 浏览量更新于2024-07-31 收藏 503KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"深入理解Java反射机制" 在Java编程中，反射（Reflection）是一个强大的工具，它允许运行中的Java程序对自身进行检查并且可以直接操作程序的内部属性。这使得开发者能够在运行时动态地创建对象和调用方法，增加了代码的灵活性和可扩展性。Java反射机制是Java平台独特特性的体现，相较于编译直接生成本地代码的语言，如C++，Java的动态性更为突出。 Java程序的执行过程始于类加载。当Java虚拟机（JVM）启动时，它会加载并初始化应用程序所需的类。类加载是Java运行时的一个关键组成部分，它包括加载、验证、准备、解析和初始化五个阶段。类加载器（ClassLoader）负责这个过程，它们根据类的全名（包括包名）从指定的类路径中找到对应的.class文件，并将其转换为内存中的类对象。文章中提到的"Java classes and class loading"部分，着重介绍了类加载机制。简单来说，JVM有三种类型的类加载器：bootstrap class loader（引导类加载器）、extension class loader（扩展类加载器）和applicaton class loader（应用程序类加载器）。引导类加载器加载JRE的核心库，扩展类加载器加载JDK的扩展目录中的类，而应用程序类加载器则加载我们编写的类和第三方库。类加载问题可能引发复杂性，尤其是在J2EE和其他大型架构中。例如，类加载冲突可能导致应用程序的异常行为或无法正常运行。当多个类加载器尝试加载相同的类时，如果它们没有协调好，就会出现这样的问题。 Java反射API提供了一种方式来访问运行时的类信息，包括类的字段、方法和构造器。通过`Class`类，我们可以获取到任何对象的类信息，创建实例，调用私有方法，甚至修改类的静态字段。以下是一些关键的反射API： 1. `Class.forName(String className)`：根据类名动态加载类。 2. `Class.getDeclaredFields()`：获取类的所有声明的字段，包括私有和受保护的。 3. `Class.getDeclaredMethods()`：获取类的所有声明的方法，包括私有和受保护的。 4. `Constructor<?> getDeclaredConstructor(Class<?>... parameterTypes)`：获取特定参数类型的构造器。 5. `Method.invoke(Object obj, Object... args)`：调用对象的方法，可以是私有的。掌握Java反射机制对于理解和解决高级编程问题至关重要，尤其是在处理插件系统、元编程以及需要动态修改或扩展程序行为的场景中。了解这些动态特性，将使你能够充分利用Java平台的潜力，编写出更加灵活和适应性强的代码。

资源详情

资源推荐

public int accessSame(int loops) {

m_value = 0;

for (int index = 0; index < loops; index++) {

m_value = (m_value + ADDITIVE_VALUE) *

MULTIPLIER_VALUE;

}

return m_value;

}

public int accessReference(int loops) {

TimingClass timing = new TimingClass();

for (int index = 0; index < loops; index++) {

timing.m_value = (timing.m_value + ADDITIVE_VALUE) *

MULTIPLIER_VALUE;

}

return timing.m_value;

}

public int accessReflection(int loops) throws Exception {

TimingClass timing = new TimingClass();

try {

Field field = TimingClass.class.

getDeclaredField("m_value");

for (int index = 0; index < loops; index++) {

int value = (field.getInt(timing) +

ADDITIVE_VALUE) * MULTIPLIER_VALUE;

field.setInt(timing, value);

}

return timing.m_value;

} catch (Exception ex) {

System.out.println("Error using reflection");

throw ex;

}

The test program calls each method repeatedly with a large loop count, averaging the time measurements over several calls. The time for the ﬁrst

call to each method is not included in the average, so initialization time isn't a factor in the results. In the test runs for this article, I used a loop

count of 10 million for each call, running on a 1GHz PIIIm system. My timing results with three different Linux JVMs are shown in Figure 1.

All tests used the default settings for each JVM.

Figure 1. Field access times

The logarithmic scale of the chart allows the full range of times to be displayed, but lessens the visual impact of the differences. In the case of the

ﬁrst two sets of ﬁgures (the Sun JVMs), the execution time using reﬂection is over 1000 times greater than that using direct access. The IBM

JVM does somewhat better by comparison, but the reﬂection method still takes more than 700 times as long as the other methods. There were no

signiﬁcant differences in times between the other two methods on any JVM, though the IBM JVM did run these almost twice as fast as the Sun

JVMs. Most likely, this difference reﬂects the specialized optimizations used by the Sun Hot Spot JVMs, which tend to do poorly in simple

benchmarks.

Besides the ﬁeld access time tests, I did the same sort of timing test for method calls. For method calls, I tried the same three access variations as

for ﬁeld access, with the added variable of using no-argument methods versus passing and returning a value on the method calls. Listing 8

shows the code for the three methods used to test the passed-and-returned value form of the calls.

Listing 8. Method access performance test code

public int callDirectArgs(int loops) {

int value = 0;

for (int index = 0; index < loops; index++) {

value = step(value);

}

return value;

}

public int callReferenceArgs(int loops) {

TimingClass timing = new TimingClass();

int value = 0;

for (int index = 0; index < loops; index++) {

value = timing.step(value);

}

return value;

}

public int callReflectArgs(int loops) throws Exception {

TimingClass timing = new TimingClass();

try {

Method method = TimingClass.class.getMethod

("step", new Class [] { int.class });

Object[] args = new Object[1];

Object value = new Integer(0);

for (int index = 0; index < loops; index++) {

args[0] = value;

value = method.invoke(timing, args);

}

return ((Integer)value).intValue();

} catch (Exception ex) {

System.out.println("Error using reflection");

throw ex;

}

Figure 2 shows my timing results for method calls. Here again, reﬂection is much slower than the direct alternative. The differences aren't quite

as large as for the ﬁeld access case, though, ranging from several hundred times slower on the Sun 1.3.1 JVM to less than 30 times slower on

the IBM JVM for the no-argument case. The test performance for reﬂection method calls with arguments are substantially slower than the calls

with no arguments on all JVMs. This is probably partially because of the java.lang.Integer wrapper needed for the int value passed

and returned. Because Integers are immutable, a new one needs to be generated for each method return, adding considerable overhead.

Figure 2. Method call times

Reﬂection performance was one area of focus for Sun when developing the 1.4 JVM, which shows in the reﬂection method call results. The

Sun 1.4.1 JVM shows greatly improved performance over the 1.3.1 version for this type of operation, running about seven times faster in my

tests. The IBM 1.4.0 JVM again delivered even better performance for this simple test, though, running two to three times faster than the Sun

1.4.1 JVM.

I also wrote a similar timing test program for creating objects using reﬂection. The differences for this case aren't nearly as signiﬁcant as for the

ﬁeld and method call cases, though. Constructing a simple java.lang.Object instance with a newInstance() call takes about 12 times

剩余54页未读，继续阅读

普通网友

粉丝: 0
资源:
3

深入理解Java反射机制

java reflection in action

Java Reflection in Action

Java Reflection In Action

java.lang.reflect.InaccessibleObjectException

内存中动态编译执行java代码

java执行jar包中的某个方法

java.lang.reflect.MalformedParameterizedTypeException:

java获取所有使用某个注解的类

BeanUtils.copyProperties() 是浅拷贝还是深拷贝

如何获取某个注解下的所有类

method.invoke()

获取 classpath 下所有的 类信息

如何获取被注解注释的所有类

Generating Your Own Metadata by Using the Annotation Processor

bean的生命周期 实例详解

Handler dispatch failed; nested exception is java.lang.NoSuchFieldError: REFLECTION

Java 不安全的反射 unsafe reflection

Caused by: org.apache.ibatis.reflection.ReflectionException: There is no getter for property named 'id' in 'class java.lang.Integer'

eclipse如何自动生成类图

String resourcePath = getClass().getClassLoader().getResource("").getPath();获得的路径是E:\%e5%8a%a8%e5%8a%9b%e8%8a%82%e7%82%b9\Java\xml-annotation-orm\out\production\xml-orm-mysql-reflection\，只想要xml-orm-mysql-reflection\该怎么做

最新资源

获取 classpath 下所有的类信息

bean的生命周期实例详解