针对《面试心得与总结—BAT、网易、蘑菇街》一文中出现的技术问题的收集与整理（3）

JVM

1. 内存模型以及分区，需要详细到每个区放什么

JVM内存区域模型

1.方法区

也称”永久代” 、“非堆”，  它用于存储虚拟机加载的类信息、常量、静态变量、是各个线程共享的内存区域。默认最小值为16MB，最大值为64MB，可以通过-XX:PermSize 和 -XX:MaxPermSize 参数限制方法区的大小。

运行时常量池：是方法区的一部分，Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池，用于存放编译器生成的各种符号引用，这部分内容将在类加载后放到方法区的运行时常量池中。

2.虚拟机栈

描述的是Java 方法执行的内存模型：每个方法被执行的时候 都会创建一个“栈帧”用于存储局部变量表(包括参数)、操作栈、方法出口等信息。每个方法被调用到执行完的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。声明周期与线程相同，是线程私有的。

局部变量表存放了编译器可知的各种基本数据类型(boolean、byte、char、short、int、float、long、double)、对象引用(引用指针，并非对象本身)，其中64位长度的long和double类型的数据会占用2个局部变量的空间，其余数据类型只占1个。局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在栈帧中分配多大的局部变量是完全确定的，在运行期间栈帧不会改变局部变量表的大小空间。

3.本地方法栈

与虚拟机栈基本类似，区别在于虚拟机栈为虚拟机执行的java方法服务，而本地方法栈则是为Native方法服务。

4.堆

也叫做java 堆、GC堆是java虚拟机所管理的内存中最大的一块内存区域，也是被各个线程共享的内存区域，在JVM启动时创建。该内存区域存放了对象实例及数组(所有new的对象)。其大小通过-Xms(最小值)和-Xmx(最大值)参数设置，-Xms为JVM启动时申请的最小内存，默认为操作系统物理内存的1/64但小于1G，-Xmx为JVM可申请的最大内存，默认为物理内存的1/4但小于1G，默认当空余堆内存小于40%时，JVM会增大Heap到-Xmx指定的大小，可通过-XX:MinHeapFreeRation=来指定这个比列；当空余堆内存大于70%时，JVM会减小heap的大小到-Xms指定的大小，可通过XX:MaxHeapFreeRation=来指定这个比列，对于运行系统，为避免在运行时频繁调整Heap的大小，通常-Xms与-Xmx的值设成一样。

由于现在收集器都是采用分代收集算法，堆被划分为新生代和老年代。新生代主要存储新创建的对象和尚未进入老年代的对象。老年代存储经过多次新生代GC(Minor GC)任然存活的对象。

新生代：

程序新创建的对象都是从新生代分配内存，新生代由Eden Space和两块相同大小的Survivor Space(通常又称S0和S1或From和To)构成，可通过-Xmn参数来指定新生代的大小，也可以通过-XX:SurvivorRation来调整Eden Space及Survivor Space的大小。

老年代：

用于存放经过多次新生代GC任然存活的对象，例如缓存对象，新建的对象也有可能直接进入老年代，主要有两种情况：①.大对象，可通过启动参数设置-XX:PretenureSizeThreshold=1024(单位为字节，默认为0)来代表超过多大时就不在新生代分配，而是直接在老年代分配。②.大的数组对象，切数组中无引用外部对象。

老年代所占的内存大小为-Xmx对应的值减去-Xmn对应的值。

5.程序计数器

是最小的一块内存区域，它的作用是当前线程所执行的字节码的行号指示器，在虚拟机的模型里，字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、异常处理、线程恢复等基础功能都需要依赖计数器完成。

2. 堆里面的分区：Eden，survival from to，老年代，各自的特点。

HotSpot虚拟机的分代收集，分为一个Eden区、两个Survivor去以及Old Generation/Tenured区，其中Eden以及Survivor共同组成New Generatiton/Young space。通常将对New Generation进行的回收称为Minor GC;对Old Generation进行的回收称为Major GC，但由于Major GC除并发GC外均需对整个堆以及Permanent Generation进行扫描和回收，因此又称为Full GC。

