反射
每个Java class在jvm中都有一个对应对象描述。每个Java对象都有一个只想class的指针。反射的实质获取对象指向Class元数据描述的信息，详见java.lang.class类。反射通过class对类的描述可以获取类field、method、包括匿名类和内部类等所有类定义的信息。下面详细介绍反射的实现：
1.先检查 AccessibleObject的override属性是否为true。
得到调用这个方法的Class,然后做是否有权限访问的校验，校验之后缓存一次，以便下次如果还是这个类来调用就不用去做校验了，直接用上次的结果，（很奇怪用这种方式缓存，因为这种方式如果下次换个类来调用的话，就不用会缓存了，而再验证一遍，把这次的结果做为缓存，但上一次的缓存结果就被冲掉了。这是一个很简单的缓冲机制，只适用于一个类的重复调用)。
否则返回DelegatingMethodAccessorImpl，并将他与一个NativeMethodAccessorImpl互相引用。但DelegatingMethodAccessorImpl执行invoke方法的时候又委托给NativeMethodAccessorImpl了。
4.NativeMethodAccessorImpl的invkoe方法:
注意这里有一个计数器numInvocations，每调用一次方法+1,当比 ReflectionFactory.inflationThreshold(15)大的时候,用MethodAccessorGenerator创建一个MethodAccessor,并把之前的DelegatingMethodAccessorImpl引用替换为现在新创建的。下一次DelegatingMethodAccessorImpl就不会再交给NativeMethodAccessorImpl执行了，而是交给新生成的java字节码的MethodAccessor。
MethodAccessorGenerator使用了asm字节码动态加载技术，暂不深入研究。
总结 一个方法可以生成多个Method对象，但只有一个root对象，主要用于持有一个MethodAccessor对象，这个对象也可以认为一个方法只有一个，相当于是static的。因为Method的invoke是交给MethodAccessor执行的，所以我所想要知道的答案在MethodAccessor的invoke中，深入MethodAccessor：
注意到TestClassLoad类上不会有对类A的符号依赖——也就是说在加载并初始化TestClassLoad类时不需要关心类A的存在与否，而是等到main()方法执行到调用Class.forName()时才试图对类A做动态加载；这里用的是一个参数版的forName()，也就是使用当前方法所在类的ClassLoader来加载，并且初始化新加载的类。……好吧这个细节跟主题没啥关系。
回到主题。这次我的测试环境是Sun的JDK 1.6.0 update 13 build 03。编译上述代码，并在执行TestClassLoad时加入-XX:+TraceClassLoading参数（或者-verbose:class或者直接-verbose都行），如下：
java -XX:+TraTestClassLoad ceClassLoading
可以看到前15次反射调用A.foo()方法并没有什么稀奇的地方，但在第16次反射调用时似乎有什么东西被触发了，导致JVM新加载了一堆类，其中就包括[Loaded sun.reflect.GeneratedMethodAccessor1 from __JVM_DefineClass__]这么一行。这是哪里来的呢？
先来看看JDK里Method.invoke()是怎么实现的。
可以看到Method.invoke()实际上并不是自己实现的反射调用逻辑，而是委托给sun.reflect.MethodAccessor来处理。
每个实际的Java方法只有一个对应的Method对象作为root，。这个root是不会暴露给用户的，而是每次在通过反射获取Method对象时新创建Method对象把root包装起来再给用户。在第一次调用一个实际Java方法对应得Method对象的invoke()方法之前，实现调用逻辑的MethodAccessor对象还没创建；等第一次调用时才新创建MethodAccessor并更新给root，然后调用MethodAccessor.invoke()真正完成反射调用。
可以看到它只是一个单方法接口，其invoke()方法与Method.invoke()的对应。
创建MethodAccessor实例的是ReflectionFactory。
sun.reflect.ReflectionFactory：
这里就可以看到有趣的地方了。如注释所述，实际的MethodAccessor实现有两个版本，一个是Java实现的，另一个是native code实现的。Java实现的版本在初始化时需要较多时间，但长久来说性能较好；native版本正好相反，启动时相对较快，但运行时间长了之后速度就比不过Java版了。这是HotSpot的优化方式带来的性能特性，同时也是许多虚拟机的共同点：跨越native边界会对优化有阻碍作用，它就像个黑箱一样让虚拟机难以分析也将其内联，于是运行时间长了之后反而是托管版本的代码更快些。
为了权衡两个版本的性能，Sun的JDK使用了"inflation"的技巧：让Java方法在被反射调用时，开头若干次使用native版，等反射调用次数超过阈值时则生成一个专用的MethodAccessor实现类，生成其中的invoke()方法的字节码，以后对该Java方法的反射调用就会使用Java版。
PS.可以在启动命令里加上-Dsun.reflect.noInflation=true，就会RefactionFactory的noInflation属性就变成true了，这样不用等到15调用后，程序一开始就会用java版的MethodAccessor了。
上面看到了ReflectionFactory.newMethodAccessor()生产MethodAccessor的逻辑，在"开头若干次"时用到的DelegatingMethodAccessorImpl代码如下：
sun.reflect.DelegatingMethodAccessorImpl：
这是一个间接层，方便在native与Java版的MethodAccessor之间实现切换。
然后下面就是native版MethodAccessor的Java一侧的声明:
sun.reflect.NativeMethodAccessorImpl：
每次NativeMethodAccessorImpl.invoke()方法被调用时，都会增加一个调用次数计数器，看超过阈值没有；一旦超过，则调用MethodAccessorGenerator.generateMethod()来生成Java版的MethodAccessor的实现类，并且改变DelegatingMethodAccessorImpl所引用的MethodAccessor为Java版。后续经由DelegatingMethodAccessorImpl.invoke()调用到的就是Java版的实现了。
注意到关键的invoke0()方法是个native方法。它在HotSpot VM里是由JVM_InvokeMethod()函数所支持的：
其中的关键又是Reflection::invoke_method()：
OpenJDK 6 build 17的MethodAccessorGenerator。它的基本工作就是在内存里生成新的专用Java类，并将其加载。就贴这么一个方法：
去阅读源码的话，可以看到MethodAccessorGenerator是如何一点点把Java版的MethodAccessor实现类生产出来的。也可以看到GeneratedMethodAccessor+数字这种名字是从哪里来的了，就在上面的generateName()方法里。
对本文开头的例子的A.foo()，生成的Java版MethodAccessor大致如下：
就反射调用而言，这个invoke()方法非常干净（然而就"正常调用"而言这额外开销还是明显的）。注意到参数数组被拆开了，把每个参数都恢复到原本没有被Object[]包装前的样子，然后对目标方法做正常的invokevirtual调用。由于在生成代码时已经循环遍历过参数类型的数组，生成出来的代码里就不再包含循环了。
至此找到我的答案了，因为MethodAccessor会做强制类型转换再进行方法调用，但父类强制转化成子类的的时候就会报错类型不匹配错误了，所以如果变量的引用声明是父但实际指向的对象是子，那么这种调用也是可以的。
当该反射调用成为热点时，它甚至可以被内联到靠近Method.invoke()的一侧，大大降低了反射调用的开销。而native版的反射调用则无法被有效内联，因而调用开销无法随程序的运行而降低。
虽说Sun的JDK这种实现方式使得反射调用方法成本比以前降低了很多，但Method.invoke()本身要用数组包装参数；而且每次调用都必须检查方法的可见性（在Method.invoke()里），也必须检查每个实际参数与形式参数的类型匹配性（在NativeMethodAccessorImpl.invoke0()里或者生成的Java版MethodAccessor.invoke()里）；而且Method.invoke()就像是个独木桥一样，各处的反射调用都要挤过去，在调用点上收集到的类型信息就会很乱，影响内联程序的判断，使得Method.invoke()自身难以被内联到调用方。
相比之下JDK7里新的MethodHandler则更有潜力，在其功能完全实现后能达到比普通反射调用方法更高的性能。在使用MethodHandle来做反射调用时，MethodHandle.invoke()的形式参数与返回值类型都是准确的，所以只需要在链接方法的时候才需要检查类型的匹配性，而不必在每次调用时都检查。而且MethodHandle是不可变值，在创建后其内部状态就不会再改变了；JVM可以利用这个知识而放心的对它做激进优化，例如将实际的调用目标内联到做反射调用的一侧。
本来Java的安全机制使得不同类之间不是任意信息都可见，但Sun的JDK里开了个口，有一个标记类专门用于开后门：
