四、JVM

1、Java虚拟机中，数据类型可以分为哪几类？

• Java虚拟机是通过某些数据类型来执行计算的，数据类型可以分为两种：基本类型和引用类型，基本类型的变量持有原始值，而引用类型的变量持有引用值。

  

• Java语言中的所有基本类型同样也都是Java虚拟机中的基本类型。但是boolean有点特别，虽然Java虚拟机也把boolean看做基本类型，但是指令集对boolean只有很有限的支持，当编译器把Java源代码编译为字节码时，它会用int或者byte来表示boolean。在Java虚拟机中，false是由整数零来表示的，所有非零整数都表示true，涉及boolean值的操作则会使用int。另外，boolean数组是当做byte数组来访问的。

• Java虚拟机还有一个只在内部使用的基本类型：returnAddress，Java程序员不能使用这个类型，这个基本类型被用来实现Java程序中的finally子句。该类型是jsr, ret以及jsr_w指令需要使用到的，它的值是JVM指令的操作码的指针。returnAddress类型不是简单意义上的数值，不属于任何一种基本类型，并且它的值是不能被运行中的程序所修改的。

• Java虚拟机的引用类型被统称为“引用（reference）”，有三种引用类型：类类型、接口类型、以及数组类型，它们的值都是对动态创建对象的引用。类类型的值是对类实例的引用；数组类型的值是对数组对象的引用，在Java虚拟机中，数组是个真正的对象；而接口类型的值，则是对实现了该接口的某个类实例的引用。还有一种特殊的引用值是null，它表示该引用变量没有引用任何对象。

2、为什么不把基本类型放堆中呢？

基本类型（如int、float、boolean等）是值类型，它们的值存储在栈中，而不是堆中。在Java中，栈和堆是两种不同的内存分配方式，它们各自有不同的特点和适用场景。

栈是一种线性数据结构，它具有快速的分配和释放内存的特点。栈中存储的数据是按照后进先出（LIFO）的顺序访问的，每个栈帧都包含了局部变量、方法参数和返回值等信息。由于栈的内存分配方式是顺序的，因此栈中的数据访问速度非常快，适用于存储局部变量和方法调用过程中的临时数据。

堆是一种动态数据结构，它的内存分配方式是不规则的，由垃圾回收器负责管理。堆中存储的数据是按照任意顺序访问的，每个对象都有一个唯一的地址，可以通过引用来访问。由于堆的内存分配方式是不规则的，因此堆中的数据访问速度相对较慢，但是可以存储任意大小的数据，适用于存储动态生成的对象和数据结构。

将基本类型存储在堆中，会增加内存分配和访问的开销，并且会使程序的性能降低。因此，为了提高程序的性能和效率，Java将基本类型存储在栈中，而将对象和数据结构存储在堆中。

3、JVM 由哪些部分组成？

JVM 的结构基本上由 4 部分组成：

• 类加载器，在 JVM 启动时或者类运行时将需要的 class 加载到 JVM 中
• 执行引擎，执行引擎的任务是负责执行 class 文件中包含的字节码指令，相当于实际机器上的 CPU
• 内存区，将内存划分成若干个区以模拟实际机器上的存储、记录和调度功能模块，如实际机器上的各种功能的寄存器或者 PC 指针的记录器等
• 本地方法调用，调用 C 或 C++ 实现的本地方法的代码返回结果

4、类加载器是有了解吗？

​ 顾名思义，类加载器（class loader）用来加载 Java 类到 Java 虚拟机中。一般来说，Java 虚拟机使用 Java 类的方式如下：Java 源程序（.java 文件）在经过 Java 编译器编译之后就被转换成 Java 字节代码（.class 文件）。

​ 类加载器负责读取 Java 字节代码，并转换成 java.lang.Class类的一个实例。每个这样的实例用来表示一个 Java 类。通过此实例的 newInstance()方法就可以创建出该类的一个对象。实际的情况可能更加复杂，比如 Java 字节代码可能是通过工具动态生成的，也可能是通过网络下载的。

5、Java 虚拟机是如何判定两个 Java 类是相同的？

​ Java 虚拟机不仅要看类的全名是否相同，还要看加载此类的类加载器是否一样。只有两者都相同的情况，才认为两个类是相同的。即便是同样的字节代码，被不同的类加载器加载之后所得到的类，也是不同的。比如一个 Java 类 com.example.Sample，编译之后生成了字节代码文件 Sample.class。两个不同的类加载器 ClassLoaderA和 ClassLoaderB分别读取了这个 Sample.class文件，并定义出两个 java.lang.Class类的实例来表示这个类。这两个实例是不相同的。对于 Java 虚拟机来说，它们是不同的类。试图对这两个类的对象进行相互赋值，会抛出运行时异常 ClassCastException。

