1、运行时数据区域有哪些？

• 有方法区、虚拟机栈、本地方法栈、堆、程序计数器，其中方法区和堆是由线程共享的数据区，其他几个是线程隔离的数据区。
• 程序计数器：程序计数器是一块较小的内存，他可以看作是当前线程所执行的行号指示器。
  • 字节码解释器工作的时候就是通过改变这个计数器的值来选取下一条需要执行的字节码的指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。
  • 如果线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址。如果正在执行的是Native方法，这个计数器则为空。
  • 此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemotyError情况的区域
• Java虚拟机栈：虚拟机栈描述的是Java方法执行的内存模型
  • 每个方法在执行的同时都会创建一个栈帧用于储存局部变量表、操作数栈、动态链接、方法出口等信息。每个方法从调用直至完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。
  • 栈内存就是虚拟机栈，或者说是虚拟机栈中局部变量表的部分。
  • 局部变量表存放了编辑期可知的各种基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（refrence）类型和returnAddress类型（指向了一条字节码指令的地址），其中64位长度的long和double类型的数据会占用两个局部变量空间，其余的数据类型只占用1个。
  • Java虚拟机规范对这个区域规定了两种异常状况：
    • 如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常。
    • 如果虚拟机扩展时无法申请到足够的内存，就会跑出OutOfMemoryError异常
• 本地方法栈：
  • 本地方法栈和虚拟机栈发挥的作用是非常类似的，他们的区别是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务。
  • 本地方法栈区域也会抛出StackOverflowError和OutOfMemoryErroy异常。
• Java堆：是Java虚拟机所管理的内存中最大的一块。
  • Java堆是被所有线程共享的一块内存区域，在虚拟机启动的时候创建，此内存区域的唯一目的是存放对象实例，几乎所有的对象实例都在这里分配内存。所有的对象实例和数组都在堆上分配。
  • Java堆是垃圾收集器管理的主要区域。Java堆细分为新生代和老年代。
  • Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可。如果在堆中没有完成实例分配，并且堆也无法在扩展时将会抛出OutOfMemoryError异常。
• 方法区：用于储存已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
  • 不需要连续的内存和可以选择固定大小或者可扩展外，还可以选择不实现垃圾收集。这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载。
  • 当方法区无法满足内存分配需求时，将抛出OutOfMemoryErroy异常。
• 运行时常量池：是方法区的一部分。
  • Class文件中除了有关的版本、字段、方法、接口等描述信息外、还有一项信息是常量池，用于存放编辑期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放
  • Java语言并不要求常量一定只有编辑期才能产生，也就是可能将新的常量放入池中，这种特性被开发人员利用得比较多的便是String类的intern()方法（一种手动将字符串加入常量池中的native方法）。
  • 当常量池无法再申请到内存时会抛出OutOfMemoryError异常。

2、对象的内存布局？对象的访问定位方式有哪些？使用指针访问和使用句柄访问各具有何优势？

2.1、对象的内存布局？

• 在HotSpot虚拟机中，对象在内存中储存的布局可以分为3块区域：对象头、实例数据和对齐填充。
• 对象头包括两部分：
  • 储存对象自身的运行时数据，如哈希码、GC分带年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳
  • 另一部分是指类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是那个类的实例

2.2、对象的访问定位方式有哪些？

• 使用句柄访问
  • Java堆中将会划分出一块内存来作为句柄池，reference中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自的具体地址。
• 使用直接指针访问
  • Java堆对象的布局就必须考虑如何访问类型数据的相关信息，而refreence中存储的直接就是对象的地址。

2.3、使用指针访问和使用句柄访问各具有何优势？

• 使用句柄访问优势
  • reference中存储的是稳定的句柄地址，在对象被移动(垃圾收集时移动对象是非常普遍的行为)时，只会改变句柄中的实例数据指针，而reference本身不需要修改
• 使用直接指针访问优势
  • 速度更快，节省了一次指针定位的时间开销，由于对象的访问在Java中非常频繁，因此这类开销积少成多后也是一项非常可观的执行成本。

3、对象的创建过程

3.1、说一下对象的创建过程？比如：Dog dog= new Dog()

对象创建主要分为五个步骤

• 类加载检查：
  • Java虚拟机（jvm）在读取一条new指令时候，首先检查能否在常量池中定位到这个类的符号引用，并且检查这个符号引用代表的类是否被加载、解析和初始化。如果没有，则会先执行相应的类加载过程。
