1.Java内存区域是如何划分的？

Java堆：线程共享的，唯一目的就是用于存放对象实例，是垃圾收集器管理的主要区域；
Java虚拟机栈：线程私有的，每个方法在执行的同时都会创建一个栈帧用于存储局部变量等，局部变量表存放了编译器可知的各种基本数据类型和对象引用；
本地方法栈：和虚拟机栈类似，不过它是为Native方法服务；
程序计数器：线程私有的，可以看作是当前线程所执行的字节码的行号指示器，以便线程切换后恢复执行使用；
方法区：线程共享的，用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据；该区域的内存回收主要是针对常量池的回收和类型的卸载（特别是要注意一些动态字节码框架和自定义ClassLoader的场景下）；在HotSpot里经常被称为永久代，在Java 8里已被废除了，被元空间取代；

2.对象是否可用以及引用类型。

由于引用计数法无法解决循环引用的问题，所以一般都是使用可达性分析来判断的，即通过一系列称为“GC Roots”的对象（比如虚拟机栈引用的对象、方法区中的类静态属性和常量引用对象）作为起点，从这些节点一直往下搜索，走过的路径称为引用链；而那些没有与引用链相连的对象即为不可达，会被回收；
可以通过覆盖finalize方法来实现对象的“自救”，避免在标记后被回收，但通常不建议这么做；
对象的引用类型可分为：强引用、软引用（在内存溢出前会将这种类型的对象进行第二次回收）、弱引用（弱引用对象只能生存到下次垃圾回收之前）、虚引用（不会对生存时间存在影响，也无法通过它获取对象，主要目的就是在回收时收到一个系统通知）；

3.有哪些常见的垃圾收集算法？

标记-清除算法：首先标记出所有需要回收的对象，然后统一回收所有被标记的对象；缺点是效率不高且容易产生大量不连续的内存碎片；
复制算法：将可用内存分为大小相等的两块，每次只使用其中一块；当这一块用完了，就将还活着的对象复制到另一块上，然后把已使用过的内存清理掉。在HotSpot里，考虑到大部分对象存活时间很短，将内存分为Eden和两块Survivor，默认比例为8:1:1。代价是存在部分内存空间浪费，且可能存在空间不够需要分配担保的情况，所以适合在新生代使用；
标记-整理算法：首先标记出所有需要回收的对象，然后让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。适用于老年代。
分代收集算法：一般把Java堆分新生代和老年代，在新生代用复制算法，在老年代用标记-清理或标记-整理算法，是现代虚拟机通常采用的算法。

PS：堆的划分及回收过程详解

1. Eden区最大，对外提供堆内存。当Eden区快要满了，则进行Minor GC，把存活对象放入Survivor A区，清空Eden区；

2. Eden区被清空后，继续对外提供堆内存；

3. 当Eden区再次被填满，此时对Eden区和Survivor A区同时进行Minor GC，把存活对象放入Survivor B区，同时清空Eden 区和Survivor A区；

4. Eden区继续对外提供堆内存，并重复上述过程，即在Eden区填满后，把Eden区和某个Survivor区的存活对象放到另一个Survivor区；

5. 当某个Survivor区被填满，且仍有对象未被复制完毕时或者某些对象在反复Survive 15次左右时，则把这部分剩余对象放到Old区；

6. 当Old区也被填满时，进行Major GC，对Old区进行垃圾回收。

4.有哪些常见的垃圾收集器？

这里讨论JDK 1.7 Update 14之后的HotSpot虚拟机，包含的虚拟机如下图所示（存在连线的表示可以搭配使用）：

扫描二维码关注公众号，回复： 6133013 查看本文章

(1)Serial收集器

最基本、发展历史最悠久，在JDK 1.3之前是新生代收集的唯一选择；
是一个单线程（只会使用一个收集线程，且必须暂停所有工作线程）的收集器，采用的是复制算法；
现在依然是虚拟机运行在Client模式下的默认新生代收集器，主要就是因为它简单而高效（没有线程交互的开销）；

(2)ParNew收集器

其实就是Serial收集器的多线程版本，采用的也是复制算法；
ParNew收集器在单CPU环境中绝对不会有比Serial收集器更好的效果；
是许多运行在Server模式下虚拟机首选的新生代收集器，重要原因就是除了Serial收集器外，只有它能与CMS收集器配合工作；