6、Java类加载过程（生命周期）

1. 加载、Loading(装载)阶段

加载是类加载的第一个过程，在这个阶段，将完成一下三件事情：

• 通过一个类的全限定名获取该类的二进制流
• 将该二进制流中的静态存储结构转化为方法去运行时数据结构。
• 在内存中生成该类的 Class 对象，作为该类的数据访问入口

2. 验证

验证的目的是为了确保 Class 文件的字节流中的信息不回危害到虚拟机.在该阶段主要完成以下四钟验证

• 文件格式验证：验证字节流是否符合 Class 文件的规范，如主次版本号是否在当前虚拟机范围内，常量池中的常量是否有不被支持的类型
• 元数据验证:对字节码描述的信息进行语义分析，如这个类是否有父类，是否集成了不被继承的类等。
• 字节码验证：是整个验证过程中最复杂的一个阶段，通过验证数据流和控制流的分析，确定程序语义是否正确，主要针对方法体的验证。如：方法中的类型转换是否正确，跳转指令是否正确等
• 符号引用验证：这个动作在后面的解析过程中发生，主要是为了确保解析动作能正确执行

3. 准备

   简言之，为类的静态变量分配内存，并将其初始化为默认值。

   在这个阶段，虚拟机就会为这个类分配相应的内存空间，并设置默认初始值。Java虚拟机为各类型变量默认的初始值如表所示。

   

public static int value=123;//在准备阶段 value 初始值为 0 。在初始化阶段才会变为 123 。

4. 解析

该阶段主要完成符号引用到直接引用的转换动作。解析动作并不一定在初始化动作完成之前，也有可能在初始化之后。

5. 初始化

初始化阶段，简言之，为类的静态变量赋予正确的初始值。(显式初始化)

具体描述

类的初始化是类装载的最后一个阶段。如果前面的步骤都没有问题，那么表示类可以顺利装载到系统中。此时，类才会开始执行Java字节码。（即： 到了初始化阶段，才真正开始执行类中定义的 Java 程序代码 。）

初始化阶段的重要工作是执行类的初始化方法:<clinit>()方法。

• 该方法仅能由Java编译器生成并由JVM调用，程序开发者 无法自定义 一个同名的方法，更无法直接在Java程序中调用该方法，虽然该方法也是由字节码指令所组成。
• 它是由类静态成员的赋值语句以及static语句块合并产生的。

<clinit>():只有在给类中的static的变量显示赋值或在静态代码中赋值了。才会生成此方法。
<init>():一定会出现在Class的method表中。

6. 使用

   任何一个类型在使用之前都必须经历过完整的加载、链接和初始化3个类加载步骤。一旦一个类型成功经历过这3个步骤之后，便“万事俱备，只欠东风”，就等着开发者使用了。

   开发人员可以在程序中访问和调用它的静态类成员信息（比如：静态字段、静态方法），或者使用new关键字为其创建对象实例。

7. 卸载

​ 在类加载器的内部实现中，用一个Java集合来存放所加载类的引用。另一方面，一个Class对象总是会引用它的类加载器，调用Class对象的getClassLoader()方法，就能获得它的类加载器。由此可见，代表某个类的Class实例与其类的加载器之间为双向关联关系。

一个类的实例总是引用代表这个类的Class对象。在Object类中定义了getClass()方法，这个方法返回代表对象所属类的Class对象的引用。此外，所有的Java类都有一个静态属性class，它引用代表这个类的Class对象。

7、Class的forName("Java.lang.String")和Class的getClassLoader()的loadClass("Java.lang.String")有什么区别？

• 使用 loadClass() 方法获得的 Class 对象只完成了类加载过程中的第一步：加载，后续的操作均未进行。
• 使用 Class.forName() 方法获得 Class 对象是已经执行完初始化的了

Class的forName("Java.lang.String")和Class的getClassLoader().loadClass("Java.lang.String")都是用于获取Java.lang.String类的Class对象的方法，但是它们有一些区别。

1. Class.forName("Java.lang.String")方法会触发类的静态初始化，而ClassLoader.loadClass("Java.lang.String")方法不会触发类的静态初始化。静态初始化是指在类加载时执行的static块，如果一个类没有被加载过，则在调用Class.forName("Java.lang.String")方法时会进行类的加载和静态初始化，如果一个类已经被加载过，则只进行静态初始化；而ClassLoader.loadClass("Java.lang.String")方法只进行类的加载，不进行静态初始化，所以在调用该方法后需要手动调用类的静态方法或者使用类的实例触发静态初始化。
2. Class.forName("Java.lang.String")方法默认使用当前线程的ClassLoader进行类的加载，而ClassLoader.loadClass("Java.lang.String")方法需要显式指定ClassLoader进行类的加载。如果需要使用自定义的ClassLoader进行类的加载，则可以使用ClassLoader.loadClass("Java.lang.String")方法。
3. Class.forName("Java.lang.String")方法可以加载并返回指定类的Class对象，如果指定的类不存在，则会抛出ClassNotFoundException异常。而ClassLoader.loadClass("Java.lang.String")方法只进行类的加载，返回的是一个Class对象的引用，需要手动进行类型转换。