• Eden区是分配对象的区域。
• Survivor是minor/younger gc后存储存活对象的区域。
• Tenured区域存储长时间存活的对象

1.Eden区

Eden区位于Java堆的年轻代，是新对象分配内存的地方，由于堆是所有线程共享的，因此在堆上分配内存需要加锁。而Sun JDK为提升效率，会为每个新建的线程在Eden上分配一块独立的空间由该线程独享，这块空间称为TLAB（Thread Local Allocation Buffer）。在TLAB上分配内存不需要加锁，因此JVM在给线程中的对象分配内存时会尽量在TLAB上分配。如果对象过大或TLAB用完，则仍然在堆上进行分配。如果Eden区内存也用完了，则会进行一次Minor GC（young GC）。

2.Survival from to

Survival区与Eden区相同都在Java堆的年轻代。Survival区有两块，一块称为from区，另一块为to区，这两个区是相对的，在发生一次Minor GC后，from区就会和to区互换。在发生Minor GC时，Eden区和Survival from区会把一些仍然存活的对象复制进Survival to区，并清除内存。Survival to区会把一些存活得足够旧的对象移至年老代。

3.年老代

年老代里存放的都是存活时间较久的，大小较大的对象，因此年老代使用标记整理算法。当年老代容量满的时候，会触发一次Major GC（full GC），回收年老代和年轻代中不再被使用的对象资源。
3. 对象创建方法，对象的内存分配，对象的访问定位。

Java对象的创建大致上有以下几个步骤：

1. 类加载检查：检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类的加载过程
   
2. 为对象分配内存：对象所需内存的大小在类加载完成后便完全确定，为对象分配空间的任务等同于把一块确定大小的内存从Java堆中划分出来。由于堆被线程共享，因此此过程需要进行同步处理（分配在TLAB上不需要同步）
   
3. 内存空间初始化：虚拟机将分配到的内存空间都初始化为零值（不包括对象头），内存空间初始化保证了对象的实例字段在Java代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值。
   
4. 对象设置：JVM对对象头进行必要的设置，保存一些对象的信息（指明是哪个类的实例，哈希码，GC年龄等）
5. init：执行完上面的4个步骤后，对JVM来说对象已经创建完毕了，但对于Java程序来说，我们还需要对对象进行一些必要的初始化。

对象的内存分配

Java对象的内存分配有两种情况，由Java堆是否规整来决定（Java堆是否规整由所采用的垃圾收集器是否带有压缩整理功能决定）：

1. 指针碰撞(Bump the pointer)：如果Java堆中的内存是规整的，所有用过的内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，分配内存也就是把指针向空闲空间那边移动一段与内存大小相等的距离
   
2. 空闲列表(Free List)：如果Java堆中的内存不是规整的，已使用的内存和空闲的内存相互交错，就没有办法简单的进行指针碰撞了。虚拟机必须维护一张列表，记录哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录

对象的访问定位

对象的访问形式取决于虚拟机的实现，目前主流的访问方式有使用句柄和直接指针两种：

使用句柄：

如果使用句柄访问，Java堆中将会划分出一块内存来作为句柄池，引用中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自的具体地址信息：

优势：引用中存储的是稳定的句柄地址，在对象被移动(垃圾收集时移动对象是非常普遍的行为)时只会改变句柄中的实例数据指针，而引用本身不需要修改。

直接指针：

如果使用直接指针访问对象，那么对象的实例数据中就包含一个指向对象类型数据的指针，引用中存的直接就是对象的地址：

优势：速度更快，节省了一次指针定位的时间开销，积少成多的效应非常可观。

4. GC的两种判定方法：引用计数与引用链。

基于引用计数与基于引用链这两大类别的自动内存管理方式最大的不同之处在于：前者只需要局部信息，而后者需要全局信息

引用计数