PS：关于垃圾收集器的并行和并发

并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态；
并发（Concurrent）：指用户线程与垃圾收集线程同时执行，用户线程在继续执行而垃圾收集程序运行在另外一个CPU上；

(3)CMS收集器

是一种以获取最短回收停顿时间为目标的收集器，特别适合互联网站或者B/S的服务端；
它是基于标记-清除 算法实现的，主要包括4个步骤：初始标记（STW，只是初始标记一下GC Roots能直接关联到的对象，速度很快）、并发标记（非STW，执行GC RootsTracing，耗时比较长）、重新标记（STW，修正并发标记期间因用户程序继续导致变动的那一部分对象标记）和并发清除（非STW，耗时较长）；
还有3个明显的缺点：CMS收集器对CPU非常敏感（占用部分线程及CPU资源，影响总吞吐量）、无法处理浮动垃圾（默认达到92%就触发垃圾回收）、大量内存碎片产生（可以通过参数启动压缩）；

5.介绍一下G1收集器的原理和实现。

一款面向服务端应用的垃圾收集器，后续会替换掉CMS垃圾收集器；
特点：

并行与并发（充分利用多核多CPU缩短STW时间）
分代收集（独立管理整个Java堆，但针对不同年龄的对象采取不同的策略）
空间整合（局部看是基于复制算法，从整体来看是基于标记-整理算法，都不会产生内存碎片）
可预测的停顿（可以明确指定在一个长度为M毫秒的时间片内垃圾收集不会超过N毫秒）

将堆分为大小相等的独立区域，避免全区域的垃圾收集；新生代和老年代不再物理隔离，只是部分Region的集合；
G1跟踪各个Region垃圾堆积的价值大小，在后台维护一个优先列表，根据允许的收集时间优先回收价值最大的Region；
Region之间的对象引用以及其他收集器中的新生代与老年代之间的对象引用，采用Remembered Set来避免全堆扫描；
分为几个步骤，和CMS的过程比较类似：

初始标记（标记一下GC Roots能直接关联的对象并修改TAMS值，需要STW但耗时很短）
并发标记（从GC Root从堆中对象进行可达性分析找存活的对象，耗时较长但可以与用户线程并发执行）
最终标记（为了修正并发标记期间产生变动的那一部分标记记录，这一期间的变化记录在Remembered 
Set Log里，然后合并到Remembered Set里，该阶段需要STW但是可并行执行）
筛选回收（对各个Region回收价值排序，根据用户期望的GC停顿时间制定回收计划来回收）；

6.你们的服务配置的虚拟机参数是怎么样的？

我们的服务的虚拟机参数：

-server       --启用能够执行优化的编译器，显著提高服务器的性能
-Xmx4000M     --堆最大值
-Xms4000M     --堆初始大小
-Xmn600M      --年轻代大小
-XX:PermSize=200M         --持久代初始大小
-XX:MaxPermSize=200M      --持久代最大值
-Xss256K                  --每个线程的栈大小
-XX:+DisableExplicitGC    --关闭System.gc()
-XX:SurvivorRatio=1       --年轻代中Eden区与两个Survivor区的比值
-XX:+UseConcMarkSweepGC   --使用CMS内存收集
-XX:+UseParNewGC          --设置年轻代为并行收集
-XX:+CMSParallelRemarkEnabled        --降低标记停顿
-XX:+UseCMSCompactAtFullCollection   --在FULL GC的时候，对年老代进行压缩，可能会影响性能，但是可以消除碎片
-XX:CMSFullGCsBeforeCompaction=0     --此值设置运行多少次GC以后对内存空间进行压缩、整理
-XX:+CMSClassUnloadingEnabled        --回收动态生成的代理类 SEE：http://stackoverflow.com/questions/3334911/what-does-jvm-flag-cmsclassunloadingenabled-actually-do
-XX:LargePageSizeInBytes=128M        --内存页的大小不可设置过大， 会影响Perm的大小
-XX:+UseFastAccessorMethods          --原始类型的快速优化
-XX:+UseCMSInitiatingOccupancyOnly   --使用手动定义初始化定义开始CMS收集，禁止hostspot自行触发CMS GC
-XX:CMSInitiatingOccupancyFraction=80  --使用cms作为垃圾回收，使用80％后开始CMS收集
-XX:SoftRefLRUPolicyMSPerMB=0          --每兆堆空闲空间中SoftReference的存活时间
-XX:+PrintGCDetails                    --输出GC日志详情信息
-XX:+PrintGCApplicationStoppedTime     --输出垃圾回收期间程序暂停的时间
-Xloggc:$WEB_APP_HOME/.tomcat/logs/gc.log  --把相关日志信息记录到文件以便分析.
-XX:+HeapDumpOnOutOfMemoryError            --发生内存溢出时生成heapdump文件
-XX:HeapDumpPath=$WEB_APP_HOME/.tomcat/logs/heapdump.hprof  --heapdump文件地址