综上所述，Class.forName("Java.lang.String")方法触发类的静态初始化，使用当前线程的ClassLoader进行类的加载，可以加载并返回指定类的Class对象；而ClassLoader.loadClass("Java.lang.String")方法只进行类的加载，需要显式指定ClassLoader进行类的加载，不会触发类的静态初始化，返回的是一个Class对象的引用，需要手动进行类型转换。

8、双亲委派机制

规定了类加载的顺序是：引导类加载器先加载，若加载不到，由扩展类加载器加载，若还加载不到，才会由系统类加载器或自定义的类加载器进行加载。

双亲委派机制在java.lang.ClassLoader.loadClass(String,boolean)接口中体现。该接口的逻辑如下：

(1)先在当前加载器的缓存中查找有无目标类，如果有，直接返回。

(2)判断当前加载器的父加载器是否为空，如果不为空，则调用parent.loadClass(name, false)接口进行加载。

(3)反之，如果当前加载器的父类加载器为空，则调用findBootstrapClassOrNull(name)接口，让引导类加载器进行加载。

(4)如果通过以上3条路径都没能成功加载，则调用findClass(name)接口进行加载。该接口最终会调用java.lang.ClassLoader接口的defineClass系列的native接口加载目标Java类。

双亲委派的模型就隐藏在这第2和第3步中。

9、双亲委派机制的优势与劣势

1.双亲委派机制优势

• 避免类的重复加载，确保一个类的全局唯一性

Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关系可以避免类的重复加载，当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次。

• 保护程序安全，防止核心API被随意篡改

2**.双亲委托模式的弊端**

检查类是否加载的委托过程是单向的，这个方式虽然从结构上说比较清晰，使各个ClassLoader的职责非常明确，但是同时会带来一个问题，即顶层的ClassLoader无法访问底层的ClassLoader所加载的类。

通常情况下，启动类加载器中的类为系统核心类，包括一些重要的系统接口，而在应用类加载器中，为应用类。按照这种模式，应用类访问系统类自然是没有问题，但是系统类访问应用类就会出现问题。比如在系统类中提供了一个接口，该接口需要在应用类中得以实现，该接口还绑定一个工厂方法，用于创建该接口的实例，而接口和工厂方法都在启动类加载器中。这时，就会出现该工厂方法无法创建由应用类加载器加载的应用实例的问题。

3.结论：

由于Java虚拟机规范并没有明确要求类加载器的加载机制一定要使用双亲委派模型，只是建议采用这种方式而已。

比如在Tomcat中，类加载器所采用的加载机制就和传统的双亲委派模型有一定区别，当缺省的类加载器接收到一个类的加载任务时，首先会由它自行加载，当它加载失败时，才会将类的加载任务委派给它的超类加载器去执行，这同时也是Servlet规范推荐的一种做法。

10、破坏双亲委派机制

1、破坏双亲委派机制1

双亲委派模型并不是一个具有强制性约束的模型，而是Java设计者推荐给开发者们的类加载器实现方式。

在Java的世界中大部分的类加载器都遵循这个模型，但也有例外的情况，直到Java模块化出现为止，双亲委派模型主要出现过3次较大规模“被破坏”的情况。

第一次破坏双亲委派机制：

双亲委派模型的第一次“被破坏”其实发生在双亲委派模型出现之前——即JDK 1.2面世以前的“远古”时代。

由于双亲委派模型在JDK 1.2之后才被引入，但是类加载器的概念和抽象类java.lang.ClassLoader则在Java的第一个版本中就已经存在，面对已经存在的用户自定义类加载器的代码，Java设计者们引入双亲委派模型时不得不做出一些妥协，为了兼容这些已有代码，无法再以技术手段避免loadClass()被子类覆盖的可能性，只能在JDK1.2之后的java.lang.ClassLoader中添加一个新的protected方法findClass()，并引导用户编写的类加载逻辑时尽可能去重写这个方法，而不是在loadClass()中编写代码。上节我们已经分析过loadClass()方法，双亲委派的具体逻辑就实现在这里面，按照loadClass()方法的逻辑，如果父类加载失败，会自动调用自己的findClass()方法来完成加载，这样既不影响用户按照自己的意愿去加载类，又可以保证新写出来的类加载器是符合双亲委派规则的。