引用计数顾名思义，就是记录下一个对象被引用指向的次数。引用计数方式最基本的形态就是让每个被管理的对象与一个引用计数器关联在一起，该计数器记录着该对象当前被引用的次数，每当创建一个新的引用指向该对象时其计数器就加1，每当指向该对象的引用失效时计数器就减1。当该计数器的值降到0就认为对象死亡。每个计数器只记录了其对应对象的局部信息——被引用的次数，而没有（也不需要）一份全局的对象图的生死信息。由于只维护局部信息，所以不需要扫描全局对象图就可以识别并释放死对象；但也因为缺乏全局对象图信息，所以无法处理循环引用的状况。

引用链

引用链需要内存的全局信息，当使用引用链进行GC时，从对象图的“根”（GC Root，必然是活的引用，包括栈中的引用，类静态属性的引用，常量的引用，JNI的引用等）出发扫描出去，基于引用的可到达性算法来判断对象的生死。这使得对象的生死状态能批量的被识别出来，然后批量释放死对象。引用链不需要显式维护对象的引用计数，只在GC使用可达性算法遍历全局信息的时候判断对象是否被引用，是否存活。

5. GC的三种收集方法：标记清除、标记整理、复制算法的原理与特点，分别用在什么地方，如果让你优化收集方法，有什么思路？

标记清除

标记清除算法分两步执行：

1. 暂停用户线程，通过GC Root使用可达性算法标记存活对象
2. 清除未被标记的垃圾对象

标记清除算法缺点如下：

1. 效率较低，需要暂停用户线程
2. 清除垃圾对象后内存空间不连续，存在较多内存碎片

标记算法如今使用的较少了

复制算法

复制算法也分两步执行，在复制算法中一般会有至少两片的内存空间（一片是活动空间，里面含有各种对象，另一片是空闲空间，里面是空的）：

1. 暂停用户线程，标记活动空间的存活对象
2. 把活动空间的存活对象复制到空闲空间去，清除活动空间

复制算法相比标记清除算法，优势在于其垃圾回收后的内存是连续的。

但是复制算法的缺点也很明显：

1. 需要浪费一定的内存作为空闲空间
2. 如果对象的存活率很高，则需要复制大量存活对象，导致效率低下

复制算法一般用于年轻代的Minor GC，主要是因为年轻代的大部分对象存活率都较低

标记整理

标记整理算法是标记清除算法的改进，分为标记、整理两步：

1. 暂停用户线程，标记所有存活对象
2. 移动所有存活对象，按内存地址次序一次排列，回收末端对象以后的内存空间

标记整理算法与标记清除算法相比，整理出的内存是连续的；而与复制算法相比，不需要多片内存空间。

然而标记整理算法的第二步整理过程较为麻烦，需要整理存活对象的引用地址，理论上来说效率要低于复制算法。

因此标记整理算法一般引用于老年代的Major GC

参考博文：Java虚拟机学习（2）：垃圾收集算法

6. GC收集器有哪些？CMS收集器与G1收集器的特点？

常见的GC收集器如下图所示，连线代表可搭配使用：

1.Serial收集器（串行收集器）

用于新生代的单线程收集器，收集时需要暂停所有工作线程（Stop the world）。优点在于：简单高效，单个CPU时没有线程交互的开销，堆较小时停顿时间不长。常与Serial Old 收集器一起使用，示意图如下所示：

2.ParNew收集器（parallel new 收集器，新生代并行收集器）

Serial收集器多线程版本，除了使用多线程外和Serial收集器一模一样。常与Serial Old 收集器一起使用，示意图如下：

3.Parallel Scavenge收集器

与ParNew收集器一样是一款多线程收集器，其特点在于关注点与别的GC收集器不同：一般的GC收集器关注于缩短工作线程暂停的时间，而该收集器关注于吞吐量，因此也被称为吞吐量优先收集器。（吞吐量 = 用户运行代码时间 /  (用户运行代码时间 + 垃圾回收时间)）高吞吐量与停顿时间短相比主要强调任务快完成，因此常和Parallel Old 收集器一起使用（没有Parallel Old之前与Serial Old一起使用），示意图如下：