7.如何进行性能调优以及常用的JDK的命令行工具有哪些？

JVM调优：CPU使用率与Load值偏大（Thread count以及GC count）、关键接口响应时间很慢（GC time以及GC log中的STW的时间）、发生Full GC或者Old CMS GC非常频繁（内存泄露）；
JVM停顿（尽量避免Full GC、关闭偏向锁、输出GC日志到内存文件系统、关闭JVM输出的jstat日志）；
将Java性能优化分为4个层级：应用层、数据库层、框架层、JVM层。每层优化难度逐级增加，涉及的知识和解决的问题也会不同。比如应用层需要理解代码逻辑，通过Java线程栈定位有问题代码行等；数据库层面需要分析SQL、定位死锁等；框架层需要懂源代码，理解框架机制；JVM 层需要对GC的类型和工作机制有深入了解，对各种 JVM 参数作用了然于胸；
围绕Java性能优化，有两种最基本的分析方法：现场分析法和事后分析法。现场分析法通过保留现场，再采用诊断工具分析定位。现场分析对线上影响较大，部分场景不太合适。事后分析法需要尽可能多收集现场数据，然后立即恢复服务，同时针对收集的现场数据进行事后分析和复现。
OS 的诊断主要关注的是 CPU、Memory、I/O 三个方面。top、vmstat、 free –m、iostat；常用的Java应用诊断包括线程、堆栈、GC 等方面的诊断，可以使用jstack 、jstat、jmap；

8.类的加载器是什么？

虚拟机设计团队把类加载阶段的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到虚拟机外部去实现，实现这个动作的代码模块称为类加载器；这种设计给Java语言带来了非常强大的灵活性；
双亲委派模型要求除了顶层的启动类加载器外，其他的类加载器都应当有自己的父类加载器，如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，只有父类加载器反馈自己无法完成这个加载请求时，子加载器才会尝试自己去加载；这对于保证程序的稳定运作很重要；

OSGI实现模块化热部署的关键是它自定义的类加载机制的实现，每个Bundle（通过Import-Package和Export-Package导入和导出依赖）都有自己的类加载器，类加载器之间形成了更加复杂的网状结构；

9.谈谈你对Java内存模型的理解

虚拟机规范视图通过JMM来屏蔽掉各种硬件和操作系统的内存访问差异，主要目标是定义程序中各个变量的访问限制，即在虚拟机将变量存储到内存和从内存中取出变量这样的底层细节；
主内存与工作内存：Java内存模型规定了所有的变量都存储在主内存中，每个线程还有自己的工作内存，线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量；

可见性（主内存和工作内存）、原子性（volatile的long是具备原子性的）、有序性（happen—before规则）；
Java语言中有一个“先行发生”（happen—before）的规则，它是Java内存模型中定义的两项操作之间的偏序关系，如果操作A先行发生于操作B，其意思就是说，在发生操作B之前，操作A产生的影响都能被操作B观察到，“影响”包括修改了内存中共享变量的值、发送了消息、调用了方法等，它与时间上的先后发生基本没有太大关系。下面是Java内存模型中的八条可保证happen—before的规则，它们无需任何同步器协助就已经存在，可以在编码中直接使用。如果两个操作之间的关系不在此列，并且无法从下列规则推导出来的话，它们就没有顺序性保障，虚拟机可以对它们进行随机地重排序。