2、破坏双亲委派机制2

第二次破坏双亲委派机制：线程上下文类加载器

双亲委派模型的第二次“被破坏”是由这个模型自身的缺陷导致的，双亲委派很好地解决了各个类加载器协作时基础类型的一致性问题（越基础的类由越上层的加载器进行加载），基础类型之所以被称为“基础”，是因为它们总是作为被用户代码继承、调用的API存在，但程序设计往往没有绝对不变的完美规则，如果有基础类型又要调用回用户的代码，那该怎么办呢？

这并非是不可能出现的事情，一个典型的例子便是JNDI服务，JNDI现在已经是Java的标准服务，它的代码由启动类加载器来完成加载（在JDK 1.3时加入到rt.jar的），肯定属于Java中很基础的类型了。但JNDI存在的目的就是对资源进行查找和集中管理，它需要调用由其他厂商实现并部署在应用程序的ClassPath下的JNDI服务提供者接口（Service Provider Interface，SPI）的代码，现在问题来了，启动类加载器是绝不可能认识、加载这些代码的，那该怎么办？（SPI:在Java平台中，通常把核心类rt.jar中提供外部服务、可由应用层自行实现的接口称为SPI）

为了解决这个困境，Java的设计团队只好引入了一个不太优雅的设计：线程上下文类加载器（Thread Context ClassLoader）。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器

有了线程上下文类加载器，程序就可以做一些“舞弊”的事情了。JNDI服务使用这个线程上下文类加载器去加载所需的SPI服务代码，这是一种父类加载器去请求子类加载器完成类加载的行为，这种行为实际上是打通了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型的一般性原则，但也是无可奈何的事情。Java中涉及SPI的加载基本上都采用这种方式来完成，例如JNDI、JDBC、JCE、JAXB和JBI等。不过，当SPI的服务提供者多于一个的时候，代码就只能根据具体提供者的类型来硬编码判断，为了消除这种极不优雅的实现方式，在JDK 6时，JDK提供了java.util.ServiceLoader类，以META-INF/services中的配置信息，辅以责任链模式，这才算是给SPI的加载提供了一种相对合理的解决方案。

默认上下文加载器就是应用类加载器，这样以上下文加载器为中介，使得启动类加载器中的代码也可以访问应用类加载器中的类。

3、破坏双亲委派机制3

第三次破坏双亲委派机制：

双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求而导致的。如：**代码热替换（Hot Swap）、模块热部署（Hot Deployment）**等

IBM公司主导的JSR-291（即OSGi R4.2）实现模块化热部署的关键是它自定义的类加载器机制的实现，每一个程序模块（OSGi中称为Bundle）都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGi环境下，类加载器不再双亲委派模型推荐的树状结构，而是进一步发展为更加复杂的网状结构。

当收到类加载请求时，OSGi将按照下面的顺序进行类搜索：

1）*将以java.开头的类，委派给父类加载器加载。

2）否则，将委派列表名单内的类，委派给父类加载器加载。

3）否则，将Import列表中的类，委派给Export这个类的Bundle的类加载器加载。

4）否则，查找当前Bundle的ClassPath，使用自己的类加载器加载。

5）否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器加载。

6）否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载。

7）否则，类查找失败。

说明：只有开头两点仍然符合双亲委派模型的原则，其余的类查找都是在平级的类加载器中进行的

11、什么是tomcat类加载机制？

Tomcat8 和 Tomcat6比较大的区别是 ：

Tomcat8可以通过配置<Loader delegate="true"/>表示遵循双亲委派机制。

Tomcat 如何实现自己独特的类加载机制？

所以，Tomcat 是怎么实现的呢？牛逼的Tomcat团队已经设计好了。我们看看他们的设计图：

当应用需要到某个类时，则会按照下面的顺序进行类加载：

1 使用bootstrap引导类加载器加载

2 使用system系统类加载器加载

3 使用应用类加载器在WEB-INF/classes中加载

4 使用应用类加载器在WEB-INF/lib中加载

5 使用common类加载器在CATALINA_HOME/lib中加载

好了，至此，我们已经知道了tomcat为什么要这么设计，以及是如何设计的，那么，tomcat 违背了java 推荐的双亲委派模型了吗？答案是：违背了。 我们前面说过：双亲委派模型要求除了顶层的启动类加载器之外，其余的类加载器都应当由自己的父类加载器加载。

很显然，tomcat 不是这样实现，tomcat 为了实现隔离性，没有遵守这个约定，每个webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器。

1、既然 Tomcat 不遵循双亲委派机制，那么如果我自己定义一个恶意的HashMap，会不会有风险呢？(阿里面试问题)

答： 显然不会有风险，如果有，Tomcat都运行这么多年了，那能不改进吗？

