请你说说BIO、NIO、AIO
UNIX 系统下， IO 模型一共有 5 种： 同步阻塞 I/O、同步非阻塞 I/O、I/O 多路复用、信号驱动 I/O 和异步 I/O。
BIO 属于同步阻塞 IO 模型 。同步阻塞 IO 模型中，应用程序发起 read 调用后，会一直阻塞，直到内核把数据拷贝到用户空间。
NIO (Non-blocking/New I/O) ，Java 中的 NIO 于 Java 1.4 中引入，对应 java.nio 包，提供了 Channel , Selector，Buffer 等抽象。NIO 中的 N 可以理解为 Non-blocking，不单纯是 New。它是支持面向缓冲的，基于通道的 I/O 操作方法。 对于高负载、高并发的（网络）应用，应使用 NIO 。
Java 中的 NIO 可以看作是 I/O 多路复用模型。也有很多人认为，Java 中的 NIO 属于同步非阻塞 IO 模型。用户线程发送请求后，可以做其他工作，应用程序不断进行 I/O 系统调用轮询数据是否已经准备好（的过程是十分消耗 CPU 资源的）。 但在数据复制阶段，用户线程依然属于阻塞状态。
IO 多路复用模型中，线程首先发起 select 调用，询问内核数据是否准备就绪，等内核把数据准备好了，用户线程再发起 read 调用。read 调用的过程（数据从内核空间 -> 用户空间）还是阻塞的。
AIO (Asynchronous I/O) ，AIO 也就是 NIO 2。Java 7 中引入了 NIO 的改进版 NIO 2,它是异步 IO 模型。异步 IO 是基于事件和回调机制实现的，也就是应用操作之后会直接返回，不会堵塞在那里，当后台处理完成，操作系统会通知相应的线程进行后续的操作。
52、说说NIO
得分点 Buffer、Channel、Selector
新的输入/输出（NIO）库是在JDK 1.4中引入的。NIO弥补了原来同步阻塞I/O的不足,它在标准Java代码中提供了高速的、面向块的I/O。通过定义包含数据的类,以及通过以块的形式处理这些数据。NIO包含三个核心的组件：Buffer（缓冲区）、Channel（通道）、Selector（多路复用器）。 Buffer是一个对象,它包含一些要写入或者要读出的数据。在NIO类库中加入Buffer对象,体现了新库与原I/O的一个重要区别。在面向流的I/O中,可以将数据直接写入或者将数据直接读到Stream对象中。在NIO库中,所有数据都是用缓冲区处理的。在读取数据时,它是直接读到缓冲区中的。在写入数据时,写入到缓冲区中。任何时候访问NIO中的数据,都是通过缓冲区进行操作。 Channel是一个通道,可以通过它读取和写入数据,它就像自来水管一样,网络数据通过Channel读取和写入。通道与流的不同之处在于通道是双向的,流只是在一个方向上移动而且通道可以用于读、写或者同时用于读写。因为Channel是全双工的,所以它可以比流更好地映射底层操作系统的API。特别是在UNIX网络编程模型中,底层操作系统的通道都是全双工的,同时支持读写操作。 Selector会不断地轮询注册在其上的Channel,如果某个Channel上面有新的TCP连接接入、读和写事件,这个Channel就处于就绪状态,会被Selector轮询出来,然后通过SelectionKey可以获取就绪Channel的集合,进行后续的I/O操作。一个多路复用器Selector可以同时轮询多个Channel,由于JDK使用了epoll()代替传统的select实现,所以它并没有最大连接句柄1024/2048的限制。这也就意味着只需要一个线程负责Selector的轮询,就可以接入成千上万的客户端,这确实是个非常巨大的进步。
加分回答 Java 7的NIO2提供了异步Channel支持,这种异步Channel可以提供更高效的IO,这种基于异步Channel的IO机制也被称为异步IO（AsynchronousIO）。NIO2为O提供了两个接口和三个实现类,其中AsynchronousSocketChannel和AsynchronousServerSocketChannel是支持TCP通信的异步Channel。
请你说说IO多路复用（select、poll、epoll）
得分点 概念、select、poll、epoll
I/O 多路复用是一种使得程序能同时监听多个文件描述符的技术,从而提高程序的性能。I/O 多路复用能够在单个线程中,通过监视多个 I/O 流的状态来同时管理多个 I/O 流,一旦检测到某个文件描述符上我们关心的事件发生（就绪）,能够通知程序进行相应的处理（读写操作）。 Linux 下实现 I/O 复用的系统调用主要有 select、poll 和 epoll。
select 的主旨思想： - 首先要构造一个关于文件描述符的列表,将要监听的文件描述符添加到该列表中,这个文件描述符的列表数据类型为 fd_set,它是一个整型数组,总共是 1024 个比特位,每一个比特位代表一个文件描述符的状态。比如当需要 select 检测时,这一位为 0 就表示不检测对应的文件描述符的事件,为 1 表示检测对应的文件描述符的事件。 - 调用 select() 系统调用,监听该列表中的文件描述符的事件,这个函数是阻塞的,直到这些描述符中的一个或者多个进行 I/O 操作时,该函数才返回,并修改文件描述符的列表中对应的值,0 表示没有检测到该事件,1 表示检测到该事件。函数对文件描述符的检测的操作是由内核完成的。 - select() 返回时,会告诉进程有多少描述符要进行 I/O 操作,接下来遍历文件描述符的列表进行 I/O 操作。
select 的缺点： 1. 每次调用select,都需要把 fd 集合从用户态拷贝到内核态,这个开销在 fd 很多时会很大； 2. 同时每次调用 select 都需要在内核遍历传递进来的所有 fd,这个开销在 fd 很多时也很大； 3. select 支持的文件描述符数量太小了,默认是 1024（由 fd_set 决定）； 4. 文件描述符集合不能重用,因为内核每次检测到事件都会修改,所以每次都需要重置； 5. 每次 select 返回后,只能知道有几个 fd 发生了事件,但是具体哪几个还需要遍历文件描述符集合进一步判断。
poll 的原理和 select 类似,poll 支持的文件描述符没有限制。
epoll如下题
select，poll，epoll都是IO多路复用的机制。I/O多路复用就是通过一种机制，一个进程可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。但select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间。
select
int select (int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
select 函数监视的文件描述符分3类，分别是writefds、readfds、和exceptfds。调用后select函数会阻塞，直到有描述符就绪（有数据 可读、可写、或者有except），或者超时（timeout指定等待时间，如果立即返回设为null即可），函数返回。当select函数返回后，可以 通过遍历fdset，来找到就绪的描述符。
select目前几乎在所有的平台上支持，其良好跨平台支持也是它的一个优点。select的一 个缺点在于单个进程能够监视的文件描述符的数量存在最大限制，在Linux上一般为1024，可以通过修改宏定义甚至重新编译内核的方式提升这一限制，但 是这样也会造成效率的降低。
poll
int poll (struct pollfd *fds, unsigned int nfds, int timeout);
不同与select使用三个位图来表示三个fdset的方式，poll使用一个 pollfd的指针实现。
struct pollfd {
int fd; /* file descriptor */
short events; /* requested events to watch */
short revents; /* returned events witnessed */
};
pollfd结构包含了要监视的event和发生的event，不再使用select“参数-值”传递的方式。同时，pollfd并没有最大数量限制（但是数量过大后性能也是会下降）。 和select函数一样，poll返回后，需要轮询pollfd来获取就绪的描述符。
从上面看，select和poll都需要在返回后，
通过遍历文件描述符来获取已经就绪的socket。事实上，同时连接的大量客户端在一时刻可能只有很少的处于就绪状态，因此随着监视的描述符数量的增长，其效率也会线性下降。
epoll
相对于select和poll来说，epoll更加灵活，没有描述符限制。epoll使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需一次。
int epoll_create(int size)；//创建一个epoll的句柄，size用来告诉内核这个监听的数目一共有多大
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)；
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);
epoll原理
得分点 epoll_create、epoll_ctrl、epoll_wt、红黑树、双向链表、epoll的两种工作模式
epoll 是一种更加高效的 IO 复用技术,epoll 的使用步骤及原理如下：
- 调用
epoll_create()会在内核中创建一个eventpoll结构体数据,称之为epoll对象,在这个结构体中有 2 个比较重要的数据成员,一个是需要检测的文件描述符的信息struct_root rbr（红黑树）,还有一个是就绪列表struct list_head rdlist,存放检测到数据发送改变的文件描述符信息（双向链表）； - 调用
epoll_ctrl()可以向epoll对象中添加、删除、修改要监听的文件描述符及事件； - 调用
epoll_wt()可以让内核去检测就绪的事件,并将就绪的事件放到就绪列表中并返回,通过返回的事件数组做进一步的事件处理。
epoll 的两种工作模式：
LT模式（水平触发）LT（Level - Triggered）是缺省的工作方式,并且同时支持Block和Nonblock Socket。在这种做法中,内核检测到一个文件描述符就绪了,然后可以对这个就绪的fd进行IO操作,如果不作任何操作,内核还是会继续通知。ET模式（边沿触发）ET（Edge - Triggered）是高速工作方式,只支持Nonblock socket。在这种模式下,当描述符从未就绪变为就绪时,内核通过 epoll 检测到。然后它会假设你知道文件描述符已经就绪,并且不会再为那个文件描述符发送更多的就绪通知,直到你做了某些操作导致那个文件描述符不再为就绪状态了。但是请注意,如果一直不对这个fd进行IO操作（从而导致它再次变成未就绪）,内核不会发送更多的通知（only once）。ET模式在很大程度上减少了 epoll 事件被重复触发的次数,因此效率要比LT模式高。epoll工作在ET模式的时候,必须使用非阻塞套接口,以避免由于一个文件描述符的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。
补：线程和进程的区别
1.进程有【独立的地址空间】，线程有自己的堆栈和局部变量，但是线程之间没有单独的地址空间
2.进程和线程切换时，需要切换进程和线程的上下文，【进程的上下文切换时间开销】远远大于【线程上下文切换时间】，耗费资源较大，效率要差一些
3.【进程的并发性较低，线程的并发性较高】 4.每个独立的进程有一个程序运行的入口，顺序执行序列和程序的出口，线程不能独立执行
5.系统在运行的时候会为【每个进程分配不同的内存空间】，对线程而言，除CPU外，系统不会为线程分配内存
6.一个【进程奔溃后】，在保护模式下不会对其他进程产生影响，但是一个线程奔溃后整个进程都会死掉，所以多进程比多线程更健壮。 ①进程是一个“执行中的程序”,是系统进行资源分配和调度独立单位； ②线程是进程的一个实体，一个进程中拥有多个线程，线程之间共享地址空间和其他资源； ③与进程不同的是同类的多个线程共享进程的堆和方法区资源，但每个线程有自己的程序计数器、虚拟机栈和本地方法栈，所以系统在产生一个线程，或是在各个线程之间作切换工作时，负担要比进程小得多，也正因为如此，线程也被称为轻量级进程。
协程是线程的抽象单位，减少了线程切换过程中的资源代价
1、简单说下你对JVM的了解
得分点 跨平台、HotSpot、内存模型
JVM是Java语言跨平台的关键,Java在虚拟机层面隐藏了底层技术的复杂性以及机器与操作系统的差异性。运行程序的物理机千差万别,而JVM则在千差万别的物理机上面建立了统一的运行平台,实现了在任意一台JVM上编译的程序,都能在任何其他JVM上正常运行。这一极大的优势使得Java应用的开发比传统C/C++应用的开发更高效快捷,程序员可以把主要精力放在具体业务逻辑,而不是放在保障物理硬件的兼容性上。JVM会在用户不知不觉中完成对硬件平台的兼容及对内存等资源的管理工作。 HotSpot是Sun/OracleJDK和OpenJDK中的默认Java虚拟机,也是目前使用范围最广的Java虚拟机。HotSpot既继承了Sun之前两款商用虚拟机的优点,也有许多自己新的技术优势,如它名称中的HotSpot指的就是它的热点代码探测技术。HotSpot的热点代码探测能力可以通过执行计数器找出最具有编译价值的代码,然后通知即时编译器以方法为单位进行编译。如果一个方法被频繁调用,或方法中有效循环次数很多,将会分别触发标准即时编译和栈上替换编译行为。通过编译器与解释器恰当地协同工作,可以在最优化的程序响应时间与最佳执行性能中取得平衡,而且无须等待本地代码输出才能执行程序,即时编译的时间压力也相对减小,这样有助于引入更复杂的代码优化技术,输出质量更高的本地代码。 JVM由三部分组成：类加载子系统、执行引擎、运行时数据区。 1. 类加载子系统,可以根据指定的全限定名来载入类或接口。 2. 执行引擎,负责执行那些包含在被载入类的方法中的指令。 3. 当程序运行时,JVM需要内存来存储许多内容,例如：字节码、对象、参数、返回值、局部变量、运算的中间结果,等等,JVM会把这些东西都存储到运行时数据区中,以便于管理。而运行时数据区又可以分为方法区、堆、虚拟机栈、本地方法栈、程序计数器。
2、说说Java运行时数据区
得分点 程序计数器、虚拟机栈、本地方法栈、堆、方法区
程序计数器
程序计数器是一块较小的内存空间,它可以看作是当前线程所执行的字节码的行号指示器。在Java虚拟机的概念模型里,字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令,它是程序控制流的指示器,分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。 由于Java虚拟机的多线程是通过线程轮流切换、分配处理器执行时间的方式来实现的,在任何一个确定的时刻,一个处理器都只会执行一条线程中的指令。因此,为了线程切换后能恢复到正确的执行位置,每条线程都需要有一个独立的程序计数器,各条线程之间计数器互不影响,独立存储,我们称这类内存区域为“线程私有”的内存。
虚拟机栈
虚拟机栈也是线程私有的,它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的线程内存模型：每个方法被执行的时候,Java虚拟机都会同步创建一个栈帧用于存储局部变量表、操作数栈、动态连接、方法出口等信息。每一个方法被调用直至执行完毕的过程,就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。其中,栈通常就是指这里讲的虚拟机栈,或者更多的情况下只是指虚拟机栈中局部变量表部分。 在Java虚拟机规范中,对这个内存区域规定了两类异常状况：如果线程请求的栈深度大于虚拟机所允许的深度,将抛出StackOverflowError异常。如果Java虚拟机栈容量可以动态扩展,当栈扩展时无法申请到足够的内存会抛出OutOfMemoryError异常。
本地方法栈
本地方法栈与虚拟机栈所发挥的作用是非常相似的,其区别只是虚拟机栈为虚拟机执行Java方法服务,而本地方法栈则是为虚拟机使用到的本地方法服务。 Java虚拟机规范对本地方法栈中方法使用的语言、使用方式与数据结构并没有任何强制规定,因此具体的虚拟机可以根据需要自由实现它,甚至有的Java虚拟机直接就把本地方法栈和虚拟机栈合二为一。 与虚拟机栈一样,本地方法栈也会在栈深度溢出或者栈扩展失败时分别抛出StackOverflowError和OutOfMemoryError异常。
堆
堆是虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域,在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例,Java世界里“几乎”所有的对象实例都在这里分配内存。堆是垃圾收集器管理的内存区域,因此一些资料中它也被称作“GC堆”。 堆既可以被实现成固定大小的,也可以是可扩展的,不过当前主流的Java虚拟机都是按照可扩展来实现的。如果在Java堆中没有内存完成实例分配,并且堆也无法再扩展时,JVM将会抛出OutOfMemoryError异常。
方法区
方法区与堆一样,是各个线程共享的内存区域,它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。虽然Java虚拟机规范中把方法区描述为堆的一个逻辑部分,但是它却有一个别名叫作“非堆”,目的是与堆区分开来。 运行时常量池是方法区的一部分。Class文件中除了有类的版本、字段、方法、接口等描述信息外,还有一项信息是常量池表,用于存放编译期生成的各种字面量与符号引用。 根据Java虚拟机规范的规定,如果方法区无法满足新的内存分配需求时,将抛出OutOfMemoryError异常。
3、说说JVM的垃圾回收机制
得分点 新生代收集、老年代收集、混合收集、整堆收集
垃圾回收通常有三件事情要做，第一将决定哪些对象要回收，jvm决定了将未被引用的对象占用空间回收，通常用引用计数法或者可达性分析法，后者是jvm主流使用方法. 第二什么时候回收JVM，通常在内存不够用时，或定期回收， 第三用什么方式回收。有分代回收，分区域回收法
当前商业虚拟机的垃圾收集器,大多数都遵循了“分代收集”的理论进行设计,分代收集名为理论,实质是一套符合大多数程序运行实际情况的经验法则。而分代收集理论,建立在如下三个分代假说之上,即弱分代假说、强分代假说、跨代引用假说。依据分代假说理论,垃圾回收可以分为如下几类： 1. 新生代收集：目标为新生代的垃圾收集。 2. 老年代收集：目标为老年代的垃圾收集,目前只有CMS收集器会有这种行为。 3. 混合收集：目标为整个新生代及部分老年代的垃圾收集,目前只有G1收集器会有这种行为。 4. 整堆收集：目标为整个堆和方法区的垃圾收集。
加分回答 HotSpot虚拟机内置了很多垃圾收集器,其中针对新生代的垃圾收集器有Serial、ParNew、Parallel Scavenge,针对老年代的垃圾收集器有CMS、Serial Old、Parallel Old。此外,HotSpot还内置了面向整堆的G1收集器。在上述收集器中,常见的组合方式有： 1. Serial + Serial Old,是客户端模式下常用的收集器。 2. ParNew + CMS,是服务端模式下常用的收集器。 3. Parallel Scavenge + Parallel Old,适用于后台运算而不需要太多交互的分析任务。
4、说说JVM的垃圾回收算法
常用的垃圾回收算法有：标记清除算法、标记复制算法、标记整理算法。
标记清除算法
算法分为“标记”和“清除”两个阶段,首先标记出所有需要回收的对象,在标记完成后,统一回收掉所有被标记的对象,也可以反过来,标记存活的对象,统一回收所有未被标记的对象。
它主要有如下两个缺点： 第一个是执行效率不稳定,如果Java堆中包含大量对象,而且其中大部分是需要被回收的,这时必须进行大量标记和清除的动作,导致标记和清除两个过程的执行效率都随对象数量增长而降低。 第二个是内存空间碎片化问题,标记、清除之后会产生大量不连续的内存碎片,空间碎片太多可能会导致当程序在运行过程中需要分配较大对象时无法找到足够的连续的内存而不得不提前触发另一次垃圾收集。
标记复制算法
将可用内存按容量划分为大小相等的两块,每次只使用其中的一块。当这一块的内存用完了,就将还存活着的对象复制到另外一块上面,然后再把已使用过的内存空间一次清理掉。 对于多数对象都是可回收的情况,算法需要复制的就是占少数的存活对象,而且每次都是针对整个半区进行内存回收,分配内存时也就不用考虑有空间碎片的复杂情况,只要移动堆顶指针,按顺序分配即可。 这种复制回收算法的代价是将可用内存缩小为了原来的一半,空间浪费未免太多了一点。另外,如果内存中多数对象都是存活的,这种算法将会产生大量的内存间复制的开销。所以,现在的商用Java虚拟机大多都优先采用了这种收集算法去回收新生代。
标记整理算法
其中的标记过程仍然与“标记-清除”算法一样,但后续步骤不是直接对可回收对象进行清理,而是让所有存活的对象都向内存空间一端移动,然后直接清理掉边界以外的内存。 如果移动存活对象,尤其是在老年代这种每次回收都有大量对象存活区域,移动存活对象并更新所有引用这些对象的地方将会是一种极为负重的操作,而且这种对象移动操作必须全程暂停用户应用程序才能进行,像这样的停顿被最初的虚拟机设计者形象地描述为“Stop The World”
加分回答
目前,新生代的垃圾回收采用标记复制算法比较多,老年代的垃圾回收采用标记整理算法比较多。而标记复制算法浪费一半内存的缺点长期以来被人诟病,所以业界也有人针对该算法给出了改进的方案。 IBM公司曾有一项专门研究对新生代“朝生夕灭”的特点做了更量化的诠释——新生代中的对象有98%熬不过第一轮收集。因此并不需要按照1∶1的比例来划分新生代的内存空间。在1989年,Andrew Appel针对具备“朝生夕灭”特点的对象,提出了一种更优化的半区复制分代策略,现在称为“Appel式回收”。 Appel式回收的具体做法是把新生代分为一块较大的Eden空间和两块较小的Survivor空间,每次分配内存只使用Eden和其中一块Survivor。发生垃圾搜集时,将Eden和Survivor中仍然存活的对象一次性复制到另外一块Survivor空间上,然后直接清理掉Eden和已用过的那块Survivor空间。 HotSpot虚拟机的Serial、ParNew等新生代收集器均采用了这种策略来设计新生代的内存布局。HotSpot虚拟机默认Eden和Survivor的大小比例是8:1:1,也即每次新生代中可用内存空间为整个新生代容量的90%（Eden的80%加上一个Survivor的10%）,只有一个Survivor空间,即10%的新生代是会被“浪费”的。 98%的对象可被回收仅仅是“普通场景”下测得的数据,任何人都没有办法百分百保证每次回收都只有不多于10%的对象存活,因此Appel式回收还有一个充当罕见情况的“逃生门”的安全设计,当Survivor空间不足以容纳一次Minor GC之后存活的对象时,就需要依赖其他内存区域（实际上大多就是老年代）进行分配担保。
5、说说GC的可达性分析
得分点 GC Roots、引用链
当前主流的商用程序语言的内存管理子系统，都是通过可达性分析算法来判定对象是否存活的。这个算法的基本思路就是通过一系列称为“GC Roots”的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径称为“引用链”，如果某个对象到GC Roots间没有任何引用链相连，或者用图论的话来说就是从GC Roots到这个对象不可达时，则证明此对象是不可能再被使用的。
在Java技术体系里面，固定可作为GC Roots的对象包括以下几种：
- 在虚拟机栈中引用的对象，譬如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等；
- 在方法区中类静态属性引用的对象，譬如
Java类的引用类型静态变量； - 在方法区中常量引用的对象，譬如字符串常量池里的引用；
- 在本地方法栈中引用的对象；
JVM内部的引用，如基本数据类型对应的Class对象，常驻的异常对象，以及系统类加载器；- 所有被同步锁持有的对象；
- 反映Java虚拟机内部情况的
JMXBean、JVMTI中注册的回调、本地代码缓存等。
加分回答 真正宣告一个对象死亡，至少要经历两次标记过程：
- 第一次标记 如果对象在进行可达性分析后发现没有与
GC Roots相连接的引用链，那它将会被第一次标记，随后进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。假如对象没有覆盖finalize()方法，或者**finalize()方法已经被虚拟机调用过**，那么虚拟机将这两种情况都视为“没有必要执行”。反之，该对象将会被放置在一个名为F-Queue的队列之中，并在稍后由一条由虚拟机自动建立的、低调度优先级的Finalizer线程去执行它们的finalize()方法。 - 第二次标记 稍后，收集器将对
F-Queue中的对象进行第二次小规模的标记。如果对象要在finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可，譬如把自己（this）赋值给某个类变量或者对象的成员变量，那在第二次标记时它将被移出“即将回收”的集合。如果对象这时候还没有逃脱，那基本上它就真的要被回收了。finalize()方法是对象逃脱死亡命运的最后一次机会，需要注意的是，任何一个对象的finalize()方法都只会被系统自动调用一次，如果对象面临下一次回收，它的finalize()方法不会被再次执行。另外，finalize()方法的运行代价高昂，不确定性大，无法保证各个对象的调用顺序，如今已被官方明确声明为不推荐使用的语法。
6、请你说说Java的四种引用方式
得分点 强引用、软引用、弱引用、虚引用
在JDK 1.2版之后,Java对引用的概念进行了扩充,将引用分为分为强引用、软引用、弱引用、虚引用4种,这4种引用强度依次逐渐减弱。
强引用是最传统的“引用”的定义,是指在程序代码之中普遍存在的引用赋值,即类似“Object obj=new Object()”这种引用关系。无论任何情况下,只要强引用关系还存在,垃圾收集器就永远不会回收掉被引用的对象。
软引用是用来描述一些还有用,但非必须的对象。只被软引用关联着的对象,在系统将要发生内存溢出异常前,会把这些对象列进回收范围之中进行第二次回收,如果这次回收还没有足够的内存,才会抛出内存溢出异常。
弱引用也是用来描述那些非必须的对象,但是它的强度比软引用更弱一些,被弱引用关联的对象只能生存到下一次垃圾收集发生为止。当垃圾收集器开始工作,无论当前内存是否足够,都会回收掉只被弱引用关联的对象。
虚引用是最弱的一种引用关系。一个对象是否有虚引用的存在,完全不会对其生存时间构成影响,也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的只是为了能在这个对象被收集器回收时收到一个系统通知。
终结器引用（FinalReference）
7、请你讲下CMS垃圾回收器
得分点 老年代、低停顿、标记清除、四个步骤
CMS收集器是一种以获取最短回收停顿时间为目标的收集器,从名字上就可以看出CMS收集器是基于标记清除算法实现的,它的运作过程相对于前面几种收集器来说要更复杂一些,整个过程分为四个步骤,包括：初始标记、并发标记、重新标记、并发清除。其中初始标记、重新标记这两个步骤仍然需要“Stop The World” 。
- 初始标记仅仅只是标记一下
GC Roots能直接关联到的对象,速度很快。 - 并发标记阶段就是从
GC Roots的直接关联对象开始遍历整个对象图的过程,这个过程耗时较长但是不需要停顿用户线程,可以与垃圾收集线程一起并发运行。 - 重新标记阶段则是为了修正并发标记期间,因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录,这个阶段的停顿时间通常会比初始标记阶段稍长一些,但也远比并发标记阶段的时间短。
- 并发清除阶段,清理删除掉标记阶段判断的已经死亡的对象,由于不需要移动存活对象,所以这个阶段也是可以与用户线程同时并发的。
加分回答 CMS是一款优秀的收集器,它最主要的优点在名字上已经体现出来：并发收集、低停顿,一些官方公开文档里面也称之为“并发低停顿收集器”。CMS收集器是HotSpot虚拟机追求低停顿的第一次成功尝试,但是它还远达不到完美的程度,至少有以下三个明显的缺点：
- 并发阶段,它虽然不会导致用户线程停顿,却因为占用一部分线程而导致应用程序变慢,降低总吞吐量。
- 它无法处理“浮动垃圾”,有可能会出现“并发失败”进而导致另一次Full GC的发生。
- 它是一款基于标记清除算法实现的收集器,这意味着收集结束时会有大量空间碎片产生。
8、请你讲下G1垃圾回收器
得分点 整堆、Region、标记整理、四个步骤
Garbage First（G1）收集器开创了收集器面向局部收集的设计思路和基于Region的内存布局形式。在G1收集器出现之前的所有其他收集器,垃圾收集的目标范围要么是整个新生代,要么就是整个老年代,再要么就是整个Java堆。而G1跳出了这个限制,它可以面向堆内存任何部分来组成回收集进行回收,衡量标准不再是它属于哪个分代,而是哪块内存中存放的垃圾数量最多,回收收益最大,这就是G1收集器的Mixed GC模式。 G1也仍是遵循分代收集理论设计的,但其堆内存的布局与其他收集器有非常明显的差异：G1不再坚持固定大小以及固定数量的分代区域划分,而是把连续的Java堆划分为多个大小相等的独立区域（Region）,每一个Region都可以根据需要,扮演新生代的Eden空间、Survivor空间,或者老年代空间。 此外,还有一类专门用来存储大对象的特殊区域（Humongous Region）。G1认为只要超过了Region一半的对象即可判定为大对象。而对于那些超过了整个Region容量的超级大对象,将会被存放在N个连续的Humongous Region之中,G1的大多数行为都把Humongous Region作为老年代的一部分来进行看待。 更具体的处理思路是,让G1收集器去跟踪各个Region里面的垃圾堆积的“价值”大小,价值即回收所获得的空间大小以及回收所需时间的经验值,然后在后台维护一个优先级列表,每次根据用户设定允许的收集停顿时间,优先处理回收价值收益最大的那些Region,这也就是“Garbage First”名字的由来。
G1收集器的运作过程大致可划分为以下四个步骤：初始标记、并发标记、最终标记、筛选回收。其中,初始标记和最终标记阶段仍然需要停顿所有的线程,但是耗时很短。
加分回答 G1与CMS的对比：G1从整体来看是基于标记整理算法实现的收集器,但从局部上看又是基于标记复制算法实现。无论如何,这两种算法都意味着G1运作期间不会产生内存空间碎片,垃圾收集完成之后能提供规整的可用内存。比起CMS,G1的弱项也可以列举出不少。例如在用户程序运行过程中,G1无论是为了垃圾收集产生的内存占用还是程序运行时的额外执行负载都要比CMS要高。 G1与CMS的选择： 目前在小内存应用上CMS的表现大概率仍然要会优于G1,而在大内存应用上G1则大多能发挥其优势,这个优劣势的Java堆容量平衡点通常在6GB至8GB之间。以上这些也仅是经验之谈,随着HotSpot的开发者对G1的不断优化,也会让对比结果继续向G1倾斜。
G1收集器是一个多线程的采用标记清除算法的，面向混合收集（同时收集新生带和老年带）的一个垃圾收集器。G1收集器将整个堆内存区域划分为多个大小相等的region，以region为单位进行垃圾收集并获取每个region的收集效率和收集收益，通过一张优先级表对其进行维护。同时每个region中维护了一个remember set用来存储该分区中的对象所引用的对象在其他分区的位置来避免在做可达性分析算法时全堆扫描。G1垃圾收集器垃圾回收主要包括四个流程：1，初始标记，2，并发标记（类似于CMS），3，最终标记在并发标记中维护了一个remember set log用来记录在该阶段发生变化的对象引用关系，在该阶段就是将该信息同步到最终标记信息中。4，并发筛选回收：根据优先级表选择分区进行垃圾回收，用户线程不停顿。
9、说说类加载机制
得分点 加载、验证、准备、解析、初始化
一个类型从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期将会经历加载、验证、准备、解析、初始化、使用、卸载七个阶段，其中验证、准备、解析三个部分统称为连接，而前五个阶段则是类加载的完整过程。
- 在加载阶段
JVM需要在内存中生成一个代表这个类的Class对象，作为方法区这个类的各种数据的访问入口。 - 验证阶段大致上会完成下面四个阶段的检验动作：文件格式验证、元数据验证、字节码验证、符号引用验证。
- 准备阶段是正式为类中定义变量（静态变量）分配到内存并设置类变量初始值的阶段，这些变量所使用的内存都应当在方法区中进行分配，但必须注意到方法区本身是一个逻辑上的区域。
- 解析阶段是
Java虚拟机将常量池内的符号替换为直接引用的过程，符号引用以一组符号来描述所引用的目标，直接引用是可以直接指向目标的指针、相对偏移量或者一个能间接定位到目标的句柄。 - 类的初始化阶段是类加载过程的最后一个步骤，直到初始化阶段，
Java虚拟机才真正开始执行类中编写的Java程序代码，将主导权移交给应用程序。本质上，初始化阶段就是执行类构造器<clinit>()的过程。<clinit>()并不是程序员在Java代码中直接编写的方法，它是Javac编译器的自动生成物。
加分回答 关于在什么情况下需要开始类加载过程的第一个阶段“加载”，《Java虚拟机规范》中并没有进行强制约束，这点可以交给虚拟机的具体实现来自由把握。但是对于初始化阶段，《Java虚拟机规范》则是严格规定了有且只有六种情况必须立即对类进行“初始化”：
- 使用
new实例化对象、读写类的静态字段、调用类的静态方法时。 - 使用
java.lang.reflect包的方法对类型进行反射调用时。 - 当初始化类时，若发现其父类还没有进行过初始化，则先初始化这个父类。
- 虚拟机启动时，需要指定一个要执行的主类，虚拟机会先初始化这个主类。
- 当使用
JDK 7新加入的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四种类型的方法句柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化。 - 当一个接口中定义了
JDK 8新加入的默认方法（被default关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。
10、说说JVM的双亲委派模型
得分点 启动类加载器、扩展类加载器、应用程序类加载器,ClassLoader
ClassLoader在Java中有着非常重要的作用，它主要工作在Class装载的加载阶段，其主要作用是从系统外部获得Class二级制数据流。它是Java的核心组件，所有的Class都是由ClassLoader进行加载的，ClassLoader负责通过将Class文件里的二进制数据流装载进系统，然后交给Java虚拟机进行连接、初始化等操作。
当我们使用一个类时会先对类进行加载，双亲委派模型就是java提供的一种类加载机制。java中默认存在三种类加载器：1，启动类加载器（BootstrapClassLoader），主要用于加载<java_home>\lib中的类库。2，扩展类加载器（ExtClassLoader），主要用于加载<java_home>\lib\ext文件夹下的类库。3，应用程序类加载器（Application ClassLoader），用于classpath下的类，即用户自定义的类。启动类加载器存在于jvm层面，使用c++语言编写，用户无法调用。双亲委派模型建立了一个逻辑上的从上到下的父子关系（启动类加载器，扩展类加载器，应用程序类加载器，这里的父子类不是继承关系），向上委派：当一个类加载器收到一个类加载请求后他不会立即执行类加载而时将请求向上转发交给父类加载器去执行。向下查找：当一个父类加载器无法加载某个类时便会将类加载的请求向下转发交给子类实现。双亲委派模型最大的优点是可以避免类的覆盖
双亲委派模型要求除了顶层的启动类加载器外,其余的类加载器都应有自己的父类加载器。不过这里类加载器之间的父子关系一般不是以 继承的关系来实现的，而是通常使用组合关系来复用父加载器的代码。 双亲委派模型的工作过程是 ,如果一个类加载器收到了类加载的请求,它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成,每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器中,只有当父加载器反馈自己无法完成这个加载请求时，子加载器才会尝试自己去完成加载。使用双亲委派模型来组织类加载器之间的关系，一个显而易见的好处就是Java中的类随着它的类加载器一起具备了一种带有优先级的层次关系。 例如object类，使用双亲委派模型，在程序的各种类加载器环境中都能够保证object是同一个类。反之，如果没有使用双亲委派模型，都由各个类加载器自行去加载的话，系统中可能有多个object类
11、说说类的实例化过程
得分点 类加载、分配内存、初始化零值、状态设置、构造函数
在JVM中,对象的创建遵循如下过程： 当JVM遇到一条字节码new指令时,首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用,并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有,那必须先执行相应的类加载过程。 在类加载检查通过后,接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成后便可完全确定,为对象分配空间的任务实际上便等同于把一块确定大小的内存块从Java堆中划分出来。 内存分配完成之后,虚拟机必须将分配到的内存空间都初始化为零值,如果使用了TLAB的话,这一项工作也可以提前至TLAB分配时顺便进行。这步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用,使程序能访问到这些字段的数据类型所对应的零值。 接下来,虚拟机还要对对象进行必要的设置,例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象的对象头之中。根据虚拟机当前运行状态的不同,如是否启用偏向锁等,对象头会有不同的设置方式。 在上面工作都完成之后,从虚拟机的视角来看,一个新的对象已经产生了。但是从Java程序的视角看来,对象创建才刚刚开始——构造函数,即Class文件中的<init>()方法还没有执行,所有的字段都为默认的零值,对象需要的其他资源和状态信息也还没有按照预定的意图构造好。 一般来说,new指令之后会接着执行<init>()方法,按照程序员的意愿对对象进行初始化,这样一个真正可用的对象才算完全被构造出来。
12、请你说说内存溢出
得分点 增加内存、错误日志、代码走查、内存查看工具
内存溢出,简单地说内存溢出就是指程序运行过程中申请的内存大于系统能够提供的内存,导致无法申请到足够的内存,于是就发生了内存溢出。引起内存溢出的原因有很多种,常见的有以下几种： 1. 内存中加载的数据量过于庞大,如一次从数据库取出过多数据； 2. 集合类中有对对象的引用,使用完后未清空,使得JVM不能回收； 3. 代码中存在死循环或循环产生过多重复的对象实体； 4. 使用的第三方软件中的BUG； 5. 启动参数内存值设定的过小。
内存溢出的解决方案： - 第一步,修改JVM启动参数,直接增加内存。 - 第二步,检查错误日志,查看“OutOfMemory”错误前是否有其它异常或错误。 - 第三步,对代码进行走查和分析,找出可能发生内存溢出的位置。 - 第四步,使用内存查看工具动态查看内存使用情况。
加分回答 除了程序计数器外,虚拟机内存的其他几个运行时区域都有发生OOM异常的可能。
Java堆溢出 Java堆用于储存对象实例,我们只要不断地创建对象,并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象,那么随着对象数量的增加,总容量触及最大堆的容量限制后就会产生内存溢出异常。
虚拟机栈和本地方法栈溢出 HotSpot虚拟机中并不区分虚拟机栈和本地方法栈,如果虚拟机的栈内存允许动态扩展,当扩展栈容量无法申请到足够的内存时,将抛出OutOfMemoryError异常。
方法区和运行时常量池溢出 方法区溢出也是一种常见的内存溢出异常,在经常运行时生成大量动态类的应用场景里,就应该特别关注这些类的回收状况。这类场景常见的包括：程序使用了CGLib字节码增强和动态语言、大量JSP或动态产生JSP文件的应用、基于OSGi的应用等。 在JDK 6或更早之前的HotSpot虚拟机中,常量池都是分配在永久代中,即常量池是方法区的一部分,所以上述问题在常量池中也同样会出现。而HotSpot从JDK 7开始逐步“去永久代”的计划,并在JDK 8中完全使用元空间来代替永久代,所以上述问题在JDK 8中会得到避免。
本地直接内存溢出 直接内存的容量大小可通过-XX：MaxDirectMemorySize参数来指定,如果不去指定,则默认与Java堆最大值一致。如果直接通过反射获取Unsafe实例进行内存分配,并超出了上述的限制时,将会引发OOM异常。
13、请你说说内存泄漏
得分点 分析器、详细日志、引用对象、泄漏警告、基准测试、代码审查
内存泄漏,是指不再使用的对象仍然被引用,导致垃圾收集器无法回收它们的内存。由于不再使用的对象仍然无法清理,甚至这种情况可能会越积越多,最终导致致命的OutOfMemoryError。可以按照如下的思路来分析和解决内存泄漏问题： 1. 启用分析器 Java分析器是通过应用程序监视和诊断内存泄漏的工具,它可以分析我们的应用程序内部发生的事情,例如如何分配内存。使用分析器,我们可以比较不同的方法并找到可以最佳利用资源的方式。 2. 启用详细垃圾收集日志 通过启用详细垃圾收集日志,我们可以跟踪GC的详细进度。要启用该功能,我们需要将以下内容添加到JVM的配置当中：-verbose:gc。通过这个参数,我们可以看到GC内部发生的细节。 3. 使用引用对象 我们还可以借助java.lang.ref包内置的Java引用对象来规避问题,使用java.lang.ref包,而不是直接引用对象,即使用对象的特殊引用,使得它们可以轻松地被垃圾收集。 4. Eclipse内存泄漏警告 对于JDK1.5以及更高的版本中,Eclipse会在遇到明显的内存泄漏情况时显示警告和错误。因此,在Eclipse中开发时,我们可以定期地访问“问题”选项卡,并更加警惕内存泄漏警告。 5. 基准测试 我们可以通过执行基准测试来衡量和分析Java代码的性能。通过这种方式,我们可以比较执行相同任务的替代方法的性能。这可以帮助我们选择更好的方法,并可以帮助我们节约内存。 6. 代码审查 最后,我们总是采用经典的老方式来进行简单的代码演练。在某些情况下,即使这种看似微不足道的方法也有助于消除一些常见的内存泄漏问题。 加分回答 通俗地说,我们可以将内存泄漏视为一种疾病,它通过阻塞重要的内存资源来降低应用程序的性能。和所有其他疾病一样,如果不治愈,随着时间的推移,它可能导致致命的应用程序崩溃。 内存泄漏很难解决,找到它们需要对Java语言有很深的理解并掌握复杂的命令。在处理内存泄漏时,没有一刀切的解决方案,因为泄漏可能通过各种不同的事件发生。 但是,如果我们采用最佳实践并定期执行严格的代码演练和分析,那么我们就可以将应用程序中内存泄漏的风险降到最低。
14、说说垃圾收集器
Serial（新生代）、Serial Old（老年代）：适用于单核小CPU，单核工作，回收时会暂停其他工作stop the word。
PawNew（新生代）、CMS（老年代）：适用于多核CPU，最求短暂停时间，多核工作，使用标记清除算法，最短的暂停时间。
Parallel Scavenge（新生代-标记复制算法）、Parallel Old（老年代-标记整理算法）：1.7,1.8默认的组合，适用于多核CPU，追求最大吞吐量
G1 jdk1.9默认，适用于大内存多核CPU服务器，它不按整个新生代或老年代去回收，而是开辟了面向局部收集，实现了较小的收集暂停时间和高吞吐量。
直接内存
Direct Memory
- 常见于 NIO 操作时，用于数据缓冲区
- 分配回收成本较高，但读写性能高
- 不受 JVM 内存回收管理
分配和回收原理
- 使用了
Unsafe对象完成直接内存的分配回收，并且回收需要主动调用freeMemory方法 ByteBuffffer的实现类内部，使用了Cleaner（虚引用）来监测ByteBuffffer对象，一旦ByteBuffffer对象被垃圾回收，那么就会由ReferenceHandler线程通过 Cleaner 的clean方法调用freeMemory来释放直接内
分代垃圾回收
- 对象首先分配在伊甸园区域
- 新生代空间不足时，触发 minor gc，伊甸园和 from 存活的对象使用 copy 复制到 to 中，存活的
对象年龄加 1并且交换 from to
- minor gc 会引发 stop the world，暂停其它用户的线程，等垃圾回收结束，用户线程才恢复运行
- 当对象寿命超过阈值时，会晋升至老年代，最大寿命是15（4bit）
- 当老年代空间不足，会先尝试触发 minor gc，如果之后空间仍不足，那么触发 full gc，STW的时
间更长
常见参数含义
堆初始大小-Xms
堆最大大小-Xmx 或 -XX:MaxHeapSize=size
新生代大小-Xmn 或 (-XX:NewSize=size + -XX:MaxNewSize=size )
幸存区比例（动态）-XX:InitialSurvivorRatio=ratio 和 -XX:+UseAdaptiveSizePolicy
幸存区比例-XX:SurvivorRatio=ratio
晋升阈值-XX:MaxTenuringThreshold=threshold
晋升详情-XX:+PrintTenuringDistribution
GC详情-XX:+PrintGCDetails -verbose:gc
FullGC 前 MinorGC-XX:+ScavengeBeforeFullGC