1、程序次序规则：在一个单独的线程中，按照程序代码的执行流顺序，（时间上）先执行的操作happen—before（时间上）后执行的操作。
2、管理锁定规则：一个unlock操作happen—before后面（时间上的先后顺序，下同）对同一个锁的lock操作。
3、volatile变量规则：对一个volatile变量的写操作happen—before后面对该变量的读操作。
4、线程启动规则：Thread对象的start（）方法happen—before此线程的每一个动作。
5、线程终止规则：线程的所有操作都happen—before对此线程的终止检测，可以通过Thread.join（）方法结束、Thread.isAlive（）的返回值等手段检测到线程已经终止执行。
6、线程中断规则：对线程interrupt（）方法的调用happen—before发生于被中断线程的代码检测到中断时事件的发生。
7、对象终结规则：一个对象的初始化完成（构造函数执行结束）happen—before它的finalize（）方法的开始。
8、传递性：如果操作A happen—before操作B，操作B happen—before操作C，那么可以得出A happen—before操作C。

比如双重检查实现单例模式可能存在并发问题，可以使用内部静态类实现。

public class Singleton {

private Singleton() {}

// Lazy initialization holder class idiom for static fields

private static class InstanceHolder {

private static final Singleton instance = new Singleton();

}

public static Singleton getSingleton() {

return InstanceHolder.instance;

}

10.是否了解偏向锁？

JVM锁有4种状态：无锁、偏向锁（通过MarkWord的线程ID）、轻量级锁（通过MarkWord的锁记录指针）、重量级锁；

11. 类的实例化顺序，比如父类静态数据，构造函数，字段，子类静态数据，构造函数，字段，他们的执行顺序

答：先静态、先父后子。
先静态：父静态 > 子静态
优先级：父类静态代码块> 子类静态代码块 > 非静态代码块 > 构造函数
一个类的实例化过程：
1，父类中的static代码块，当前类的static
2，顺序执行父类的普通代码块
3，父类的构造函数
4，子类普通代码块
5，子类（当前类）的构造函数，按顺序执行。
6，子类方法的执行

12. JVM内存分配

这里写图片描述

13. Java 8的内存分代改进

从永久代到元空间，在小范围自动扩展永生代避免溢出

14. JVM垃圾回收机制，何时触发MinorGC等操作

分代垃圾回收机制：不同的对象生命周期不同。把不同生命周期的对象放在不同代上，不同代上采用最合适它的垃圾回收方式进行回收。
JVM中共划分为三个代：年轻代、年老代和持久代，
年轻代：存放所有新生成的对象；
年老代：在年轻代中经历了N次垃圾回收仍然存活的对象，将被放到年老代中，故都是一些生命周期较长的对象；
持久代：用于存放静态文件，如Java类、方法等。
新生代的垃圾收集器命名为“minor gc”，老生代的GC命名为”Full Gc 或者Major GC”.其中用System.gc()强制执行的是Full Gc.
判断对象是否需要回收的方法有两种：
1.引用计数
当某对象的引用数为0时，便可以进行垃圾收集。
2.对象引用遍历
果某对象不能从这些根对象的一个（至少一个）到达，则将它作为垃圾收集。在对象遍历阶段，gc必须记住哪些对象可以到达，以便删除不可到达的对象，这称为标记（marking）对象。

触发GC（Garbage Collector）的条件：
1)GC在优先级最低的线程中运行，一般在应用程序空闲即没有应用线程在运行时被调用。
2)Java堆内存不足时，GC会被调用。

15. jvm中一次完整的GC流程（从ygc到fgc）是怎样的，重点讲讲对象如何晋升到老年代等

答：对象优先在新生代区中分配，若没有足够空间，Minor GC；
大对象（需要大量连续内存空间）直接进入老年态；长期存活的对象进入老年态。如果对象在新生代出生并经过第一次MGC后仍然存活，年龄+1，若年龄超过一定限制（15），则被晋升到老年态。

16. 你知道哪几种垃圾收集器，各自的优缺点，重点讲下cms，g1

这里写图片描述

17. Eden和Survivor的比例分配等

默认比例8:1。
大部分对象都是朝生夕死。
复制算法的基本思想就是将内存分为两块，每次只用其中一块，当这一块内存用完，就将还活着的对象复制到另外一块上面。复制算法不会产生内存碎片。

18. 深入分析了Classloader，双亲委派机制

ClassLoader：类加载器（class loader）用来加载 Java 类到 Java 虚拟机中。Java 源程序（.java 文件）在经过 Java 编译器编译之后就被转换成 Java 字节代码（.class 文件）。类加载器负责读取 Java 字节代码，并转换成 java.lang.Class 类的一个实例。
双亲委派机制：某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父类加载器，依次递归，如果父类加载器可以完成类加载任务，就成功返回；只有父类加载器无法完成此加载任务时，才自己去加载。