4.Serial Old收集器

Serial收集器的年老代版本，不在赘述。

5.Parallel Old收集器

年老代的并行收集器，在JDK1.6开始使用。

6.CMS收集器（Concurrent Mark Sweep，并发标记清除收集器）

CMS收集器是一个年老代的收集器，是以最短回收停顿时间为目标的收集器，其示意图如下所示：

CMS收集器基于标记清除算法实现，主要分为4个步骤：

1. 初始标记，需要stop the world，标记GC Root能关联到的对象，速度快
2. 并发标记，对GC Root执行可达性算法
3. 重新标记，需要stop the world，修复并发标记时因用户线程运行而产生的标记变化，所需时间比初始标记长，但远比并发标记短
4. 并发清理

CMS收集器的缺点在于：

1. 其对于CPU资源很敏感。在并发阶段，虽然CMS收集器不会暂停用户线程，但是会因为占用了一部分CPU资源而导致应用程序变慢，总吞吐量降低。其默认启动的回收线程数是（cpu数量+3）/4，当cpu数较少的时候，会分掉大部分的cpu去执行收集器线程
2. 无法处理浮动垃圾，浮动垃圾即在并发清除阶段因为是并发执行，还会产生垃圾，这一部分垃圾即为浮动垃圾，要等下次收集
   
3. CMS收集器使用的是标记清除算法，GC后会产生碎片
   

7.G1收集器（Garbage First收集器）

相比CMS收集器，G1收集器主要有两处改进：

1. 使用标记整理算法，确保GC后不会产生内存碎片
2. 可以精确控制停顿，允许指定消耗在垃圾回收上的时间

G1收集器可以实现在基本不牺牲吞吐量的前提下完成低停顿的内存回收，这是由于它能够极力地避免全区域的垃圾收集，之前的收集器进行收集的范围都是整个新生代或老年代，而G1将整个Java堆（包括新生代、老年代）划分为多个大小固定的独立区域（Region），并且跟踪这些区域里面的垃圾堆积程度，在后台维护一个优先列表，每次根据允许的收集时间，优先回收垃圾最多的区域（这就是Garbage First名称的来由）。区域划分及有优先级的区域回收，保证了G1收集器在有限的时间内可以获得最高的收集效率。

7. Minor GC与Full GC分别在什么时候发生？

Minor GC也叫Young GC，当年轻代内存满的时候会触发，会对年轻代进行GC

Full GC也叫Major GC，当年老代满的时候会触发，当我们调用System.gc时也可能会触发，会对年轻代和年老代进行GC

9. 类加载的五个过程：加载、验证、准备、解析、初始化。

JVM把class文件加载的内存，并对数据进行校验、转换解析和初始化，最终形成JVM可以直接使用的Java类型的过程就是加载机制。
类从被加载到虚拟机内存中开始，到卸载出内存为止，它的生命周期包括了：加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)、卸载(Unloading)七个阶段，其中验证、准备、解析三个部分统称链接。

1.加载

在加载阶段，虚拟机需要完成以下事情：

1. 通过一个类的权限定名来获取定义此类的二进制字节流
   
2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
   
3. 在java堆中生成一个代表这个类的java.lang.Class对象，作为方法去这些数据的访问入口
   

2.验证

在验证阶段，虚拟机主要完成：

1. 文件格式验证：验证class文件格式规范
   
2. 元数据验证：这个阶段是对字节码描述的信息进行语义分析，以保证起描述的信息符合java语言规范要求
   
3. 字节码验证：进行数据流和控制流分析，这个阶段对类的方法体进行校验分析，这个阶段的任务是保证被校验类的方法在运行时不会做出危害虚拟机安全的行为
   
4. 符号引用验证：符号引用中通过字符串描述的全限定名是否能找到对应的类、符号引用类中的类，字段和方法的访问性(private、protected、public、default)是否可被当前类访问
   

