zoukankan      html  css  js  c++  java
  • JVM内运行时数据区

    JVM的基本区域:

      类加载子系统

        

      运行时数据区(内存区域)

        

      执行引擎

        

    运行时数据区域  

        

      方法区(Method Area)

        类的所有字和方法字节码,以及一些特殊方法如构造函数,接口代码也在这里定义。简单来说,所有定义的方法的信息都保存在该区域,静态变量+常量+类信息(构造方法/接口定义)+运行时常量池都存在方法区中,虽然java虚拟机规范把方法区描述为堆的一个逻辑部分,但是它却有一个别名叫做Non+Heap(堆),目的应该是为了和java的堆区分开;

      堆(Heap)

        虚拟机启动时自动分配创建,用于存放对象的实例,几乎所有对象在堆上分配内存,当对象无法在该空间申请到内存是将抛出OutOfMemoryError异常。同时也是垃圾收集器管理的主要区域;

        

          新生代  

            类出生,成长,消亡的区域,一个类在这里产生,应用,最后被垃圾回收器收集,结束生命。

            新生代分为两部分:伊甸区(Eden space)和幸存者(Survivor space),所有的类都是在伊甸区被new出来的。辛存区又分为From和To区。当Eden区的空间用完时,程序又需要创建对象,JVM的垃圾回收器将Eden区进行垃圾回收(Minor GC),将Eden区中的不再被对象应用的对象进行销毁。然后将Eden区中剩余的对象移到From Survivor区。若Form Survivor区也满了,在对该区进行垃圾回收,然后移到To Survivor区

          老年代    

            主要存放应用程序中生命周期长的内存对象。

                老年代的对象比较稳定,所以MajorGC不会频繁执行。在进行MajorGC前一般都先进行了一次MinorGC,使得有新生代的对象晋身入老年代,导致空间不够用时才触发。当无法找到足够大的连续空间分配给新创建的较大对象时也会提前触发一次MajorGC进行垃圾回收腾出空间。

                MajorGC采用标记—清除算法:首先扫描一次所有老年代,标记出存活的对象,然后回收没有标记的对象。MajorGC的耗时比较长,因为要扫描再回收。MajorGC会产生内存碎片,为了减少内存损耗,我们一般需要进行合并或者标记出来方便下次直接分配。

         当老年代也满了装不下的时候,就会抛出OOM(Out of Memory)异常。

          永久代

            指内存的永久保存区域,主要存放Class和Meta(元数据)的信息,Class在被加载的时候被放入永久区域. 它和存放实例的区域不同,GC不会在主程序运行期对永久区域进行清理。所以这也导致了永久代的区域会随着加载的Class的增多而胀满,最终抛出Out of Memory异常。
            在Java8中,永久代已经被移除,被一个称为“元数据区”(元空间)的区域所取代。
            元空间的本质和永久代类似,都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于:元空间并不在虚拟机中,而是使用本地内存。因此,默认情况下,元空间的大小仅受本地内存限制。类的元数据放入 native memory, 字符串池和类的静态变量放入java堆中. 这样可以加载多少类的元数据就不再由MaxPermSize控制, 而由系统的实际可用空间来控制.
            采用元空间而不用永久代的几点原因:
              1、为了解决永久代的Out of Memory问题,元数据和class对象存在永久代中,容易出现性能问题和内存溢出。
              2、类及方法的信息等比较难确定其大小,因此对于永久代的大小指定比较困难,太小容易出现永久代溢出,太大则容易导致老年代溢出(因为堆空间有限,此消彼长)。
              3、永久代会为 GC 带来不必要的复杂度,并且回收效率偏低。
              4、Oracle 可能会将HotSpot 与 JRockit 合二为一。

      虚拟机栈  

        虚拟栈描述的是java方法执行时的内存模型(JMM),每个方法在执行的时候会创建一个栈帧(stack frame),栈帧的数据结构包括局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从开始执行到退出的过程,及对应着栈帧在虚拟机栈中入栈到出栈的过程。(关于栈帧及方法执行的具体细节,在执行子系统中会有具体描述)
        虚拟机栈可能出现的异常状况:
          stackOverFlow:栈溢出,如果方法调用的栈深度大于虚拟机允许的最大栈深度,就会出现stackOverFlow异常。递归方法调用时,如果调用栈过深,就有可能引发栈溢出。这也是为什么慎用递归的原因之一以及编写递归时的注意点。
          OutOfMemory:如果虚拟机栈允许动态扩展,在扩展时无法申请到足够的内存,就会抛出OOM异常。

      本地方法栈

          对于一个运行中的Java程序而言,它还可能会用到一些跟本地方法相关的数据区。当某个线程调用一个本地方法时,它就进入了一个全新的并且不再受虚拟机限制的世界。本地方法可以通过本地方法接口来访问虚拟机的运行时数据区,但不止如此,它还可以做任何它想做的事情。

          本地方法本质上时依赖于实现的,虚拟机实现的设计者们可以自由地决定使用怎样的机制来让Java程序调用本地方法。

          任何本地方法接口都会使用某种本地方法栈。当线程调用Java方法时,虚拟机会创建一个新的栈帧并压入Java栈。然而当它调用的是本地方法时,虚拟机会保持Java栈不变,不再在线程的Java栈中压入新的帧,虚拟机只是简单地动态连接并直接调用指定的本地方法。

          如果某个虚拟机实现的本地方法接口是使用C连接模型的话,那么它的本地方法栈就是C栈。当C程序调用一个C函数时,其栈操作都是确定的。传递给该函数的参数以某个确定的顺序压入栈,它的返回值也以确定的方式传回调用者。同样,这就是虚拟机实现中本地方法栈的行为。

          很可能本地方法接口需要回调Java虚拟机中的Java方法,在这种情况下,该线程会保存本地方法栈的状态并进入到另一个Java栈。

          下图描绘了这样一个情景,就是当一个线程调用一个本地方法时,本地方法又回调虚拟机中的另一个Java方法。

          这幅图展示了JAVA虚拟机内部线程运行的全景图。一个线程可能在整个生命周期中都执行Java方法,操作它的Java栈;或者它可能毫无障碍地在Java栈和本地方法栈之间跳转。

      程序计数器  

          程序计数器是一个记录着当前线程所执行的字节码的行号指示器。
            JAVA代码编译后的字节码在未经过JIT(实时编译器)编译前,其执行方式是通过“字节码解释器”进行解释执行。简单的工作原理为解释器读取装载入内存的字节码,按照顺序读取字节码指令。读取一个指令后,将该指令“翻译”成固定的操作,并根据这些操作进行分支、循环、跳转等流程。
            从上面的描述中,可能会产生程序计数器是否是多余的疑问。因为沿着指令的顺序执行下去,即使是分支跳转这样的流程,跳转到指定的指令处按顺序继续执行是完全能够保证程序的执行顺序的。假设程序永远只有一个线程,这个疑问没有任何问题,也就是说并不需要程序计数器。但实际上程序是通过多个线程协同合作执行的。
            首先我们要搞清楚JVM的多线程实现方式。JVM的多线程是通过CPU时间片轮转(即线程轮流切换并分配处理器执行时间)算法来实现的。也就是说,某个线程在执行过程中可能会因为时间片耗尽而被挂起,而另一个线程获取到时间片开始执行。当被挂起的线程重新获取到时间片的时候,它要想从被挂起的地方继续执行,就必须知道它上次执行到哪个位置,在JVM中,通过程序计数器来记录某个线程的字节码执行位置。因此,程序计数器是具备线程隔离的特性,也就是说,每个线程工作时都有属于自己的独立计数器。

          特点:

            线程私有

            JVM规范中唯一没有规定OutOfMemoryError情况的区域  

            如果正在执行的是Native 方法,则这个计数器值为空

  • 相关阅读:
    C#操作REDIS例子
    A C# Framework for Interprocess Synchronization and Communication
    UTF8 GBK UTF8 GB2312 之间的区别和关系
    开源项目选型问题
    Mysql命令大全——入门经典
    RAM, SDRAM ,ROM, NAND FLASH, NOR FLASH 详解(引用)
    zabbix邮件报警通过脚本来发送邮件
    centos启动提示unexpected inconsistency RUN fsck MANUALLY
    rm 或者ls 报Argument list too long
    初遇Citymaker (六)
  • 原文地址:https://www.cnblogs.com/wnwn/p/11985266.html
Copyright © 2011-2022 走看看