java源码解析之反射(三)

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/qq_36285943/article/details/80152912

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

    根据原来的联系小例子进行断点调试。  对于反射中所涉及的   类  和  对象  ,进行了一个查看。  需要知道,有些时候可以通过基本规则实现,有些时候可以通过方法实现类。   就像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的结构。     差不多就是这些内容,晚安!

展开阅读全文

没有更多推荐了,返回首页