tomcat不遵循双亲委派机制，只是自定义的classLoader顺序不同，但顶层还是相同的，还是要去顶层请求classloader。

2、我们思考一下：Tomcat是个web容器， 那么它要解决什么问题？

1. 一个web容器可能需要部署两个应用程序，不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求同一个类库在同一个服务器只有一份，因此要保证每个应用程序的类库都是独立的，保证相互隔离。

2. 部署在同一个web容器中相同的类库相同的版本可以共享。否则，如果服务器有10个应用程序，那么要有10份相同的类库加载进虚拟机，这是扯淡的。

3. web容器也有自己依赖的类库，不能于应用程序的类库混淆。基于安全考虑，应该让容器的类库和程序的类库隔离开来。

4. web容器要支持jsp的修改，我们知道，jsp 文件最终也是要编译成class文件才能在虚拟机中运行，但程序运行后修改jsp已经是司空见惯的事情，否则要你何用？ 所以，web容器需要支持 jsp 修改后不用重启。

3、Tomcat 如果使用默认的类加载机制行不行？

答案是不行的。为什么？我们看:

第一个问题，如果使用默认的类加载器机制，那么是无法加载两个相同类库的不同版本的，默认的累加器是不管你是什么版本的，只在乎你的全限定类名，并且只有一份。

第二个问题，默认的类加载器是能够实现的，因为他的职责就是保证唯一性。

第三个问题和第一个问题一样。

我们再看第四个问题，我们想我们要怎么实现jsp文件的热替换，jsp 文件其实也就是class文件，那么如果修改了，但类名还是一样，类加载器会直接取方法区中已经存在的，修改后的jsp是不会重新加载的。那么怎么办呢？我们可以直接卸载掉这jsp文件的类加载器，所以你应该想到了，每个jsp文件对应一个唯一的类加载器，当一个jsp文件修改了，就直接卸载这个jsp类加载器。重新创建类加载器，重新加载jsp文件。

4、如果tomcat 的 Common ClassLoader 想加载 WebApp ClassLoader 中的类，该怎么办？

看了前面的关于破坏双亲委派模型的内容，我们心里有数了，我们可以使用线程上下文类加载器实现，使用线程上下文加载器，可以让父类加载器请求子类加载器去完成类加载的动作。

5、为什么java文件放在Eclipse/IDEA中的src文件夹下会优先jar包中的class?

tomcat类加载机制的理解，就不难明白。因为Eclipse/IDEA中的src文件夹中的文件java以及webContent中的JSP都会在tomcat启动时，被编译成class文件放在 WEB-INF/class 中。

而Eclipse/IDEA外部引用的jar包，则相当于放在 WEB-INF/lib 中。

因此肯定是 java文件或者JSP文件编译出的class优先加载。

12、你能画出HotSpotVM内存结构图吗

13、内存模型以及分区

JVM 分为堆区和栈区，还有方法区(元空间)，初始化的对象放在堆里面，引用放在栈里面，class 类信息常量池（static 常量和 static 变量）等放在方法区

• 方法区：主要是存储类信息，常量池（static 常量和 static 变量），编译后的代码（字节码）等数据
• 堆：初始化的对象，成员变量 （那种非 static 的变量），所有的对象实例和数组都要在堆上分配
• 栈：栈的结构是栈帧组成的，调用一个方法就压入一帧，帧上面存储局部变量表，操作数栈，方法出口等信息，局部变量表存放的是 8 大基础类型加上一个应用类型，所以还是一个指向地址的指针
• 本地方法栈：主要为 Native 方法服务
• 程序计数器：记录当前线程执行的行号

14、栈和堆的区别

• 栈和堆都会有OOM，但是栈不会有GC
• 栈的效率更高
• 内存大小（堆的空间大）；数据结构（栈，先进先出、堆，数组、链表、树等等）
• 栈管运行；堆管存储。

15、什么情况下会发生栈内存溢出

• 局部数组过大。当函数内部的数组过大时，有可能导致堆栈溢出。
• 递归调用层次太多。递归函数在运行时会执行压栈操作，当压栈次数太多时，也会导致堆栈溢出。

16、如何设置栈大小

-Xss size (即：-XX:ThreadStackSize)

一般默认为512k-1024k，取决于操作系统。

jdk5.0之前，默认栈大小:256k jdk5.0之后，默认栈大小: 1024k( linux \mac\windows )

设置的栈空间值过大，会导致系统可以用于创建线程的数量减少。 一般一个进程中通常有3000-5000个线程。

17、方法和栈帧的关系？

每个线程都有自己的栈，栈中的数据都是以**栈帧（Stack Frame）**的格式存在。