• 内存分配
  • 在类加载完成后，则开始为新生的对象分配内存。该对象所需的内存大小在类加载完成后便可确定，因此为每个对象分配的内存大小是确定的。而分配方式主要有两种，分别为：
    • 指针碰撞：
      • 应用场合为：堆内存规整（通俗的说就是用过的内存被整齐充分的利用，用过的内存放在一边，没有用过的放在另外一边，而中间利用一个分界值指针对这两边的内存进行分界，从而掌握内存分配情况）。即在开辟内存空间时候，将分界值指针往没用过的内存方向移动向应大小位置即可）。
      • 将堆内存这样划分的代表的GC收集器算法有：Serial，ParNew。
      • 空闲列表：
        • 应用场合：堆内存不规整（虚拟机维护一个可以记录内存块是否可以用的列表来了解内存分配情况）即在开辟内存空间时候，找到一块足够大的内存块分配给该对象即可，同时更新记录列表。
        • 将堆内存这样划分的代表的GC收集器算法有：CMS。
  • 对于多线程的情况，如何确保一个线程分配了对象内存但尚未修改内存管理指针时，其他线程又分配该块内存而覆盖的情况？
    • 有一种方法，就是让每一个线程在堆中先预分配一小块内存（TLAB本地线程分配缓冲），每个线程只在自己的内存中分配内存。但对象本身按其访问属性是可以线程共享访问的。
• 初始化默认值
  • 虚拟机需要将分配到的内存空间都进行初始化（即给一些默认值），这将做是为了保证对象实例的字段在Java代码中可以在不赋初值的情况下使用。
• 设置对象头
  • 虚拟机对对象进行一些简单设置，如标记该对象是哪个类的实例，这个对象的hash码，该对象所处的年龄段等等（这些可以理解为对象实例的基本信息）。这些信息被写在对象头中。jvm根据当前的运行状态，会给出不同的设置方式。
• 执行初始化方法
  • 最后执行由开发人员编写的对象的初始化方法，把对象按照开发人员的设计进行初始化，一个对象便创建出来了。

3.2、变量创建过程种放在虚拟机哪里？

• 变量是实例变量、局部变量或静态变量的不同将引用放在不同的地方：
  • 如果dog局部变量，dog变量在栈帧的局部变量表，这个对象的引用就放在栈帧。
  • 如果dog是实例变量，dog变量在堆中，对象的引用就放在堆。
  • 如果dog是静态变量，dog变量在方法区，对象的引用就放在方法区。

4、OutOfMemoryError异常在哪些数据区域中可能会出现？

• Java堆溢出
  • Java堆用于存储对象实例，只要不断的创建对象，并且保证GCRoots到对象之间有可达路径来避免垃圾回收机制清除这些对象，那么在数量到达最大堆的容量限制后就会产生内存溢出异常
  • 如果是内存泄漏，可进一步通过工具查看泄漏对象到GC Roots的引用链。于是就能找到泄露对象是通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收它们的。掌握了泄漏对象的类型信息及GC Roots引用链的信息，就可以比较准确地定位出泄漏代码的位置
  • 如果不存在泄露，换句话说，就是内存中的对象确实都还必须存活着，那就应当检查虚拟机的堆参数（-Xmx与-Xms），与机器物理内存对比看是否还可以调大，从代码上检查是否存在某些对象生命周期过长、持有状态时间过长的情况，尝试减少程序运行期的内存消耗
• 虚拟机栈和本地方法栈溢出
  • 对于HotSpot来说，虽然-Xoss参数（设置本地方法栈大小）存在，但实际上是无效的，栈容量只由-Xss参数设定。关于虚拟机栈和本地方法栈，在Java虚拟机规范中描述了两种异常：
    • 如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError
    • 如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常
  • 在单线程下，无论由于栈帧太大还是虚拟机栈容量太小，当内存无法分配的时候，虚拟机抛出的都是StackOverflowError异常。
  • 注意：如果是多线程导致的内存溢出，与栈空间是否足够大并不存在任何联系，这个时候每个线程的栈分配的内存越大，反而越容易产生内存溢出异常。解决的时候是在不能减少线程数或更换64为的虚拟机的情况下，就只能通过减少最大堆和减少栈容量来换取更多的线程。
