java源码解析之反射（三）

    接着便是开始调试该体系。   大致过了一遍代码，发现自己懵懵懂懂，恍恍惚惚。  没有思绪，因此适时的调试一下十分有必要。 

    根据原来的联系小例子进行断点调试。  对于反射中所涉及的   类  和  对象  ，进行了一个查看。  需要知道，有些时候可以通过基本规则实现，有些时候可以通过方法实现类。   就像1+1=2，水往低处流，int不用声明一样，有些东西是跟随它整个生态共存的。  实例化类对象分别使用了三种方式：   Class.forName(Student.class);   Class c=Student.class;    new Student().getClass();   实例化对象类则主要通过两种方式：   new Student() ,  c.newInstance();  查看它们的源码：

    可以知道的是它与构造相关的方法有关。  然后看看代理的相关调试：

    看到这里需要明确一下，newInstance方法的实现  位于  sun包下的该方法实现。通过断点调试的进度，了解到其关于反射的一些实现，实际上是从Class开始，因此注意到与Class关系密切，不得不看一看：

    这里注意到，原来用了这么久的Class,它竟然是为所有的类对象提供了泛型。 

    反射的那些组件的来源。  

    这里可以看到生成了一个$Proxy0类，查找可以知道既不属于jdk，更不属于用户。  因此断定它是再运行时生成的类。  并且上一篇中Proxy.class中的  ProxyClassFactory.class中的属性也很好的说明了这一点。 

    这里需要注意了。   之前的那个InvokationHandler接口的实现其实依然位于  sun包下的NativeMethodAccessorImpl中。

 

    发现这个反射与代理可以说从根本上动摇了class的体系结构。  从Class的结构也可以说明这一点。  但是这是它本身的一次大的进步，所以这些改动都是十分值得的。   只是纠正下自己的观念，不要再将反射当成功能的一种扩展，而应该将其视为留在java体系中鲜活的血液，共生共存。 

    由于这里已经涉及到了Class，那么索性就来个一刀两断，一了百了。  彻底看看java.lang.Class。

    这是它的依赖关系，发现有很多都来自了reflect包下。

    可见这里，Class本身作为了一个泛型的提供者。 

    发现它的构造，也就是实例化对象的时候，其实例的时一个类加载器。  那么这个是哪个累加器呢？   猜想应该为AppClassLoader。 

    关于属性的行为的一个理解如上图中。

    类的抽象模型。  

既然涉及到了Class，那么是时候来处理一下Object.  虽然听过了N多次，但是没有去认真看过。

    这里算直接首次接触哈希码吧。   内容写的已经比较详细。

 

    至此便是反射体系所有要交代的。   回顾一下可以知道，了解了一下反射的结构，代理的结构，Class的结构，Object的结构。     差不多就是这些内容，晚安！