• 在这个线程上正在执行的每个方法都各自对应一个栈帧（Stack Frame）。
• 栈帧是一个内存区块，是一个数据集，维系着方法执行过程中的各种数据信息。

在一条活动线程中，一个时间点上，只会有一个活动的栈帧。即只有当前正在执行的方法的栈帧(栈顶栈帧)是有效的，这个栈帧被称为当前栈帧(Current Frame) ，与当前栈帧相对应的方法就是当前方法(Current Method) ，定义这个方法的类就是当前类(Current Class) 。 如果在该方法中调用了其他方法，对应的新的栈帧会被创建出来，放在栈的顶端，成为新的当前帧。 执行引擎运行的所有字节码指令只针对当前栈帧进行操作。

18、栈桢内部结构

每个栈帧中存储着：

• 局部变量表（Local Variables）
• 操作数栈（Operand Stack）（或表达式栈）
• 动态链接(Dynamic Linking) （或指向运行时常量池的方法引用）
• 方法返回地址（Return Address）（或方法正常退出或者异常退出的定义）
• 一些附加信息

19、局部变量表

• 局部变量表也被称之为局部变量数组或本地变量表

• 定义为一个数字数组，主要用于存储方法参数和定义在方法体内的局部变量，这些数据类型包括各类基本数据类型(8种)、对象引用（reference），以及returnAddress类型。

• 局部变量表所需的容量大小是在编译期确定下来的，并保存在方法的Code属性的maximum local variables数据项中。在方法运行期间是不会改变局部变量表的大小的。

• 方法嵌套调用的次数由栈的大小决定。一般来说，栈越大，方法嵌套调用次数越多。对一个函数而言，它的参数和局部变量越多，使得局部变量表膨胀，它的栈帧就越大，以满足方法调用所需传递的信息增大的需求。进而函数调用就会占用更多的栈空间，导致其嵌套调用次数就会减少。

• 局部变量表中的变量只在当前方法调用中有效。在方法执行时，虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。当方法调用结束后，随着方法栈帧的销毁，局部变量表也会随之销毁。

20、操作数栈

• 我们说Java虚拟机的解释引擎是基于栈的执行引擎，其中的栈指的就是操作数栈。
• 每一个独立的栈帧中除了包含局部变量表以外，还包含一个后进先出（Last-In-First-Out）的操作数栈，也可以称之为表达式栈（Expression Stack）。
• 操作数栈就是JVM执行引擎的一个工作区，当一个方法刚开始执行的时候，一个新的栈帧也会随之被创建出来，这个方法的操作数栈是空的。
• 每一个操作数栈都会拥有一个明确的栈深度用于存储数值，其所需的最大深度在编译期就定义好了，保存在方法的Code属性中，为max_stack的值。
• 栈中的任何一个元素都是可以任意的Java数据类型。
• • 32bit的类型占用一个栈单位深度
  • 64bit的类型占用两个栈单位深度
• 操作数栈，在方法执行过程中，根据字节码指令，并非采用访问索引的方式来进行数据访问的，而是只能通过标准的入栈（push）和出栈（pop）操作，往栈中写入数据或提取数据来完成一次数据访问。
• 某些字节码指令将值压入操作数栈，其余的字节码指令将操作数取出栈。使用它们后再把结果压入栈。比如：执行复制、交换、求和等操作
• 如果被调用的方法带有返回值的话，其返回值将会被压入当前栈帧的操作数栈中，并更新PC寄存器中下一条需要执行的字节码指令。

21、栈溢出的情况

栈溢出:StackOverflowError;

举个简单的例子:在main方法中调用main方法,就会不断压栈执行,直到栈溢出;

栈的大小可以是固定大小的,也可以是动态变化（动态扩展）的。

如果是固定的,可以通过-Xss设置栈的大小;

如果是动态变化的,当栈大小到达了整个内存空间不足了,就是抛出OutOfMemory异常(java.lang.OutOfMemoryError)

22、调整栈大小,就能保证不出现溢出吗?

不能。因为调整栈大小,只会减少出现溢出的可能,栈大小不是可以无限扩大的,所以不能保证不出现溢出

23、分配的栈内存越大越好吗?

不是,因为增加栈大小，会造成每个线程的栈都变的很大,使得一定的栈空间下,能创建的线程数量会变小

24、垃圾回收是否会涉及到虚拟机栈?

不会;垃圾回收只会涉及到方法区和堆中,方法区和堆也会存在溢出的可能;

程序计数器,只记录运行下一行的地址,不存在溢出和垃圾回收;

虚拟机栈和本地方法栈,都是只涉及压栈和出栈,可能存在栈溢出,不存在垃圾回收。

25、对象都分配在堆上？

