JAVA面试题第四天

今天是第四天。
1.jdk1.5引入了泛型，泛型的存在是用来解决什么问题。
泛型的本质是参数化类型，也就是操作的数据类型被指定为一个 参数，好处就是可以在编译的时候可以检查类型安全，并且所有强制转化都是隐式和自动，提高了代码的重用率。

2.JAVA的HashSet内部是如何工作的。
底层是基于hashMap实现的，基本上都是直接调用底层HashMap的相关方法来完成的。
http://wiki.jikexueyuan.com/project/java-collection/hashset.html

3.什么是序列化，怎么序列化，为什么序列化，反序列化会遇到什么问题，如何解决。
http://www.importnew.com/17964.html
序列化是将Java对象的状态信息转化为可以存储或者传输的形式的过程，一般一个对象存储在一个存储媒介中，例如档案或者记忆体缓冲，在网络上传输可以是字节或者是XML格式。字节和XML格式的编码方式可以完全还原相等的对象，这个过程被称为反序列化。
在java中，我们可以创建对象和使用对象，但是对象是存活在JVM中的，所以当JVM停止运行的时候，对象就不存在了，我们需要持久化的对象让我们可以在需要的时候重新读取出对象。JAVA序列化可以实现该功能。序列话对象的状态保存为字节数组。
实现序列化的接口和类有：serializable,externalizable,ObjectOutput,ObjectInput。

4.什么情况下会发生栈内存溢出
在线程请求的栈深度超过了虚拟机所允许的深度，会抛出StackOverflowerror的异常，在虚拟机动态扩展栈无法请求到足够的内存空间时，则会抛出outofMemoryError的异常。

5.JVM的内存结构，Eden和survivor比例。
Eden：survivor（from）：survivor（to）=8：1：1
http://blog.csdn.net/lojze_ly/article/details/49456255

6.JVM中一次完整的GC流程是怎样的，对象如何晋升到老年代，说说你知道的几种主要的JVM参数。
新生代对象诞生在Eden中，在minor gc后，如果对象依然存活，就变成survivor，进行标记代数，如此检查次数后，存活下来的对象就变成老年代了。
http://www.cnblogs.com/redcreen/archive/2011/05/04/2037056.html

-Xms 初始堆大小
-Xmx 最大堆大小
-Xmn 年轻代大小 推荐配置为整个堆的3/8
-XX:newSize 新生代初始内存大小
-XX:NewRatio 年轻代和年老代的比值
-XX:MaxNewSize 年轻代最大值
-XX:PermSize 设置持久代（perm gen）初始值
-XX:MaxPermSize 设置持久代最大值
-Xss 每个线程的堆栈大小
-XX:SurvivorRatio Eden区与Survivor的大小比值，设置为8，则两个Survivor区与一个Eden区的比值为2:8

7.你知道哪几种垃圾收集器。各自的优缺点，重点讲下cms，包括原理，流程，优缺点。
Serial、parNew、Parallel Scavenge、SerialOld、ParallelOld、GMS、G1。
https://wangkang007.gitbooks.io/jvm/content/chapter1.html
如果收集算法是内存回收的方法论，垃圾回收器就是内存回收的具体实现。
CMS收集器是以获取最短回收停顿时间为目标的收集器。
CMS收集器是基于标记-清除算法实现的。过程可以分为4个步骤：
1.初始标记
2.并发标记
3.重新标记
4.并发清除
初始标记、重新标记这两个步骤仍然需要stop the world，初始标记仅仅只是标记一下GC Roots能够直接关联的对象，速度很快，并发标记就是进行GC Roots Trancing 的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个标记阶段的停顿时间会比初始标记的停顿时间长一些，但是你比并发标记的时间短。
CMS收集器无法处理浮动垃圾，可能会出现Concurrent Mode Failure 失败而导致另一次FULL GC的产生，由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然还是会有新的垃圾不断产生，在这一部分垃圾出现在标记过程之后，CMS无法在档次手机处理掉它们，只好留待下一次GC清理掉。这一部分垃圾就被称为"浮动垃圾"。也是由于在垃圾收集阶段用户线程还需要运行，那也就是还需要留有足够的内存空间给用户线程使用，因此CMS收集器不能像是其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用，在JDK1.5的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活，这是一个偏保守的设置于，入股在应用中老年代增长不是太快，可以适当调高参数-XX:CMSInitiatingOccupancyFraction的值来提高触发百分比，以便降低内存回收次数从而获得更好的性能，在JDK1.6，CMS收集器的启动阈值已经提升至92%。要是CMS运行期间预留的内存无法满足程序需求，就会出现一次Concurrent Mode Failure 的失败，这时虚拟机启动后备预案：临时启动Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就太长了，所以说参数-XX:CMSInitiatingOccupancyFrantion设置的太高很容易导致大量Concurrent Mode Failure失败，性能降低。
CMS是一款基于“标记—清除”算法实现的收集器，如果读者对前面这种算法介绍还有印象的话，就可能想到这意味着收集结束时会有大量空间碎片产生。空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。为了解决这个问题，CMS收集器提供了一个-XX:+UseCMSCompactAtFullCollection开关参数（默认就是开启的），用于在CMS收集器顶不住要进行FullGC时开启内存碎片的合并整理过程，内存整理的过程是无法并发的，空间碎片问题没有了，但停顿时间不得不变长。虚拟机设计者还提供了另外一个参数-XX:CMSFullGCsBeforeCompaction，这个参数是用于设置执行多少次不压缩的Full GC后，跟着来一次带压缩的（默认值为0，表示每次进入Full GC时都进行碎片整理）。