• 方法区和运行时常量池溢出
  • String.intern()是一个Native方法，它的作用是：如果字符串常量池中已经包含一个等于此String对象的字符串，则返回代表池中这个字符串的String对象；否则，将此String对象包含的字符串添加到常量池中，并且返回此String对象的引用
  • 由于常量池分配在永久代中，可以通过-XX:PermSize和-XX:MaxPermSize限制方法区大小，从而间接限制其中常量池的容量。
  • Intern():JDK1.6 intern方法会把首次遇到的字符串实例复制到永久代，返回的也是永久代中这个字符串实例的引用，而由StringBuilder创建的字符串实例在Java堆上，所以必然不是一个引用。JDK1.7 intern()方法的实现不会再复制实例，只是在常量池中记录首次出现的实例引用，因此intern()返回的引用和由StringBuilder创建的那个字符串实例是同一个。

5、java中垃圾收集的方法有哪些？

• 标记-清除:
  • 这是垃圾收集算法中最基础的，根据名字就可以知道，它的思想就是标记哪些要被回收的对象，然后统一回收。这种方法很简单，但是会有两个主要问题：
    • 效率不高，标记和清除的效率都很低。
    • 会产生大量不连续的内存碎片，导致以后程序在分配较大的对象时，由于没有充足的连续内存而提前触发一次GC动作。
• 复制算法:
  • 为了解决效率问题，复制算法将可用内存按容量划分为两部分，然后每次只使用其中的一块，当一块内存用完时，就将还存活的对象复制到第二块内存上，然后一次性清楚完第一块内存。但是这种方式，内存的代价太高，每次基本上都要浪费一般的内存。
  • 于是将该算法进行了改进，内存区域不再是按照1：1去划分，而是将内存划分为8:1:1三部分，较大那份内存交Eden区，其余是两块较小的内存区叫Survior区。每次都会优先使用Eden区，若Eden区满，就将对象复制到第二块内存区上，然后清除Eden区，如果此时存活的对象太多，以至于Survivor不够时，会将这些对象通过分配担保机制复制到老年代中。(java堆又分为新生代和老年代)
• 标记-整理
  • 该算法主要是为了解决标记-清除，产生大量内存碎片的问题；当对象存活率较高时，也解决了复制算法的效率问题。它的不同之处就是在清除对象的时候现将可回收对象移动到一端，然后清除掉端边界以外的对象，这样就不会产生内存碎片了。
• 分代收集
  • 现在的虚拟机垃圾收集大多采用这种方式，它根据对象的生存周期，将堆分为新生代和老年代。在新生代中，由于对象生存期短，每次回收都会有大量对象死去，那么这时就采用复制算法。老年代里的对象存活率较高，没有额外的空间进行分配担保，所以可以使用标记-整理 或者 标记-清除。

6、java中可以作为GC Roots的对象有哪些？

• 虚拟机栈中引用的对象。
• 方法区类静态属性引用的对象。
• 方法区常量池引用的对象。
• 本地方法栈JNI引用的对象。
• 如何理解一个对象不一定会被回收？
  • 虽然这些算法可以判定一个对象是否能被回收，但是当满足上述条件时，一个对象比不一定会被回收。当一个对象不可达GC Root时，这个对象并不会立马被回收，而是出于一个死缓的阶段，若要被真正的回收需要经历两次标记。
  • 如果对象在可达性分析中没有与GCRoot的引用链，那么此时就会被第一次标记并且进行一次筛选，筛选的条件是是否有必要执行finalize()方法。当对象没有覆盖finalize()方法或者已被虚拟机调用过，那么就认为是没必要的。
  • 如果该对象有必要执行finalize()方法，那么这个对象将会放在一个称为F-Queue的对队列中，虚拟机会触发一个Finalize()线程去执行，此线程是低优先级的，并且虚拟机不会承诺一直等待它运行完，这是因为如果finalize()执行缓慢或者发生了死锁，那么就会造成F-Queue队列一直等待，造成了内存回收系统的崩溃。GC对处于F-Queue中的对象进行第二次被标记，这时，该对象将被移除”即将回收”集合，等待回收。

7、Class.forName() 和ClassLoader.loadClass()区别？

• 问到的是反射，但是在底层涉及到了虚拟机的类加载知识。
• Class.forName() 默认执行类加载过程中的连接与初始化动作，一旦执行初始化动作，静态变量就会被初始化为程序员设置的值，如果有静态代码块，静态代码块也会被执行。
• ClassLoader.loadClass() 默认只执行类加载过程中的加载动作，后面的动作都不会执行。