• 《Java虚拟机规范》中对Java堆的描述是：所有的对象实例以及数组都应当在运行时分配在堆上。（The heap is the run-time data area from which memory for all class instances and arrays is allocated ) 数组和对象可能永远不会存储在栈上，因为栈帧中保存引用，这个引用指向对象或者数组在堆中的位置。
• 我要说的是：“几乎”所有的对象实例都在这里分配内存。——从实际使用角度看的。

26、堆里面的分区：Eden，survival （from+ to），老年代，各自的特点。

​ 堆里面分为新生代和老生代（java8 取消了永久代，采用了 Metaspace），新生代包含 Eden+Survivor 区，survivor 区里面分为 from 和 to 区，内存回收时，如果用的是复制算法，从 from 复制到 to，当经过一次或者多次 GC 之后，存活下来的对象会被移动到老年区，当 JVM 内存不够用的时候，会触发 Full GC，清理 JVM 老年区当新生区满了之后会触发 YGC,先把存活的对象放到其中一个 Survice区，然后进行垃圾清理。因为如果仅仅清理需要删除的对象，这样会导致内存碎片，因此一般会把 Eden 进行完全的清理，然后整理内存。那么下次 GC 的时候，就会使用下一个 Survive，这样循环使用。如果有特别大的对象，新生代放不下，就会使用老年代的担保，直接放到老年代里面。因为 JVM 认为，一般大对象的存活时间一般比较久远。

• 存储在JVM中的Java对象可以被划分为两类：
  • 一类是生命周期较短的瞬时对象，这类对象的创建和消亡都非常迅速
  • 另外一类对象的生命周期却非常长，在某些极端的情况下还能够与JVM的生命周期保持一致。
• Java堆区进一步细分的话，可以划分为年轻代（YoungGen）和老年代（OldGen）
• 其中年轻代又可以划分为Eden空间、Survivor0空间和Survivor1空间（有时也叫做from区、to区）。

• 几乎所有的Java对象都是在Eden区被new出来的。
• 绝大部分的Java对象的销毁都在新生代进行了。
  • IBM 公司的专门研究表明，新生代中 80% 的对象都是“朝生夕死”的。

27、如何设置堆内存大小？

• Java堆区用于存储Java对象实例，那么堆的大小在JVM启动时就已经设定好了，大家可以通过选项”-Xmx”和”-Xms”来进行设置。

  • “-Xms”用于表示堆区的起始内存，等价于-XX:InitialHeapSize
  • “-Xmx”则用于表示堆区的最大内存，等价于-XX:MaxHeapSize

• 一旦堆区中的内存大小超过“-Xmx”所指定的最大内存时，将会抛出OutOfMemoryError:heap异常。

• 通常会将 -Xms 和 -Xmx两个参数配置相同的值，其目的是为了能够在java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小，从而提高性能。

  • heap默认最大值计算方式：如果物理内存少于192M,那么heap最大值为物理内存的一半。如果物理内存大于等于1G，那么heap的最大值为物理内存的1/4。
  • heap默认最小值计算方式：最少不得少于8M，如果物理内存大于等于1G，那么默认值为物理内存的1/64，即1024/64=16M。最小堆内存在jvm启动的时候就会被初始化。

28、初始堆大小和最大堆大小一样，问这样有什么好处？

通常会将 -Xms 和 -Xmx两个参数配置相同的值，其目的是为了能够在java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小，从而提高性能。

29、JVM中最大堆大小有没有限制

在Oracle Solaris 7和Oracle Solaris 8 SPARC平台上，这个值的上限大约是4000 MB减去开销。在Oracle Solaris 2.6和x86平台上，上限大约是2000 MB减去开销。在Linux平台上，上限大约是2000 MB减去开销。

另：对于32位操作系统，如果物理内存等于4G，那么堆内存可以达到1G。对于64位操作系统，如果物理内存为128G，那么heap最多可以达到32G。

30、如何设置新生代与老年代比例

下面这参数开发中一般不会调：

• 配置新生代与老年代在堆结构的占比。
  • 默认**-XX:NewRatio=2**，表示新生代占1，老年代占2，新生代占整个堆的1/3
  • 可以修改-XX:NewRatio=4，表示新生代占1，老年代占4，新生代占整个堆的1/5
• 可以使用选项”-Xmn”设置新生代最大内存大小
  • 这个参数一般使用默认值就可以了。

31、如何设置Eden、幸存者区比例

• 在HotSpot中，Eden空间和另外两个Survivor空间缺省所占的比例是8:1:1（要显式配置）
• 当然开发人员可以通过选项“-XX:SurvivorRatio”调整这个空间比例。比如-XX:SurvivorRatio=8

32、对象分配过程

1.new的对象先放伊甸园区。此区有大小限制。

2.当伊甸园的空间填满时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC/YGC)，将伊甸园区中的不再被其他对象所引用的对象进行销毁。再加载新的对象放到伊甸园区

