接着便是开始调试该体系，适时的调试一下十分有必要。
根据原来的联系小例子进行断点调试。对于反射中所涉及的 类 和 对象 ，进行了一个查看。 需要知道，有些时候可以通过基本规则实现，有些时候可以通过方法实现类。就像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多次，但是没有去认真看过。
这里算直接首次接触哈希码吧。 内容写的已经比较详细。