19. JVM的编译优化

20. 对Java内存模型的理解，以及其在并发中的应用

Java内存模型的主要目标: 定义程序中各个变量的访问规则。
Java线程之间的通信由Java内存模型（本文简称为JMM）控制。
所有变量的存储都在主内存，每条线程还都有自己的工作内存，线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作必须在工作内存完成，而不能直接读取主内存中的变量。不同的线程直接无法访问对方工作内存中的变量，线程间变量的传递均需要通过主内存来完成。
这里写图片描述

线程间通信：
1. 首先，线程A把本地内存A中更新过的共享变量刷新到主内存中去。
2. 然后，线程B到主内存中去读取线程A之前已更新过的共享变量。

21. 指令重排序，内存栅栏等

指令重排序：编译器或运行时环境为了优化程序性能而采取的对指令进行重新排序执行的一种手段。在单线程程序中，对存在控制依赖的操作重排序，不会改变执行结果；但在多线程程序中，对存在控制依赖的操作重排序，可能会改变程序的执行结果。

22. OOM错误，stackoverflow错误，permgen space错误

23. JVM常用参数

JVM主要参数：堆设置、回收器选择（串行、并行、并发收集器）

24. tomcat结构，类加载器流程

这里写图片描述
目录结构：
• /bin：存放windows或Linux平台上启动和关闭Tomcat的脚本文件
• /conf：存放Tomcat服务器的各种全局配置文件，其中最重要的是server.xml和web.xml
• /doc：存放Tomcat文档
• /server：包含三个子目录：classes、lib和webapps
• /server/lib：存放Tomcat服务器所需的各种JAR文件
• /server/webapps：存放Tomcat自带的两个WEB应用admin应用和 manager应用
• /common/lib：存放Tomcat服务器以及所有web应用都可以访问的jar文件
• /shared/lib：存放所有web应用都可以访问的jar文件（但是不能被Tomcat服务器访问）
• /logs：存放Tomcat执行时的日志文件
• /src：存放Tomcat的源代码
• /webapps：Tomcat的主要Web发布目录，默认情况下把Web应用文件放于此目录
• /work：存放JSP编译后产生的class文件

类加载器模式，双亲委派模式：
这里写图片描述

25. volatile的语义，它修饰的变量一定线程安全吗

一个变量被定义为volatile之后，具备两重语义：①保证此变量对所有线程的可见性，即当一条线程修改了这个值，新值对于其他所有线程来说是立即得知的，普通变量需要通过主内存传递。②禁止指令重排序优化。
Volatile修饰的变量不一定是线程安全的，eg非原子操作a++等

26. g1和cms区别,吞吐量优先和响应优先的垃圾收集器选择

CMS收集器：一款以获取最短回收停顿时间为目标的收集器，是基于“标记-清除”算法实现的，分为4个步骤：初始标记、并发标记、重新标记、并发清除。
G1收集器：面向服务端应用的垃圾收集器，过程：初始标记；并发标记；最终标记；筛选回收。整体上看是“标记-整理”，局部看是“复制”，不会产生内存碎片。
吞吐量优先的并行收集器：以到达一定的吞吐量为目标，适用于科学技术和后台处理等。
响应时间优先的并发收集器：保证系统的响应时间，减少垃圾收集时的停顿时间。适用于应用服务器、电信领域等。

27. 说一说你对环境变量classpath的理解？如果一个类不在classpath下，为什么会抛出ClassNotFoundException异常，如果在不改变这个类路径的前期下，怎样才能正确加载这个类？

classpath是javac编译器的一个环境变量。它的作用与import、package关键字有关。package的所在位置，就是设置CLASSPATH当编译器面对import packag这个语句时，它先会查找CLASSPATH所指定的目录，并检视子目录java/util是否存在，然后找出名称吻合的已编译文件（.class文件）。如果没有找到就会报错！
动态加载包

28. 说一下强引用、软引用、弱引用、虚引用以及他们之间和gc的关系

强引用：new出的对象之类的引用，
只要强引用还在，永远不会回收
软引用：引用但非必须的对象，内存溢出异常之前，回收
弱引用：非必须的对象，对象能生存到下一次垃圾收集发生之前。
虚引用：对生存时间无影响，在垃圾回收时得到通知。

【JVM】