3.然后将伊甸园中的剩余对象移动到幸存者0区。

4.如果再次触发垃圾回收，此时上次幸存下来的放到幸存者0区的，如果没有回收，就会放到幸存者1区。

5.如果再次经历垃圾回收，此时会重新放回幸存者0区，接着再去幸存者1区。

6.啥时候能去养老区呢？可以设置次数。默认是15次。

• 可以设置参数：-XX:MaxTenuringThreshold=<N> 设置对象晋升老年代的年龄阈值。

7.在养老区，相对悠闲。当养老区内存不足时，再次触发GC：Major GC，进行养老区的内存清理。

8.若养老区执行了Major GC之后发现依然无法进行对象的保存，就会产生OOM异常

33、内存分配原则

• 优先分配到Eden
• 大对象直接分配到老年代
  • 尽量避免程序中出现过多的大对象
• 长期存活的对象分配到老年代
• 动态对象年龄判断
  • 如果Survivor 区中相同年龄的所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象可以直接进入老年代，无须等到 MaxTenuringThreshold 中要求的年龄。
• 空间分配担保
  • -XX:HandlePromotionFailure

34、解释MinorGC、MajorGC、FullGC

JVM在进行GC时，并非每次都对上面三个内存(新生代、老年代；方法区)区域一起回收的，大部分时候回收的都是指新生代。

针对HotSpot VM的实现，它里面的GC按照回收区域又分为两大种类型：

• 一种是部分收集（Partial GC）

• 一种是整堆收集（Full GC）

• 部分收集：不是完整收集整个Java堆的垃圾收集。其中又分为：

  • 新生代收集（Minor GC / Young GC）：只是新生代（Eden\S0,S1）的垃圾收集

  • 老年代收集（Major GC / Old GC）：只是老年代的垃圾收集。

  • 目前，只有CMS GC会有单独收集老年代的行为。

  • 注意，很多时候Major GC会和Full GC混淆使用，需要具体分辨是老年代回收还是整堆回收。

• 混合收集（Mixed GC)：收集整个新生代以及部分老年代的垃圾收集。

  • 目前，只有G1 GC会有这种行为

• 整堆收集（Full GC)：收集整个java堆和方法区的垃圾收集。

35、GC 的两种判定方法

• 引用计数法：指的是如果某个地方引用了这个对象就+1，如果失效了就-1，当为 0 就会回收但是 JVM 没有用这种方式，因为无法判定相互循环引用（A 引用 B,B 引用 A）的情况
• 引用链法： 通过一种 GC ROOT 的对象（方法区中静态变量引用的对象等-static 变量）来判断，如果有一条链能够到达 GC ROOT 就说明，不能到达 GC ROOT 就说明可以回收

36、java 中垃圾收集的方法有哪些?

1. 标记-清除

   这是垃圾收集算法中最基础的，根据名字就可以知道，它的思想就是标记哪些要被回收的对象，然后统一回收。这种方法很简单，但是会有两个主要问题：1.效率不高，标记和清除的效率都很低；2.会产生大量不连续的内存碎片，导致以后程序在分配较大的对象时，由于没有充足的连续内存而提前触发一次 GC 动作。

2. 复制算法

   为了解决效率问题，复制算法将可用内存按容量划分为相等的两部分，然后每次只使用其中的一块，当一块内存用完时，就将还存活的对象复制到第二块内存上，然后一次性清楚完第一块内存，再将第二块上的对象复制到第一块。但是这种方式，内存的代价太高，每次基本上都要浪费一般的内存。于是将该算法进行了改进，内存区域不再是按照 1：1 去划分，而是将内存划分为8:1:1 三部分，较大那份内存交 Eden 区，其余是两块较小的内存区叫 Survior 区。每次都会优先使用 Eden 区，若 Eden 区满，就将对象复制到第二块内存区上，然后清除 Eden 区，如果此时存活的对象太多，以至于 Survivor 不够时，会将这些对象通过分配担保机制复制到老年代中。(java 堆又分为新生代和老年代)

3. 标记-整理

   该算法主要是为了解决标记-清除，产生大量内存碎片的问题；当对象存活率较高时，也解决了复制算法的效率问题。它的不同之处就是在清除对象的时候现将可回收对象移动到一端，然后清除掉端边界以外的对象，这样就不会产生内存碎片了。

4. 分代收集

   现在的虚拟机垃圾收集大多采用这种方式，它根据对象的生存周期，将堆分为新生代和老年代。在新生代中，由于对象生存期短，每次回收都会有大量对象死去，那么这时就采用复制算法。老年代里的对象存活率较高，没有额外的空间进行分配担保，所以可以使用标记-整理 或者 标记-清除。