1.ArrayList和LinkedList的了解？
2.HashMap和Hashtable的了解？
3.对于上面两个容器的初始值和每次扩充容量大小，以及为什么HashMap的长度是那个规律？
4.HashMap多线程操作会导致什么问题？-
5.谈谈synchronized关键字的理解？
6.原子性的理解？锁的理解？
7.JVM的理解？Java1.8版本有什么了解？
8.什么是OOM？StackOverflowError和OutOfMemoryError？
9.JVM的常用参数调优？
10.内存快照抓取和MAT分析hprof文件？-
————————————————
- ArrayList和LinkedList的了解？
ArrayList底层使用的是Object数组，所以执行数据的插入和删除元素的时间可能会移动相应的元素。LinkedList底层使用的是双向链表数据结构，所以插入和删除不受元素位置的影响。但对于访问集合中的元素，ArrayList可以根据下标索引序号快速响应，而LinkedList不支持快速随机访问元素。
- HashMap和Hashtable的了解？
对于不同的JDK版本有着不同的底层结构。HashMap在JDK1.8之前底层是数组和链表结合而成的链表散列。HashMap通过key的hashCode处理得到hash值，然后通过(数组长度-1)&hash判断当前元素存放的位置，如果当前位置存在元素的话，就判断该元素与要存入的元素的hash值以及key是否相同，如果相同的话就覆盖，否则就通过拉链法解决冲突。JDK1.8之后当链表长度大于阀值就转化为红黑树减少搜索时间。
HashMap和Hashtable的区别
HashMap和Hashtable都实现了Map接口，但决定用哪一个之前先要弄清楚它们之间的分别。主要的区别有：线程安全性，同步(synchronization)，以及速度。
HashMap几乎可以等价于Hashtable，除了HashMap是非synchronized的，并可以接受null(HashMap可以接受为null的键值(key)和值(value)，而Hashtable则不行)。
HashMap是非synchronized，而Hashtable是synchronized，这意味着Hashtable是线程安全的，多个线程可以共享一个Hashtable；而如果没有正确的同步的话，多个线程是不能共享HashMap的。Java 5提供了ConcurrentHashMap，它是HashTable的替代，比HashTable的扩展性更好。
另一个区别是HashMap的迭代器(Iterator)是fail-fast迭代器，而Hashtable的enumerator迭代器不是fail-fast的。所以当有其它线程改变了HashMap的结构（增加或者移除元素），将会抛出ConcurrentModificationException，但迭代器本身的remove()方法移除元素则不会抛出ConcurrentModificationException异常。但这并不是一个一定发生的行为，要看JVM。这条同样也是Enumeration和Iterator的区别。
由于Hashtable是线程安全的也是synchronized，所以在单线程环境下它比HashMap要慢。如果你不需要同步，只需要单一线程，那么使用HashMap性能要好过Hashtable。
HashMap不能保证随着时间的推移Map中的元素次序是不变的。
要注意的一些重要术语：
sychronized意味着在一次仅有一个线程能够更改Hashtable。就是说任何线程要更新Hashtable时要首先获得同步锁，其它线程要等到同步锁被释放之后才能再次获得同步锁更新Hashtable。
Fail-safe和iterator迭代器相关。如果某个集合对象创建了Iterator或者ListIterator，然后其它的线程试图“结构上”更改集合对象，将会抛出ConcurrentModificationException异常。但其它线程可以通过set()方法更改集合对象是允许的，因为这并没有从“结构上”更改集合。但是假如已经从结构上进行了更改，再调用set()方法，将会抛出IllegalArgumentException异常。
结构上的更改指的是删除或者插入一个元素，这样会影响到map的结构。
我们能否让HashMap同步？
HashMap可以通过下面的语句进行同步：
Map m = Collections.synchronizeMap(hashMap);
结论
Hashtable和HashMap有几个主要的不同：线程安全以及速度。仅在你需要完全的线程安全的时候使用Hashtable，而如果你使用Java 5或以上的话，请使用ConcurrentHashMap吧。
- 对于上面两个容器的初始值和每次扩充容量大小，以及为什么HashMap的长度是那个规律？
如果不指定容器的初始值，Hashtable默认为11，每次扩充为原来的2n+1，HashMap默认初始为16，每次扩充为2的幂次方大小。
为什么长度要是2的幂次方呢
Hash 值的范围值-2147483648到2147483647，前后加起来大概40亿的映射空间。那当然是不能直接拿的。
只能通过映射，就是对数组取模。“ (n - 1) & hash”。（n代表数组长度）这是公式。
取余(%)操作中如果除数是2的幂次则等价于与其除数减一的与(&)操作（也就是说 hash%length==hash&(length-1)的前提是 length 是2的 n 次方；）。” 并且 采用二进制位操作 &，相对于%能够提高运算效率，
- HashMap多线程操作会导致什么问题？
大多数javaer都知道HashMap是线程不安全的，多线程环境下数据可能会发生错乱，一定要谨慎使用。这个结论是没错，可是HashMap的线程不安全远远不是数据脏读这么简单，它还有可能会发生死锁，造成内存飙升100%的问题。
死锁的四个条件
1）互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待，直至占有资源的进程用毕释放。
2）请求和保持条件：指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其它资源保持不放。
3）不剥夺条件：指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放。
4）环路等待条件：指在发生死锁时，必然存在一个进程——资源的环形链，即进程集合{P0，P1，P2，···，Pn}中的P0正在等待一个P1占用的资源；P1正在等待P2占用的资源，……，Pn正在等待已被P0占用的资源。
我们来分析一下链表的互相引用符不符合上面四个条件：
①互斥条件：链表上的节点同一时间此时被两个线程占用，两个线程占用访问节点的权利，符合该条件
②请求和保持条件：Thread1保持着节点e1，又提出了占用节点e2(此时尚未释放e2)；而Thread2此时占用e2,又提出了占用节点e1，Thread1占用着Thread2接下来要用的e1,而Thread2又占用着Thread1接下来要用的e2，符合该条件
③：不剥夺条件：线程是由自己的退出的，此时并没有任何中断机制（sleep或者wait方法或者interuppted中断），只能由自己释放，满足条件
④：环路等待条件：e1、e2、e3等形成了资源的环形链条，满足该条件
- 谈谈synchronized关键字的理解？
解决了多线程访问共享资源造成的数据紊乱，所以采用该关键字修饰的方法或者代码块在任何时刻只能由一个线程执行。
原子性的理解？
多线程操作的一系列复合操作，要么全部成功，要么全部失败回到操作前的初始值。
锁的理解？
锁的加入就是为了防止多线程同时对共享资源的操作造成数据的紊乱。
6.****JVM的理解？Java1.8版本有什么了解？
JVM运行时数据区，分为线程共享部分（方法区、堆）和线程隔离区（虚拟机栈、本地方法栈和程序计数器）。
** 1.方法区**
用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
运行时常量池(Runtime Constant Pool)是方法区的一部分。.Class文件中除了有类的版本/字段/方法/接口等描述信息外,还有一项信息是常量池(Constant Pool Table),用于存放编译期生成的各种字面量和符号引用,这部分内容将类在加载后进入方法区的运行时常量池中存放.
运行时常量区的内容并不只是在编译期间产生，通过String.intern()也可以实现在运行时向常量区中添加内容。
需要注意的是：从JDK8开始，方法区被元数据区替代了。
2.堆
是JVM中最大的一块内存区域，该区域的目的只是用于存储对象实例及数组。该区域也是GC的最主要区域。
根据Java虚拟机规范的规定,Java堆可以处于物理上不连续的内存空间中,只要逻辑上是连续的即可,就像我们的磁盘空间一样.在实现时,既可以实现固定大小的,也可以是可扩展的,不过当前主流的虚拟机都是按照可扩展来实现的(通过-Xmx和-Xms控制).如果在堆中没有内存完成实例分配,并且堆也无法再扩展时,就会抛出OutOfMemoryError异常。
3.虚拟机栈
每个线程方法在执行时都会创建一个栈帧，包含局部变量表、返回地址、操作数栈等信息。每个方法的执行与完成就对应的栈帧的入栈与出栈过程。局部变量表占用空间的大小在编译期就确定了。
这里需要注意：如果线程请求的栈深度大于虚拟机所允许的深度，将会抛出StackOverflowError异常；如果虚拟机栈可以动态扩展（当前大部分的Java虚拟机都可动态扩展，只不过Java虚拟机规范中也允许固定长度的虚拟机栈），当扩展时无法申请到足够的内存时将会抛出OutOfMemoryError异常。
** 4.本地方法栈**
与虚拟机栈类似，不过其中执行是本地方法。对于HotSpot虚拟机而言，本地方法栈和虚拟机栈是统一的。
** 5.程序计数器**
是一个小的内存空间，如果线程正在执行的是一个java方法，则此内存区域记录正在执行的虚拟机字节码指令的地址；如果线程正在执行的是native方法，则计算器中的值为空。此内存区域是唯一一个在JAVA虚拟机规范中没有规定任何OutOfMemoryError情况的区域。
JVM中ClassLoader类加载器的认识
1.加载
加载指的是将类的class文件读入到内存，并为之创建一个java.lang.Class对象，也就是说，当程序中使用任何类时，系统都会为之建立一个java.lang.Class对象。
类的加载由类加载器完成，类加载器通常由JVM提供，这些类加载器也是前面所有程序运行的基础，JVM提供的这些类加载器通常被称为系统类加载器。除此之外，开发者可以通过继承ClassLoader基类来创建自己的类加载器。
通过使用不同的类加载器，可以从不同来源加载类的二进制数据，通常有如下几种来源。
1.从本地文件系统加载class文件，这是前面绝大部分示例程序的类加载方式。
2.从JAR包加载class文件，这种方式也是很常见的，前面介绍JDBC编程时用到的数据库驱动类就放在JAR文件中，JVM可以从JAR文件中直接加载该class文件。
3.通过网络加载class文件。
4.把一个Java源文件动态编译，并执行加载。
类加载器通常无须等到“首次使用”该类时才加载该类，Java虚拟机规范允许系统预先加载某些类。
2.链接
当类被加载之后，系统为之生成一个对应的Class对象，接着将会进入连接阶段，连接阶段负责把类的二进制数据合并到JRE中。类连接又可分为如下3个阶段。
1)验证：验证阶段用于检验被加载的类是否有正确的内部结构，并和其他类协调一致。Java是相对C++语言是安全的语言，例如它有C++不具有的数组越界的检查。这本身就是对自身安全的一种保护。验证阶段是Java非常重要的一个阶段，它会直接的保证应用是否会被恶意入侵的一道重要的防线，越是严谨的验证机制越安全。验证的目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求，不会危害虚拟机自身安全。其主要包括四种验证，文件格式验证，元数据验证，字节码验证，符号引用验证。
四种验证做进一步说明：
文件格式验证：主要验证字节流是否符合Class文件格式规范，并且能被当前的虚拟机加载处理。例如：主，次版本号是否在当前虚拟机处理的范围之内。常量池中是否有不被支持的常量类型。指向常量的中的索引值是否存在不存在的常量或不符合类型的常量。
** 元数据验证：**对字节码描述的信息进行语义的分析，分析是否符合java的语言语法的规范。
** 字节码验证：**最重要的验证环节，分析数据流和控制，确定语义是合法的，符合逻辑的。主要的针对元数据验证后对方法体的验证。保证类方法在运行时不会有危害出现。
符号引用验证：主要是针对符号引用转换为直接引用的时候，是会延伸到第三解析阶段，主要去确定访问类型等涉及到引用的情况，主要是要保证引用一定会被访问到，不会出现类等无法访问的问题。
2)准备：类准备阶段负责为类的静态变量分配内存，并设置默认初始值。
3)解析：将类的二进制数据中的符号引用替换成直接引用。说明一下：符号引用：符号引用是以一组符号来描述所引用的目标，符号可以是任何的字面形式的字面量，只要不会出现冲突能够定位到就行。布局和内存无关。直接引用：是指向目标的指针，偏移量或者能够直接定位的句柄。该引用是和内存中的布局有关的，并且一定加载进来的。
3.初始化
初始化是为类的静态变量赋予正确的初始值，准备阶段和初始化阶段看似有点矛盾，其实是不矛盾的，如果类中有语句：private static int a = 10，它的执行过程是这样的，首先字节码文件被加载到内存后，先进行链接的验证这一步骤，验证通过后准备阶段，给a分配内存，因为变量a是static的，所以此时a等于int类型的默认初始值0，即a=0,然后到解析（后面在说），到初始化这一步骤时，才把a的真正的值10赋给a,此时a=10。
- 什么是OOM？StackOverflowError和OutOfMemoryError？
OOM：java.lang.OutOfMemoryError 内存溢出
StackOverflowError：递归过深，递归没有出口。
OutOfMemoryError：JVM空间溢出，创建对象速度高于GC回收速度。
JVM的常用参数调优？
在调优之前，我们需要记住下面的原则：
多数的 Java 应用不需要在服务器上进行 GC 优化； 多数导致 GC 问题的 Java 应用，都不是因为我们参数设置错误，而是代码问题； 在应用上线之前，先考虑将机器的 JVM 参数设置到最优（最适合）； 减少创建对象的数量； 减少使用全局变量和大对象； GC 优化是到最后不得已才采用的手段； 在实际使用中，分析 GC 情况优化代码比优化 GC 参数要多得多。
GC 调优目的
将转移到老年代的对象数量降低到最小； 减少 GC 的执行时间。
策略 1：将新对象预留在新生代，由于 Full GC 的成本远高于 Minor GC，因此尽可能将对象分配在新生代是明智的做法，实际项目中根据 GC 日志分析新生代空间大小分配是否合理，适当通过“-Xmn”命令调节新生代大小，最大限度降低新对象直接进入老年代的情况。
策略 2：大对象进入老年代，虽然大部分情况下，将对象分配在新生代是合理的。但是对于大对象这种做法却值得商榷，大对象如果首次在新生代分配可能会出现空间不足导致很多年龄不够的小对象被分配的老年代，破坏新生代的对象结构，可能会出现频繁的 full gc。因此，对于大对象，可以设置直接进入老年代（当然短命的大对象对于垃圾回收老说简直就是噩梦）。-XX:PretenureSizeThreshold 可以设置直接进入老年代的对象大小。
策略 3：合理设置进入老年代对象的年龄，-XX:MaxTenuringThreshold 设置对象进入老年代的年龄大小，减少老年代的内存占用，降低 full gc 发生的频率。
策略 4：设置稳定的堆大小，堆大小设置有两个参数：-Xms 初始化堆大小，-Xmx 最大堆大小。
策略5：注意： 如果满足下面的指标，则一般不需要进行 GC 优化：
MinorGC 执行时间不到50ms； Minor GC 执行不频繁，约10秒一次； Full GC 执行时间不到1s； Full GC 执行频率不算频繁，不低于10分钟1次。