3.准备

准备阶段是正式为类变量（被static修饰的变量）分配内存并设置变量初始值（0值）的阶段，这些内存都将在方法区中进行分配

4.解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程

常见的解析有四种：

1. 类或接口的解析
   
2. 字段解析
   
3. 类方法解析
   
4. 接口方法解析

5.初始化

初始化阶段才真正开始执行类中定义的java程序代码，初始化阶段是执行类构造器<clinit>()方法的过程

参考博文：Java虚拟机学习（3）： 类加载机制

10. 双亲委派模型：Bootstrap ClassLoader、Extension ClassLoader、ApplicationClassLoader

上图中所展示的类加载器之间的这种层次关系，就称为类加载器的双亲委托模型。双亲委托模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承的关系来实现，而是使用组合关系来复用父加载器的代码。

public abstract class ClassLoader { 
 
    privatestatic nativevoid registerNatives(); 
    static{ 
        registerNatives(); 
    } 
 
    // The parent class loader for delegation 
    privateClassLoader parent; 
 
    // Hashtable that maps packages to certs 
    privateHashtable package2certs = newHashtable(11); 

双亲委托的工作过程：如果一个类加载器收到了一个类加载请求，它首先不会自己去加载这个类，而是把这个请求委托给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父类加载器反馈自己无法完成加载请求(它管理的范围之中没有这个类)时，子加载器才会尝试着自己去加载。

使用双亲委托模型来组织类加载器之间的关系，有一个显而易见的好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系，例如java.lang.Object存放在rt.jar之中，无论那个类加载器要加载这个类，最终都是委托给启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类，相反，如果没有双亲委托模型，由各个类加载器去完成的话，如果用户自己写一个名为java.lang.Object的类，并放在classpath中，应用程序中可能会出现多个不同的Object类，java类型体系中最基本安全行为也就无法保证。

分派：静态分派与动态分派

静态分派

所有依赖静态类型来定位方法执行版本的分派动作称为静态分派，其典型应用是方法重载（重载是通过参数的静态类型而不是实际类型来选择重载的版本的）

    class Car {}  
    class Bus extends Car {}  
    class Jeep extends Car {}  
    public class Main {  
        public static void main(String[] args) throws Exception {  
            // Car 为静态类型，Car 为实际类型  
            Car car1 = new Car();  
            // Car 为静态类型，Bus 为实际类型  
            Car car2 = new Bus();  
            // Car 为静态类型，Jeep 为实际类型  
            Car car3 = new Jeep();  
              
            showCar(car1);  
            showCar(car2);  
            showCar(car3);  
        }  
        private static void showCar(Car car) {  
            System.out.println("I have a Car !");  
        }  
        private static void showCar(Bus bus) {  
            System.out.println("I have a Bus !");  
        }  
        private static void showCar(Jeep jeep) {  
            System.out.println("I have a Jeep !");  
        }  
    }  

结果

动态分派

与静态分派类似，动态分派指在在运行期根据实际类型确定方法执行版本，其典型应用是方法重写（即多态）。

举例Java代码如下：

    class Car {  
        public void showCar() {  
            System.out.println("I have a Car !");  
        }  
    }  
    class Bus extends Car {  
        public void showCar() {  
            System.out.println("I have a Bus !");  
        }  
    }  
    class Jeep extends Car {  
        public void showCar() {  
            System.out.println("I have a Jeep !");  
        }  
    }  
    public class Main {  
        public static void main(String[] args) throws Exception {  
            // Car 为静态类型，Car 为实际类型  
            Car car1 = new Car();  
            // Car 为静态类型，Bus 为实际类型  
            Car car2 = new Bus();  
            // Car 为静态类型，Jeep 为实际类型  
            Car car3 = new Jeep();  
              
            car1.showCar();  
            car2.showCar();  
            car3.showCar();  
        }  
    }  

可以看出来重写是一个根据实际类型决定方法版本的动态分派过程。

参考链接： http://www.importnew.com/20438.html