从JVM内存和Class结构来理解反射

作者: 朱端的一坨 | 来源:发表于2016-09-23 18:48 被阅读347次

    背景

    最近又把反射相关的内容看了一下,正好结合了之前看的JVM的内容一起柔了一下,觉得这样去思考能更加直观和清洗的理解到反射的原理和使用。因此把整个理解过程记录一下,以便之后复习和加深理解使用。

    首先还是先对反射进行一个简单的回顾,JDK1.5之后引入了反射的机制后,使得Java具备了元编程的能力(虽然更多的时候可能体现在对私有方法和属性的操作上),极大的丰富了我们设计上的可能性。概略的来说,针对反射的应用,就是通过class.forname的方式加载\获取相关的类后,再通过method的invoke方法来调用相关的方法,又或者通过设置属性的方式来操作类的局部变量。

    但是仅仅是这种简单的操作,有时候会给我们带来困惑,为什么能通过这种方式来操作我们的类,或者类似的为什么synchronize关键字会有锁类或者锁方法的区别?其实通过对JVM的了解,能够更好的理解到这种设计的根本原因和具体原理。

    JVM中分层的内存结构

    工欲善其事必先利其器,我们先来看一下JVM的内存结构的相关内容,本着能画图就不写字(懒)的原则,对大致的结构进行了一个整理。

    其中部分图来源于一篇笔记整理JVM工作原理,这篇博客写的很清楚细致,推荐有兴趣的小伙伴们仔细看一下。

    JVM大致内存结构.png

    以ClassLoader作为了整个图的入口,主要是考虑到JVM本身第一步就是通过ClassLoader来将所有需要的内容载入到虚拟机中的,不过关于ClassLoader就不在这里详细描述了。

    可以看到执行引擎就是我们最需要关注的内容,是整个java程序运行的核心部分,至于其余的本地方法区JVM已经自己和系统做好的交互,我们不用太过于关注。

    进一步打开执行引擎来看,就看到了网上流传最经典的JVM内存的5部分模型,而其中最重要需要理解的就是方法区和堆的内容。至于剩下的栈的内容和计数器的内容,并非说它们不重要,相反这两部分才是最重要的,因为java程序的运行可以没有堆,但是一定不能没用栈和计数器。至于原因相信有学习过计算机体系架构的小伙伴们一定很熟悉,这几兄弟构成了整个系统的运行基础。特别的是每一个线程都会分配有一个自己的方法栈,这也就是为何局部变量是局部的原因。当然JVM的具体处理过程中,也会根据具体的内存情况和策略为线程分配TLAB(线程私有的堆空间)以优化处理一些同步上的问题,不过这点并非一定会存在,且不是本文的重点,也就一笑而过吧 :)

    然后方法区和堆具体又可以映射倒了内部的内存分代模型(这里不是很清楚如果使用的是最早的引用计数法的回收机制的时候是不是同样的模型,希望有清楚的小伙伴不吝指教一下 :D ),其实也很好理解:

    1. 由于方法区存储的主要是常量池、类的静态信息等不会变动的内容,因此存储到了Permanent Generation这一不会被GC和改动的内存空间上
    2. 其余可共享的变量/实例信息则会存储在New Generation和Old Generation上,至于为什么会存在这种差异则主要是和GC的实际策略相关的(在经过GC标记了x次后的对象会从New进入到Old,而Old只会被Full GC处理)。
    3. 而New Generation中根据Minor GC的处理情况(主要对应了GC方法中的标记法)又分为了Eden、Survivor From、Survivor To三个部分。简单的来说通常一个新的对象会建立在Eden上,而经过Minor GC的对象则会在Survivor中移动(特殊的,这里的From和To只是为了区分两个Survivor区,但是并非严格的是从From到To的意义,因为在GC的过程中,可能对象毁在两个区中反复移动)

    Class文件结构

    其实网上关于Class文件结构部分的内容很多,而且很多讲的很好,鉴于这也不是这次的重点,就仅仅是简单的记录一下最基本的一个理解,关于字节码有兴趣的小伙伴可以看一下这个,挺不错的: 【深入Java虚拟机】之二:Class类文件结构

    参考下图的(来源于:上面提到的文章,如有侵权请联系我删除,谢谢),我们可以发现,字节码中其实就存储了最基本的关于类的所有信息,这部分静态的信息最终会进入到方法区的里面去(也就是Perm里面)

    字节码文件结构.png

    另一个角度看反射

    至此我们对JVM和字节码的整体结构就有了一个比较直观的了解,那么反射究竟做了些什么呢?就可以从中窥见一些端倪。

    首先我们知道在类的加载过程中仅有两种方式,一种是通过new来创建,第二是通过forname来获取到对象(其中第一种方式包含了第二种方式,只是new的时候,除了forname外JVM还做了实例化等一系列工作),而这些对象的来源都是通过ClassLoader读取进入到内存中的。而这些class最基本的信息,也就是字节码中所存储的所有的接口、方法、属性之类的信息都会存储在方法区中,一直不会变化。

    那么反射其实就是通过从方法区中读取出了class所有的相关信息后,再显示的调用了实例化的方法(也就是构造器来实例化类)后,模拟了整个类的创建、引用和调用的过程,只是这整个过程更为底层一些(相比直接new多了好几个步骤)。但是总的来说,其实我们正常的使用对象上并没有很大的区别(当然关于private这个权限的处理上,反射做了特殊的处理来绕过了权限的认证)

    结语

    总觉得最终还是又回到了那个主题上,究竟是想要更灵活还是更安全,反射无疑为我们提供了更多更丰富的设计手段和实现技巧,但是不可避免的还是部分的“破坏”了整个Java最初的设计理念:更透明更安全。

    针对反射的一点粗浅理解就到这里吧,还有很多细节上和具体源码实现上的东西还不是很清楚,这篇文章如果以后再帮我回忆知识点的路上也能帮助他人就太好了,也希望如果有所谬误请大牛们不吝指出~谢谢 :)

    相关文章

      网友评论

        本文标题:从JVM内存和Class结构来理解反射

        本文链接:https://www.haomeiwen.com/subject/bnvaettx.html