呦呵丶晓晓的博客

LeetCode题解 - 01.两数之和

2020-11-27T04:05:13.000Z

题目

1.两数之和
难度：简单

给定一个整数数组 nums 和一个目标值 target，请你在该数组中找出和为目标值的那 两个 整数，并返回他们的数组下标。

你可以假设每种输入只会对应一个答案。但是，数组中同一个元素不能使用两遍。

示例:

给定 nums = [2, 7, 11, 15], target = 9

因为 nums[0] + nums[1] = 2 + 7 = 9
所以返回 [0, 1]

题解

暴力法

确定第一个元素i，然后搜索其后的元素j，当满足条件nums[i] + nums[j] == target时，返回[i,j]

时间复杂度：O(n^2^)
空间复杂度：O(1)

class Solution:
    def twoSum(self, nums: List[int], target: int) -> List[int]:
        length = len(nums)
        for i in range(length):
            for j in range(i + 1, length):
                if nums[i] + nums[j] == target:
                    return [i, j]

哈希表

将元素放入HashMap中，使用元素值作为Key，元素的索引作为Value
查找时当使用target - num[i]为Key的元素存在则返回[HashMap[target - num[i]],num[i]]

时间复杂度 O(n)
空间复杂度 O(n)

使用测试样例测试返回值为[1,0],与给定结果的[0,1]顺序不符，但也能通过。

class Solution:
    def twoSum(self, nums: List[int], target: int) -> List[int]:
        table = dict()
        for i in range(len(nums)):
            n = nums[i]
            tmp = target - n
            if tmp in table:
                return [i, table[tmp]]
            else:
                table[n] = i

Java面试（阿里P6）

2019-09-07T00:38:54.000Z

一面(技术面)

自我介绍和项目

这个因人而异，但自我介绍和项目多说一些简历上没有的。

Java的内存分区

Java程序是交由JVM执行的，所以Java内存区域划分的时候事实上是指JVM区域划分。

执行过程

如图所示，首先Java源代码文件(.java后缀)会被Java编译器编译为字节码文件（.class后缀），然后由JVM中的类加载器加载各个类的字节码文件，加载完毕之后，交由JVM执行引擎执行。在整个程序执行过程中，JVM会用一段空间来存储程序执行期间需要用到的数据和相关信息，这段空间一般被称作Runtime Data Area（运行时数据区）也就是我们常常说的JVM内存。因此，在Java中我们常常说到的内存管理就是针对这段空间进行管理（如何分配和回收内存空间）。

运行时数据区

根据《Java虚拟机规范》的规定，运行时数据区通常包括这几个部分：

Java栈（VM Stack）
本地方法区（Native Method Stack）
程序计数器（Program Counter Register）
方法区（Method Area）
堆（Heap）

如上图所示，JVM运行时数据区包括这五部分，在JVM规范中虽然规定了程序在执行期间运行时数据区应该包括这几部分，但是至于具体如何实现并没有做出规定，不同的虚拟机厂商可以有不同的实现方式。

运行时数据区的每部分存储了那些数据？

程序计数器

程序计数器（Program Counter Regist）也有称作为PC寄存器，在汇编语言中，程序计数器是指CPU中的寄存器，它保存的是程序当前执行的指令地址（也可以说是下一条指令的所在存储单元地址），当CPU需要指令时，需要从程序计数器中得到当前执行的指令所在存储单元地址，然后根据得到的地址获取到指令，在得到指令后，程序计数器便会自动加1或者根据转移指针得到下一条指令的地址，如此循环，直至执行完所有指令。
虽然JVM中的程序计数器并不像汇编语言中的程序计数器一样是物理概念上的CUP寄存器，但是JVM中的程序计数器的功能跟汇编语言中的程序计数器的功能在逻辑上是等同的，也就是说是用来指示执行哪条指令的。
由于在JVM中，多线程是通过线程轮流切换来获得CPU执行时间的，因此，在任一具体时刻，一个CPU的内核只会执行一条线程中的指令，因此，为了能够使得每个线程都在线程切换后能够恢复在切换之前的程序执行位置，每个线程都需要有自己独立的程序计数器，并且不能互相被干扰，否则就会影响到程序的正常执行次序。因此，程序计数器是每个线程所私有的。
在JVM规范中规定，如果线程执行的是非native方法，则程序计数器中保存的是当前需要执行的指令的地址；如果线程执行的是native方法，则程序计数器中的值是undefined。
由于程序计数器中存储的数据所占空间的大小不会随程序的执行而发生改变，因此，对于程序计数器不会发生内存溢出现象(OutOfMemory)。

Java栈

Java栈也称作是虚拟机栈（Java Vitual Machine Stack），也就是我们常常所说的栈，跟c语言的数据段中的栈类似。事实上，Java栈是Java方法执行的内存模型。
Java栈中存放的是一个个栈帧，每个栈帧对应着一个被调用的方法，在栈帧中包括:

局部变量表（Local Variable）
操作数栈（Operaand Stack）
指向当前方法所属的类的运行时常量池的引用（Reference to runtime constant tool）
方法返回地址（Return Address）
一些额外的附加信息

当线程执行一个方法时，就会随之创建一个对应的栈帧，并将建立的栈帧压栈。当方法执行完毕之后，便会将栈帧出栈。因此可知，线程当前执行的方法所对应的栈帧必定位于Java栈的顶部。讲到这里，大家就应该会明白为什么在使用递归方法的时候容易导致栈内存溢出的现象了以及为什么栈区的空间不用程序员去管理了（当然在Java中，程序员基本不用关系到内存分配和释放的事情，因为Java有自己的垃圾回收机制），这部分空间的分配和释放都是由系统自动实施的。对于所有的程序设计语言来说，栈这部分空间对程序员来说是不透明的。下图表示了一个Java栈的模型：

局部变量表，顾名思义，就是用来存储放出方法中的局部变量（包括在方法中申明的非静态变量以及函数形参）。对于基本数据类型的变量，则直接存储他的值，对于应用类型的变量，存的是指向对象的应用。
操作栈帧，想必学过数据结构中的栈的朋友想必对表达式求值问题不会陌生，栈最典型的一个应用就是用来对表达式求值。想想一个线程执行方法的过程中，实际上就是不断执行语句的过程，而归根到底就是进行计算的过程。因此可以这么说，程序中的所有计算过程都是在借助于操作数栈来完成的。
指向运行时常量池的引用，因为在方法执行的过程中有可能需要用到类中的常量，所以必须要有一个引用指向运行时的常量池
方法返回地址，当一个方法执行完毕后，要返回之前调用它的地方，因此在栈帧中必须保存一个方法的返回地址。
虚拟机规范允许具体的虚拟机实现增加一些规范里没有描述的信息到栈帧中，例如与高度相关的信息，这部分信息完全取决于具体的虚拟机实现。在实际开发中，一般会把动态连接，方法返回地址与其它附加信息全部归为一类，称为栈帧信息。

由于每个线程执行正在执行的方法可能不同，因此每个线程都有一个Java栈，互不干扰。

本地方法栈

本地方法栈与Java栈的作用和原理相似，区别只不过是Java栈是为执行Java方法服务的，而本地方法栈则是执行本地方法（Native Method）服务的，在JVM规范中，并没有对本地方法栈的具体实现方法以及数据结构做强制规定，虚拟机可以自由实现它，在HotSpot虚拟机中直接把本地方法栈和Java栈合二为一。

堆

在c语言中，堆这部分空间是唯一一个程序员管理的内存区域，程序员可以通过malloc函数和free函数在堆上申请和释放空间。Java中的堆是用来存储对象本身以及数组（数组引用是放在Java栈中的）。只不过和c语言不通，在Java中，程序员基本不关心空间释放的问题，Java的垃圾回收机制会自动进行处理，因此这部分空间也是Java垃圾收集器管理的主要区域。另外堆是被所有线程池共享的，在JVM中只有一个堆。

方法区

方法区在JVM中也是一个非常重要的区域，它与堆一样，是被线程池共享的区域。在方法区中，存储每个类的信息（包括类的名称、方法信息、字段信息）静态变量、常量以及编译器变异后的的代码等。
在class文件中除了类的字段、方法、接口等描述信息外，还有一项是常量池，用来存储编译期间生成的字面量和符号引用。
在方法区中有一个非常重要的部分就是运行时常量池，它是每一个类或接口的常量池的运行时表示形式，在类和接口被加载到JVM后，对应的常量池就被创建出来。当然并非class文件常量池中的内容才能进入运行时常量池，在运行期间也可将新的常量放入运行时常量池中，比如String的intern方法。

在JVM规范中，没有强制要求方法区必须实现垃圾回收机。

Java对象的回收方式，回收算法

其实问的就是垃圾收集策略与算法
程序计数器、虚拟机栈、本地方法栈随线程而生，也随线程而灭；栈帧随着方法的开始而入栈，随着方法的结束而出栈。这几个区域的内存分配和回收都具有确定性，在这几个区域内不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟随着回收了。
而对于 Java 堆和方法区，我们只有在程序运行期间才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾收集器所关注的正是这部分内存。

判定对象是否存活

若一个对象不被任何对象或变量引用，那么它就是无效对象，需要被回收。

引用计数法

在对象头维护着一个 counter 计数器，对象被引用一次则计数器 +1；若引用失效则计数器 -1。当计数器为 0 时，就认为该对象无效了。

引用计数算法的实现简单，判定效率也很高，在大部分情况下它都是一个不错的算法。但是主流的 Java 虚拟机里没有选用引用计数算法来管理内存，主要是因为它很难解决对象之间循环引用的问题。

e.g. objA 和 objB 都有字段instance表示当前对象对其他对象的引用
objA.instance = objB
objB.instance = objA
由于它们互相引用着对方，导致它们的引用计数都不为 0，于是引用计数算法无法通知 GC 收集器回收它们。

可达性分析法

所有和GC Roots直接或间接关联的对象都是有效对象，和GC Roots没有关联的对象就是无效对象。

GC Roots是指：

Java 虚拟机栈（栈帧中的本地变量表）中引用的对象
本地方法栈中引用的对象
方法区中常量引用的对象
方法区中类静态属性引用的对象

GC Roots 并不包括堆中对象所引用的对象，这样就不会有循环引用的问题。

引用的种类

判定对象是否存活与引用有关。在 JDK 1.2 以前，Java 中的引用定义很传统，一个对象只有被引用或者没有被引用两种状态，我们希望能描述这一类对象：当内存空间还足够时，则保留在内存中；如果内存空间在进行垃圾手收集后还是非常紧张，则可以抛弃这些对象。很多系统的缓存功能都符合这样的应用场景。
在 JDK 1.2 之后，Java 对引用的概念进行了扩充，将引用分为了以下四种。不同的引用类型，主要体现的是对象不同的可达性状态reachable和垃圾收集的影响。

强引用（Strong Reference）

类似 “Object obj = new Object()” 这类的引用，就是强引用，只要强引用存在，垃圾收集器永远不会回收被引用的对象。但是，如果我们错误地保持了强引用，比如：赋值给了 static 变量，那么对象在很长一段时间内不会被回收，会产生内存泄漏。

软引用（Soft Reference）

软引用是一种相对强引用弱化一些的引用，可以让对象豁免一些垃圾收集，只有当 JVM 认为内存不足时，才会去试图回收软引用指向的对象。JVM 会确保在抛出 OutOfMemoryError 之前，清理软引用指向的对象。软引用通常用来实现内存敏感的缓存，如果还有空闲内存，就可以暂时保留缓存，当内存不足时清理掉，这样就保证了使用缓存的同时，不会耗尽内存。

弱引用（Weak Reference）

弱引用的强度比软引用更弱一些。当 JVM 进行垃圾回收时，无论内存是否充足，都会回收只被弱引用关联的对象。

虚引用（Phantom Reference）

虚引用也称幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响。它仅仅是提供了一种确保对象被 finalize 以后，做某些事情的机制，比如，通常用来做所谓的 Post-Mortem 清理机制。

回收堆中无效对象

对于可达性分析中不可达的对象，也并不是没有存活的可能。

判定`finalize()`是否有必要执行

JVM 会判断此对象是否有必要执行 finalize() 方法，如果对象没有覆盖 finalize() 方法，或者 finalize() 方法已经被虚拟机调用过，那么视为“没有必要执行”。那么对象基本上就真的被回收了。

如果对象被判定为有必要执行finalize()方法，那么对象会被放入一个F-Queue队列中，虚拟机会以较低的优先级执行这些finalize()方法，但不会确保所有的finalize()方法都会执行结束。如果finalize()方法出现耗时操作，虚拟机就直接停止指向该方法，将对象清除。

对象重生或死亡

如果在执行finalize()方法时，将this赋给了某一个引用，那么该对象就重生了。如果没有，那么就会被垃圾收集器清除。

任何一个对象的finalize()方法只会被系统**自动**调用一次，如果对象面临下一次回收，它的 finalize() 方法不会被再次执行，想继续在finalize()中自救就失效了。

回收方法区内存

方法区中存放生命周期较长的类信息、常量、静态变量，每次垃圾收集只有少量的垃圾被清除。方法区中主要清除两种垃圾：

废弃常量
无用的类

判定废弃常量

只要常量池中的常量不被任何变量或对象引用，那么这些常量就会被清除掉。比如，一个字符串"bingo"进入了常量池，但是当前系统没有任何一个String 对象引用常量池中的"bingo"常量，也没有其它地方引用这个字面量，必要的话，"bingo"常量会被清理出常量池。

判定无用的类

判定一个类是否是“无用的类”，条件较为苛刻。

该类的所有对象都已经被清除
加载该类的 ClassLoader 已经被回收
该类的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

一个类被虚拟机加载进方法区，那么在堆中就会有一个代表该类的对象：java.lang.Class。这个对象在类被加载进方法区时创建，在方法区该类被删除时清除。

垃圾收集算法

学会了如何判定无效对象、无用类、废弃常量之后，剩余工作就是回收这些垃圾。常见的垃圾收集算法有以下几个：

标记-清除算法

标记的过程是：遍历所有的 GC Roots，然后将所有 GC Roots 可达的对象标记为存活的对象。
清除的过程将遍历堆中所有的对象，将没有标记的对象全部清除掉。与此同时，清除那些被标记过的对象的标记，以便下次的垃圾回收。

这种方法有两个不足：

效率问题：标记和清除两个过程的效率都不高。
空间问题：标记清除之后会产生大量不连续的内存碎片，碎片太多可能导致以后需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

复制算法（新生代）

为了解决效率问题，“复制”收集算法出现了。它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块内存用完，需要进行垃圾收集时，就将存活者的对象复制到另一块上面，然后将第一块内存全部清除。这种算法有优有劣：

优点：不会有内存碎片的问题。
缺点：内存缩小为原来的一半，浪费空间。

为了解决空间利用率问题，可以将内存分为三块： Eden、From Survivor、To Survivor，比例是 8:1:1，每次使用 Eden 和其中一块 Survivor。回收时，将 Eden 和 Survivor 中还存活的对象一次性复制到另外一块 Survivor 空间上，最后清理掉 Eden 和刚才使用的 Survivor 空间。这样只有 10% 的内存被浪费。

但是我们无法保证每次回收都只有不多于 10% 的对象存活，当 Survivor 空间不够，需要依赖其他内存（指老年代）进行分配担保。

分配担保

为对象分配内存空间时，如果 Eden+Survivor 中空闲区域无法装下该对象，会触发 MinorGC 进行垃圾收集。但如果 Minor GC 过后依然有超过 10% 的对象存活，这样存活的对象直接通过分配担保机制进入老年代，然后再将新对象存入Eden区。

标记-整理算法（老年代）

标记：它的第一个阶段与标记/清除算法是一模一样的，均是遍历 GC Roots，然后将存活的对象标记。
整理：移动所有存活的对象，且按照内存地址次序依次排列，然后将末端内存地址以后的内存全部回收。因此，第二阶段才称为整理阶段。

这是一种老年代的垃圾收集算法。老年代的对象一般寿命比较长，因此每次垃圾回收会有大量对象存活，如果采用复制算法，每次需要复制大量存活的对象，效率很低。

分代收集算法

根据对象存活周期的不同，将内存划分为几块。一般是把 Java 堆分为新生代和老年代，针对各个年代的特点采用最适当的收集算法。

新生代：复制算法
老年代：标记-清除算法、标记-整理算法

CMS和G1了解么，CMS解决什么问题，说一下回收的过程。

这个就分别说一下CMS(Concurrent Mark-Sweep)和G1吧~

Permanent Generation在JDK1.8之后被元空间(Metaspace)替代
幸存者区（Survivor Space）的S0与S1分别叫做From与To**(没有先后对应关系，向下看)**。
在GC开始的时候，对象只会存在于Eden区和Survivor区的From，Survivor区的To是空的。
紧接着进行GC，Eden区中所有存活的对象都会被复制到To，而在From中，仍存活的对象会根据他们的年龄值来决定去向。年龄达到一定值(年龄阈值，可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到老年代中，没有达到阈值的对象会被复制到To。
经过这次GC后，Eden区和From已经被清空。这个时候，From和To会交换他们的角色，也就是新的To就是上次GC前的From，新的From就是上次GC前的To。不管怎样，都会保证Survivor区的To的是空的。Minor GC会一直重复这样的过程，直到To被填满，To被填满之后，会将所有对象移动到老年代中。

CMS

CMS(Concurrent Mark-Sweep)是以牺牲吞吐量为代价来获得最短回收停顿时间的垃圾回收器。对于要求服务器响应速度的应用上，这种垃圾回收器非常适合。在启动JVM参数加上-XX:+UseConcMarkSweepGC，这个参数表示对于老年代的回收采用CMS。CMS采用的基础算法是：标记—清除。

CMS过程

初始标记(STW initial mark) ：在这个阶段，需要虚拟机停顿正在执行的任务，官方的叫法STW(Stop The Word)。这个过程从垃圾回收的”根对象”开始，只扫描到能够和”根对象”直接关联的对象，并作标记。所以这个过程虽然暂停了整个JVM，但是很快就完成了。
并发标记(Concurrent marking) ：这个阶段紧随初始标记阶段，在初始标记的基础上继续向下追溯标记。并发标记阶段，应用程序的线程和并发标记的线程并发执行，所以用户不会感受到停顿。
并发预清理(Concurrent precleaning) ：并发预清理阶段仍然是并发的。在这个阶段，虚拟机查找在执行并发标记阶段新进入老年代的对象(可能会有一些对象从新生代晋升到老年代，或者有一些对象被分配到老年代)。通过重新扫描，减少下一个阶段”重新标记”的工作，因为下一个阶段会Stop The World。
重新标记(STW remark) ：这个阶段会暂停虚拟机，收集器线程扫描在CMS堆中剩余的对象。扫描从”跟对象”开始向下追溯，并处理对象关联。
并发清理(Concurrent sweeping) ：清理垃圾对象，这个阶段收集器线程和应用程序线程并发执行。
并发重置(Concurrent reset) ：这个阶段，重置CMS收集器的数据结构，等待下一次垃圾回收。

CMS缺点

CMS回收器采用的基础算法是Mark-Sweep。所有CMS不会整理、压缩堆空间。这样就会有一个问题：经过CMS收集的堆会产生空间碎片。 CMS不对堆空间整理压缩节约了垃圾回收的停顿时间，但也带来的堆空间的浪费。为了解决堆空间浪费问题，CMS回收器不再采用简单的指针指向一块可用堆空间来为下次对象分配使用。而是把一些未分配的空间汇总成一个列表，当JVM分配对象空间的时候，会搜索这个列表找到足够大的空间来hold住这个对象。
需要更多的CPU资源。从上面的图可以看到，为了让应用程序不停顿，CMS线程和应用程序线程并发执行，这样就需要有更多的CPU，单纯靠线程切换是不靠谱的。并且，重新标记阶段，为空保证STW快速完成，也要用到更多的甚至所有的CPU资源。当然，多核多CPU也是未来的趋势！
CMS的另一个缺点是它需要更大的堆空间。因为CMS标记阶段应用程序的线程还是在执行的，那么就会有堆空间继续分配的情况，为了保证在CMS回收完堆之前还有空间分配给正在运行的应用程序，必须预留一部分空间。也就是说，CMS不会在老年代满的时候才开始收集。相反，它会尝试更早的开始收集，已避免上面提到的情况：在回收完成之前，堆没有足够空间分配！默认当老年代使用68%的时候，CMS就开始行动了。 –XX:CMSInitiatingOccupancyFraction =n 来设置这个阀值。

总得来说，CMS回收器减少了回收的停顿时间，但是降低了堆空间的利用率。

CMS的适用场景

虽然说了CMS的诸多缺点，但是他还是有自己的适用场景的，并且目前国内很多公司仍然使用者CMS算法，学习他也还是有必要的。

如果你的应用程序对停顿比较敏感，并且在应用程序运行的时候可以提供更大的内存和更多的CPU(也就是硬件配置较高)，那么使用CMS来收集会给你带来好处。
如果在JVM中，有相对较多存活时间较长的对象(老年代比较大)会更适合使用CMS。

G1

在G1中，堆被划分成许多个连续的区域(region)。每个区域大小相等，在1M~32M之间。JVM最多支持2000个区域，可推算G1能支持的最大内存为2000*32M=62.5G。区域(region)的大小在JVM初始化的时候决定，也可以用-XX:G1HeapReginSize设置。
在G1中没有物理上的Yong(Eden/Survivor)/Old Generation，它们是逻辑的，使用一些非连续的区域(Region)组成的。

G1 是一款面向服务端应用的垃圾收集器，它没有新生代和老年代的概念，而是将堆划分为一块块独立的 Region。当要进行垃圾收集时，首先估计每个 Region 中垃圾的数量，每次都从垃圾回收价值最大的 Region 开始回收，因此可以获得最大的回收效率。
从整体上看， G1 是基于标记-整理算法实现的收集器，从局部（两个 Region 之间）上看是基于复制算法实现的，这意味着运行期间不会产生内存空间碎片。

Q:一个对象和它内部所引用的对象可能不在同一个 Region 中，那么当垃圾回收时，是否需要扫描整个堆内存才能完整地进行一次可达性分析？
A:并不！每个 Region 都有一个 Remembered Set，用于记录本区域中所有对象引用的对象所在的区域，进行可达性分析时，只要在 GC Roots 中再加上 Remembered Set 即可防止对整个堆内存进行遍历。

G1过程

如果不计算维护 Remembered Set 的操作，G1 收集器的工作过程分为以下几个步骤：

初始标记：Stop The World，仅使用一条初始标记线程对所有与 GC Roots 直接关联的对象进行标记。
并发标记：使用一条标记线程与用户线程并发执行。此过程进行可达性分析，速度很慢。
最终标记：Stop The World，使用多条标记线程并发执行。
筛选回收：回收废弃对象，此时也要 Stop The World，并使用多条筛选回收线程并发执行。

CMS回收停顿了几次？为什么停顿？

首先CMS回收停顿了两次。一次是initial mark阶段，一次是remark阶段。具体请参考上一个问题CMS过程。

Java栈什么时候会发生内存溢出，Java堆呢，说一种场景

这里就把常见的都说一说。

Java栈溢出(StackOverflowError)

看下面这段代码

public class StackOverFlowTest{     
    public void stackOverFlowMethod(){    
        stackOverFlowMethod();/* 导致栈溢出的就是这句 */
    }    
    public static void main(String[] args){    
        OOMTest oom = new OOMTest();    
        oom.stackOverFlowMethod();    
    }    
}

堆溢出(OutOfMemoryError:java heap space)

堆内存溢出的时候，虚拟机会抛出java.lang.OutOfMemoryError:java heap space,出现此种情况的时候，我们需要根据内存溢出的时候产生的dump文件来具体分析（需要增加-XX:+HeapDumpOnOutOfMemoryErrorjvm启动参数）。出现此种问题的时候有可能是内存泄露，也有可能是内存溢出了。

如果内存泄露，我们要找出泄露的对象是怎么被GC ROOT引用起来，然后通过引用链来具体分析泄露的原因。
如果出现了内存溢出问题，这往往是程序本生需要的内存大于了我们给虚拟机配置的内存，这种情况下，我们可以采用调大-Xmx来解决这种问题。

内存溢出代码示例

public class OOMTest{    
        public static void main(String[] args){    
                List<byte[]> buffer = new ArrayList<byte[]>();    
                buffer.add(new byte[10*1024*1024]);    
        }    

}

通过如下命令启动

1
2
3


java -verbose:gc -Xmn10M -Xms20M -Xmx20M -XX:+PrintGC OOMTest

控制台会有如下输出


[GC 1180K->366K(19456K), 0.0037311 secs]    
[Full GC 366K->330K(19456K), 0.0098740 secs]    
[Full GC 330K->292K(19456K), 0.0090244 secs]    
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space    
        at OOMTest.main(OOMTest.java:7)

从运行结果可以看出，JVM进行了一次Minor gc和两次的Major gc，从Major gc的输出可以看出，gc以后old区使用率为134K，而字节数组为10M，加起来大于了old generation的空间，所以抛出了异常，如果调整-Xms21M,-Xmx21M,那么就不会触发gc操作也不会出现异常了。

从侧面验证了一个结论：当对象大于新生代剩余内存的时候，将直接放入老年代，当老年代剩余内存还是无法放下的时候，触发垃圾收集，收集后还是不能放下就会抛出内存溢出异常了。

持久带溢出(OutOfMemoryError: PermGen space)

我们知道Hotspot jvm通过持久带实现了Java虚拟机规范中的方法区，而运行时的常量池就是保存在方法区中的，因此持久带溢出有可能是运行时常量池溢出，也有可能是方法区中保存的class对象没有被及时回收掉或者class信息占用的内存超过了我们配置。
当持久带溢出的时候抛出java.lang.OutOfMemoryError: PermGen space。

使用一些应用服务器的热部署的时候，我们就会遇到热部署几次以后发现内存溢出了，这种情况就是因为每次热部署的后，原来的Class没有被卸载掉。
如果应用程序本身比较大，涉及的类库比较多，但是我们分配给持久带的内存（通过-XX:PermSize和-XX:MaxPermSize来设置）比较小的时候也可能出现此种问题。
一些第三方框架，比如spring,hibernate都通过字节码生成技术（比如CGLib）来实现一些增强的功能，这种情况可能需要更大的方法区来存储动态生成的Class文件。

我们知道Java中字符串常量是放在常量池中的，String.intern()这个方法运行的时候，会检查常量池中是否存和本字符串相等的对象，如果存在直接返回对常量池中对象的引用，不存在的话，先把此字符串加入常量池，然后再返回字符串的引用。那么我们就可以通过String.intern()方法来模拟一下运行时常量区的溢出。

代码如下：

public class OOMTest{    
        public static void main(String... args){    
                List list = new ArrayList();    
                while(true){    
                        list.add(UUID.randomUUID().toString().intern());    
                }    
        }        
}

通过如下命令启动

1
2
3


java -verbose:gc -Xmn5M -Xms10M -Xmx10M -XX:MaxPermSize=1M -XX:+PrintGC OOMTest

控制台会有如下输出


Exception in thread "main" java.lang.OutOfMemoryError: PermGen space    
        at java.lang.String.intern(Native Method)    
        at OOMTest.main(OOMTest.java:8)

OutOfMemoryError:unable to create native thread

最后我们在来看看java.lang.OutOfMemoryError:unable to create natvie thread这种错误。出现这种情况的时候，一般是下面两种情况导致的：

程序创建的线程数超过了操作系统的限制。对于Linux系统，我们可以通过ulimit -u来查看此限制。
给虚拟机分配的内存过大，导致创建线程的时候需要的native内存太少。

操作系统对每个进程的内存是有限制的，我们启动Jvm,相当于启动了一个进程，假如我们一个进程占用了4G的内存，那么通过下面的公式计算出来的剩余内存就是建立线程栈的时候可以用的内存。
线程栈总可用内存 = 4G - (-Xmx的值) - (-XX:MaxPermSize的值) - 程序计数器占用的内存
通过上面的公式我们可以看出，-Xmx 和 MaxPermSize 的值越大，那么留给线程栈可用的空间就越小，在-Xss参数配置的栈容量不变的情况下，可以创建的线程数也就越小。因此如果是因为这种情况导致的unable to create native thread,那么要么我们增大进程所占用的总内存，或者减少-Xmx或者-Xss来达到创建更多线程的目的。

面试者的回答

这一题面试者在面试的时候回答了集合类持有对象:如果对象的引用刚好被单例所持有的话，JVM就不会回收该引用。解决方案最简单只需要将单例中持有对象的变量使用static修饰，并在初始化时置为null。

`软引用`和`弱引用`的区别

这个问题引申自上一个问题
Q:集合类如何解决OOM问题
A:用软引用和弱引用。
四种引用的定义参考问题Java对象的回收方式，回收算法下的引用种类

在应用程序中，我们使用引用类可以边面在程序执行期间将对象留在内存中。如果我们一软引用，弱引用或虚引用的方式引用对象，这样垃圾收集器就能够随意的释放对象。如果希望尽可能的减少程序在其生命周期中所占的内存大小时，这些引用类就很有好处。
必须指出的一个问题:要使用这些特殊的引用类，就不能保留对对象的强引用。如果保留了对对象的强引用，那么就会浪费这些类所提供的任何好处。
四种引用最主要的区别就是垃圾回收器回收的时机不同：
1. 强引用: 我们经常使用的一种引用。基本上垃圾回收器不会主动的去回收
2. 弱引用: 垃圾回收器会立刻回收弱引用。
3. 软引用: 在JVM没有出现内存不足的情况下，垃圾回收器不会去主动回收软引用
4. 虚引用: 虚引用引用的字符串会被垃圾回收器回收，自己本身会被添加到关联的引用队列中去。

Java里的锁了解哪些

面试者说了Lock和synchronized

并发关键字

volatile短见字

可以这样说，volatile 关键字是 Java 虚拟机提供的轻量级的同步机制。

功能

volatile 有 2 个主要功能：

可见性。一个线程对共享变量的修改，其他线程能够立即得知这个修改。普通变量不能做到这一点，普通变量的值在线程间传递需要通过主内存来完成。
禁止指令重排序。

底层原理

加入 volatile 关键字时，会多出 lock 前缀指令，该 lock 前缀指令相当于内存屏障，内存屏障会提供 3 个功能：

在执行到内存屏障这句指令时，在其前面的操作都已完成了
强制将处理器行的数据缓存写回内存
一个处理器的缓存回写到内存会导致其他工作内存中的缓存失效

应用场景

状态标记
volatile + boolean

DCL 单例模式（Double Check Lock，双重校验锁）

public class Singleton {

    private volatile static Singleton singleton=null;

    private Singleton(){}

    public static Singleton getSingleton(){
        if(singleton==null){
            synchronized (Singleton.class){
                if(singleton==null){
                    singleton=new Singleton();
                }
            }
        }
        return singleton;
    }
}

synchronized关键字

线程安全问题:

存在共享数据（临界资源）
存在多条线程共同操作这些共享数据

解决：同步机制。

同一时刻有且只有一个线程在操作共享数据，其他线程必须等到该线程处理完数据后再对共享数据进行操作。

同步的前提：

多个线程
多个线程使用的是同一个锁对象

同步的弊端：

当线程相当多时，因为每个线程都会去判断同步上的锁，这是很耗费资源的，无形中会降低程序的运行效率。

功能

使用 synchroinzed 进行同步，可以保证原子性（保证每个时刻只有一个线程执行同步代码）和可见性（对一个变量执行 unlock 操作之前，必须把变量值同步回主内存）。

使用

synchronized 修饰的对象有几种：

修饰一个类。

作用范围是 synchronized 后面括号括起来的部分

作用对象是这个类的所有对象

class ClassName {
   public void method() {
      synchronized(ClassName.class) {
         // todo
      }
   }
}

修饰一个方法：被修饰的方法称为同步方法。
作用范围是整个方法
作用对象是调用这个方法的对象
1
2
3
4
public synchronized void method(){
// todo
}
修饰一个静态的方法。
作用的范围是整个方法
作用对象是这个类的所有对象
1
2
3
4
public synchronized static void method() {
// todo
}
修饰一个代码块：被修饰的代码块称为同步语句块
作用范围是大括号 {} 括起来的代码块
作用对象是调用这个代码块的对象

注意：如果锁的是类对象的话，尽管new多个实例对象，但他们仍然是属于同一个类依然会被锁住，即线程之间保证同步关系。

原理

public class SynchronizedDemo {
    public static void main(String[] args) {
        synchronized (SynchronizedDemo.class) { //锁住类对象
        }
        method();
    }

    private synchronized static void method() { //锁住类对象
    }
}

任意一个对象都拥有自己的Monitor，当这个对象由同步块或者同步方法调用时，执行方法的线程必须先获取该对象的Monitor才能进入同步块和同步方法，如果没有获取到Monitor的线程将会被阻塞在同步块和同步方法的入口处，进入到BLOCKED状态。

synchronized同步语句块的实现使用的是monitorenter和monitorexit指令。

monitorenter 指令指向同步代码块的开始位置，monitorexit 指令则指明同步代码块的结束位置。

使用synchronized进行同步，其关键就是必须要对对象的Monitor进行获取，当线程获取Monitor后才能继续往下执行，否则就只能等待。而这个获取的过程是互斥的，即同一时刻只有一个线程能够获取到 Monitor。

上面的SynchronizedDemo中在执行完同步代码块之后紧接着再会去执行一个静态同步方法，而这个方法锁的对象依然就这个类对象，那么这个正在执行的线程还需要获取该锁吗？

答案是不必的，从上图中就可以看出来，执行静态同步方法的时候就只有一条monitorexit指令，并没有monitorenter获取锁的指令。这就是锁的重入性，即在同一线程中，线程不需要再次获取同一把锁。 synchronized先天具有重入性。每个对象拥有一个计数器，当线程获取该对象锁后，计数器就会+1，释放锁后就会将计数器-1。

synchronized修饰的方法并没有monitorenter指令和monitorexit指令，取得代之的是 ACC_SYNCHRONIZED 标识，该标识指明了该方法是一个同步方法，JVM 通过该 ACC_SYNCHRONIZED 访问标志来辨别一个方法是否声明为同步方法，从而执行相应的同步调用。

锁优化策略

JDK 1.6 之后对synchronized进行优化。

锁的 4 种状态：

无锁
偏向锁
轻量级锁
重量级锁

自旋锁

在很多应用上，共享数据的锁定状态只会持续很短一段时间。自旋锁的思想是让一个线程在请求一个共享数据的锁时执行忙循环（自旋）一段时间，如果在这段时间内能获得锁，就可以避免进入阻塞状态。

自旋锁虽然能避免进入阻塞状态从而减少开销，但是它需要进行忙循环操作占用 CPU 时间，它只适用于共享数据的锁定状态很短的场景。

在 JDK 1.6 中引入了自适应的自旋锁。自适应意味着自旋的次数不再固定了，而是由前一次在同一个锁上的自旋次数及锁的拥有者的状态来决定。

锁消除

锁消除是指对于被检测出不可能存在竞争的共享数据的锁进行消除。

锁消除主要是通过逃逸分析来支持，如果堆上的共享数据不可能逃逸出去被其它线程访问到，那么就可以把它们当成私有数据对待，也就可以将它们的锁进行消除。

对于一些看起来没有加锁的代码，其实隐式的加了很多锁。例如下面的字符串拼接代码就隐式加了锁：

public static String concatString(String s1, String s2, String s3) {
    return s1 + s2 + s3;
}

String是一个不可变的类，编译器会对String的拼接自动优化。在JDK 1.5之前，会转化为 StringBuffer对象的连续append()操作：

public static String concatString(String s1, String s2, String s3) {
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    sb.append(s3);
    return sb.toString();
}

每个append()方法中都有一个同步块。虚拟机观察变量sb，很快就会发现它的动态作用域被限制在concatString()方法内部。也就是说，sb的所有引用永远不会逃逸到concatString()方法之外，其他线程无法访问到它，因此可以进行消除。

锁粗化

如果一系列的连续操作都对同一个对象反复加锁和解锁，频繁的加锁操作就会导致性能损耗。

上一节的示例代码中连续的append()方法就属于这类情况。如果虚拟机探测到由这样的一串零碎的操作都对同一个对象加锁，将会把加锁的范围扩展（粗化）到整个操作序列的外部。对于上一节的示例代码就是扩展到第一个 append()操作之前直至最后一个append()操作之后，这样只需要加锁一次就可以了。

偏向锁

在大多数情况下，锁不仅不存在多线程竞争，而且总是由同一个线程多次获得。偏向锁的思想是偏向于第一个获取锁对象的线程，这个线程在之后获取该锁就不再需要进行同步操作，甚至连CAS操作也不再需要。

轻量级锁

轻量级锁是由偏向锁升级而来，偏向锁运行在一个线程进入同步块的情况下，当第二个线程加入锁争用的时候，偏向锁就会升级为轻量级锁。

对于绝大部分的锁，在整个同步周期内都是不存在竞争的，因此也就不需要都使用互斥量进行同步，可以先采用CAS操作进行同步，如果CAS失败了再改用互斥量进行同步。

volatile 与 synchronized 比较

volatile 是 JVM 轻量级的同步机制，所以性能比 synchronized 要好
volatile 只能修饰变量
synchronized 可以修饰代码块或者方法
多线程访问 volatile 不会出现阻塞
synchronized 会出现阻塞
volatile 只能保证可见性，不能保证原子性
synchroinzed 能保证原子性，也间接保证了可见性
volatile 修饰的变量不会被编译器优化
synchronized 修饰的变量可以被编译器优化

Lock 体系

Condition 条件对象

条件对象是线程同步对象中的一种，主要用来等待某种条件的发生，条件发生后，可以唤醒等待在该条件上的一个线程或者所有线程。

条件对象要与锁一起协同工作。通过ReentrantLock的newCondtion获取实例对象。

1
2
3

ReentrantLock lock = new ReentrantLock();
Condition condition = lock.newCondition();

注意：

Condition 中有await、signal、signalAll ，分别对应 Object 中放入 wait、notify、notifyAll 方法，其实 Condition 也有上述三种方法，改变方法名称是为了避免使用上语义的混淆。
await 和 signal / signalAll 方法就像一个开关控制着线程 A（等待方）和线程 B（通知方）。
线程 awaitThread 先通过 lock.lock() 方法获取锁成功后调用了 condition.await() 方法进入等待队列，
另一个线程 signalThread 通过 lock.lock() 方法获取锁成功后调用了 condition.signal / signalAll，使得线程 awaitThread 能够有机会移入到同步队列中，当其他线程释放 Lock 后使得线程 awaitThread 能够有机会获取 Lock，从而使得线程 awaitThread 能够从 await 方法中退出，然后执行后续操作。如果 awaitThread 获取 Lock 失败会直接进入到同步队列。
一个 Lock 可以与多个 Condition 对象绑定。

AQS

AQS(AbtsractQueueSynchronized) 即同步队列器。

AQS 是一个抽象类，本身并没有实现任何同步接口的，只是通过提供同步状态的获取和释放来供自定义的同步组件使用。

AQS 的实现依赖内部的双向队列（底层是双向链表）。

如果当前线程获取同步状态失败，则会将该线程以及等待状态等信息封装为 Node，将其加入同步队列的尾部，同时阻塞当前线程，当同步状态释放时，唤醒队列的头结点。

private transient volatile Node head; //同步队列的头结点
private transient volatile Node tail; //同步队列的尾结点
private volatile int state; //同步状态。
// state=0,表示同步状态可用；state=1，表示同步状态已被占用

可重入

某个线程试图获取一个已经有该线程持有的锁，那么这个请求就会成功。“重入”意味着获取的锁的操作的粒度是“线程”而不是“调用”。重入的一种实现方法是，为每个锁关联一个计数器（方便解锁）和一个所有者线程（知道是哪个线程是可重入的）。

公平锁与非公平锁

公平锁是指多个线程在等待同一个锁时，按照申请锁的顺序来依次获取锁。

公平锁	非公平锁
公平锁每次获取到锁为同步队列中的第一个节点，保证请求资源时间上的绝对顺序	非公平锁有可能刚释放锁的线程下次继续获取该锁，则有可能导致其他线程永远无法获取到锁，造成“饥饿”现象。
公平锁为了保证时间上的绝对顺序，需要频繁的上下文切换	非公平锁会降低一定的上下文切换，降低性能开销因此，ReentrantLock 默认选择的是非公平锁

独占锁和共享锁

独占锁模式下，每次只能有一个线程能持有锁，ReentrantLock 就是以独占方式实现的互斥锁。

共享锁，则允许多个线程同时获取锁，并发访问共享资源，如：ReadWriteLock。

很显然，独占锁是一种悲观保守的加锁策略，它避免了读/读冲突，如果某个只读线程获取锁，则其他读线程都只能等待，这种情况下就限制了不必要的并发性，因为读操作并不会影响数据的一致性。

共享锁则是一种乐观锁，它放宽了加锁策略，允许多个执行读操作的线程同时访问共享资源。

ReentrantLock

ReentrantLock 即可重入锁，有 3 个内部类：Sync、FairSync 和 NonfairSync。

abstract static class Sync extends AbstractQueuedSynchronizer {
    //...
}

static final class FairSync extends Sync {
    //...
}

static final class NonfairSync extends Sync {
    //...
}

Sync 是一个继承 AQS 的抽象类，并发控制就是通过 Sync 实现的。
重写了 tryRelease() , 有两个子类 FiarSync 和 NonfairSync，即公平锁和非公平锁。
由于 Sync 重写 tryRealese() 方法，并且 FairSync 和 NonfairSync没有再次重写该方法，所以 公平锁和非公平锁释放锁的操作是一样的，即唤醒等待队列中第一个被挂起的线程。
公平锁和非公平锁获取锁的方式是不同的。
公平锁获取锁时，如果一个线程已经获取了锁，其他线程都会被挂起进入等待队列，后面来的线程等待的时间没有等待队列中线程等待的时间长的话，那么就会放弃获取锁，直接进入等待队列；
非公平锁获取锁的方式是一种抢占式的，不考虑线程等待时间，无论是哪个线程获取了锁，则其他线程就进入等待队列。

private final Sync sync;

public ReentrantLock() { //默认是非公平锁
    sync = new NonfairSync();
}

public ReentrantLock(boolean fair) { //可设置为公平锁
    sync = fair ? new FairSync() : new NonfairSync();
}

ReentrantLock 与 synchronized 的区别

锁的实现：
synchronized 是 JVM 实现的，ReentrantLock 是 JDK 实现的。
性能：
JDK1.6 后对 synchronized 进行了很多优化，两者的性能大致相同。
等待可中断：
当持有锁的线程长期未释放锁时，正在等待的线程可选择放弃等待，改为处理其他事情。
ReentrantLock 是等待可中断的，synchronized 则不行。
公平锁：
公平锁是指多个线程在等待同一个锁时，按照申请锁的顺序来依次获取锁。
synchronized 默认是非公平锁，ReentrantLock 既可以是公平锁，又可以是非公平锁。
锁绑定多个条件：
一个 ReentrantLock 可以绑定多个 Condition 对象。

LockSupport

LockSupport 位于 java.util.concurrent.locks 包下。 LockSupprot 是线程的阻塞原语，用来阻塞线程和唤醒线程。

每个使用 LockSupport 的线程都会与一个许可关联，

如果该许可可用，并且可在线程中使用，则调用 park() 将会立即返回，否则可能阻塞。

如果许可尚不可用，则可以调用 unpark 使其可用。

但是注意许可不可重入，也就是说只能调用一次 park() 方法，否则会一直阻塞。

LockSupport 中方法

方法	说明
void park()	阻塞当前线程，如果调用 unpark() 方法或者当前线程被中断，能从 park()方法中返回
void park(Object blocker)	功能同park()，入参增加一个Object对象，用来记录导致线程阻塞的阻塞对象，方便进行问题排查
void parkNanos(long nanos)	阻塞当前线程，最长不超过nanos纳秒，增加了超时返回的特性
void parkNanos(Object blocker, long nanos)	功能同 parkNanos(long nanos)，入参增加一个 Object 对象，用来记录导致线程阻塞的阻塞对象，方便进行问题排查
void parkUntil(long deadline)	阻塞当前线程，deadline 已知
void parkUntil(Object blocker, long deadline)	功能同 parkUntil(long deadline)，入参增加一个 Object 对象，用来记录导致线程阻塞的阻塞对象，方便进行问题排查
void unpark(Thread thread)	唤醒处于阻塞状态的指定线程

实际上 LockSupport 阻塞和唤醒线程的功能是依赖于 sun.misc.Unsafe，比如 park() 方法的功能实现则是靠unsafe.park() 方法。另外在阻塞线程这一系列方法中还有一个很有意思的现象：每个方法都会新增一个带有Object 的阻塞对象的重载方法。那么增加了一个 Object 对象的入参会有什么不同的地方了？

调用 park() 方法 dump 线程：


"main" #1 prio=5 os_prio=0 tid=0x02cdcc00 nid=0x2b48 waiting on condition [0x00d6f000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
        at learn.LockSupportDemo.main(LockSupportDemo.java:7)

调用 park(Object blocker) 方法 dump 线程:

"main" #1 prio=5 os_prio=0 tid=0x0069cc00 nid=0x6c0 waiting on condition [0x00dcf000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x048c2d18> (a java.lang.String)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at learn.LockSupportDemo.main(LockSupportDemo.java:7)

通过分别调用这两个方法然后 dump 线程信息可以看出，带 Object 的 park 方法相较于无参的 park 方法会增加

1 2	- parking to wait for <0x048c2d18> (a java.lang.String)

这种信息就类似于记录案发现场，有助于工程人员能够迅速发现问题解决问题。

注意：

synchronized 使线程阻塞，线程会进入到 BLOCKED 状态
调用 LockSupprt 方法阻塞线程会使线程进入到 WAITING 状态

LockSupport 使用示例

import java.util.concurrent.locks.LockSupport;

public class LockSupportExample {
    public static void main(String[] args) {
        Thread t1 = new Thread(() -> {
            LockSupport.park();
            System.out.println(Thread.currentThread().getName() + "被唤醒");
        });
        Thread t2 = new Thread(() -> {
            LockSupport.park();
            System.out.println(Thread.currentThread().getName() + "被唤醒");
        });
        t1.start();
        t2.start();
        try {
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        LockSupport.unpark(t1);
        LockSupport.unpark(t2);
    }
}

1
2
3

Thread-0被唤醒
Thread-1被唤醒

t1 线程调用LockSupport.park()使t1阻塞，当mian线程睡眠3秒结束后通过 LockSupport.unpark(t1)方法唤醒t1 线程,t1 线程被唤醒执行后续操作。另外，还有一点值得关注的是，LockSupport.unpark(t1)可以通过指定线程对象唤醒指定的线程。

它们(Lock和synchronized)的使用方式和实现原理有什么区别呢？

详见上一问的回答，已经解释的很详细了；

synchronized锁升级的过程

面试者的回答：偏向锁到轻量级锁再到重量级锁
Q:它们分别是怎么实现的，解决的是哪些问题，什么时候会发生锁升级？

在 jdk6 之后便引入了偏向锁和轻量级锁，所以总共有4种锁状态，级别由低到高依次为：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态。这几个状态会随着竞争情况逐渐升级。

注意：锁可以升级但不能降级。

在使用synchronized来同步代码块的时候，经编译后，会在代码块的起始位置插入monitorenter指令，在结束或异常处插入monitorexit指令。当执行到monitorenter指令时，将会尝试获取对象所对应的monitor的所有权，即尝试获得对象的锁。而synchronized用的锁是存放在Java对象头中的。

Java 对象头和 Monitor

Java 对象头

以 Hotspot 虚拟机为例，Hotspot 的对象头主要包括两部分数据：Mark Word（标记字段）、Klass Pointer（类型指针）。

Mark Word：默认存储对象的 HashCode，分代年龄和锁标志位信息。这些信息都是与对象自身定义无关的数据，所以 Mark Word 被设计成一个非固定的数据结构以便在极小的空间内存存储尽量多的数据。它会根据对象的状态复用自己的存储空间，也就是说在运行期间 Mark Word 里存储的数据会随着锁标志位的变化而变化。
Klass Point：对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。

Monitor

Monitor 可以理解为一个同步工具或一种同步机制，通常被描述为一个对象。每一个 Java 对象就有一把看不见的锁，称为内部锁或者 Monitor 锁。
Monitor 是线程私有的数据结构，每一个线程都有一个可用monitor record列表，同时还有一个全局的可用列表。每一个被锁住的对象都会和一个monitor关联，同时monitor中有一个Owner字段存放拥有该锁的线程的唯一标识，表示该锁被这个线程占用。

偏向锁

偏向锁的获取和撤销逻辑

首先获取锁对象的Markword，判断是否处于可偏向状态。(biased_lock=1、且 ThreadId 为空)
如果是可偏向状态，则通过CAS操作，把当前线程的ID写入到MarkWord
1. 如果cas成功，那么 markword 就会变成这样。表示已经获得了锁对象的偏向锁，接着执行同步代码块
2. 如果cas失败，说明有其他线程已经获得了偏向锁，这种情况说明当前锁存在竞争，需要撤销已获得偏向锁的线程，并且把它持有的锁升级为轻量级锁（这个操作需要等到全局安全点，也就是没有线程在执行字节码）才能执行
如果是已偏向状态，需要检查 markword 中存储的 ThreadID 是否等于当前线程的 ThreadID a) 如果相等，不需要再次获得锁，可直接执行同步代码块 b) 如果不相等，说明当前锁偏向于其他线程，需要撤销偏向锁并升级到轻量级锁

偏向锁的撤销

偏向锁的撤销并不是把对象恢复到无锁可偏向状态（因为偏向锁并不存在锁释放的概念），而是在获取偏向锁的过程中，发现cas失败也就是存在线程竞争时，直接把被偏向的锁对象升级到被加了轻量级锁的状态。

对原持有偏向锁的线程进行撤销时，原获得偏向锁的线程有两种情况：

原获得偏向锁的线程如果已经退出了临界区，也就是同步代码块执行完了，那么这个时候会把对象头设置成无锁状态并且争抢锁的线程可以基于 CAS 重新偏向当前线程。
如果原获得偏向锁的线程的同步代码块还没执行完，处于临界区之内，这个时候会把原获得偏向锁的线程升级为轻量级锁后继续执行同步代码块。

在我们的应用开发中，绝大部分情况下一定会存在2个以上的线程竞争，那么如果开启偏向锁，反而会提升获取锁的资源消耗。所以可以通过jvm参数UseBiasedLocking来设置开启或关闭偏向锁

轻量级锁

轻量级锁的加锁和解锁逻辑

锁升级为轻量级锁之后，对象的 Markword 也会进行相应的的变化。升级为轻量级锁的过程：

线程在自己的栈桢中创建锁记录LockRecord。
将锁对象的对象头中的MarkWord复制到线程的刚刚创建的锁记录中。
将锁记录中的Owner指针指向锁对象。
将锁对象的对象头的MarkWord替换为指向锁记录的指针。

轻量级锁的解锁

轻量级锁的锁释放逻辑其实就是获得锁的逆向逻辑，通过CAS操作把线程栈帧中的LockRecord替换回到锁对象的MarkWord中，如果成功表示没有竞争。如果失败，表示当前锁存在竞争，那么轻量级锁就会膨胀成为重量级锁

自旋锁

轻量级锁在加锁过程中，用到了自旋锁

所谓自旋，就是指当有另外一个线程来竞争锁时，这个线程会在原地循环等待，而不是把该线程给阻塞，直到那个获得锁的线程释放锁之后，这个线程就可以马上获得锁的。

注意，锁在原地循环的时候，是会消耗 cpu 的，就相当于在执行一个啥也没有的for循环。

所以，轻量级锁适用于那些同步代码块执行的很快的场景，这样，线程原地等待很短的时间就能够获得锁了。自旋锁的使用，其实也是有一定的概率背景，在大部分同步代码块执行的时间都是很短的。所以通过看似无异议的循环反而能提升锁的性能。但是自旋必须要有一定的条件控制，否则如果一个线程执行同步代码块的时间很长，那么这个线程不断的循环反而会消耗CPU资源。默认情况下自旋的次数是10次，可以通过preBlockSpin 来修改
在 JDK1.6 之后，引入了自适应自旋锁，自适应意味着自旋的次数不是固定不变的，而是根据前一次在同一个锁上自旋的时间以及锁的拥有者的状态来决定。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也是很有可能再次成功，进而它将允许自旋等待持续相对更长的时间。
如果对于某个锁，自旋很少成功获得过，那在以后尝试获取这个锁时将可能省略掉自旋过程，直接阻塞线程，避免浪费处理器资源

重量级锁

当轻量级锁膨胀到重量级锁之后，意味着线程只能被挂起阻塞来等待被唤醒了。

Tomcat了解么，说一下类加载器结构吧。

以Tomcat6为例

Tomcat的类加载机制是违反了双亲委托原则的，对于一些未加载的非基础类(Object,String等)，各个web应用自己的类加载器(WebAppClassLoader)会优先加载，加载不到时再交给commonClassLoader走双亲委托。
对于JVM来说：按照这个过程可以想到，如果同样在CLASSPATH指定的目录中和自己工作目录中存放相同的class，会优先加载CLASSPATH目录中的文件。

Q:既然 Tomcat 不遵循双亲委派机制，那么如果我自己定义一个恶意的HashMap，会不会有风险呢？
A:显然不会有风险，如果有，Tomcat都运行这么多年了，那群Tomcat大神能不改进吗？ tomcat不遵循双亲委派机制，只是自定义的classLoader顺序不同，但顶层还是相同的，还是要去顶层请求classloader。

Spring中如何让A和B两个bean按顺序加载？

通过标识位

我们可以在业务层自己控制A，B的初始化顺序，在A中设置一个是否初始化的标记，B初始化前检测A是否得以初始化，如果没有则调用A的初始化方法，所谓的check-and-act。

代码实现如下:
Bean A：

@Service
public class A {
 
  private static volatile boolean initialized;
 
  @Autowired
  private B b;
 
  public A() {
    System.out.println("A construct");
  }
 
  @PostConstruct
  public void init() {
    initA();
  }
 
  public boolean isInitialized() {
    return initialized;
  }
 
  public void initA() {
    if (!isInitialized()) {
      System.out.println("A init");
    }
    initialized = true;
  }
}

Bean B:

@Service
public class B {
 
  @Autowired
  private A a;
 
 
  public B() {
    System.out.println("B construct");
  }
 
  @PostConstruct
  public void init() {
    initB();
  }
 
 
  private void initB() {
    if (!a.isInitialized()) {
      a.initA();
    }
    System.out.println("B init");
  }
}

运行结果

A construct
B construct
A init
B init

这种方法好处是可以做到Lazy initialization（懒加载），但是如果类似逻辑很多的话代码中到处充斥着类似代码，不优雅，所以考虑是否框架本身就可以满足我们的需要。

使用`@DependsOn`

@DependsOn只是保证的被依赖的bean先于当前bean被实例化，被创建，所以如果要采用这种方式实现bean初始化顺序的控制，那么可以把初始化逻辑放在构造函数中，但是复杂耗时的逻辑仿造构造器中是不合适的，会影响系统启动速度。

容器加载bean之前

Spring框架中很多地方都为我们提供了扩展点，很好的体现了开闭原则（OCP）。其中BeanFactoryPostProcessor可以允许我们在容器加载任何bean之前修改应用上下文中的BeanDefinition（从XML配置文件或者配置类中解析得到的bean信息，用于后续实例化bean）。

示例代码如下:

@Component
public class ABeanFactoryPostProcessor implements BeanFactoryPostProcessor {
  @Override
  public void postProcessBeanFactory(ConfigurableListableBeanFactory configurableListableBeanFactory) throws BeansException {
    A.initA();
  }
}

这种方式把A中的初始化逻辑放到了加载bean之前，很适合加载系统全局配置，但是这种方式中初始化逻辑不能依赖bean的状态。

事件监听器的有序性

Spring 中的Ordered也是一个很重要的组件，很多逻辑中都会判断对象是否实现了Ordered接口，如果实现了就会先进行排序操作。比如在事件发布的时候，对获取到的ApplicationListener会先进行排序。所以可以利用事件监听器在处理事件时的有序性，在应用上下文refresh完成后，分别实现A，B中对应的初始化逻辑。

示例代码如下:

Bean A:

@Component
public class ApplicationListenerA implements ApplicationListener, Ordered {
  @Override
  public void onApplicationEvent(ApplicationContextEvent event) {
    initA();
  }
 
  @Override
  public int getOrder() {
    return Ordered.HIGHEST_PRECEDENCE; // 比 ApplicationListenerB 优先级高
  }
 
  public static void initA() {
    System.out.println("A init");
  }
}

Bean B:

@Component
public class ApplicationListenerB implements ApplicationListener, Ordered{
  @Override
  public void onApplicationEvent(ApplicationContextEvent event) {
    initB();
  }
 
  @Override
  public int getOrder() {
    return Ordered.HIGHEST_PRECEDENCE -1;
  }
 
  private void initB() {
    System.out.println("B init");
  }
}

这种方式就是站在事件响应的角度，上下文加载完成后，先实现A逻辑，然后实现B逻辑。

海量数据去重

Q:10亿个数去重
A:用hash分片做
Q:可能不均匀
A:用Bitmap
Q:数字量更多怎么办
A:用两个bitmap
注：这题面试者的回答并没有让面试官满意。我们也就这个问题做个讨论，结果做个参考。

如果允许使用中间件，且硬件条件允许的情况下可以使用MapReduce+HDFS,参考巧用MapReduce+HDFS，海量数据去重的五大策略
- 只使用HDFS和MapReduce
- 使用HDFS和Hbase
- 使用HDFS，MapReduce和存储控制器
- 使用Streaming，HDFS，MapReduce
- 结合块技术使用MapReduce
参考海量数据去重之SimHash算法简介和应用
如果再在物理内存上加了限制，就需要考虑写入文件了

二面(技术面)

讲一下项目。

同上，多说些简历上没有的。

讲一下多线程把，用到哪些写一下。

基本线程类

基本线程类指的是Thread类，Runnable接口，Callable接口

高级多线程控制类

ThreadLocal类,java.util.concurrent.atomic包下实现的Automic类,Lock类,容器类(BlockingQueue,ConcurrentHashMap等),ThreadPoolExecutor(线程池)

线程池由哪些组件组成，有哪些线程池，分别怎么使用，以及拒绝策略有哪些。

线程池由哪些些组件组成

线程池管理器（ThreadPoolManager）:用于创建并管理线程池
工作线程（WorkThread）: 线程池中线程
任务接口（Task）:每个任务必须实现的接口，以供工作线程调度任务的执行。
任务队列:用于存放没有处理的任务。提供一种缓冲机制。

有哪些线程池以及使用场景

具体代码请查阅API或者Google

newCachedThreadPool：创建一个可缓存线程池程。是一种线程数量不定的线程池，并且其最大线程数为Integer.MAX_VALUE，这个数是很大的，一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程。但是线程池中的空闲线程都有超时限制，这个超时时长是60秒，超过60秒闲置线程就会被回收。调用execute将重用以前构造的线程(如果线程可用)。这类线程池比较适合执行大量的耗时较少的任务，当整个线程池都处于闲置状态时，线程池中的线程都会超时被停止。
newFixedThreadPool：创建一个定长线程池。每当提交一个任务就创建一个工作线程，当线程处于空闲状态时，它们并不会被回收，除非线程池被关闭了，如果工作线程数量达到线程池初始的最大数，则将提交的任务存入到池队列（没有大小限制）中。由于newFixedThreadPool只有核心线程并且这些核心线程不会被回收，这样它更加快速底相应外界的请求。
newScheduledThreadPool：创建一个定长线程池。它的核心线程数量是固定的，而非核心线程数是没有限制的，并且当非核心线程闲置时会被立即回收，它可安排给定延迟后运行命令或者定期地执行。这类线程池主要用于执行定时任务和具有固定周期的重复任务。
newSingleThreadExecutor：创建一个单线程化的线程池。这类线程池内部只有一个核心线程，以无界队列方式来执行该线程，这使得这些任务之间不需要处理线程同步的问题，它确保所有的任务都在同一个线程中按顺序中执行，并且可以在任意给定的时间不会有多个线程是活动的。

拒绝策略有哪些

当线程池的任务缓存队列已满并且线程池中的线程数目达到maximumPoolSize时，如果还有任务到来就会采取任务拒绝策略。

JDK自带的拒绝策略

ThreadPoolExecutor.AbortPolicy:丢弃任务并抛出RejectedExecutionException异常。
ThreadPoolExecutor.DiscardPolicy：丢弃任务，但是不抛出异常。
ThreadPoolExecutor.DiscardOldestPolicy：丢弃队列最前面的任务，然后重新提交被拒绝的任务
ThreadPoolExecutor.CallerRunsPolicy：由调用线程（提交任务的线程）处理该任务

第三方的拒绝策略

Dubbo
- 输出了一条警告级别的日志，日志内容为线程池的详细设置参数，以及线程池当前的状态，还有当前拒绝任务的一些详细信息。可以说，这条日志，使用dubbo的有过生产运维经验的或多或少是见过的，这个日志简直就是日志打印的典范，其他的日志打印的典范还有spring。得益于这么详细的日志，可以很容易定位到问题所在。
- 输出当前线程堆栈详情，这个太有用了，当你通过上面的日志信息还不能定位问题时，案发现场的dump线程上下文信息就是你发现问题的救命稻草，这个可以参考《dubbo线程池耗尽事件-"CyclicBarrier惹的祸"》
- 继续抛出拒绝执行异常，使本次任务失败，这个继承了JDK默认拒绝策略的特性
Netty
类似JDK 中的 CallerRunsPolicy，舍不得丢弃任务。不同的是，CallerRunsPolicy 是直接在调用者线程执行的任务。而 Netty是新建了一个线程来处理的。所以，Netty的实现相较于调用者执行策略的使用面就可以扩展到支持高效率高性能的场景了。但是也要注意一点，Netty的实现里，在创建线程时未做任何的判断约束，也就是说只要系统还有资源就会创建新的线程来处理，直到new不出新的线程了，才会抛创建线程失败的异常
activeMq
最大努力执行任务型，当触发拒绝策略时，在尝试一分钟的时间重新将任务塞进任务队列，当一分钟超时还没成功时，就抛出异常
PinPoint
和其他的实现都不同。他定义了一个拒绝策略链，包装了一个拒绝策略列表，当触发拒绝策略时，会将策略链中的rejectedExecution依次执行一遍。

什么时候多线程会发生死锁，写一个例子吧

什么时候多线程会发生死锁

死锁产生的原因

系统资源的竞争
通常系统中拥有的不可剥夺资源，其数量不足以满足多个进程运行的需要，使得进程在运行过程中，会因争夺资源而陷入僵局，如磁带机、打印机等。只有对不可剥夺资源的竞争才可能产生死锁，对可剥夺资源的竞争是不会引起死锁的。
进程推进顺序非法
进程在运行过程中，请求和释放资源的顺序不当，也同样会导致死锁。例如，并发进程 P1、P2分别保持了资源R1、R2，而进程P1申请资源R2，进程P2申请资源R1时，两者都会因为所需资源被占用而阻塞。
信号量使用不当也会造成死锁。进程间彼此相互等待对方发来的消息，结果也会使得这些进程间无法继续向前推进。例如，进程A等待进程B发的消息，进程B又在等待进程A 发的消息，可以看出进程A和B不是因为竞争同一资源，而是在等待对方的资源导致死锁。
死锁产生的必要条件
产生死锁必须同时满足以下四个条件，只要其中任一条件不成立，死锁就不会发生。
1. 互斥条件：进程要求对所分配的资源（如打印机）进行排他性控制，即在一段时间内某资源仅为一个进程所占有。此时若有其他进程请求该资源，则请求进程只能等待。
2. 不剥夺条件：进程所获得的资源在未使用完毕之前，不能被其他进程强行夺走，即只能由获得该资源的进程自己来释放（只能是主动释放)。
3. 请求和保持条件：进程已经保持了至少一个资源，但又提出了新的资源请求，而该资源已被其他进程占有，此时请求进程被阻塞，但对自己已获得的资源保持不放。
4. 循环等待条件：存在一种进程资源的循环等待链，链中每一个进程已获得的资源同时被链中下一个进程所请求。即存在一个处于等待状态的进程集合{Pl, P2, …, pn}，其中Pi等待的资源被P(i+1)占有（i=0, 1, …, n-1)，Pn等待的资源被P0占有

死锁代码示例

/** 
 * 一个简单的死锁类 
 * 当DeadLock类的对象flag==1时（td1），先锁定o1,睡眠500毫秒 
 * 而td1在睡眠的时候另一个flag==0的对象（td2）线程启动，先锁定o2,睡眠500毫秒 
 * td1睡眠结束后需要锁定o2才能继续执行，而此时o2已被td2锁定； 
 * td2睡眠结束后需要锁定o1才能继续执行，而此时o1已被td1锁定； 
 * td1、td2相互等待，都需要得到对方锁定的资源才能继续执行，从而死锁。 
 */  
public class DeadLock implements Runnable {  
    public int flag = 1;  
    //静态对象是类的所有对象共享的  
    private static Object o1 = new Object();
    private static Object o2 = new Object();   
    @Override  
    public void run() {  
        System.out.println("flag=" + flag);  
        if (flag == 1) {  
            synchronized (o1) {  
                try {  
                    Thread.sleep(500);  
                } catch (Exception e) {  
                    e.printStackTrace();  
                }  
                synchronized (o2) {  
                    System.out.println("1");  
                }  
            }  
        }  
        if (flag == 0) {  
            synchronized (o2) {  
                try {  
                    Thread.sleep(500);  
                } catch (Exception e) {  
                    e.printStackTrace();  
                }  
                synchronized (o1) {  
                    System.out.println("0");  
                }  
            }  
        }  
    }  
  
    public static void main(String[] args) {  
          
        DeadLock td1 = new DeadLock();  
        DeadLock td2 = new DeadLock();  
        td1.flag = 1;  
        td2.flag = 0;  
        //td1,td2都处于可执行状态，但JVM线程调度先执行哪个线程是不确定的。  
        //td2的run()可能在td1的run()之前运行  
        new Thread(td1).start();  
        new Thread(td2).start();  
  
    }  
}

一个字符串集合，找出pdd并且删除。

皮一下，面试官是不是和pdd有什么过节？

这个题可延伸部分很多，主要注意以下几点：

要考虑保证线程安全
使用迭代器迭代集合内元素时，不能删除集合内元素

Redis是单线程还是多线程，Redis的分布式怎么做？

Redis是单线程还是多线程

Redis是单线程的，这样设计省去了上下文切换的性能与时间消耗

Redis的分布式怎么做

这里的解决方案很多，但是既然使用了分布式，那么Redis也就必须使用集群，避免单点问题。
在使用Redis做分布式时，Redis不仅仅能充当缓存，还可以基于Redis实现分布式锁。
更多解决方案细节自行百度或者Google

RPC了解么

面试者回答：主要是协议栈+数据格式+序列化方式，然后需要有服务注册中心管理生产者和消费者。

详细参考RPC原理及RPC实例分析

TCP三次握手的过程，如果没有第三次握手有什么问题。

在回答这个问题前首先我们要了解TCP连接的建立与释放（三次握手、四次挥手）

TCP协议相关知识

TCP协议简介

TCP是面向连接的运输层协议，它提供可靠交付的、全双工的、面向字节流的点对点服务。HTTP协议便是基于TCP协议实现的。（虽然作为应用层协议，HTTP协议并没有明确要求必须使用TCP协议作为运输层协议，但是因为HTTP协议对可靠性的的要求，默认HTTP是基于TCP协议的。若是使用UDP这种不可靠的、尽最大努力交付的运输层协议来实现HTTP的话，那么TCP协议的流量控制、可靠性保障机制等等功能就必须全部放到应用层来实现）而相比网络层更进一步，运输层着眼于应用进程间的通信，而不是网络层的主机间的通讯。我们常见的端口、套接字等概念就是由此而生。（端口代表主机上的一个应用进程、而套接字则是ip地址与端口号的合体，可以在网络范围内唯一确定一个应用进程） TCP协议的可靠传输是通过滑动窗口的方法实现的；拥塞控制则有着慢开始和拥塞避免、快重传和快恢复、RED随机早期检测几种办法。

报文格式参考

脑图参考

TCP报文段的首部分为固定部分和选项部分，固定部分长20byte，而选项部分长度可变。（若整个首部长度不是4byte的整数倍的话，则需要用填充位来填充）在固定首部中，与本文密切相关的是以下几项：

seq（序号）：TCP连接字节流中每一个字节都会有一个编号，而本字段的值指的是本报文段所发送数据部分第一个字节的序号。
ack（确认号）：表示期望收到的下一个报文段数据部分的第一个字节的编号，编号为ack-1及以前的字节已经收到。
SYN：当本字段为1时，表示这是一个连接请求或者连接接受报文。
ACK：仅当本字段为1时，确认号才有效。
FIN：用来释放一个连接。当本字段为1时，表示此报文段的发送端数据已发送完毕，要求释放运输连接。

TCP的运输连接管理

运输连接具有三个阶段：连接建立、数据传送以及连接释放。运输连接管理就是对连接建立以及连接释放过程的管控，使得其能正常运行，达到这些目的：使通信双方能够确知对方的存在、可以允许通信双方协商一些参数（最大报文段长度、最大窗口大小等等）、能够对运输实体资源进行分配（缓存大小等）。TCP连接的建立采用客户-服务器模式：主动发起连接建立的应用进程叫做客户，被动等待连接建立的应用进程叫做服务器。

连接建立阶段

第一次握手：客户端的应用进程主动打开，并向客户端发出请求报文段。其首部中：SYN=1,seq=x。
第二次握手：服务器应用进程被动打开。若同意客户端的请求，则发回确认报文，其首部中：SYN=1,ACK=1,ack=x+1,seq=y。
第三次握手：客户端收到确认报文之后，通知上层应用进程连接已建立，并向服务器发出确认报文，其首部：ACK=1,ack=y+1。当服务器收到客户端的确认报文之后，也通知其上层应用进程连接已建立。

在这个过程中，通信双方的状态如下图，其中CLOSED：关闭状态、LISTEN：收听状态、SYN-SENT：同步已发送、SYN-RCVD：同步收到、ESTAB-LISHED：连接已建立。

连接释放阶段

第一次挥手：数据传输结束以后，客户端的应用进程发出连接释放报文段，并停止发送数据，其首部：FIN=1,seq=u。
第二次挥手：服务器端收到连接释放报文段之后，发出确认报文，其首部：ack=u+1,seq=v。此时本次连接就进入了半关闭状态，客户端不再向服务器发送数据。而服务器端仍会继续发送。
第三次挥手：若服务器已经没有要向客户端发送的数据，其应用进程就通知服务器释放TCP连接。这个阶段服务器所发出的最后一个报文的首部应为：FIN=1,ACK=1,seq=w,ack=u+1。
第四次挥手：客户端收到连接释放报文段之后，必须发出确认：ACK=1,seq=u+1,ack=w+1。再经过2MSL(最长报文端寿命)后，本次TCP连接真正结束，通信双方完成了他们的告别。

在这个过程中，通信双方的状态如下图，其中：
ESTAB-LISHED：连接建立状态
FIN-WAIT-1：终止等待1状态
FIN-WAIT-2：终止等待2状态
CLOSE-WAIT：关闭等待状态
LAST-ACK：最后确认状态
TIME-WAIT：时间等待状态
CLOSED：关闭状态

完整过程如图所示：

Q:在握手与挥手的过程中，往复的ack与seq有什么含义？
A:这是通信双方在通信过程中的一种确认手段，确保通信双方通信的正确性。例如小时候模仿电视剧里无线电呼叫的过程：
- 土豆土豆，我是地瓜，你能听到吗？
- 地瓜地瓜，我是土豆，我能听到。
若客户端的报文请求号为土豆，则服务器端就将返回确认号土豆+1（标志土豆已收到），是一种通信双方的确认手段。

Q:在结束连接的过程中，为什么在收到服务器端的连接释放报文段之后，客户端还要继续等待2MSL之后才真正关闭TCP连接呢？
A:这里有两个原因
需要保证服务器端收到了客户端的最后一条确认报文。假如这条报文丢失，服务器没有接收到确认报文，就会对连接释放报文进行超时重传，而此时客户端连接已关闭，无法做出响应，就造成了服务器端不停重传连接释放报文，而无法正常进入关闭状态的状况。而等待2MSL，就可以保证服务器端收到了最终确认；若服务器端没有收到，那么在2MSL之内客户端一定会收到服务器端的重传报文，此时客户端就会重传确认报文，并重置计时器。
2.存在一种已失效的连接请求报文段，需要避免这种报文端出现在本连接中，造成异常。这种“已失效的连接请求报文段”是这么形成的：假如客户端发出了连接请求报文，然而服务器端没有收到，于是客户端进行超时重传，再一次发送了连接请求报文，并成功建立连接。然而，第一次发送的连接请求报文并没有丢失，只是在某个网络结点中发生了长时间滞留，随后，这个最初发送的报文段到达服务器端，会使得服务器端误以为客户端发出了新的请求，造成异常。

Q:若通信双方同时请求连接或同时请求释放连接，情况如何？
A:这种情况虽然发生的可能性极小，但是是确实存在的，TCP也特意设计了相关机制，使得在这种情况下双方仅建立一条连接。双方同时请求连接的情况下，双方同时发出请求连接报文，并进入SYN-SENT状态；当收到对方的请求连接报文后，会再次发送请求连接报文，确认号为对方的SYN+1，并进入SYN-RCVD状态；当收到对方第二次发出的携带确认号的请求报文之后，会进入ESTAB-LISHED状态。双方同时请求释放连接也是同样的，双方同时发出连接释放报文，并进入FIN-WAIT-1状态；在收到对方的报文之后，发送确认报文，并进入CLOSING状态；在收到对方的确认报文后，进入TIME-WAIT状态，等待2MSL之后关闭连接。需要注意的是，这个时候虽然不用再次发送确认报文并确认对方收到，双方仍需等待2MSL之后再关闭连接，是为了防止已失效的连接请求报文段的影响。

如果没有第三次握手有什么问题

没有第三步，那就是服务器发送给客户端的SYN没有收到回应，其实这就是SYN洪泛攻击。
感兴趣可以自己百度或者Google一下，这里不做过多解释。

SYN攻击属于DDOS攻击的一种，它利用TCP协议缺陷，通过发送大量的半连接请求，耗费CPU和内存资源。
SYN攻击除了能影响主机外，还可以危害路由器、防火墙等网络系统，事实上SYN攻击并不管目标是什么系统，只要这些系统打开TCP服务就可以实施。
服务器接收到连接请求(syn=j)，将此信息加入未连接队列，并发送请求包给客户(syn=k,ack=j+1)，此时进入SYN_RECV状态。当服务器未收到客户端的确认包时，重发请求包，一直到超时，才将此条目从未连接队列删除。配合IP欺骗，SYN攻击能达到很好的效果，通常，客户端在短时间内伪造大量不存在的IP地址，向服务器不断地发送syn包，服务器回复确认包，并等待客户的确认，由于源地址是不存在的，服务器需要不断的重发直至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。

三面(技术面)

自我介绍

已经麻木，进入背稿阶段~

cap了解么，分别指什么，base呢，强一致性和弱一致性有什么方法来做，2pc了解么，说一下大概过程。

cap分别指什么

这是在分布式系统中的概念，内容是以下三个要素最多只能同时实现两点，不可能三者兼顾。

Consistency（一致性）
Availability（可用性）
Partition tolerance（分区容错性）

BASE理论

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）的简写。BASE是对CAP中一致性和可用性权衡的结果，契合性思想是即使无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方式来使得系统达到最终一致性。

基本可用
基本可用是指分布式系统在出现不可预知的故障的时候，允许损失部分可用性。
1. 相应时间上的损失：正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户的查询结果，但由于出现故障，查询结果的响应时间增加到1-2秒。
  2.功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利的完成每一笔订单，但是在一些节日大促购物高峰的时候（比如双十一），由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
弱状态
弱状态也称为软状态，和硬状态相对应，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同的节点之间的数据副本进行数据的同步过程存在延迟。
最终一致性
最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质就是需要系统最终数据达到一致，而不需要实时保证系统数据的强一致性。在没有发生故障的前提下，数据达到一致状态的时间延迟，取决于网络延迟、系统负载和数据复制方案设计等因素。
在时间工程实践中，最终一致性存在以下五类主要变种。
- 因果一致性
- 读己之所写
- 会话一致性
- 单调读一致性
- 单调写一致性

强一致性和弱一致性有什么方法来做

强一致性

两阶段提交（2PC）

两阶段提交协议把分布式事务分成两个过程，一个是准备阶段，一个是提交阶段，准备阶段和提交阶段都是由事务管理器发起的，为了接下来讲解方便，我们把事务管理器称为协调者，把资管管理器称为参与者。

准备阶段：协调者向参与者发起指令，参与者评估自己的状态，如果参与者评估指令可以完成，参与者会写redo或者undo日志（这也是前面提起的Write-Ahead Log的一种），然后锁定资源，执行操作，但是并不提交。
提交阶段：如果每个参与者明确返回准备成功，也就是预留资源和执行操作成功，协调者向参与者发起提交指令，参与者提交资源变更的事务，释放锁定的资源；如果任何一个参与者明确返回准备失败，也就是预留资源或者执行操作失败，协调者向参与者发起中止指令，参与者取消已经变更的事务，执行undo日志，释放锁定的资源。

两阶段提交事务提交示意图：

两阶段提交事务回滚示意图：

我们看到两阶段提交协议在准备阶段锁定资源，是一个重量级的操作，并能保证强一致性，但是实现起来复杂、成本较高，不够灵活，更重要的是它有如下致命的问题：

阻塞：从上面的描述来看，对于任何一次指令必须收到明确的响应，才会继续做下一步，否则处于阻塞状态，占用的资源被一直锁定，不会被释放。
单点故障：如果协调者宕机，参与者没有了协调者指挥，会一直阻塞，尽管可以通过选举新的协调者替代原有协调者，但是如果之前协调者在发送一个提交指令后宕机，而提交指令仅仅被一个参与者接受，并且参与者接收后也宕机，新上任的协调者无法处理这种情况。
脑裂：协调者发送提交指令，有的参与者接收到执行了事务，有的参与者没有接收到事务，就没有执行事务，多个参与者之间是不一致的。

上面所有的这些问题，都是需要人工干预处理，没有自动化的解决方案，因此两阶段提交协议在正常情况下能保证系统的强一致性，但是在出现异常情况下，当前处理的操作处于错误状态，需要管理员人工干预解决，因此可用性不够好，这也符合CAP协议的一致性和可用性不能兼得的原理。

三阶段提交(3pc)

三阶段提交协议是两阶段提交协议的改进版本。它通过超时机制解决了阻塞的问题，并且把两个阶段增加为三个阶段。

询问阶段：协调者询问参与者是否可以完成指令，协调者只需要回答是还是不是，而不需要做真正的操作，这个阶段超时导致中止。
准备阶段：如果在询问阶段所有的参与者都返回可以执行操作，协调者向参与者发送预执行请求，然后参与者写redo和undo日志，执行操作，但是不提交操作；如果在询问阶段任何参与者返回不能执行操作的结果，则协调者向参与者发送中止请求，这里的逻辑与两阶段提交协议的的准备阶段是相似的，这个阶段超时导致成功。
提交阶段：如果每个参与者在准备阶段返回准备成功，也就是预留资源和执行操作成功，协调者向参与者发起提交指令，参与者提交资源变更的事务，释放锁定的资源；如果任何一个参与者返回准备失败，也就是预留资源或者执行操作失败，协调者向参与者发起中止指令，参与者取消已经变更的事务，执行undo日志，释放锁定的资源，这里的逻辑与两阶段提交协议的提交阶段一致。

然而，这里与两阶段提交协议有两个主要的不同：

增加了一个询问阶段，询问阶段可以确保尽可能早的发现无法执行操作而需要中止的行为，但是它并不能发现所有的这种行为，只会减少这种情况的发生。
在准备阶段以后，协调者和参与者执行的任务中都增加了超时，一旦超时，协调者和参与者都继续提交事务，默认为成功，这也是根据概率统计上超时后默认成功的正确性最大。

三阶段提交协议与两阶段提交协议相比，具有如上的优点，但是一旦发生超时，系统仍然会发生不一致，只不过这种情况很少见罢了，好处就是至少不会阻塞和永远锁定资源。

TTC(Try-Confirm-Cancel)

上面两节讲解了两阶段提交协议和三阶段提交协议，实际上他们能解决转账和下订单和扣库存中的分布式事务的问题，但是遇到极端情况，系统会发生阻塞或者不一致的问题，需要运营或者技术人工解决。无论两阶段还是三阶段方案中都包含多个参与者、多个阶段实现一个事务，实现复杂，性能也是一个很大的问题，因此，在互联网高并发系统中，鲜有使用两阶段提交和三阶段提交协议的场景。
阿里巴巴提出了新的TCC协议，TCC协议将一个任务拆分成Try、Confirm、Cancel，正常的流程会先执行Try，如果执行没有问题，再执行Confirm，如果执行过程中出了问题，则执行操作的逆操Cancel，从正常的流程上讲，这仍然是一个两阶段的提交协议，但是，在执行出现问题的时候，有一定的自我修复能力，如果任何一个参与者出现了问题，协调者通过执行操作的逆操作来取消之前的操作，达到最终的一致状态。
可以看出，从时序上，如果遇到极端情况下TCC会有很多问题的，例如，如果在Cancel的时候一些参与者收到指令，而一些参与者没有收到指令，整个系统仍然是不一致的，这种复杂的情况，系统首先会通过补偿的方式，尝试自动修复的，如果系统无法修复，必须由人工参与解决。
从TCC的逻辑上看，可以说TCC是简化版的三阶段提交协议，解决了两阶段提交协议的阻塞问题，但是没有解决极端情况下会出现不一致和脑裂的问题。然而，TCC通过自动化补偿手段，会把需要人工处理的不一致情况降到到最少，也是一种非常有用的解决方案，根据线人，阿里在内部的一些中间件上实现了TCC模式。
我们给出一个使用TCC的实际案例，在秒杀的场景，用户发起下单请求，应用层先查询库存，确认商品库存还有余量，则锁定库存，此时订单状态为待支付，然后指引用户去支付，由于某种原因用户支付失败，或者支付超时，系统会自动将锁定的库存解锁供其他用户秒杀。

弱一致性

最终一致性

最终一致性是弱一致性的一种特例，保证用户最终能够读取到某操作对系统特定数据的更新。但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。也可以简单的理解为在一段时间后，节点间的数据会最终达到一致状态。对于最终一致性最好的例子就是DNS系统，由于DNS多级缓存的实现，所以修改DNS记录后不会在全球所有DNS服务节点生效，需要等待DNS服务器缓存过期后向源服务器更新新的记录才能实现。最终一致性根据更新数据后各进程访问到数据的时间和方式的不同，又可以区分为：

因果一致性：如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将返回更新后的值，且一次写入将保证取代前一次写入。与进程A无因果关系的进程C的访问遵守一般的最终一致性规则。
读己之所写一致性：当进程A自己更新一个数据项之后，它总是访问到更新过的值，绝不会看到旧值。这是因果一致性模型的一个特例。
会话一致性：这是上一个模型的实用版本，它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统的保证不会延续到新的会话。
单调读一致性：如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。
单调写一致性：系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性，就非常难以编程了。

同时最终一致性的不同方式可以进行组合，从服务端角度，如何尽快将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，是提高系统的可用度和用户体验非常重要的方面。对于分布式数据系统：

N — 数据复制的份数
W — 更新数据是需要保证写完成的节点数
R — 读取数据的时候需要读取的节点数

如果W+R>N：则是强一致性，写的节点和读的节点重叠。例如对于典型的一主一备同步复制的关系型数据库。N=2,W=2,R=1，则不管读的是主库还是备库的数据，都是一致的。
如果W+R<=N：则是弱一致性。例如对于一主一备异步复制的关系型数据库，N=2,W=1,R=1，则如果读的是备库，就可能无法读取主库已经更新过的数据，所以是弱一致性。

对于分布式系统，为了保证高可用性，一般设置N>=3。不同的N,W,R组合，是在可用性和一致性之间取一个平衡，以适应不同的应用场景。

如果N=W,R=1，任何一个写节点失效，都会导致写失败，因此可用性会降低，但是由于数据分布的N个节点是同步写入的，因此可以保证强一致性。
如果N=R,W=1，只需要一个节点写入成功即可，写性能和可用性都比较高。但是读取其他节点的进程可能不能获取更新后的数据，因此是弱一致性。这种情况下，如果W<(N+1)/2，并且写入的节点不重叠的话，则会存在写冲突。

负载均衡怎么做的呢，为什么这么做？

负载均衡相关知识

软件负载解决的两个核心问题是：选谁、转发，其中最著名的是LVS（Linux Virtual Server）。

负载均衡分类

最常用的是四层和七层负载均衡。

二层负载均衡

负载均衡服务器对外依然提供一个VIP（虚IP），集群中不同的机器采用相同IP地址，但机器的MAC地址不一样。当负载均衡服务器接受到请求之后，通过改写报文的目标MAC地址的方式将请求转发到目标机器实现负载均衡。

三层负载均衡

和二层负载均衡类似，负载均衡服务器对外依然提供一个VIP（虚IP），但集群中不同的机器采用不同的IP地址。当负载均衡服务器接受到请求之后，根据不同的负载均衡算法，通过IP将请求转发至不同的真实服务器。

四层负载均衡

四层负载均衡工作在OSI模型的传输层，由于在传输层，只有TCP/UDP协议，这两种协议中除了包含源IP、目标IP以外，还包含源端口号及目的端口号。四层负载均衡服务器在接受到客户端请求后，以后通过修改数据包的地址信息（IP+端口号）将流量转发到应用服务器。

七层负载均衡

七层负载均衡工作在OSI模型的应用层，应用层协议较多，常用http、radius、DNS等。七层负载就可以基于这些协议来负载。这些应用层协议中会包含很多有意义的内容。比如同一个Web服务器的负载均衡，除了根据IP加端口进行负载外，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。

对于一般的应用来说，有了Nginx就够了。Nginx可以用于七层负载均衡。但是对于一些大的网站，一般会采用DNS+四层负载+七层负载的方式进行多层次负载均衡。

常用负载均衡工具

硬件负载均衡性能优越，功能全面，但价格昂贵，一般适合初期或者土豪级公司长期使用。因此软件负载均衡在互联网领域大量使用。常用的软件负载均衡软件有Nginx、LVS、HaProxy等。
Nginx/LVS/HAProxy是目前使用最广泛的三种负载均衡软件。

LVS

主要用来做四层负载均衡。

Nginx

是一个网页服务器，它能反向代理HTTP、HTTPS,、SMTP、POP3、IMAP的协议链接，以及一个负载均衡器和一个HTTP缓存。
Nginx主要用来做七层负载均衡。
并发性能：官方支持每秒5万并发，实际国内一般到每秒2万并发，有优化到每秒10万并发的。具体性能看应用场景。

特点：

模块化设计：良好的扩展性，可以通过模块方式进行功能扩展。
高可靠性：主控进程和worker是同步实现的，一个worker出现问题，会立刻启动另一个worker。
内存消耗低：一万个长连接（keep-alive）,仅消耗2.5MB内存。
支持热部署：不用停止服务器，实现更新配置文件，更换日志文件、更新服务器程序版本。
并发能力强：官方数据每秒支持5万并发；
功能丰富：优秀的反向代理功能和灵活的负载均衡策略

Haproxy

主要用来做七层负载均衡。

静态负载均衡算法包括：轮询、比率、优先权。
动态负载均衡算法包括：最少连接数、最快响应速度、观察方法、预测法、动态性能分配、动态服务器补充、服务质量、服务类型、规则模式。

为什么这么做

此部分主要注意一下几个问题：

多节点包与配置的一致性
文件的存放（包含上传的文件与日志文件）
会话的共享与一致性（Session），如果是基于Restful的，虽然没有了Session但也需要注意某些信息的存储与验证，例如用户信息与缓存
如果是异构系统，需要注意通信报文格式的保证，比如使用消息队列，传输Json格式的数据。

了解过集群雪崩么？

类似的问题还有缓存的雪崩，缓存穿透，缓存击穿等

雪崩效应产生的几种场景

流量激增：比如异常流量、用户重试导致系统负载升高；
缓存刷新：假设A为client端，B为Server端，假设A系统请求都流向B系统，请求超出了B系统的承载能力，就会造成B系统崩溃；
程序有Bug：代码循环调用的逻辑问题，资源未释放引起的内存泄漏等问题；
硬件故障：比如宕机，机房断电，光纤被挖断等。
线程同步等待：系统间经常采用同步服务调用模式，核心服务和非核心服务共用一个线程池和消息队列。如果一个核心业务线程调用非核心线程，这个非核心线程交由第三方系统完成，当第三方系统本身出现问题，导致核心线程阻塞，一直处于等待状态，而进程间的调用是有超时限制的，最终这条线程将断掉，也可能引发雪崩；

常见解决方案

使用超时策略和熔断器机制

针对上述雪崩情景：有很多应对方案，但没有一个万能的模式能够应对所有场景。
针对流量激增：采用自动扩缩容以应对突发流量，或在负载均衡器上安装限流模块。
针对缓存刷新：参考Cache应用中的服务过载案例研究。
针对硬件故障：多机房容灾，跨机房路由，异地多活等。
针对同步等待：使用Hystrix做故障隔离，熔断器机制等可以解决依赖服务不可用的问题。

MySQL的主从复制怎么做的，具体原理是什么，有什么优缺点。

基于Sql语句或行复制原理

首先，mysql主库在事务提交时会把数据库变更作为事件Events记录在二进制文件binlog中；mysql主库上的sys_binlog控制binlog日志刷新到磁盘。
主库推送二进制文件binlog中的事件到从库的中继日志relay log,之后从库根据中继日志重做数据库变更操作。通过逻辑复制，以此来达到数据一致。

Mysql通过3个线程来完成主从库之间的数据复制：其中BinLog Dump线程跑在主库上，I/O线程和SQL线程跑在从库上。当从库启动复制（start slave）时，首先创建I/O线程连接主库，主库随后创建Binlog Dump线程读取数据库事件并发给I/O线程，I/O线程获取到数据库事件更新到从库的中继日志Realy log中去，之后从库上的SQL线程读取中继日志relay log中更新的数据库事件并应用。

基于GTID原理

主节点更新数据时，会在事务前产生GTID，一起记录到binlog日志中。
从节点的I/O线程将变更的bin log，写入到本地的relay log中。
SQL线程从relay log中获取GTID，然后对比本地binlog是否有记录（所以MySQL从节点必须要开启binary log）。
如果有记录，说明该GTID的事务已经执行，从节点会忽略。
如果没有记录，从节点就会从relay log中执行该GTID的事务，并记录到bin log。
在解析过程中会判断是否有主键，如果没有就用二级索引，如果有就用全部扫描。

优缺点

基于SQL语句的复制(statement-based replication, SBR)，

优点：
历史悠久，技术成熟。
产生的binlog文件较小，比较节省空间。
binlog中包含了所有数据库更改信息，可以据此来审核数据库的安全等情况。
binlog可以用于实时的还原，而不仅仅用于复制。
主从版本可以不一样，从服务器版本可以比主服务器版本高。
缺点：
不是所有的UPDATE语句都能被复制，尤其是包含不确定操作的时候。
调用具有不确定因素的 UDF 时复制也可能出问题
使用以下函数的语句也无法被复制：
- LOAD_FILE()
- UUID()
- USER()
- FOUND_ROWS()
- SYSDATE() (除非启动时启用了 –sysdate-is-now 选项)
- INSERT … SELECT 会产生比 RBR 更多的行级锁

基于行的复制(row-based replication, RBR)，

优点：
任何情况都可以被复制，这对复制来说是最安全可靠的
多数情况下，从服务器上的表如果有主键的话，复制就会快了很多
复制以下几种语句时的行锁更少：
- INSERT … SELECT
- 包含 AUTO_INCREMENT 字段的 INSERT
- 没有附带条件或者并没有修改很多记录的 UPDATE 或 DELETE 语句
  - 执行 INSERT，UPDATE，DELETE 语句时锁更少
  - 从服务器上采用多线程来执行复制成为可能。
缺点：
binlog 文件太大
复杂的回滚时 binlog 中会包含大量的数据
主服务器上执行 UPDATE 语句时，所有发生变化的记录都会写到 binlog 中，而 SBR 只会写一次，这会导致频繁发生 binlog 的并发写问题
UDF 产生的大 BLOB 值会导致复制变慢
无法从 binlog 中看到都复制了写什么语句，无法进行审计。

Redis有哪些集群模式，各自的区别？

主从复制，基于SYNC命令，如果主节点都挂了，服务也就挂了，不能水平扩容
哨兵模式，基于状态监控，可选举出新的master节点，有一定弹性抗灾能力，不能水平扩容
Redis官方提供的Cluster集群模式(服务端)，基于数据分片
Jedis sharding集群(客户端sharding)，基于hash算法
利用中间件代理，比如codis等，具体看使用的中间件

项目用到了多线程，如果线程数很多会怎么样？

这个问题属于一个比较开发性的问题，且能延伸出很多东西。
首先线程数过多，会导致CPU占用率居高不下，相应的散热需求就会上升，费电是一方面，如果占用率长时间居高不下很有可能导致服务器宕机。

Q: 那么如何控制线程数？
A: 线程池。消息队列。

Q: 如何确定一个合理的线程数？
A: 处理器敏感的程序，和CPU核心数持平；对于处理并发和网络通讯的程序，开几个到几十个，但不宜太多。

Q: 如何处理大任务？
A: 使用Fork/Join 框。

分布式了解哪些东西，消息队列了解么，用在什么场景？怎么保证Kafka数据不丢失，以及确保消息不会被重复消费？消息送达确认是怎么做的？

应用场景：削峰，限流和异步

消息队列 Kafka

关于kafka
使用同步模式的时候，有3种状态保证消息被安全生产，在配置为1（只保证写入leader成功）的话，如果刚好leader partition挂了，数据就会丢失。
还有一种情况可能会丢失消息，就是使用异步模式的时候，当缓冲区满了，如果配置为0（还没有收到确认的情况下，缓冲池一满，就清空缓冲池里的消息），
数据就会被立即丢弃掉。

在数据生产时避免数据丢失的方法：
只要能避免上述两种情况，那么就可以保证消息不会被丢失。
就是说在同步模式的时候，确认机制设置为-1，也就是让消息写入leader和所有的副本。
还有，在异步模式下，如果消息发出去了，但还没有收到确认的时候，缓冲池满了，在配置文件中设置成不限制阻塞超时的时间，也就说让生产端一直阻塞，这样也能保证数据不会丢失。

在数据消费时，避免数据丢失的方法：如果使用了storm，要开启storm的ackfail机制；如果没有使用storm，确认数据被完成处理之后，再更新offset值。低级API中需要手动控制offset值。

数据重复消费的情况，如果处理？

去重：将消息的唯一标识保存到外部介质中，每次消费处理时判断是否处理过；
不管：大数据场景中，报表系统或者日志信息丢失几条都无所谓，不会影响最终的统计分析结果。

Kafka本身支持At least once消息送达语义，因此实现消息发送的幂等关键是要实现Broker端消息的去重。为了实现消息发送的幂等性，Kafka引入了两个新的概念：

PID:每个新的Producer在初始化的时候会被分配一个唯一的PID，这个PID对用户是不可见的。
Sequence Numbler:对于每个PID，该Producer发送数据的每个都对应一个从0开始单调递增的Sequence Number

Broker端在缓存中保存了这Sequence Numbler，对于接收的每条消息，如果其序号比Broker缓存中序号大于1则接受它，否则将其丢弃。这样就可以实现了消息重复提交了。但是，只能保证单个Producer对于同一个的Exactly Once语义。不能保证同一个Producer一个topic不同的partion幂等。

四面(HR面)

这里全靠自己发挥了

工作中遇到的最大挑战是什么，你如何克服的？
你最大的优点和最大的缺点，各自说一个？
缺点尽量说一些无关痛痒的，不要说自己不善于表达。
未来的职业发展，短期和长期的规划是什么？
实在迷茫没想法，想一想自己是不是有心力去钻研技术，有就说技术晋升路线，没有就管理晋升路线，百度或Google上有很多模板可以借鉴。

Java面试

2019-08-27T01:05:15.000Z

基础与常识

面向对象和面向过程的区别

面向过程 ：面向过程性能比面向对象高。 因为类调用时需要实例化，开销比较大，比较消耗资源，所以当性能是最重要的考量因素的时候，比如单片机、嵌入式开发、Linux/Unix等一般采用面向过程开发。但是，面向过程没有面向对象易维护、易复用、易扩展。
面向对象 ：面向对象易维护、易复用、易扩展。 因为面向对象有封装、继承、多态性的特性，所以可以设计出低耦合的系统，使系统更加灵活、更加易于维护。但是，面向对象性能比面向过程低。

Q:面向过程性能比面向对象高
A: 面向过程也需要分配内存，计算内存偏移量，Java性能差的主要原因并不是因为它是面向对象语言，而是Java是半编译语言，最终的执行代码并不是可以直接被CPU执行的二进制机械码。
而面向过程语言大多都是直接编译成机械码在电脑上执行，并且其它一些面向过程的脚本语言性能也并不一定比Java好。

关于`JVM`、`JDK`和`JRE`最详细通俗的解答

JVM

Java虚拟机（JVM）是运行 Java 字节码的虚拟机。JVM有针对不同系统的特定实现（Windows，Linux，macOS），目的是使用相同的字节码，它们都会给出相同的结果。

什么是字节码?采用字节码的好处是什么?

在 Java 中，JVM可以理解的代码就叫做字节码（即扩展名为 .class 的文件），它不面向任何特定的处理器，只面向虚拟机。Java 语言通过字节码的方式，在一定程度上解决了传统解释型语言执行效率低的问题，同时又保留了解释型语言可移植的特点。所以 Java 程序运行时比较高效，而且，由于字节码并不针对一种特定的机器，因此，Java程序无须重新编译便可在多种不同操作系统的计算机上运行。

Java 程序从源代码到运行一般有下面3步：

我们需要格外注意的是 .class->机器码这一步。在这一步 JVM 类加载器首先加载字节码文件，然后通过解释器逐行解释执行，这种方式的执行速度会相对比较慢。而且，有些方法和代码块是经常需要被调用的(也就是所谓的热点代码)，所以后面引进了 JIT 编译器，而JIT 属于运行时编译。当 JIT 编译器完成第一次编译后，其会将字节码对应的机器码保存下来，下次可以直接使用。而我们知道，机器码的运行效率肯定是高于 Java 解释器的。这也解释了我们为什么经常会说 Java 是编译与解释共存的语言。

HotSpot采用了惰性评估(Lazy Evaluation)的做法，根据二八定律，消耗大部分系统资源的只有那一小部分的代码（热点代码），而这也就是JIT所需要编译的部分。JVM会根据代码每次被执行的情况收集信息并相应地做出一些优化，因此执行的次数越多，它的速度就越快。JDK 9引入了一种新的编译模式AOT(Ahead of Time Compilation)，它是直接将字节码编译成机器码，这样就避免了JIT预热等各方面的开销。JDK支持分层编译和AOT协作使用。但是，AOT 编译器的编译质量是肯定比不上 JIT 编译器的。

JDK

JDK是Java Development Kit，它是功能齐全的Java SDK。它拥有JRE所拥有的一切，还有编译器（javac）和工具（如javadoc和jdb）。它能够创建和编译程序。

JRE

JRE 是 Java运行时环境。它是运行已编译 Java 程序所需的所有内容的集合，包括 Java虚拟机（JVM），Java类库，java命令和其他的一些基础构件。但是，它不能用于创建新程序。

如果你只是为了运行一下 Java 程序的话，那么你只需要安装 JRE 就可以了。如果你需要进行一些 Java 编程方面的工作，那么你就需要安装JDK了。但是，这不是绝对的。有时，即使您不打算在计算机上进行任何Java开发，仍然需要安装JDK。例如，如果要使用JSP部署Web应用程序，那么从技术上讲，您只是在应用程序服务器中运行Java程序。那你为什么需要JDK呢？因为应用程序服务器会将 JSP 转换为 Java servlet，并且需要使用 JDK 来编译 servlet。

`Oracle JDK` 和 `OpenJDK` 的对比

Oracle JDK版本将每三年发布一次，而OpenJDK版本每三个月发布一次；
OpenJDK 是一个参考模型并且是完全开源的，而Oracle JDK是OpenJDK的一个实现，并不是完全开源的；
Oracle JDK 比 OpenJDK 更稳定。OpenJDK和Oracle JDK的代码几乎相同，但Oracle JDK有更多的类和一些错误修复。因此，如果您想开发企业/商业软件，我建议您选择Oracle JDK，因为它经过了彻底的测试和稳定。某些情况下，有些人提到在使用OpenJDK 可能会遇到了许多应用程序崩溃的问题，但是，只需切换到Oracle JDK就可以解决问题；
在响应性和JVM性能方面，Oracle JDK与OpenJDK相比提供了更好的性能；
Oracle JDK不会为即将发布的版本提供长期支持，用户每次都必须通过更新到最新版本获得支持来获取最新版本；
Oracle JDK根据二进制代码许可协议获得许可，而OpenJDK根据GPL v2许可获得许可。

字符型常量和字符串常量的区别？

形式上: 字符常量是单引号引起的一个字符; 字符串常量是双引号引起的若干个字符
含义上: 字符常量相当于一个整型值( ASCII 值),可以参加表达式运算; 字符串常量代表一个地址值(该字符串在内存中存放位置)
占内存大小字符常量只占2个字节; 字符串常量占若干个字节(至少一个字符结束标志) (注意： char在Java中占两个字节)

java编程思想第四版：2.2.2节

构造器 Constructor 是否可被 override

在讲继承的时候我们就知道父类的私有属性和构造方法并不能被继承，所以 Constructor 也就不能被 override（重写）,但是可以 overload（重载）,所以你可以看到一个类中有多个构造函数的情况。

重载和重写的区别

重载： 发生在同一个类中，方法名必须相同，参数类型不同、个数不同、顺序不同，方法返回值和访问修饰符可以不同，发生在编译时。　　
重写： 发生在父子类中，方法名、参数列表必须相同，返回值范围小于等于父类，抛出的异常范围小于等于父类，访问修饰符范围大于等于父类；如果父类方法访问修饰符为 private 则子类就不能重写该方法。

Java 面向对象编程三大特性: 封装、继承、多态

封装

封装把一个对象的属性私有化，同时提供一些可以被外界访问的属性的方法，如果属性不想被外界访问，我们大可不必提供方法给外界访问。但是如果一个类没有提供给外界访问的方法，那么这个类也没有什么意义了。

继承

继承是使用已存在的类的定义作为基础建立新类的技术，新类的定义可以增加新的数据或新的功能，也可以用父类的功能，但不能选择性地继承父类。通过使用继承我们能够非常方便地复用以前的代码。

关于继承如下 3 点请记住：

子类拥有父类对象所有的属性和方法（包括私有属性和私有方法），但是父类中的私有属性和方法子类是无法访问，只是拥有。
子类可以拥有自己属性和方法，即子类可以对父类进行扩展。
子类可以用自己的方式实现父类的方法。（以后介绍）。

多态

所谓多态就是指程序中定义的引用变量所指向的具体类型和通过该引用变量发出的方法调用在编程时并不确定，而是在程序运行期间才确定，即一个引用变量到底会指向哪个类的实例对象，该引用变量发出的方法调用到底是哪个类中实现的方法，必须在由程序运行期间才能决定。

在Java中有两种形式可以实现多态：继承（多个子类对同一方法的重写）和接口（实现接口并覆盖接口中同一方法）。

`String`、`StringBuffer` 和 `StringBuilder` 的区别是什么? `String` 为什么是不可变的?

可变性

简单的来说：String 类中使用 final 关键字修饰字符数组来保存字符串，private　final　char　value[]，所以 String 对象是不可变的。而StringBuilder 与 StringBuffer 都继承自 AbstractStringBuilder 类，在 AbstractStringBuilder 中也是使用字符数组保存字符串char[]value 但是没有用 final 关键字修饰，所以这两种对象都是可变的。

StringBuilder 与 StringBuffer 的构造方法都是调用父类构造方法也就是 AbstractStringBuilder 实现的，大家可以自行查阅源码。

AbstractStringBuilder.java

abstract class AbstractStringBuilder implements Appendable, CharSequence {
    char[] value;
    int count;
    AbstractStringBuilder() {
    }
    AbstractStringBuilder(int capacity) {
        value = new char[capacity];
    }

线程安全性

String 中的对象是不可变的，也就可以理解为常量，线程安全。AbstractStringBuilder 是 StringBuilder 与 StringBuffer 的公共父类，定义了一些字符串的基本操作，如 expandCapacity、append、insert、indexOf 等公共方法。StringBuffer 对方法加了同步锁或者对调用的方法加了同步锁，所以是线程安全的。StringBuilder 并没有对方法进行加同步锁，所以是非线程安全的。　

性能

每次对 String 类型进行改变的时候，都会生成一个新的 String 对象，然后将指针指向新的 String 对象。StringBuffer 每次都会对 StringBuffer 对象本身进行操作，而不是生成新的对象并改变对象引用。相同情况下使用 StringBuilder 相比使用 StringBuffer 仅能获得 10%~15% 左右的性能提升，但却要冒多线程不安全的风险。

对于三者使用的总结：

操作少量的数据: 适用String
单线程操作字符串缓冲区下操作大量数据: 适用StringBuilder
多线程操作字符串缓冲区下操作大量数据: 适用StringBuffer

自动装箱与拆箱

装箱：将基本类型用它们对应的引用类型包装起来；
拆箱：将包装类型转换为基本数据类型；

在一个静态方法内调用一个非静态成员为什么是非法的?

由于静态方法可以不通过对象进行调用，因此在静态方法里，不能调用其他非静态变量，也不可以访问非静态变量成员。

接口和抽象类的区别是什么？

接口的方法默认是 public，所有方法在接口中不能有实现(Java 8 开始接口方法可以有默认实现），而抽象类可以有非抽象的方法。
接口中除了static、final变量，不能有其他变量，而抽象类中则不一定。
一个类可以实现多个接口，但只能实现一个抽象类。接口自己本身可以通过extends关键字扩展多个接口。
接口方法默认修饰符是public，抽象方法可以有public、protected和default这些修饰符（抽象方法就是为了被重写所以不能使用private关键字修饰！）。
从设计层面来说，抽象是对类的抽象，是一种模板设计，而接口是对行为的抽象，是一种行为的规范。

在JDK8中，接口也可以定义静态方法，可以直接用接口名调用。实现类和实现是不可以调用的。如果同时实现两个接口，接口中定义了一样的默认方法，则必须重写，不然会报错。
关于抽象类
JDK 1.8以前，抽象类的方法默认访问权限为protected
JDK 1.8时，抽象类的方法默认访问权限变为default
关于接口
JDK 1.8以前，接口中的方法必须是public的
JDK 1.8时，接口中的方法可以是public的，也可以是default的
JDK 1.9时，接口中的方法可以是private的

成员变量与局部变量的区别有哪些？

从语法形式上看:成员变量是属于类的，而局部变量是在方法中定义的变量或是方法的参数；成员变量可以被 public,private,static 等修饰符所修饰，而局部变量不能被访问控制修饰符及 static 所修饰；但是，成员变量和局部变量都能被 final 所修饰。
从变量在内存中的存储方式来看:如果成员变量是使用static修饰的，那么这个成员变量是属于类的，如果没有使用static修饰，这个成员变量是属于实例的。而对象存在于堆内存，局部变量则存在于栈内存。
从变量在内存中的生存时间上看:成员变量是对象的一部分，它随着对象的创建而存在，而局部变量随着方法的调用而自动消失。
成员变量如果没有被赋初值:则会自动以类型的默认值而赋值（一种情况例外:被 final 修饰的成员变量也必须显式地赋值），而局部变量则不会自动赋值。

创建一个对象用什么运算符?对象实体与对象引用有何不同?

new运算符，new创建对象实例（对象实例在堆内存中），对象引用指向对象实例（对象引用存放在栈内存中）。一个对象引用可以指向0个或1个对象（一根绳子可以不系气球，也可以系一个气球）;一个对象可以有n个引用指向它（可以用n条绳子系住一个气球）。

构造方法有哪些特性？

名字与类名相同。
没有返回值，但不能用void声明构造函数。
生成类的对象时自动执行，无需调用。

静态方法和实例方法有何不同

在外部调用静态方法时，可以使用”类名.方法名”的方式，也可以使用”对象名.方法名”的方式。而实例方法只有后面这种方式。也就是说，调用静态方法可以无需创建对象。
静态方法在访问本类的成员时，只允许访问静态成员（即静态成员变量和静态方法），而不允许访问实例成员变量和实例方法；实例方法则无此限制。

对象的相等与指向他们的引用相等,两者有什么不同?

对象的相等，比的是内存中存放的内容是否相等。而引用相等，比较的是他们指向的内存地址是否相等。

对象的相等一般指的是调用equals()方法进行比较
引用相等一般指==判等操作符进行比较

== 与 equals(重要)

== : 它的作用是判断两个对象的地址是不是相等。即，判断两个对象是不是同一个对象(基本数据类型==比较的是值，引用数据类型==比较的是内存地址)。

equals() : 它的作用也是判断两个对象是否相等。但它一般有两种使用情况：

情况1：类没有覆盖 equals() 方法。则通过 equals() 比较该类的两个对象时，等价于通过“==”比较这两个对象。
情况2：类覆盖了 equals() 方法。一般，我们都覆盖 equals() 方法来比较两个对象的内容是否相等；若它们的内容相等，则返回 true (即，认为这两个对象相等)。

举个例子：

public class test1 {
    public static void main(String[] args) {
        String a = new String("ab"); // a 为一个引用
        String b = new String("ab"); // b为另一个引用,对象的内容一样
        String aa = "ab"; // 放在常量池中
        String bb = "ab"; // 从常量池中查找
        if (aa == bb) // true
            System.out.println("aa==bb");
        if (a == b) // false，非同一对象
            System.out.println("a==b");
        if (a.equals(b)) // true
            System.out.println("aEQb");
        if (42 == 42.0) { // true
            System.out.println("true");
        }
    }
}

说明：

String 中的 equals 方法是被重写过的，因为 object 的 equals 方法是比较的对象的内存地址，而 String 的 equals 方法比较的是对象的值。
当创建 String 类型的对象时，虚拟机会在常量池中查找有没有已经存在的值和要创建的值相同的对象，如果有就把它赋给当前引用。如果没有就在常量池中重新创建一个 String 对象。

hashCode 与 equals (重要)

面试官可能会问你：”你重写过 hashcode 和 equals 么，为什么重写equals时必须重写hashCode方法？”

hashCode（）介绍

hashCode() 的作用是获取哈希码，也称为散列码；它实际上是返回一个int整数。这个哈希码的作用是确定该对象在哈希表中的索引位置。hashCode() 定义在JDK的Object.java中，这就意味着Java中的任何类都包含有hashCode() 函数。

散列表存储的是键值对(key-value)，它的特点是：能根据“键”快速的检索出对应的“值”。这其中就利用到了散列码！（可以快速找到所需要的对象）

为什么要有 hashCode

我们先以”HashSet 如何检查重复”为例子来说明为什么要有 hashCode： 当你把对象加入 HashSet 时，HashSet 会先计算对象的 hashcode 值来判断对象加入的位置，同时也会与其他已经加入的对象的 hashcode 值作比较，如果没有相符的hashcode，HashSet会假设对象没有重复出现。但是如果发现有相同 hashcode 值的对象，这时会调用 equals()方法来检查 hashcode 相等的对象是否真的相同。如果两者相同，HashSet 就不会让其加入操作成功。如果不同的话，就会重新散列到其他位置。（摘自我的Java启蒙书《Head first java》第二版）。这样我们就大大减少了 equals 的次数，相应就大大提高了执行速度。

通过我们可以看出：hashCode() 的作用就是获取哈希码，也称为散列码；它实际上是返回一个int整数。这个哈希码的作用是确定该对象在哈希表中的索引位置。**hashCode() 在散列表中才有用，在其它情况下没用。**在散列表中hashCode() 的作用是获取对象的散列码，进而确定该对象在散列表中的位置。

`hashCode()`与`equals()`的相关规定

如果两个对象相等，则hashcode一定也是相同的
两个对象相等,对两个对象分别调用equals方法都返回true
两个对象有相同的hashcode值，它们也不一定是相等的
因此，equals 方法被覆盖过，则 hashCode 方法也必须被覆盖
hashCode() 的默认行为是对堆上的对象产生独特值。如果没有重写 hashCode()，则该 class 的两个对象无论如何都不会相等（即使这两个对象指向相同的数据）

简述`程序`、`进程`、`线程`的基本概念。以及他们之间关系是什么?

程序是含有指令和数据的文件，被存储在磁盘或其他的数据存储设备中，也就是说程序是静态的代码。

进程是程序的一次执行过程，是系统运行程序的基本单位，因此进程是动态的。系统运行一个程序即是一个进程从创建，运行到消亡的过程。简单来说，一个进程就是一个执行中的程序，它在计算机中一个指令接着一个指令地执行着，同时，每个进程还占有某些系统资源如CPU时间，内存空间，文件，输入输出设备的使用权等等。换句话说，当程序在执行时，将会被操作系统载入内存中。

线程与进程相似，但线程是一个比进程更小的执行单位。一个进程在其执行的过程中可以产生多个线程。与进程不同的是同类的多个线程共享同一块内存空间和一组系统资源，所以系统在产生一个线程，或是在各个线程之间作切换工作时，负担要比进程小得多，也正因为如此，线程也被称为轻量级进程。

关系：线程是进程划分成的更小的运行单位。线程和进程最大的不同在于基本上各进程是独立的，而各线程则不一定，因为同一进程中的线程极有可能会相互影响。从另一角度来说，进程属于操作系统的范畴，主要是同一段时间内，可以同时执行一个以上的程序，而线程则是在同一程序内几乎同时执行一个以上的程序段。

线程有哪些基本状态？

Java 线程在运行的生命周期中的指定时刻只可能处于下面6种不同状态的其中一个状态（图源《Java 并发编程艺术》4.1.4节）:

线程在生命周期中并不是固定处于某一个状态而是随着代码的执行在不同状态之间切换。Java 线程状态变迁如下图所示（图源《Java 并发编程艺术》4.1.4节）：

由上图可以看出：

线程创建之后它将处于 NEW（新建） 状态，调用 start() 方法后开始运行，线程这时候处于 READY（可运行） 状态。可运行状态的线程获得了 cpu 时间片（timeslice）后就处于 RUNNING（运行） 状态。

操作系统隐藏 Java虚拟机（JVM）中的 RUNNABLE 和 RUNNING 状态，它只能看到 RUNNABLE 状态（图源：HowToDoInJava：Java Thread Life Cycle and Thread States），所以 Java 系统一般将这两个状态统称为 RUNNABLE（运行中） 状态。

当线程执行 wait()方法之后，线程进入 WAITING（等待） 状态。进入等待状态的线程需要依靠其他线程的通知才能够返回到运行状态，而 TIME_WAITING(超时等待) 状态相当于在等待状态的基础上增加了超时限制，比如通过 sleep（long millis）方法或 wait（long millis）方法可以将 Java 线程置于 TIMED WAITING 状态。当超时时间到达后 Java 线程将会返回到 RUNNABLE 状态。当线程调用同步方法时，在没有获取到锁的情况下，线程将会进入到 BLOCKED（阻塞） 状态。线程在执行 Runnable 的run()方法之后将会进入到 TERMINATED（终止） 状态。

关于 final 关键字的一些总结

final关键字主要用在三个地方：变量、方法、类。

对于一个final变量，如果是基本数据类型的变量，则其数值一旦在初始化之后便不能更改；如果是引用类型的变量，则在对其初始化之后便不能再让其指向另一个对象。
当用final修饰一个类时，表明这个类不能被继承。final类中的所有成员方法都会被隐式地指定为final方法。
使用final方法的原因有两个。第一个原因是把方法锁定，以防任何继承类修改它的含义；第二个原因是效率。在早期的Java实现版本中，会将final方法转为内嵌调用。但是如果方法过于庞大，可能看不到内嵌调用带来的任何性能提升（现在的Java版本已经不需要使用final方法进行这些优化了）。类中所有的private方法都隐式地指定为final。

Java 中的异常处理

Java异常类层次结构图

在 Java 中，所有的异常都有一个共同的祖先java.lang包中的 Throwable类。Throwable：有两个重要的子类：Exception（异常） 和 Error（错误） ，二者都是 Java 异常处理的重要子类，各自都包含大量子类。

Error（错误）:是程序无法处理的错误，表示运行应用程序中较严重问题。大多数错误与代码编写者执行的操作无关，而表示代码运行时 JVM（Java 虚拟机）出现的问题。例如，Java虚拟机运行错误（Virtual MachineError），当 JVM 不再有继续执行操作所需的内存资源时，将出现 OutOfMemoryError。这些异常发生时，Java虚拟机（JVM）一般会选择线程终止。

这些错误表示故障发生于虚拟机自身、或者发生在虚拟机试图执行应用时，如Java虚拟机运行错误（Virtual MachineError）、类定义错误（NoClassDefFoundError）等。这些错误是不可查的，因为它们在应用程序的控制和处理能力之外，而且绝大多数是程序运行时不允许出现的状况。对于设计合理的应用程序来说，即使确实发生了错误，本质上也不应该试图去处理它所引起的异常状况。在 Java中，错误通过Error的子类描述。

Exception（异常）:是程序本身可以处理的异常。Exception 类有一个重要的子类 RuntimeException。RuntimeException 异常由Java虚拟机抛出。NullPointerException（要访问的变量没有引用任何对象时，抛出该异常）、ArithmeticException（算术运算异常，一个整数除以0时，抛出该异常）和 ArrayIndexOutOfBoundsException （下标越界异常）。

注意：异常和错误的区别：异常能被程序本身处理，错误是无法处理。

Throwable类常用方法

public string getMessage():返回异常发生时的详细信息
public string toString():返回异常发生时的简要描述
public string getLocalizedMessage():返回异常对象的本地化信息。使用Throwable的子类覆盖这个方法，可以声称本地化信息。如果子类没有覆盖该方法，则该方法返回的信息与getMessage（）返回的结果相同
public void printStackTrace():在控制台上打印Throwable对象封装的异常信息

异常处理总结

try 块： 用于捕获异常。其后可接零个或多个catch块，如果没有catch块，则必须跟一个finally块。
catch 块： 用于处理try捕获到的异常。
finally 块： 无论是否捕获或处理异常，finally块里的语句都会被执行。当在try块或catch块中遇到return
语句时，finally语句块将在方法返回之前被执行。

在以下4种特殊情况下，finally块不会被执行：

在finally语句块第一行发生了异常。因为在其他行，finally块还是会得到执行
在前面的代码中用了System.exit(int)已退出程序。 exit是带参函数；若该语句在异常语句之后，finally会执行
程序所在的线程死亡。
关闭CPU。

注意： 当try语句和finally语句中都有return语句时，在方法返回之前，finally语句的内容将被执行，并且finally语句的返回值将会覆盖原始的返回值。如下：

public static int f(int value) {
    try {
        return value * value;
    } finally {
        if (value == 2) {
            return 0;
        }
    }
}

如果调用 f(2)，返回值将是0，因为finally语句的返回值覆盖了try语句块的返回值。

Java序列化中如果有些字段不想进行序列化，怎么办？

对于不想进行序列化的变量，使用transient关键字修饰,transient关键字的作用是：阻止实例中那些用此关键字修饰的的变量序列化；当对象被反序列化时，被transient修饰的变量值不会被持久化和恢复。transient只能修饰变量，不能修饰类和方法。

Java 中 IO 流分为几种？`BIO`,`NIO`,`AIO`有什么区别？

java 中 IO 流分为几种?

按照流的流向分，可以分为输入流和输出流；
按照操作单元划分，可以划分为字节流和字符流；
按照流的角色划分为节点流和处理流。

Java Io流共涉及40多个类，这些类看上去很杂乱，但实际上很有规则，而且彼此之间存在非常紧密的联系， Java I0流的40多个类都是从如下4个抽象类基类中派生出来的。

InputStream/Reader: 所有的输入流的基类，前者是字节输入流，后者是字符输入流。
OutputStream/Writer: 所有输出流的基类，前者是字节输出流，后者是字符输出流。

按操作方式分类结构图

按操作对象分类结构图

`BIO`,`NIO`,`AIO` 有什么区别?

BIO (Blocking I/O): 同步阻塞I/O模式，数据的读取写入必须阻塞在一个线程内等待其完成。在活动连接数不是特别高（小于单机1000）的情况下，这种模型是比较不错的，可以让每一个连接专注于自己的 I/O 并且编程模型简单，也不用过多考虑系统的过载、限流等问题。线程池本身就是一个天然的漏斗，可以缓冲一些系统处理不了的连接或请求。但是，当面对十万甚至百万级连接的时候，传统的 BIO 模型是无能为力的。因此，我们需要一种更高效的 I/O 处理模型来应对更高的并发量。
NIO (New I/O): NIO是一种同步非阻塞的I/O模型，在Java 1.4 中引入了NIO框架，对应 java.nio 包，提供了 Channel , Selector，Buffer等抽象。NIO中的N可以理解为Non-blocking，不单纯是New。它支持面向缓冲的，基于通道的I/O操作方法。 NIO提供了与传统BIO模型中的 Socket 和 ServerSocket 相对应的 SocketChannel 和 ServerSocketChannel 两种不同的套接字通道实现,两种通道都支持阻塞和非阻塞两种模式。阻塞模式使用就像传统中的支持一样，比较简单，但是性能和可靠性都不好；非阻塞模式正好与之相反。对于低负载、低并发的应用程序，可以使用同步阻塞I/O来提升开发速率和更好的维护性；对于高负载、高并发的（网络）应用，应使用 NIO 的非阻塞模式来开发
AIO (Asynchronous I/O): AIO 也就是 NIO 2。在 Java 7 中引入了 NIO 的改进版 NIO 2,它是异步非阻塞的IO模型。异步 IO 是基于事件和回调机制实现的，也就是应用操作之后会直接返回，不会堵塞在那里，当后台处理完成，操作系统会通知相应的线程进行后续的操作。AIO 是异步IO的缩写，虽然 NIO 在网络操作中，提供了非阻塞的方法，但是 NIO 的 IO 行为还是同步的。对于 NIO 来说，我们的业务线程是在 IO 操作准备好时，得到通知，接着就由这个线程自行进行 IO 操作，IO操作本身是同步的。查阅网上相关资料，我发现就目前来说 AIO 的应用还不是很广泛，Netty 之前也尝试使用过 AIO，不过又放弃了。

编码与实践

正确使用 `equals()` 方法

Object的equals方法容易抛空指针异常，应使用常量或确定有值的对象来调用 equals。

举个例子：

// 不能使用一个值为null的引用类型变量来调用非静态方法，否则会抛出异常
String str = null;
if (str.equals("SnailClimb")) {
  // Do sth...
} else {
  // Do sth...
}

运行上面的程序会抛出空指针异常，但是我们把第二行的条件判断语句改为下面这样的话，就不会抛出空指针异常，else 语句块得到执行。：

1 2	"SnailClimb".equals(str);// false

不过更推荐使用 java.util.Objects#equals(JDK7 引入的工具类)。

1 2	Objects.equals(null,"SnailClimb");// false

我们看一下java.util.Objects#equals的源码就知道原因了。

public static boolean equals(Object a, Object b) {
// 可以避免空指针异常。如果a==null的话此时a.equals(b)就不会得到执行，避免出现空指针异常。
    return (a == b) || (a != null && a.equals(b));
}

注意：

每种原始类型都有默认值一样，如int默认值为 0，boolean 的默认值为 false，null 是任何引用类型的默认值，不严格的说是所有 Object 类型的默认值
可以使用==或者!=操作来比较null值，但是不能使用其他算法或者逻辑操作。在Java中null==null将返回true
不能使用一个值为null的引用类型变量来调用非静态方法，否则会抛出异常

整形包装类值的比较

所有整形包装类对象值得比较必须使用equals方法。

先看下面这个例子：

Integer x = 3;
Integer y = 3;
System.out.println(x == y);// true
Integer a = new Integer(3);
Integer b = new Integer(3);
System.out.println(a == b);//false
System.out.println(a.equals(b));//true

当使用自动装箱方式创建一个Integer对象时，当数值在-128~127时，会将创建的 Integer对象缓存起来，当下次再出现该数值时，直接从缓存中取出对应的Integer对象。所以上述代码中，x和y引用的是相同的Integer对象。

注意：如果你的IDE(IDEA/Eclipse/MyEclipse)上安装了阿里巴巴的p3c插件，这个插件如果检测到你用 ==的话会报错提示，推荐安装一个这个插件，很不错。

BigDecimal

BigDecimal 的用处

《阿里巴巴Java开发手册》 中提到：浮点数之间的等值判断，基本数据类型不能用==来比较，包装数据类型不能用 equals 来判断。 具体原理和浮点数的编码方式有关，这里就不多提了，我们下面直接上实例：

float a = 1.0f - 0.9f;
float b = 0.9f - 0.8f;
System.out.println(a);// 0.100000024
System.out.println(b);// 0.099999964
System.out.println(a == b);// false

具有基本数学知识的我们很清楚的知道输出并不是我们想要的结果（精度丢失），我们如何解决这个问题呢？一种很常用的方法是：使用使用 BigDecimal 来定义浮点数的值，再进行浮点数的运算操作。

BigDecimal a = new BigDecimal("1.0");
BigDecimal b = new BigDecimal("0.9");
BigDecimal c = new BigDecimal("0.8");
BigDecimal x = a.subtract(b);// 0.1
BigDecimal y = b.subtract(c);// 0.1
System.out.println(x.equals(y));// true

BigDecimal 的大小比较

a.compareTo(b) : 返回 -1 表示小于，0 表示等于， 1表示大于。

BigDecimal a = new BigDecimal("1.0");
BigDecimal b = new BigDecimal("0.9");
System.out.println(a.compareTo(b));// 1

BigDecimal 保留几位小数

通过 setScale方法设置保留几位小数以及保留规则。保留规则有挺多种，不需要记，IDEA会提示。

BigDecimal m = new BigDecimal("1.255433");
BigDecimal n = m.setScale(3,BigDecimal.ROUND_HALF_DOWN);
System.out.println(n);// 1.255

BigDecimal 的使用注意事项

注意：我们在使用BigDecimal时，为了防止精度丢失，推荐使用它的 BigDecimal(String) 构造方法来创建对象。《阿里巴巴Java开发手册》对这部分内容也有提到如下图所示。

总结

BigDecimal 主要用来操作（大）浮点数，BigInteger 主要用来操作大整数（超过 long 类型）
BigDecimal 的实现利用到了 BigInteger, 所不同的是 BigDecimal 加入了小数位的概念

基本数据类型与包装数据类型的使用标准

Reference:《阿里巴巴Java开发手册》

【强制】所有的 POJO 类属性必须使用包装数据类型。
【强制】RPC 方法的返回值和参数必须使用包装数据类型。
【推荐】所有的局部变量使用基本数据类型。

比如我们如果自定义了一个Student类,其中有一个属性是成绩score,如果用Integer而不用int定义,一次考试,学生可能没考,值是null,也可能考了,但考了0分,值是0,这两个表达的状态明显不一样.

说明 :POJO类属性没有初值是提醒使用者在需要使用时，必须自己显式地进行赋值，任何 NPE问题，或者入库检查，都由使用者来保证。

正例 : 数据库的查询结果可能是null，因为自动拆箱，用基本数据类型接收有NPE 风险。

反例 : 比如显示成交总额涨跌情况，即±x%，x为基本数据类型，调用的RPC服务，调用不成功时，返回的是默认值，页面显示为 0%，这是不合理的，应该显示成中划线。所以包装数据类型的 null 值，能够表示额外的信息，如:远程调用失败，异常退出。

NPE:NullPointerException即空指针异常

集合的转换与注意事项

简介

Arrays.asList()在平时开发中还是比较常见的，我们可以使用它将一个数组转换为一个List集合。

String[] myArray = { "Apple", "Banana", "Orange" }； 
List myList = Arrays.asList(myArray);
//上面两个语句等价于下面一条语句
List myList = Arrays.asList("Apple","Banana", "Orange");

JDK 源码对于这个方法的说明：

/**
 *返回由指定数组支持的固定大小的列表。此方法作为基于数组和基于集合的API之间的桥梁，与 Collection.toArray()结合使用。返回的List是可序列化并实现RandomAccess接口。
 */ 
public static  List asList(T... a) {
    return new ArrayList<>(a);
}

阿里巴巴Java 开发手册》对其的描述

Arrays.asList()将数组转换为集合后,底层其实还是数组，《阿里巴巴Java 开发手册》对于这个方法有如下描述：

使用时的注意事项总结

传递的数组必须是对象数组，而不是基本类型。

Arrays.asList()是泛型方法，传入的对象必须是对象数组。

int[] myArray = { 1, 2, 3 };
List myList = Arrays.asList(myArray);
System.out.println(myList.size());//1
System.out.println(myList.get(0));//数组地址值
System.out.println(myList.get(1));//报错：ArrayIndexOutOfBoundsException
int [] array=(int[]) myList.get(0);
System.out.println(array[0]);//1

当传入一个原生数据类型数组时，Arrays.asList() 的真正得到的参数就不是数组中的元素，而是数组对象本身！此时List 的唯一元素就是这个数组，这也就解释了上面的代码。

我们使用包装类型数组就可以解决这个问题。

1 2	Integer[] myArray = { 1, 2, 3 };

使用集合的修改方法:add()、remove()、clear()会抛出异常。

List myList = Arrays.asList(1, 2, 3);
myList.add(4);//运行时报错：UnsupportedOperationException
myList.remove(1);//运行时报错：UnsupportedOperationException
myList.clear();//运行时报错：UnsupportedOperationException

Arrays.asList() 方法返回的并不是 java.util.ArrayList ，而是 java.util.Arrays 的一个内部类,这个内部类并没有实现集合的修改方法或者说并没有重写这些方法。

1
2
3

List myList = Arrays.asList(1, 2, 3);
System.out.println(myList.getClass());//class java.util.Arrays$ArrayList

下图是java.util.Arrays$ArrayList的简易源码，我们可以看到这个类重写的方法有哪些。

private static class ArrayList extends AbstractList
      implements RandomAccess, java.io.Serializable
  {
      ...

      @Override
      public E get(int index) {
        ...
      }

      @Override
      public E set(int index, E element) {
        ...
      }

      @Override
      public int indexOf(Object o) {
        ...
      }

      @Override
      public boolean contains(Object o) {
         ...
      }

      @Override
      public void forEach(Consumersuper E> action) {
        ...
      }

      @Override
      public void replaceAll(UnaryOperator operator) {
        ...
      }

      @Override
      public void sort(Comparatorsuper E> c) {
        ...
      }
  }

我们再看一下java.util.AbstractList的remove()方法，这样我们就明白为啥会抛出UnsupportedOperationException。

public E remove(int index) {
    throw new UnsupportedOperationException();
}

如何正确的将数组转换为ArrayList？

1. 自己动手实现（教育目的）

//JDK1.5+
static  List arrayToList(final T[] array) {
  final List l = new ArrayList(array.length);

  for (final T s : array) {
    l.add(s);
  }
  return (l);
}

1
2
3

Integer [] myArray = { 1, 2, 3 };
System.out.println(arrayToList(myArray).getClass());//class java.util.ArrayList

2. 最简便的方法(推荐)

1 2	List list = new ArrayList<>(Arrays.asList("a", "b", "c"));

3. 使用 Java8 的Stream(推荐)

Integer [] myArray = { 1, 2, 3 };
List myList = Arrays.stream(myArray).collect(Collectors.toList());
//基本类型也可以实现转换（依赖boxed的装箱操作）
int [] myArray2 = { 1, 2, 3 };
List myList = Arrays.stream(myArray2).boxed().collect(Collectors.toList());

4. 使用 Guava(推荐)

对于不可变集合，你可以使用ImmutableList类及其of()与copyOf()工厂方法：（参数不能为空）

1
2
3

List il = ImmutableList.of("string", "elements");  // from varargs
List il = ImmutableList.copyOf(aStringArray);      // from array

对于可变集合，你可以使用Lists类及其newArrayList()工厂方法：

List l1 = Lists.newArrayList(anotherListOrCollection);    // from collection
List l2 = Lists.newArrayList(aStringArray);               // from array
List l3 = Lists.newArrayList("or", "string", "elements"); // from varargs

5. 使用 Apache Commons Collections

1
2
3

List list = new ArrayList();
CollectionUtils.addAll(list, str);

Collection.toArray()方法使用的坑与如何反转数组

该方法是一个泛型方法： T[] toArray(T[] a); 如果toArray方法中没有传递任何参数的话返回的是Object类型数组。

String [] s= new String[]{
    "dog", "lazy", "a", "over", "jumps", "fox", "brown", "quick", "A"
};
List list = Arrays.asList(s);
Collections.reverse(list);
s=list.toArray(new String[0]);//没有指定类型的话会报错

由于JVM优化，new String[0]作为Collection.toArray()方法的参数现在使用更好，new String[0]就是起一个模板的作用，指定了返回数组的类型，0是为了节省空间，因为它只是为了说明返回的类型。

不要在 foreach 循环里进行元素的 remove/add 操作

如果要进行remove操作，可以调用迭代器的 remove 方法而不是集合类的 remove 方法。因为如果列表在任何时间从结构上修改创建迭代器之后，以任何方式除非通过迭代器自身remove/add方法，迭代器都将抛出一个ConcurrentModificationException,这就是单线程状态下产生的 fail-fast 机制。

fail-fast 机制 ：多个线程对 fail-fast 集合进行修改的时，可能会抛出ConcurrentModificationException，单线程下也会出现这种情况，上面已经提到过。

java.util包下面的所有的集合类都是fail-fast的，而java.util.concurrent包下面的所有的类都是fail-safe的。

泛型的实际应用

实现最小值函数

自己设计一个泛型的获取数组最小值的函数.并且这个方法只能接受Number的子类并且实现了Comparable接口。

//注意：Number并没有实现Comparable
private static extends Number & Comparablesuper T>> T min(T[] values) {
    if (values == null || values.length == 0) return null;
    T min = values[0];
    for (int i = 1; i < values.length; i++) {
        if (min.compareTo(values[i]) > 0) min = values[i];
    }
    return min;
}

测试：

int minInteger = min(new Integer[]{1, 2, 3});//result:1
double minDouble = min(new Double[]{1.2, 2.2, -1d});//result:-1d
String typeError = min(new String[]{"1","3"});//报错

数据结构

使用数组实现栈

自己实现一个栈，要求这个栈具有push()、pop()（返回栈顶元素并出栈）、peek() （返回栈顶元素不出栈）、isEmpty()、size()这些基本的方法。

提示：每次入栈之前先判断栈的容量是否够用，如果不够用就用Arrays.copyOf()进行扩容；

public class MyStack {
    private int[] storage;//存放栈中元素的数组
    private int capacity;//栈的容量
    private int count;//栈中元素数量
    private static final int GROW_FACTOR = 2;

    //TODO：不带初始容量的构造方法。默认容量为8
    public MyStack() {
        this.capacity = 8;
        this.storage=new int[8];
        this.count = 0;
    }

    //TODO：带初始容量的构造方法
    public MyStack(int initialCapacity) {
        if (initialCapacity < 1)
            throw new IllegalArgumentException("Capacity too small.");

        this.capacity = initialCapacity;
        this.storage = new int[initialCapacity];
        this.count = 0;
    }

    //TODO：入栈
    public void push(int value) {
        if (count == capacity) {
            ensureCapacity();
        }
        storage[count++] = value;
    }

    //TODO：确保容量大小
    private void ensureCapacity() {
        int newCapacity = capacity * GROW_FACTOR;
        storage = Arrays.copyOf(storage, newCapacity);
        capacity = newCapacity;
    }

    //TODO：返回栈顶元素并出栈
    private int pop() {
        count--;
        if (count == -1)
            throw new IllegalArgumentException("Stack is empty.");

        return storage[count];
    }

    //TODO：返回栈顶元素不出栈
    private int peek() {
        if (count == 0){
            throw new IllegalArgumentException("Stack is empty.");
        }else {
            return storage[count-1];
        }
    }

    //TODO：判断栈是否为空
    private boolean isEmpty() {
        return count == 0;
    }

    //TODO：返回栈中元素的个数
    private int size() {
        return count;
    }

}

验证

MyStack myStack = new MyStack(3);
myStack.push(1);
myStack.push(2);
myStack.push(3);
myStack.push(4);
myStack.push(5);
myStack.push(6);
myStack.push(7);
myStack.push(8);
System.out.println(myStack.peek());//8
System.out.println(myStack.size());//8
for (int i = 0; i < 8; i++) {
    System.out.println(myStack.pop());
}
System.out.println(myStack.isEmpty());//true
myStack.pop();//报错：java.lang.IllegalArgumentException: Stack is empty.

JavaEE知识

Servlet总结

在Java Web程序中，Servlet主要负责接收用户请求 HttpServletRequest,在doGet(),doPost()中做相应的处理，并将回应HttpServletResponse反馈给用户。Servlet 可以设置初始化参数，供Servlet内部使用。一个Servlet类只会有一个实例，在它初始化时调用init()方法，销毁时调用destroy()方法。Servlet需要在web.xml中配置（MyEclipse中创建Servlet会自动配置），一个Servlet可以设置多个URL访问。Servlet不是线程安全，因此要谨慎使用类变量。

阐述Servlet和CGI的区别?

CGI的不足之处:

需要为每个请求启动一个操作CGI程序的系统进程。如果请求频繁，这将会带来很大的开销。
需要为每个请求加载和运行一个CGI程序，这将带来很大的开销
需要重复编写处理网络协议的代码以及编码，这些工作都是非常耗时的。

Servlet的优点:

只需要启动一个操作系统进程以及加载一个JVM，大大降低了系统的开销
如果多个请求需要做同样处理的时候，这时候只需要加载一个类，这也大大降低了开销
所有动态加载的类可以实现对网络协议以及请求解码的共享，大大降低了工作量。
Servlet能直接和Web服务器交互，而普通的CGI程序不能。Servlet还能在各个程序之间共享数据，使数据库连接池之类的功能很容易实现。

补充：Sun Microsystems公司在1996年发布Servlet技术就是为了和CGI进行竞争，Servlet是一个特殊的Java程序，一个基于Java的Web应用通常包含一个或多个Servlet类。Servlet不能够自行创建并执行，它是在Servlet容器中运行的，容器将用户的请求传递给Servlet程序，并将Servlet的响应回传给用户。通常一个Servlet会关联一个或多个JSP页面。以前CGI经常因为性能开销上的问题被诟病，然而Fast CGI早就已经解决了CGI效率上的问题，所以面试的时候大可不必信口开河的诟病CGI，事实上有很多你熟悉的网站都使用了CGI技术。

Servlet接口中有哪些方法及Servlet生命周期探秘

Servlet接口定义了5个方法，其中前三个方法与Servlet生命周期相关：

void init(ServletConfig config) throws ServletException
void service(ServletRequest req, ServletResponse resp) throws ServletException, java.io.IOException
void destroy()
java.lang.String getServletInfo()
ServletConfig getServletConfig()

生命周期： Web容器加载Servlet并将其实例化后，Servlet生命周期开始，容器运行其init()方法进行Servlet的初始化；请求到达时调用Servlet的service()方法，service()方法会根据需要调用与请求对应的doGet或doPost等方法；当服务器关闭或项目被卸载时服务器会将Servlet实例销毁，此时会调用Servlet的destroy()方法。init方法和destroy方法只会执行一次，service方法客户端每次请求Servlet都会执行。Servlet中有时会用到一些需要初始化与销毁的资源，因此可以把初始化资源的代码放入init方法中，销毁资源的代码放入destroy方法中，这样就不需要每次处理客户端的请求都要初始化与销毁资源。

get和post请求的区别

网上也有文章说：get和post请求实际上是没有区别，大家可以自行查询相关文章（参考文章：https://www.cnblogs.com/logsharing/p/8448446.html，知乎对应的问题链接：get和post区别？）！我下面给出的只是一种常见的答案。

get请求用来从服务器上获得资源，而post是用来向服务器提交数据；
get将表单中数据按照name=value的形式，添加到action 所指向的URL 后面，并且两者使用”?”连接，而各个变量之间使用”&”连接；post是将表单中的数据放在HTTP协议的请求头或消息体中，传递到action所指向URL；
get传输的数据要受到URL长度限制（最大长度是 2048 个字符）；而post可以传输大量的数据，上传文件通常要使用post方式；
使用get时参数会显示在地址栏上，如果这些数据不是敏感数据，那么可以使用get；对于敏感数据还是应用使用post；
5.get使用MIME类型application/x-www-form-urlencoded的URL编码（也叫百分号编码）文本的格式传递参数，保证被传送的参数由遵循规范的文本组成，例如一个空格的编码是%20。

补充：GET方式提交表单的典型应用是搜索引擎。GET方式就是被设计为查询用的。

还有另外一种回答。推荐大家看一下：

什么情况下调用doGet()和doPost()

Form标签里的method的属性为get时调用doGet()，为post时调用doPost()。

转发(Forward)和重定向(Redirect)的区别

转发是服务器行为，重定向是客户端行为。

转发（Forward）

通过RequestDispatcher对象的forward（HttpServletRequest request,HttpServletResponse response）方法实现的。RequestDispatcher可以通过HttpServletRequest 的getRequestDispatcher()方法获得。例如下面的代码就是跳转到login_success.jsp页面。

1 2	request.getRequestDispatcher("login_success.jsp").forward(request, response);

重定向（Redirect） 是利用服务器返回的状态码来实现的。客户端浏览器请求服务器的时候，服务器会返回一个状态码。服务器通过 HttpServletResponse 的 setStatus(int status) 方法设置状态码。如果服务器返回301或者302，则浏览器会到新的网址重新请求该资源。

从地址栏显示来说

forward是服务器请求资源,服务器直接访问目标地址的URL,把那个URL的响应内容读取过来,然后把这些内容再发给浏览器.浏览器根本不知道服务器发送的内容从哪里来的,所以它的地址栏还是原来的地址.
redirect是服务端根据逻辑,发送一个状态码,告诉浏览器重新去请求那个地址.所以地址栏显示的是新的URL.

从数据共享来说

forward:转发页面和转发到的页面可以共享request里面的数据.
redirect:不能共享数据.

从运用地方来说

forward:一般用于用户登陆的时候,根据角色转发到相应的模块.
redirect:一般用于用户注销登陆时返回主页面和跳转到其它的网站等

从效率来说

forward:高.
redirect:低.

自动刷新(Refresh)

自动刷新不仅可以实现一段时间之后自动跳转到另一个页面，还可以实现一段时间之后自动刷新本页面。Servlet中通过HttpServletResponse对象设置Header属性实现自动刷新例如：

1 2	Response.setHeader("Refresh","5;URL=http://localhost:8080/servlet/example.htm");

其中5为时间，单位为秒。URL指定就是要跳转的页面（如果设置自己的路径，就会实现每过5秒自动刷新本页面一次）

Servlet与线程安全

Servlet不是线程安全的，多线程并发的读写会导致数据不同步的问题。 解决的办法是尽量不要定义name属性，而是要把name变量分别定义在doGet()和doPost()方法内。虽然使用synchronized(name){}语句块可以解决问题，但是会造成线程的等待，不是很科学的办法。
注意：多线程的并发的读写Servlet类属性会导致数据不同步。但是如果只是并发地读取属性而不写入，则不存在数据不同步的问题。因此Servlet里的只读属性最好定义为final类型的。

JSP和Servlet是什么关系

其实这个问题在上面已经阐述过了，Servlet是一个特殊的Java程序，它运行于服务器的JVM中，能够依靠服务器的支持向浏览器提供显示内容。JSP本质上是Servlet的一种简易形式，JSP会被服务器处理成一个类似于Servlet的Java程序，可以简化页面内容的生成。Servlet和JSP最主要的不同点在于，Servlet的应用逻辑是在Java文件中，并且完全从表示层中的HTML分离开来。而JSP的情况是Java和HTML可以组合成一个扩展名为.jsp的文件。有人说，Servlet就是在Java中写HTML，而JSP就是在HTML中写Java代码，当然这个说法是很片面且不够准确的。JSP侧重于视图，Servlet更侧重于控制逻辑，在MVC架构模式中，JSP适合充当视图（view）而Servlet适合充当控制器（controller）。

JSP工作原理

JSP是一种Servlet，但是与HttpServlet的工作方式不太一样。HttpServlet是先由源代码编译为class文件后部署到服务器下，为先编译后部署。而JSP则是先部署后编译。JSP会在客户端第一次请求JSP文件时被编译为HttpJspPage类（接口Servlet的一个子类）。该类会被服务器临时存放在服务器工作目录里面。下面通过实例给大家介绍。
工程JspLoginDemo下有一个名为login.jsp的Jsp文件，把工程第一次部署到服务器上后访问这个Jsp文件，我们发现这个目录下多了下图这两个东东。
.class文件便是JSP对应的Servlet。编译完毕后再运行class文件来响应客户端请求。以后客户端访问login.jsp的时候，Tomcat将不再重新编译JSP文件，而是直接调用class文件来响应客户端请求。

由于JSP只会在客户端第一次请求的时候被编译，因此第一次请求JSP时会感觉比较慢，之后就会感觉快很多。如果把服务器保存的class文件删除，服务器也会重新编译JSP。

开发Web程序时经常需要修改JSP。Tomcat能够自动检测到JSP程序的改动。如果检测到JSP源代码发生了改动。Tomcat会在下次客户端请求JSP时重新编译JSP，而不需要重启Tomcat。这种自动检测功能是默认开启的，检测改动会消耗少量的时间，在部署Web应用的时候可以在web.xml中将它关掉。

JSP有哪些内置对象、作用分别是什么

JSP内置对象 - CSDN博客

JSP有9个内置对象：

request：封装客户端的请求，其中包含来自GET或POST请求的参数；
response：封装服务器对客户端的响应；
pageContext：通过该对象可以获取其他对象；
session：封装用户会话的对象；
application：封装服务器运行环境的对象；
out：输出服务器响应的输出流对象；
config：Web应用的配置对象；
page：JSP页面本身（相当于Java程序中的this）；
exception：封装页面抛出异常的对象。

Request对象的主要方法有哪些

setAttribute(String name,Object)：设置名字为name的request 的参数值
getAttribute(String name)：返回由name指定的属性值
getAttributeNames()：返回request 对象所有属性的名字集合，结果是一个枚举的实例
getCookies()：返回客户端的所有 Cookie 对象，结果是一个Cookie 数组
getCharacterEncoding() ：返回请求中的字符编码方式 = getContentLength() ：返回请求的 Body的长度
getHeader(String name) ：获得HTTP协议定义的文件头信息
getHeaders(String name) ：返回指定名字的request Header 的所有值，结果是一个枚举的实例
getHeaderNames() ：返回所以request Header 的名字，结果是一个枚举的实例
getInputStream() ：返回请求的输入流，用于获得请求中的数据
getMethod() ：获得客户端向服务器端传送数据的方法
getParameter(String name) ：获得客户端传送给服务器端的有 name指定的参数值
getParameterNames() ：获得客户端传送给服务器端的所有参数的名字，结果是一个枚举的实例
getParameterValues(String name)：获得有name指定的参数的所有值
getProtocol()：获取客户端向服务器端传送数据所依据的协议名称
getQueryString() ：获得查询字符串
getRequestURI() ：获取发出请求字符串的客户端地址
getRemoteAddr()：获取客户端的 IP 地址
getRemoteHost() ：获取客户端的名字
getSession([Boolean create]) ：返回和请求相关 Session
getServerName() ：获取服务器的名字
getServletPath()：获取客户端所请求的脚本文件的路径
getServerPort()：获取服务器的端口号
removeAttribute(String name)：删除请求中的一个属性

request.getAttribute()和 request.getParameter()有何区别

从获取方向来看：

getParameter()是获取 POST/GET 传递的参数值；

getAttribute()是获取对象容器中的数据值；

从用途来看：

getParameter()用于客户端重定向时，即点击了链接或提交按扭时传值用，即用于在用表单或url重定向传值时接收数据用。

getAttribute() 用于服务器端重定向时，即在 sevlet 中使用了 forward 函数,或 struts 中使用了
mapping.findForward。 getAttribute 只能收到程序用 setAttribute 传过来的值。

另外，可以用 setAttribute(),getAttribute() 发送接收对象.而 getParameter() 显然只能传字符串。
setAttribute() 是应用服务器把这个对象放在该页面所对应的一块内存中去，当你的页面服务器重定向到另一个页面时，应用服务器会把这块内存拷贝另一个页面所对应的内存中。这样getAttribute()就能取得你所设下的值，当然这种方法可以传对象。session也一样，只是对象在内存中的生命周期不一样而已。getParameter()只是应用服务器在分析你送上来的 request页面的文本时，取得你设在表单或 url 重定向时的值。

总结：

getParameter()返回的是String,用于读取提交的表单中的值;（获取之后会根据实际需要转换为自己需要的相应类型，比如整型，日期类型啊等等）

getAttribute()返回的是Object，需进行转换,可用setAttribute()设置成任意对象，使用很灵活，可随时用

include指令include的行为的区别

include指令： JSP可以通过include指令来包含其他文件。被包含的文件可以是JSP文件、HTML文件或文本文件。包含的文件就好像是该JSP文件的一部分，会被同时编译执行。语法格式如下：
<%@ include file="文件相对 url 地址" %>

include动作：动作元素用来包含静态和动态的文件。该动作把指定文件插入正在生成的页面。语法格式如下：

JSP九大内置对象，七大动作，三大指令

JSP九大内置对象，七大动作，三大指令总结

讲解JSP中的四种作用域

JSP中的四种作用域包括page、request、session和application，具体来说：

page代表与一个页面相关的对象和属性。
request代表与Web客户机发出的一个请求相关的对象和属性。一个请求可能跨越多个页面，涉及多个Web组件；需要在页面显示的临时数据可以置于此作用域。
session代表与某个用户与服务器建立的一次会话相关的对象和属性。跟某个用户相关的数据应该放在用户自己的session中。
application代表与整个Web应用程序相关的对象和属性，它实质上是跨越整个Web应用程序，包括多个页面、请求和会话的一个全局作用域。

如何实现JSP或Servlet的单线程模式

对于JSP页面，可以通过page指令进行设置。
<%@page isThreadSafe=”false”%>

对于Servlet，可以让自定义的Servlet实现SingleThreadModel标识接口。

说明：如果将JSP或Servlet设置成单线程工作模式，会导致每个请求创建一个Servlet实例，这种实践将导致严重的性能问题（服务器的内存压力很大，还会导致频繁的垃圾回收），所以通常情况下并不会这么做。

实现会话跟踪的技术有哪些

使用Cookie

向客户端发送Cookie

Cookie c =new Cookie("name","value"); //创建Cookie 
c.setMaxAge(60*60*24); //设置最大时效，此处设置的最大时效为一天
response.addCookie(c); //把Cookie放入到HTTP响应中

从客户端读取Cookie

String name ="name"; 
Cookie[]cookies =request.getCookies(); 
if(cookies !=null){ 
   for(int i= 0;i
    Cookie cookie =cookies[i]; 
    if(name.equals(cookis.getName())) 
    //something is here. 
    //you can get the value 
    cookie.getValue(); 
       
   }
 }

优点: 数据可以持久保存，不需要服务器资源，简单，基于文本的Key-Value

缺点: 大小受到限制，用户可以禁用Cookie功能，由于保存在本地，有一定的安全风险。

URL 重写

在URL中添加用户会话的信息作为请求的参数，或者将唯一的会话ID添加到URL结尾以标识一个会话。

优点： 在Cookie被禁用的时候依然可以使用

缺点： 必须对网站的URL进行编码，所有页面必须动态生成，不能用预先记录下来的URL进行访问。

隐藏的表单域

1 2	<input type="hidden" name ="session" value="..."/>

优点： Cookie被禁时可以使用

缺点： 所有页面必须是表单提交之后的结果。

HttpSession

在所有会话跟踪技术中，HttpSession对象是最强大也是功能最多的。当一个用户第一次访问某个网站时会自动创建 HttpSession，每个用户可以访问他自己的HttpSession。可以通过HttpServletRequest对象的getSession方法获得HttpSession，通过HttpSession的setAttribute方法可以将一个值放在HttpSession中，通过调用 HttpSession对象的getAttribute方法，同时传入属性名就可以获取保存在HttpSession中的对象。与上面三种方式不同的是，HttpSession放在服务器的内存中，因此不要将过大的对象放在里面，即使目前的Servlet容器可以在内存将满时将HttpSession 中的对象移到其他存储设备中，但是这样势必影响性能。添加到HttpSession中的值可以是任意Java对象，这个对象最好实现了 Serializable接口，这样Servlet容器在必要的时候可以将其序列化到文件中，否则在序列化时就会出现异常。

Cookie和Session的的区别

Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。

Cookie 一般用来保存用户信息
比如:

我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；
一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；
登录一次网站后访问网站其他页面不需要重新登录。Session 的主要作用就是通过服务端记录用户的状态。 典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。

Cookie 存储在客户端中，而Session存储在服务器上，相对来说 Session 安全性更高。如果使用 Cookie 的一些敏感信息不要写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。

容器

说说List,Set,Map三者的区别？

List(对付顺序的好帮手)： List接口存储一组不唯一（可以有多个元素引用相同的对象），有序的对象
Set(注重独一无二的性质): 不允许重复的集合。不会有多个元素引用相同的对象。
Map(用Key来搜索的专家): 使用键值对存储。Map会维护与Key有关联的值。两个Key可以引用相同的对象，但Key不能重复，典型的Key是String类型，但也可以是任何对象。

Arraylist 与 LinkedList 区别?

1. 是否保证线程安全： ArrayList 和 LinkedList 都是不同步的，也就是不保证线程安全；
2. 底层数据结构： Arraylist 底层使用的是 Object 数组；LinkedList 底层使用的是 双向链表 数据结构（JDK1.6之前为循环链表，JDK1.7取消了循环。注意双向链表和双向循环链表的区别，下面有介绍到！）
3. 插入和删除是否受元素位置的影响：
1. ArrayList 采用数组存储，所以插入和删除元素的时间复杂度受元素位置的影响。 比如：执行add(E e) 方法的时候， ArrayList 会默认在将指定的元素追加到此列表的末尾，这种情况时间复杂度就是O(1)。但是如果要在指定位置 i 插入和删除元素的话（add(int index, E element) ）时间复杂度就为 O(n-i)。因为在进行上述操作的时候集合中第 i 和第 i 个元素之后的(n-i)个元素都要执行向后位/向前移一位的操作。
2. LinkedList 采用链表存储，所以插入，删除元素时间复杂度不受元素位置的影响，都是近似 O（1）而数组为近似 O（n）。
4. 是否支持快速随机访问：LinkedList 不支持高效的随机元素访问，而 ArrayList 支持。快速随机访问就是通过元素的序号快速获取元素对象(对应于get(int index) 方法)。
5. 内存空间占用：ArrayList的空间浪费主要体现在在list列表的结尾会预留一定的容量空间，而LinkedList的空间花费则体现在它的每一个元素都需要消耗比ArrayList更多的空间（因为要存放直接后继和直接前驱以及数据）。

补充内容:RandomAccess接口

1
2
3

public interface RandomAccess {
}

查看源码我们发现实际上 RandomAccess 接口中什么都没有定义。所以，在我看来 RandomAccess 接口不过是一个标识罢了。标识什么？标识实现这个接口的类具有随机访问功能。

在 binarySearch（）方法中，它要判断传入的list 是否 RamdomAccess 的实例，如果是，调用indexedBinarySearch（）方法，如果不是，那么调用iteratorBinarySearch（）方法

public static  int binarySearch(Listsuper T>> list, T key) {
if (list instanceof RandomAccess || list.size()
return Collections.indexedBinarySearch(list, key);
else
return Collections.iteratorBinarySearch(list, key);
}

ArrayList 实现了 RandomAccess 接口，而 LinkedList 没有实现。为什么呢？我觉得还是和底层数据结构有关！ArrayList 底层是数组，而 LinkedList 底层是链表。数组天然支持随机访问，时间复杂度为 O（1），所以称为快速随机访问。链表需要遍历到特定位置才能访问特定位置的元素，时间复杂度为 O（n），所以不支持快速随机访问。，ArrayList 实现了 RandomAccess 接口，就表明了他具有快速随机访问功能。 RandomAccess 接口只是标识，并不是说 ArrayList 实现 RandomAccess 接口才具有快速随机访问功能的！

下面再总结一下 list 的遍历方式选择：

实现了 RandomAccess 接口的list，优先选择普通 for 循环，其次 foreach,
未实现 RandomAccess接口的list，优先选择iterator遍历（foreach遍历底层也是通过iterator实现的,），大size的数据，千万不要使用普通for循环

补充内容:双向链表和双向循环链表

双向链表： 包含两个指针，一个prev指向前一个节点，一个next指向后一个节点。

双向循环链表： 最后一个节点的 next 指向head，而 head 的prev指向最后一个节点，构成一个环。

ArrayList 与 Vector 区别呢?为什么要用Arraylist取代Vector呢？

Vector类的所有方法都是同步的。可以由两个线程安全地访问一个Vector对象、但是一个线程访问Vector的话代码要在同步操作上耗费大量的时间。

Arraylist不是同步的，所以在不需要保证线程安全时建议使用Arraylist。

ArrayList的扩容机制

ArrayList的构造函数

ArrayList有三种方式来初始化，构造方法源码如下：

/**
 * 默认初始容量大小
 */
private static final int DEFAULT_CAPACITY = 10;


private static final Object[] DEFAULTCAPACITY_EMPTY_ELEMENTDATA = {};

/**
 *默认构造函数，使用初始容量10构造一个空列表(无参数构造)
 */
public ArrayList() {
this.elementData = DEFAULTCAPACITY_EMPTY_ELEMENTDATA;
}

/**
 * 带初始容量参数的构造函数。（用户自己指定容量）
 */
public ArrayList(int initialCapacity) {
if (initialCapacity > 0) {//初始容量大于0
//创建initialCapacity大小的数组
this.elementData = new Object[initialCapacity];
} else if (initialCapacity == 0) {//初始容量等于0
//创建空数组
this.elementData = EMPTY_ELEMENTDATA;
} else {//初始容量小于0，抛出异常
throw new IllegalArgumentException("Illegal Capacity: "+
   initialCapacity);
}
}


/**
*构造包含指定collection元素的列表，这些元素利用该集合的迭代器按顺序返回
*如果指定的集合为null，throws NullPointerException。 
*/
 public ArrayList(Collection c) {
elementData = c.toArray();
if ((size = elementData.length) != 0) {
// c.toArray might (incorrectly) not return Object[] (see 6260652)
if (elementData.getClass() != Object[].class)
elementData = Arrays.copyOf(elementData, size, Object[].class);
} else {
// replace with empty array.
this.elementData = EMPTY_ELEMENTDATA;
}
}

细心的同学一定会发现：以无参数构造方法创建 ArrayList 时，实际上初始化赋值的是一个空数组。当真正对数组进行添加元素操作时，才真正分配容量。即向数组中添加第一个元素时，数组容量扩为10。下面在我们分析 ArrayList 扩容时会讲到这一点内容！

分析ArrayList扩容机制

这里以无参构造函数创建的 ArrayList 为例分析

`add()` 方法

/**
 * 将指定的元素追加到此列表的末尾。 
 */
public boolean add(E e) {
//添加元素之前，先调用ensureCapacityInternal方法
ensureCapacityInternal(size + 1);  // Increments modCount!!
//这里看到ArrayList添加元素的实质就相当于为数组赋值
elementData[size++] = e;
return true;
}

`ensureCapacityInternal()` 方法

可以看到 add 方法首先调用了ensureCapacityInternal(size + 1)

//得到最小扩容量
private void ensureCapacityInternal(int minCapacity) {
if (elementData == DEFAULTCAPACITY_EMPTY_ELEMENTDATA) {
  // 获取默认的容量和传入参数的较大值
minCapacity = Math.max(DEFAULT_CAPACITY, minCapacity);
}

ensureExplicitCapacity(minCapacity);
}

当要 add 进第1个元素时，minCapacity为1，在Math.max()方法比较后，minCapacity 为10。

`ensureExplicitCapacity()` 方法

如果调用 ensureCapacityInternal() 方法就一定会进过（执行）这个方法，下面我们来研究一下这个方法的源码！

//判断是否需要扩容
private void ensureExplicitCapacity(int minCapacity) {
modCount++;

// overflow-conscious code
if (minCapacity - elementData.length > 0)
//调用grow方法进行扩容，调用此方法代表已经开始扩容了
grow(minCapacity);
}

我们来仔细分析一下：

当我们要 add 进第1个元素到 ArrayList 时，elementData.length 为0 （因为还是一个空的 list），因为执行了 ensureCapacityInternal() 方法，所以 minCapacity 此时为10。此时，minCapacity - elementData.length > 0 成立，所以会进入 grow(minCapacity) 方法。
当add第2个元素时，minCapacity 为2，此时e lementData.length(容量)在添加第一个元素后扩容成 10 了。此时，minCapacity - elementData.length > 0 不成立，所以不会进入（执行）grow(minCapacity) 方法。
添加第3、4···到第10个元素时，依然不会执行grow方法，数组容量都为10。

直到添加第11个元素，minCapacity(为11)比elementData.length（为10）要大。进入grow方法进行扩容。

`grow()` 方法

/**
 * 要分配的最大数组大小
 */
private static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8;

/**
 * ArrayList扩容的核心方法。
 */
private void grow(int minCapacity) {
// oldCapacity为旧容量，newCapacity为新容量
int oldCapacity = elementData.length;
//将oldCapacity 右移一位，其效果相当于oldCapacity /2，
//我们知道位运算的速度远远快于整除运算，整句运算式的结果就是将新容量更新为旧容量的1.5倍，
int newCapacity = oldCapacity + (oldCapacity >> 1);
//然后检查新容量是否大于最小需要容量，若还是小于最小需要容量，那么就把最小需要容量当作数组的新容量，
if (newCapacity - minCapacity < 0)
newCapacity = minCapacity;
   // 如果新容量大于 MAX_ARRAY_SIZE,进入(执行) `hugeCapacity()` 方法来比较 minCapacity 和 MAX_ARRAY_SIZE，
   //如果minCapacity大于最大容量，则新容量则为`Integer.MAX_VALUE`，否则，新容量大小则为 MAX_ARRAY_SIZE 即为 `Integer.MAX_VALUE - 8`。
if (newCapacity - MAX_ARRAY_SIZE > 0)
newCapacity = hugeCapacity(minCapacity);
// minCapacity is usually close to size, so this is a win:
elementData = Arrays.copyOf(elementData, newCapacity);
}

int newCapacity = oldCapacity + (oldCapacity >> 1),所以 ArrayList 每次扩容之后容量都会变为原来的 1.5 倍！（JDK1.6版本以后） JDk1.6版本时，扩容之后容量为 1.5 倍+1！详情请参考源码

>>（移位运算符）：>>1 右移一位相当于除以2，右移n位相当于除以 2 的 n 次方。这里 oldCapacity 右移1位 所以相当于oldCapacity / 2。
对于大数据的2进制运算,位移运算符比那些普通运算符的运算要快很多,因为程序仅仅移动一下而已,不去计算,这样提高了效率,节省了资源　

我们再来通过例子探究一下grow() 方法：

当add第1个元素时，oldCapacity 为0，经比较后第一个if判断成立，newCapacity = minCapacity(为10)。但是第二个if判断不会成立，即newCapacity 不比 MAX_ARRAY_SIZE大，则不会进入 hugeCapacity 方法。数组容量为10，add方法中 return true,size增为1。
当add第11个元素进入grow方法时，newCapacity为15，比minCapacity（为11）大，第一个if判断不成立。新容量没有大于数组最大size，不会进入hugeCapacity方法。数组容量扩为15，add方法中return true,size增为11。
以此类推······

这里补充一点比较重要，但是容易被忽视掉的知识点：

java 中的 length 属性是针对数组说的,比如说你声明了一个数组,想知道这个数组的长度则用到了 length 这个属性.
java 中的 length() 方法是针对字符串说的,如果想看这个字符串的长度则用到 length() 这个方法.
java 中的 size() 方法是针对泛型集合说的,如果想看这个泛型有多少个元素,就调用此方法来查看!

`hugeCapacity()` 方法。

从上面 grow() 方法源码我们知道：如果新容量大于 MAX_ARRAY_SIZE,进入(执行) hugeCapacity() 方法来比较 minCapacity 和 MAX_ARRAY_SIZE，如果minCapacity大于最大容量，则新容量则为Integer.MAX_VALUE，否则，新容量大小则为 MAX_ARRAY_SIZE 即为 Integer.MAX_VALUE - 8。

private static int hugeCapacity(int minCapacity) {
if (minCapacity < 0) // overflow
throw new OutOfMemoryError();
//对minCapacity和MAX_ARRAY_SIZE进行比较
//若minCapacity大，将Integer.MAX_VALUE作为新数组的大小
//若MAX_ARRAY_SIZE大，将MAX_ARRAY_SIZE作为新数组的大小
//MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8;
return (minCapacity > MAX_ARRAY_SIZE) ?
Integer.MAX_VALUE :
MAX_ARRAY_SIZE;
}

`System.arraycopy()` 和 `Arrays.copyOf()`方法

阅读源码的话，我们就会发现 ArrayList 中大量调用了这两个方法。比如：我们上面讲的扩容操作以及add(int index, E element)、toArray() 等方法中都用到了该方法！

`System.arraycopy()` 方法

/**
 * 在此列表中的指定位置插入指定的元素。 
 * 先调用 rangeCheckForAdd 对index进行界限检查；然后调用 ensureCapacityInternal 方法保证capacity足够大；
 * 再将从index开始之后的所有成员后移一个位置；将element插入index位置；最后size加1。
 */
public void add(int index, E element) {
rangeCheckForAdd(index);

ensureCapacityInternal(size + 1);  // Increments modCount!!
//arraycopy()方法实现数组自己复制自己
//elementData:源数组;index:源数组中的起始位置;elementData：目标数组；index + 1：目标数组中的起始位置； size - index：要复制的数组元素的数量；
System.arraycopy(elementData, index, elementData, index + 1, size - index);
elementData[index] = element;
size++;
}

我们写一个简单的方法测试以下：

public class ArraycopyTest {

public static void main(String[] args) {
// TODO Auto-generated method stub
int[] a = new int[10];
a[0] = 0;
a[1] = 1;
a[2] = 2;
a[3] = 3;
System.arraycopy(a, 2, a, 3, 3);
a[2]=99;
for (int i = 0; i < a.length; i++) {
System.out.println(a[i]);
}
}
}

结果：

1 2	0 1 99 2 3 0 0 0 0 0

`Arrays.copyOf()`方法

/**
 * 以正确的顺序返回一个包含此列表中所有元素的数组（从第一个到最后一个元素）; 返回的数组的运行时类型是指定数组的运行时类型。 
 */
public Object[] toArray() {
//elementData：要复制的数组；size：要复制的长度
return Arrays.copyOf(elementData, size);
}

个人觉得使用 Arrays.copyOf()方法主要是为了给原有数组扩容，测试代码如下：

public class ArrayscopyOfTest {

public static void main(String[] args) {
int[] a = new int[3];
a[0] = 0;
a[1] = 1;
a[2] = 2;
int[] b = Arrays.copyOf(a, 10);
System.out.println("b.length"+b.length);
}
}

结果：

1
2

两者联系和区别

联系：

看两者源代码可以发现 copyOf() 内部实际调用了 System.arraycopy() 方法

区别：

arraycopy() 需要目标数组，将原数组拷贝到你自己定义的数组里或者原数组，而且可以选择拷贝的起点和长度以及放入新数组中的位置 copyOf() 是系统自动在内部新建一个数组，并返回该数组。

`ensureCapacity()`方法

ArrayList 源码中有一个 ensureCapacity 方法不知道大家注意到没有，这个方法 ArrayList 内部没有被调用过，所以很显然是提供给用户调用的，那么这个方法有什么作用呢？

/**
 * 如有必要，增加此 ArrayList 实例的容量，以确保它至少可以容纳由minimum capacity参数指定的元素数。
 *
 * @param   minCapacity   所需的最小容量
 */
public void ensureCapacity(int minCapacity) {
int minExpand = (elementData != DEFAULTCAPACITY_EMPTY_ELEMENTDATA)
// any size if not default element table
? 0
// larger than default for default empty table. It's already
// supposed to be at default size.
: DEFAULT_CAPACITY;

if (minCapacity > minExpand) {
ensureExplicitCapacity(minCapacity);
}
}

最好在 add 大量元素之前用 ensureCapacity 方法，以减少增量重新分配的次数

我们通过下面的代码实际测试以下这个方法的效果：

public class EnsureCapacityTest {
public static void main(String[] args) {
ArrayList list = new ArrayList();
final int N = 10000000;
long startTime = System.currentTimeMillis();
for (int i = 0; i < N; i++) {
list.add(i);
}
long endTime = System.currentTimeMillis();
System.out.println("使用ensureCapacity方法前："+(endTime - startTime));

list = new ArrayList();
long startTime1 = System.currentTimeMillis();
list.ensureCapacity(N);
for (int i = 0; i < N; i++) {
list.add(i);
}
long endTime1 = System.currentTimeMillis();
System.out.println("使用ensureCapacity方法后："+(endTime1 - startTime1));
}
}

运行结果：

1
2
3

使用ensureCapacity方法前：4637
使用ensureCapacity方法后：241

通过运行结果，我们可以很明显的看出向 ArrayList 添加大量元素之前最好先使用ensureCapacity 方法，以减少增量重新分配的次数

HashMap 和 Hashtable 的区别

线程是否安全： HashMap 是非线程安全的，HashTable 是线程安全的；HashTable 内部的方法基本都经过synchronized 修饰。（如果你要保证线程安全的话就使用 ConcurrentHashMap 吧！）；
效率： 因为线程安全的问题，HashMap 要比 HashTable 效率高一点。另外，HashTable 基本被淘汰，不要在代码中使用它；
对Null key 和Null value的支持： HashMap 中，null 可以作为键，这样的键只有一个，可以有一个或多个键所对应的值为 null。。但是在 HashTable 中 put 进的键值只要有一个 null，直接抛出 NullPointerException。
初始容量大小和每次扩充容量大小的不同： ①创建时如果不指定容量初始值，Hashtable 默认的初始大小为11，之后每次扩充，容量变为原来的2n+1。HashMap 默认的初始化大小为16。之后每次扩充，容量变为原来的2倍。②创建时如果给定了容量初始值，那么 Hashtable 会直接使用你给定的大小，而 HashMap 会将其扩充为2的幂次方大小（HashMap 中的tableSizeFor()方法保证，下面给出了源代码）。也就是说 HashMap 总是使用2的幂作为哈希表的大小,后面会介绍到为什么是2的幂次方。
底层数据结构： JDK1.8 以后的 HashMap 在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为8）时，将链表转化为红黑树，以减少搜索时间。Hashtable 没有这样的机制。

HashMap 中带有初始容量的构造函数：

public HashMap(int initialCapacity, float loadFactor) {
if (initialCapacity < 0)
throw new IllegalArgumentException("Illegal initial capacity: " +
   initialCapacity);
if (initialCapacity > MAXIMUM_CAPACITY)
initialCapacity = MAXIMUM_CAPACITY;
if (loadFactor <= 0 || Float.isNaN(loadFactor))
throw new IllegalArgumentException("Illegal load factor: " +
   loadFactor);
this.loadFactor = loadFactor;
this.threshold = tableSizeFor(initialCapacity);
}
 public HashMap(int initialCapacity) {
this(initialCapacity, DEFAULT_LOAD_FACTOR);
}

下面这个方法保证了 HashMap 总是使用2的幂作为哈希表的大小。

/**
 * Returns a power of two size for the given target capacity.
 */
static final int tableSizeFor(int cap) {
int n = cap - 1;
n |= n >>> 1;
n |= n >>> 2;
n |= n >>> 4;
n |= n >>> 8;
n |= n >>> 16;
return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;
}

HashMap 和 HashSet区别

如果你看过 HashSet 源码的话就应该知道：HashSet 底层就是基于 HashMap 实现的。（HashSet 的源码非常非常少，因为除了 clone() 、writeObject()、readObject()是 HashSet 自己不得不实现之外，其他方法都是直接调用 HashMap 中的方法。

HashMap	HashSet
实现了Map接口	实现Set接口
存储键值对	仅存储对象
调用 `put（）`向map中添加元素	调用 `add（）`方法向Set中添加元素
HashMap使用键（Key）计算Hashcode	HashSet使用成员对象来计算hashcode值，对于两个对象来说hashcode可能相同，所以equals()方法用来判断对象的相等性，

HashSet如何检查重复

当你把对象加入HashSet时，HashSet会先计算对象的hashcode值来判断对象加入的位置，同时也会与其他加入的对象的hashcode值作比较，如果没有相符的hashcode，HashSet会假设对象没有重复出现。但是如果发现有相同hashcode值的对象，这时会调用equals（）方法来检查hashcode相等的对象是否真的相同。如果两者相同，HashSet就不会让加入操作成功。（摘自《Head fist java》第二版）

hashCode()与equals()的相关规定：

如果两个对象相等，则hashcode一定也是相同的
两个对象相等,对两个equals方法返回true
两个对象有相同的hashcode值，它们也不一定是相等的
综上，equals方法被覆盖过，则hashCode方法也必须被覆盖
hashCode()的默认行为是对堆上的对象产生独特值。如果没有重写hashCode()，则该class的两个对象无论如何都不会相等（即使这两个对象指向相同的数据）。

==与equals的区别

==是判断两个变量或实例是不是指向同一个内存空间 equals是判断两个变量或实例所指向的内存空间的值是不是相同
==是指对内存地址进行比较 equals()是对字符串的内容进行比较
==指引用是否相同 equals()指的是值是否相同

HashMap的底层实现

JDK1.8之前

JDK1.8 之前 HashMap 底层是 数组和链表 结合在一起使用也就是 链表散列。HashMap 通过 key 的 hashCode 经过扰动函数处理过后得到 hash 值，然后通过 (n - 1) & hash 判断当前元素存放的位置（这里的 n 指的是数组的长度），如果当前位置存在元素的话，就判断该元素与要存入的元素的 hash 值以及 key 是否相同，如果相同的话，直接覆盖，不相同就通过拉链法解决冲突。

所谓扰动函数指的就是 HashMap 的 hash 方法。使用 hash 方法也就是扰动函数是为了防止一些实现比较差的 hashCode() 方法换句话说使用扰动函数之后可以减少碰撞。

JDK 1.8 HashMap 的 hash 方法源码:

JDK 1.8 的 hash方法相比于 JDK 1.7 hash 方法更加简化，但是原理不变。

static final int hash(Object key) {
  int h;
  // key.hashCode()：返回散列值也就是hashcode
  // ^ ：按位异或
  // >>>:无符号右移，忽略符号位，空位都以0补齐
  return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}

对比一下 JDK1.7的 HashMap 的 hash 方法源码.

static int hash(int h) {
    // This function ensures that hashCodes that differ only by
    // constant multiples at each bit position have a bounded
    // number of collisions (approximately 8 at default load factor).

    h ^= (h >>> 20) ^ (h >>> 12);
    return h ^ (h >>> 7) ^ (h >>> 4);
}

相比于 JDK1.8 的 hash 方法，JDK 1.7 的 hash 方法的性能会稍差一点点，因为毕竟扰动了 4 次。

所谓 “拉链法” 就是：将链表和数组相结合。也就是说创建一个链表数组，数组中每一格就是一个链表。若遇到哈希冲突，则将冲突的值加到链表中即可。

JDK1.8之后

相比于之前的版本， JDK1.8之后在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为8）时，将链表转化为红黑树，以减少搜索时间。

TreeMap、TreeSet以及JDK1.8之后的HashMap底层都用到了红黑树。红黑树就是为了解决二叉查找树的缺陷，因为二叉查找树在某些情况下会退化成一个线性结构。

推荐阅读：

《Java 8系列之重新认识HashMap》

HashMap 的长度为什么是2的幂次方

为了能让 HashMap 存取高效，尽量较少碰撞，也就是要尽量把数据分配均匀。我们上面也讲到了过了，Hash 值的范围值-2147483648到2147483647，前后加起来大概40亿的映射空间，只要哈希函数映射得比较均匀松散，一般应用是很难出现碰撞的。但问题是一个40亿长度的数组，内存是放不下的。所以这个散列值是不能直接拿来用的。用之前还要先做对数组的长度取模运算，得到的余数才能用来要存放的位置也就是对应的数组下标。这个数组下标的计算方法是“ (n - 1) & hash”。（n代表数组长度）。这也就解释了 HashMap 的长度为什么是2的幂次方。

这个算法应该如何设计呢？

我们首先可能会想到采用%取余的操作来实现。但是，重点来了：“取余(%)操作中如果除数是2的幂次则等价于与其除数减一的与(&)操作（也就是说 hash%length==hash&(length-1)的前提是 length 是2的 n 次方；）。” 并且 采用二进制位操作 &，相对于%能够提高运算效率，这就解释了 HashMap 的长度为什么是2的幂次方。

HashMap 多线程操作导致死循环问题

主要原因在于并发下的Rehash会造成元素之间会形成一个循环链表。不过，jdk 1.8 后解决了这个问题，但是还是不建议在多线程下使用 HashMap,因为多线程下使用 HashMap 还是会存在其他问题比如数据丢失。并发环境下推荐使用 ConcurrentHashMap 。

详情请查看

ConcurrentHashMap 和 Hashtable 的区别

ConcurrentHashMap 和 Hashtable 的区别主要体现在实现线程安全的方式上不同。

底层数据结构： JDK1.7的 ConcurrentHashMap 底层采用 分段的数组+链表 实现，JDK1.8 采用的数据结构跟HashMap1.8的结构一样，数组+链表/红黑二叉树。Hashtable 和 JDK1.8 之前的 HashMap 的底层数据结构类似都是采用 数组+链表 的形式，数组是 HashMap 的主体，链表则是主要为了解决哈希冲突而存在的；
实现线程安全的方式（重要）： ① 在JDK1.7的时候，ConcurrentHashMap（分段锁） 对整个桶数组进行了分割分段(Segment)，每一把锁只锁容器其中一部分数据，多线程访问容器里不同数据段的数据，就不会存在锁竞争，提高并发访问率。到了 JDK1.8 的时候已经摒弃了Segment的概念，而是直接用 Node 数组+链表+红黑树的数据结构来实现，并发控制使用 synchronized 和 CAS 来操作。（JDK1.6以后对 synchronized锁做了很多优化）整个看起来就像是优化过且线程安全的 HashMap，虽然在JDK1.8中还能看到 Segment 的数据结构，但是已经简化了属性，只是为了兼容旧版本；② Hashtable(同一把锁) :使用 synchronized 来保证线程安全，效率非常低下。当一个线程访问同步方法时，其他线程也访问同步方法，可能会进入阻塞或轮询状态，如使用 put 添加元素，另一个线程不能使用 put 添加元素，也不能使用 get，竞争会越来越激烈效率越低。

两者的对比图：

HashTable:

JDK1.7的ConcurrentHashMap：

JDK1.8的ConcurrentHashMap（TreeBin: 红黑二叉树节点 Node: 链表节点）：

ConcurrentHashMap线程安全的具体实现方式/底层具体实现

JDK1.7（上面有示意图）

首先将数据分为一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据时，其他段的数据也能被其他线程访问。

ConcurrentHashMap 是由 Segment 数组结构和 HashEntry 数组结构组成。

Segment 实现了 ReentrantLock,所以 Segment 是一种可重入锁，扮演锁的角色。HashEntry 用于存储键值对数据。

1
2
3

static class Segment extends ReentrantLock implements Serializable {
}

一个 ConcurrentHashMap 里包含一个 Segment 数组。Segment 的结构和HashMap类似，是一种数组和链表结构，一个 Segment 包含一个 HashEntry 数组，每个 HashEntry 是一个链表结构的元素，每个 Segment 守护着一个HashEntry数组里的元素，当对 HashEntry 数组的数据进行修改时，必须首先获得对应的 Segment的锁。

JDK1.8 （上面有示意图）

ConcurrentHashMap取消了Segment分段锁，采用CAS和synchronized来保证并发安全。数据结构跟HashMap1.8的结构类似，数组+链表/红黑二叉树。Java 8在链表长度超过一定阈值（8）时将链表（寻址时间复杂度为O(N)）转换为红黑树（寻址时间复杂度为O(log(N))）

synchronized只锁定当前链表或红黑二叉树的首节点，这样只要hash不冲突，就不会产生并发，效率又提升N倍。

comparable 和 Comparator的区别

comparable接口实际上是出自java.lang包它有一个 compareTo(Object obj)方法用来排序
comparator接口实际上是出自 java.util 包它有一个compare(Object obj1, Object obj2)方法用来排序

一般我们需要对一个集合使用自定义排序时，我们就要重写compareTo()方法或compare()方法，当我们需要对某一个集合实现两种排序方式，比如一个song对象中的歌名和歌手名分别采用一种排序方法的话，我们可以重写compareTo()方法和使用自制的Comparator方法或者以两个Comparator来实现歌名排序和歌星名排序，第二种代表我们只能使用两个参数版的 Collections.sort().

Comparator定制排序

ArrayList arrayList = new ArrayList();
arrayList.add(-1);
arrayList.add(3);
arrayList.add(3);
arrayList.add(-5);
arrayList.add(7);
arrayList.add(4);
arrayList.add(-9);
arrayList.add(-7);
System.out.println("原始数组:");
System.out.println(arrayList);
// void reverse(List list)：反转
Collections.reverse(arrayList);
System.out.println("Collections.reverse(arrayList):");
System.out.println(arrayList);

// void sort(List list),按自然排序的升序排序
Collections.sort(arrayList);
System.out.println("Collections.sort(arrayList):");
System.out.println(arrayList);
// 定制排序的用法
Collections.sort(arrayList, new Comparator() {

    @Override
    public int compare(Integer o1, Integer o2) {
        return o2.compareTo(o1);
    }
});
System.out.println("定制排序后：");
System.out.println(arrayList);

Output:

原始数组:
[-1, 3, 3, -5, 7, 4, -9, -7]
Collections.reverse(arrayList):
[-7, -9, 4, 7, -5, 3, 3, -1]
Collections.sort(arrayList):
[-9, -7, -5, -1, 3, 3, 4, 7]
定制排序后：
[7, 4, 3, 3, -1, -5, -7, -9]

重写compareTo方法实现按年龄来排序

// person对象没有实现Comparable接口，所以必须实现，这样才不会出错，才可以使treemap中的数据按顺序排列
// 前面一个例子的String类已经默认实现了Comparable接口，详细可以查看String类的API文档，另外其他
// 像Integer类等都已经实现了Comparable接口，所以不需要另外实现了

public  class Person implements Comparable {
    private String name;
    private int age;

    public Person(String name, int age) {
        super();
        this.name = name;
        this.age = age;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }

    /**
     * TODO重写compareTo方法实现按年龄来排序
     */
    @Override
    public int compareTo(Person o) {
        // TODO Auto-generated method stub
        if (this.age > o.getAge()) {
            return 1;
        } else if (this.age < o.getAge()) {
            return -1;
        }
        return age;
    }
}

public static void main(String[] args) {
    TreeMap pdata = new TreeMap();
    pdata.put(new Person("张三", 30), "zhangsan");
    pdata.put(new Person("李四", 20), "lisi");
    pdata.put(new Person("王五", 10), "wangwu");
    pdata.put(new Person("小红", 5), "xiaohong");
    // 得到key的值的同时得到key所对应的值
    Set keys = pdata.keySet();
    for (Person key : keys) {
        System.out.println(key.getAge() + "-" + key.getName());

    }
}

Output：

5-小红
10-王五
20-李四
30-张三

集合框架底层数据结构总结

Collection

List

Arraylist： Object数组
Vector： Object数组
LinkedList： 双向链表(JDK1.6之前为循环链表，JDK1.7取消了循环)

Set

HashSet（无序，唯一）: 基于 HashMap 实现的，底层采用 HashMap 来保存元素
LinkedHashSet： LinkedHashSet 继承于 HashSet，并且其内部是通过 LinkedHashMap 来实现的。有点类似于我们之前说的LinkedHashMap 其内部是基于 HashMap 实现一样，不过还是有一点点区别的
TreeSet（有序，唯一）： 红黑树(自平衡的排序二叉树)

Map

HashMap： JDK1.8之前HashMap由数组+链表组成的，数组是HashMap的主体，链表则是主要为了解决哈希冲突而存在的（“拉链法”解决冲突）。JDK1.8以后在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为8）时，将链表转化为红黑树，以减少搜索时间
LinkedHashMap： LinkedHashMap 继承自 HashMap，所以它的底层仍然是基于拉链式散列结构即由数组和链表或红黑树组成。另外，LinkedHashMap 在上面结构的基础上，增加了一条双向链表，使得上面的结构可以保持键值对的插入顺序。同时通过对链表进行相应的操作，实现了访问顺序相关逻辑。详细可以查看：《LinkedHashMap 源码详细分析（JDK1.8）》
Hashtable： 数组+链表组成的，数组是 HashMap 的主体，链表则是主要为了解决哈希冲突而存在的
TreeMap： 红黑树（自平衡的排序二叉树）

如何选用集合?

主要根据集合的特点来选用，比如我们需要根据键值获取到元素值时就选用Map接口下的集合，需要排序时选择TreeMap,不需要排序时就选择HashMap,需要保证线程安全就选用ConcurrentHashMap.当我们只需要存放元素值时，就选择实现Collection接口的集合，需要保证元素唯一时选择实现Set接口的集合比如TreeSet或HashSet，不需要就选择实现List接口的比如ArrayList或LinkedList，然后再根据实现这些接口的集合的特点来选用。

ArrayList源码

ArrayList简介

ArrayList 的底层是数组队列，相当于动态数组。与 Java 中的数组相比，它的容量能动态增长。在添加大量元素前，应用程序可以使用ensureCapacity操作来增加 ArrayList 实例的容量。这可以减少递增式再分配的数量。
它继承于 AbstractList，实现了 List, RandomAccess , Cloneable , java.io.Serializable 这些接口。

在我们学数据结构的时候就知道了线性表的顺序存储，插入删除元素的时间复杂度为O(n) ,求表长以及增加元素，取第i元素的时间复杂度为 O(1)

继承了AbstractList，实现了List。它是一个数组队列，提供了相关的添加、删除、修改、遍历等功能。
实现了 RandomAccess接口 ， RandomAccess是一个标志接口，表明实现这个这个接口的 List 集合是支持 快速随机访问 的。在 ArrayList 中，我们即可以通过元素的序号快速获取元素对象，这就是快速随机访问。
实现 Cloneable 接口，即覆盖了函数 clone()，能被克隆。
实现 java.io.Serializable接口 ，这意味着ArrayList 支持序列化 ， 能通过序列化去传输 。
与Vector 不同， ArrayList中的操作不是线程安全的 ！所以，建议在单线程中才使用 ArrayList，而在多线程中可以选择 Vector 或者 CopyOnWriteArrayList。

并发

什么是线程和进程?

何为进程?

进程是程序的一次执行过程，是系统运行程序的基本单位，因此进程是动态的。系统运行一个程序即是一个进程从创建，运行到消亡的过程。
在 Java 中，当我们启动 main 函数时其实就是启动了一个 JVM 的进程，而 main 函数所在的线程就是这个进程中的一个线程，也称主线程。
如下图所示，在 windows 中通过查看任务管理器的方式，我们就可以清楚看到 window 当前运行的进程（.exe 文件的运行）。

何为线程?

线程与进程相似，但线程是一个比进程更小的执行单位。一个进程在其执行的过程中可以产生多个线程。与进程不同的是同类的多个线程共享进程的堆和方法区资源，但每个线程有自己的程序计数器、虚拟机栈和本地方法栈，所以系统在产生一个线程，或是在各个线程之间作切换工作时，负担要比进程小得多，也正因为如此，线程也被称为轻量级进程。

Java 程序天生就是多线程程序，我们可以通过 JMX 来看一下一个普通的 Java 程序有哪些线程，代码如下。

public class MultiThread {
public static void main(String[] args) {
// 获取 Java 线程管理 MXBean
ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean();
// 不需要获取同步的 monitor 和 synchronizer 信息，仅获取线程和线程堆栈信息
ThreadInfo[] threadInfos = threadMXBean.dumpAllThreads(false, false);
// 遍历线程信息，仅打印线程 ID 和线程名称信息
for (ThreadInfo threadInfo : threadInfos) {
System.out.println("[" + threadInfo.getThreadId() + "] " + threadInfo.getThreadName());
}
}
}

上述程序输出如下（输出内容可能不同，不用太纠结下面每个线程的作用，只用知道 main 线程执行 main 方法即可）：

[5] Attach Listener //添加事件
[4] Signal Dispatcher // 分发处理给 JVM 信号的线程
[3] Finalizer //调用对象 finalize 方法的线程
[2] Reference Handler //清除 reference 线程
[1] main //main 线程,程序入口

从上面的输出内容可以看出：一个 Java 程序的运行是 main 线程和多个其他线程同时运行。

请简要描述线程与进程的关系,区别及优缺点？

从 JVM 角度说进程和线程之间的关系

图解进程和线程的关系

详细内容请参照JVM相关知识部分内容

从上图可以看出：一个进程中可以有多个线程，多个线程共享进程的堆和方法区 (JDK1.8 之后的元空间)资源，但是每个线程有自己的程序计数器、虚拟机栈 和 本地方法栈。

总结： 线程是进程划分成的更小的运行单位。线程和进程最大的不同在于基本上各进程是独立的，而各线程则不一定，因为同一进程中的线程极有可能会相互影响。线程执行开销小，但不利于资源的管理和保护；而进程正相反。

程序计数器为什么是私有的?

程序计数器主要有下面两个作用：

字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制，如：顺序执行、选择、循环、异常处理。
在多线程的情况下，程序计数器用于记录当前线程执行的位置，从而当线程被切换回来的时候能够知道该线程上次运行到哪儿了。

需要注意的是，如果执行的是 native 方法，那么程序计数器记录的是 undefined 地址，只有执行的是 Java 代码时程序计数器记录的才是下一条指令的地址。

所以，程序计数器私有主要是为了线程切换后能恢复到正确的执行位置。

虚拟机栈和本地方法栈为什么是私有的?

虚拟机栈： 每个 Java 方法在执行的同时会创建一个栈帧用于存储局部变量表、操作数栈、常量池引用等信息。从方法调用直至执行完成的过程，就对应着一个栈帧在 Java 虚拟机栈中入栈和出栈的过程。
本地方法栈： 和虚拟机栈所发挥的作用非常相似，区别是： 虚拟机栈为虚拟机执行 Java 方法（也就是字节码）服务，而本地方法栈则为虚拟机使用到的 Native 方法服务。 在 HotSpot 虚拟机中和 Java 虚拟机栈合二为一。

所以，为了保证线程中的局部变量不被别的线程访问到，虚拟机栈和本地方法栈是线程私有的。

一句话简单了解堆和方法区

堆和方法区是所有线程共享的资源，其中堆是进程中最大的一块内存，主要用于存放新创建的对象 (所有对象都在这里分配内存)，方法区主要用于存放已被加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。

说说并发与并行的区别?

并发： 同一时间段，多个任务都在执行 (单位时间内不一定同时执行)；
并行： 单位时间内，多个任务同时执行。

为什么要使用多线程呢?

先从总体上来说：

从计算机底层来说： 线程可以比作是轻量级的进程，是程序执行的最小单位,线程间的切换和调度的成本远远小于进程。另外，多核 CPU 时代意味着多个线程可以同时运行，这减少了线程上下文切换的开销。
从当代互联网发展趋势来说： 现在的系统动不动就要求百万级甚至千万级的并发量，而多线程并发编程正是开发高并发系统的基础，利用好多线程机制可以大大提高系统整体的并发能力以及性能。

再深入到计算机底层来探讨：

单核时代： 在单核时代多线程主要是为了提高 CPU 和 IO 设备的综合利用率。举个例子：当只有一个线程的时候会导致 CPU 计算时，IO 设备空闲；进行 IO 操作时，CPU 空闲。我们可以简单地说这两者的利用率目前都是 50%左右。但是当有两个线程的时候就不一样了，当一个线程执行 CPU 计算时，另外一个线程可以进行 IO 操作，这样两个的利用率就可以在理想情况下达到 100%了。
多核时代: 多核时代多线程主要是为了提高 CPU 利用率。举个例子：假如我们要计算一个复杂的任务，我们只用一个线程的话，CPU 只会一个 CPU 核心被利用到，而创建多个线程就可以让多个 CPU 核心被利用到，这样就提高了 CPU 的利用率。

使用多线程可能带来什么问题?

并发编程的目的就是为了能提高程序的执行效率提高程序运行速度，但是并发编程并不总是能提高程序运行速度的，而且并发编程可能会遇到很多问题，比如：内存泄漏、上下文切换、死锁还有受限于硬件和软件的资源闲置问题。

说说线程的生命周期和状态?

Java 线程在运行的生命周期中的指定时刻只可能处于下面 6 种不同状态的其中一个状态

线程在生命周期中并不是固定处于某一个状态而是随着代码的执行在不同状态之间切换。Java 线程状态变迁如下图所示

由上图可以看出：线程创建之后它将处于 NEW（新建） 状态，调用 start() 方法后开始运行，线程这时候处于 READY（可运行） 状态。可运行状态的线程获得了 CPU 时间片（timeslice）后就处于 RUNNING（运行） 状态。

操作系统隐藏 Java 虚拟机（JVM）中的 RUNNABLE 和 RUNNING 状态，它只能看到 RUNNABLE 状态，所以 Java 系统一般将这两个状态统称为 RUNNABLE（运行中） 状态。

什么是上下文切换?

多线程编程中一般线程的个数都大于 CPU 核心的个数，而一个 CPU 核心在任意时刻只能被一个线程使用，为了让这些线程都能得到有效执行，CPU 采取的策略是为每个线程分配时间片并轮转的形式。当一个线程的时间片用完的时候就会重新处于就绪状态让给其他线程使用，这个过程就属于一次上下文切换。

概括来说就是：当前任务在执行完 CPU 时间片切换到另一个任务之前会先保存自己的状态，以便下次再切换会这个任务时，可以再加载这个任务的状态。任务从保存到再加载的过程就是一次上下文切换。

上下文切换通常是计算密集型的。也就是说，它需要相当可观的处理器时间，在每秒几十上百次的切换中，每次切换都需要纳秒量级的时间。所以，上下文切换对系统来说意味着消耗大量的 CPU 时间，事实上，可能是操作系统中时间消耗最大的操作。

Linux 相比与其他操作系统（包括其他类 Unix 系统）有很多的优点，其中有一项就是，其上下文切换和模式切换的时间消耗非常少。

什么是线程死锁?如何避免死锁?

认识线程死锁

死锁经典问题与解决请参考哲学家就餐问题

多个线程同时被阻塞，它们中的一个或者全部都在等待某个资源被释放。由于线程被无限期地阻塞，因此程序不可能正常终止。

如下图所示，线程 A 持有资源 2，线程 B 持有资源 1，他们同时都想申请对方的资源，所以这两个线程就会互相等待而进入死锁状态。

下面通过一个例子来说明线程死锁,代码模拟了上图的死锁的情况 (代码来源于《并发编程之美》)：


public class DeadLockDemo {
    private static Object resource1 = new Object();//资源 1
    private static Object resource2 = new Object();//资源 2

    public static void main(String[] args) {
        new Thread(() -> {
            synchronized (resource1) {
                System.out.println(Thread.currentThread() + "get resource1");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println(Thread.currentThread() + "waiting get resource2");
                synchronized (resource2) {
                    System.out.println(Thread.currentThread() + "get resource2");
                }
            }
        }, "线程 1").start();

        new Thread(() -> {
            synchronized (resource2) {
                System.out.println(Thread.currentThread() + "get resource2");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println(Thread.currentThread() + "waiting get resource1");
                synchronized (resource1) {
                    System.out.println(Thread.currentThread() + "get resource1");
                }
            }
        }, "线程 2").start();
    }
}

Output


Thread[线程 1,5,main]get resource1
Thread[线程 2,5,main]get resource2
Thread[线程 1,5,main]waiting get resource2
Thread[线程 2,5,main]waiting get resource1

线程 A 通过 synchronized (resource1) 获得 resource1 的监视器锁，然后通过 Thread.sleep(1000);让线程 A 休眠 1s 为的是让线程 B 得到执行然后获取到 resource2 的监视器锁。线程 A 和线程 B 休眠结束了都开始企图请求获取对方的资源，然后这两个线程就会陷入互相等待的状态，这也就产生了死锁。上面的例子符合产生死锁的四个必要条件。

学过操作系统的朋友都知道产生死锁必须具备以下四个条件：

互斥条件：该资源任意一个时刻只由一个线程占用。
请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
不剥夺条件:线程已获得的资源在末使用完之前不能被其他线程强行剥夺，只有自己使用完毕后才释放资源。
循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。

如何避免线程死锁?

我们只要破坏产生死锁的四个条件中的其中一个就可以了。

破坏互斥条件

这个条件我们没有办法破坏，因为我们用锁本来就是想让他们互斥的（临界资源需要互斥访问）。

破坏请求与保持条件

一次性申请所有的资源。

破坏不剥夺条件

占用部分资源的线程进一步申请其他资源时，如果申请不到，可以主动释放它占有的资源。

破坏循环等待条件

靠按序申请资源来预防。按某一顺序申请资源，释放资源则反序释放。破坏循环等待条件。

我们对线程 2 的代码修改成下面这样就不会产生死锁了。


new Thread(() -> {
synchronized (resource1) {
System.out.println(Thread.currentThread() + "get resource1");
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(Thread.currentThread() + "waiting get resource2");
synchronized (resource2) {
System.out.println(Thread.currentThread() + "get resource2");
}
}
}, "线程 2").start();

Output


Thread[线程 1,5,main]get resource1
Thread[线程 1,5,main]waiting get resource2
Thread[线程 1,5,main]get resource2
Thread[线程 2,5,main]get resource1
Thread[线程 2,5,main]waiting get resource2
Thread[线程 2,5,main]get resource2

Process finished with exit code 0

我们分析一下上面的代码为什么避免了死锁的发生?

线程1首先获得到 resource1 的监视器锁,这时候线程2就获取不到了。然后线程1 再去获取resource2的监视器锁，可以获取到。然后线程1释放了对resource1、resource2的监视器锁的占用，线程2获取到就可以执行了。这样就破坏了破坏循环等待条件，因此避免了死锁。

说说 sleep() 方法和 wait() 方法区别和共同点?

两者最主要的区别在于：sleep 方法没有释放锁，而 wait 方法释放了锁 。
两者都可以暂停线程的执行。
Wait 通常被用于线程间交互/通信，sleep 通常被用于暂停执行。
wait() 方法被调用后，线程不会自动苏醒，需要别的线程调用同一个对象上的 notify() 或者 notifyAll() 方法。sleep() 方法执行完成后，线程会自动苏醒。或者可以使用wait(long timeout)超时后线程会自动苏醒。

为什么我们调用 start() 方法时会执行 run() 方法，为什么我们不能直接调用 run() 方法？

这是另一个非常经典的 java 多线程面试问题，而且在面试中会经常被问到。很简单，但是很多人都会答不上来！

new 一个 Thread，线程进入了新建状态;调用 start() 方法，会启动一个线程并使线程进入了就绪状态，当分配到时间片后就可以开始运行了。 start() 会执行线程的相应准备工作，然后自动执行 run() 方法的内容，这是真正的多线程工作。而直接执行 run() 方法，会把 run 方法当成一个 main 线程下的普通方法去执行，并不会在某个线程中执行它，所以这并不是多线程工作。

调用 start 方法方可启动线程并使线程进入就绪状态，而 run 方法只是 thread 的一个普通方法调用，还是在主线程里执行。

synchronized 关键字

说一说自己对于 synchronized 关键字的了解

synchronized关键字解决的是多个线程之间访问资源的同步性，synchronized关键字可以保证被它修饰的方法或者代码块在任意时刻只能有一个线程执行。

另外，在 Java 早期版本中，synchronized属于重量级锁，效率低下，因为监视器锁（monitor）是依赖于底层的操作系统的 Mutex Lock 来实现的，Java 的线程是映射到操作系统的原生线程之上的。如果要挂起或者唤醒一个线程，都需要操作系统帮忙完成，而操作系统实现线程之间的切换时需要从用户态转换到内核态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，这也是为什么早期的 synchronized 效率低的原因。庆幸的是在 Java 6 之后 Java 官方对从 JVM 层面对synchronized 较大优化，所以现在的 synchronized 锁效率也优化得很不错了。JDK1.6对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。

说说自己是怎么使用 synchronized 关键字，在项目中用到了吗

synchronized关键字最主要的三种使用方式：

修饰实例方法: 作用于当前对象实例加锁，进入同步代码前要获得当前对象实例的锁
修饰静态方法: :也就是给当前类加锁，会作用于类的所有对象实例，因为静态成员不属于任何一个实例对象，是类成员（ static 表明这是该类的一个静态资源，不管new了多少个对象，只有一份）。所以如果一个线程A调用一个实例对象的非静态 synchronized 方法，而线程B需要调用这个实例对象所属类的静态 synchronized 方法，是允许的，不会发生互斥现象，因为访问静态 synchronized 方法占用的锁是当前类的锁，而访问非静态 synchronized 方法占用的锁是当前实例对象锁。
修饰代码块: 指定加锁对象，对给定对象加锁，进入同步代码库前要获得给定对象的锁。

总结： synchronized 关键字加到 static 静态方法和 synchronized(class)代码块上都是是给 Class 类上锁。synchronized 关键字加到实例方法上是给对象实例上锁。尽量不要使用 synchronized(String a) 因为JVM中，字符串常量池具有缓存功能！

下面我以一个常见的面试题为例讲解一下 synchronized 关键字的具体使用。

面试中面试官经常会说：“单例模式了解吗？来给我手写一下！给我解释一下双重检验锁方式实现单例模式的原理呗！”

双重校验锁实现对象单例（线程安全）


public class Singleton {

    private volatile static Singleton uniqueInstance;

    private Singleton() {
    }

    public static Singleton getUniqueInstance() {
       //先判断对象是否已经实例过，没有实例化过才进入加锁代码
        if (uniqueInstance == null) {
            //类对象加锁
            synchronized (Singleton.class) {
                if (uniqueInstance == null) {
                    uniqueInstance = new Singleton();
                }
            }
        }
        return uniqueInstance;
    }
}

另外，需要注意 uniqueInstance 采用 volatile 关键字修饰也是很有必要。

uniqueInstance 采用 volatile 关键字修饰也是很有必要的， uniqueInstance = new Singleton(); 这段代码其实是分为三步执行：

为 uniqueInstance 分配内存空间
初始化 uniqueInstance
将 uniqueInstance 指向分配的内存地址

但是由于 JVM 具有指令重排的特性，执行顺序有可能变成 1->3->2。指令重排在单线程环境下不会出先问题，但是在多线程环境下会导致一个线程获得还没有初始化的实例。例如，线程 T1 执行了 1 和 3，此时 T2 调用 getUniqueInstance() 后发现 uniqueInstance 不为空，因此返回 uniqueInstance，但此时 uniqueInstance 还未被初始化。

使用 volatile 可以禁止 JVM 的指令重排，保证在多线程环境下也能正常运行。

1.3. 讲一下 synchronized 关键字的底层原理

synchronized 关键字底层原理属于 JVM 层面。

① synchronized 同步语句块的情况


public class SynchronizedDemo {
public void method() {
synchronized (this) {
System.out.println("synchronized 代码块");
}
}
}

通过 JDK 自带的 javap 命令查看 SynchronizedDemo 类的相关字节码信息：首先切换到类的对应目录执行 javac SynchronizedDemo.java 命令生成编译后的 .class 文件，然后执行javap -c -s -v -l SynchronizedDemo.class。

从上面我们可以看出：

synchronized 同步语句块的实现使用的是 monitorenter 和 monitorexit 指令，其中 monitorenter 指令指向同步代码块的开始位置，monitorexit 指令则指明同步代码块的结束位置。当执行 monitorenter 指令时，线程试图获取锁也就是获取 monitor(monitor对象存在于每个Java对象的对象头中，synchronized 锁便是通过这种方式获取锁的，也是为什么Java中任意对象可以作为锁的原因) 的持有权。当计数器为0则可以成功获取，获取后将锁计数器设为1也就是加1。相应的在执行 monitorexit 指令后，将锁计数器设为0，表明锁被释放。如果获取对象锁失败，那当前线程就要阻塞等待，直到锁被另外一个线程释放为止。

② synchronized 修饰方法的的情况


public class SynchronizedDemo2 {
public synchronized void method() {
System.out.println("synchronized 方法");
}
}

synchronized 修饰的方法并没有 monitorenter 指令和 monitorexit 指令，取得代之的确实是 ACC_SYNCHRONIZED 标识，该标识指明了该方法是一个同步方法，JVM 通过该 ACC_SYNCHRONIZED 访问标志来辨别一个方法是否声明为同步方法，从而执行相应的同步调用。

说说 JDK1.6 之后的synchronized 关键字底层做了哪些优化，可以详细介绍一下这些优化吗

JDK1.6 对锁的实现引入了大量的优化，如偏向锁、轻量级锁、自旋锁、适应性自旋锁、锁消除、锁粗化等技术来减少锁操作的开销。

锁主要存在四种状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，他们会随着竞争的激烈而逐渐升级。注意锁可以升级不可降级，这种策略是为了提高获得锁和释放锁的效率。

谈谈 synchronized和ReentrantLock 的区别

1. 两者都是可重入锁
两者都是可重入锁。“可重入锁”概念是：自己可以再次获取自己的内部锁。比如一个线程获得了某个对象的锁，此时这个对象锁还没有释放，当其再次想要获取这个对象的锁的时候还是可以获取的，如果不可锁重入的话，就会造成死锁。同一个线程每次获取锁，锁的计数器都自增1，所以要等到锁的计数器下降为0时才能释放锁。
2. synchronized 依赖于 JVM 而 ReentrantLock 依赖于 API
synchronized 是依赖于 JVM 实现的，前面我们也讲到了虚拟机团队在 JDK1.6 为 synchronized 关键字进行了很多优化，但是这些优化都是在虚拟机层面实现的，并没有直接暴露给我们。ReentrantLock 是 JDK 层面实现的（也就是 API 层面，需要 lock() 和 unlock() 方法配合 try/finally 语句块来完成），所以我们可以通过查看它的源代码，来看它是如何实现的。
3. ReentrantLock 比 synchronized 增加了一些高级功能
相比synchronized，ReentrantLock增加了一些高级功能。主要来说主要有三点：

等待可中断；
可实现公平锁；
可实现选择性通知（锁可以绑定多个条件）

ReentrantLock提供了一种能够中断等待锁的线程的机制，通过lock.lockInterruptibly()来实现这个机制。也就是说正在等待的线程可以选择放弃等待，改为处理其他事情。
ReentrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。 ReentrantLock默认情况是非公平的，可以通过 ReentrantLock类的ReentrantLock(boolean fair)构造方法来制定是否是公平的。
synchronized关键字与wait()和notify()/notifyAll()方法相结合可以实现等待/通知机制，ReentrantLock类当然也可以实现，但是需要借助于Condition接口与newCondition() 方法。Condition是JDK1.5之后才有的，它具有很好的灵活性，比如可以实现多路通知功能也就是在一个Lock对象中可以创建多个Condition实例（即对象监视器），线程对象可以注册在指定的Condition中，从而可以有选择性的进行线程通知，在调度线程上更加灵活。在使用notify()/notifyAll()方法进行通知时，被通知的线程是由 JVM 选择的，用ReentrantLock类结合Condition实例可以实现“选择性通知” ，这个功能非常重要，而且是Condition接口默认提供的。而synchronized关键字就相当于整个Lock对象中只有一个Condition实例，所有的线程都注册在它一个身上。如果执行notifyAll()方法的话就会通知所有处于等待状态的线程这样会造成很大的效率问题，而Condition实例的signalAll()方法只会唤醒注册在该Condition实例中的所有等待线程。
如果你想使用上述功能，那么选择ReentrantLock是一个不错的选择。

4. 性能已不是选择标准

volatile关键字

讲一下Java内存模型

在 JDK1.2 之前，Java的内存模型实现总是从主存（即共享内存）读取变量，是不需要进行特别的注意的。而在当前的 Java 内存模型下，线程可以把变量保存本地内存比如机器的寄存器）中，而不是直接在主存中进行读写。这就可能造成一个线程在主存中修改了一个变量的值，而另外一个线程还继续使用它在寄存器中的变量值的拷贝，造成数据的不一致。

要解决这个问题，就需要把变量声明为volatile，这就指示 JVM，这个变量是不稳定的，每次使用它都到主存中进行读取。

说白了， volatile 关键字的主要作用就是保证变量的可见性然后还有一个作用是防止指令重排序。

说说 synchronized 关键字和 volatile 关键字的区别

synchronized关键字和volatile关键字比较

volatile关键字是线程同步的轻量级实现，所以volatile性能肯定比synchronized关键字要好。但是volatile关键字只能用于变量而synchronized关键字可以修饰方法以及代码块。synchronized关键字在JavaSE1.6之后进行了主要包括为了减少获得锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁以及其它各种优化之后执行效率有了显著提升，实际开发中使用 synchronized 关键字的场景还是更多一些。
多线程访问volatile关键字不会发生阻塞，而synchronized关键字可能会发生阻塞
volatile关键字能保证数据的可见性，但不能保证数据的原子性。synchronized关键字两者都能保证。
volatile关键字主要用于解决变量在多个线程之间的可见性，而 synchronized关键字解决的是多个线程之间访问资源的同步性。

ThreadLocal

ThreadLocal简介

通常情况下，我们创建的变量是可以被任何一个线程访问并修改的。如果想实现每一个线程都有自己的专属本地变量该如何解决呢？ JDK中提供的ThreadLocal类正是为了解决这样的问题。 ThreadLocal类主要解决的就是让每个线程绑定自己的值，可以将ThreadLocal类形象的比喻成存放数据的盒子，盒子中可以存储每个线程的私有数据。

如果你创建了一个ThreadLocal变量，那么访问这个变量的每个线程都会有这个变量的本地副本，这也是ThreadLocal变量名的由来。他们可以使用 get() 和 set() 方法来获取默认值或将其值更改为当前线程所存的副本的值，从而避免了线程安全问题。

再举个简单的例子：

比如有两个人去宝屋收集宝物，这两个共用一个袋子的话肯定会产生争执，但是给他们两个人每个人分配一个袋子的话就不会出现这样的问题。如果把这两个人比作线程的话，那么ThreadLocal就是用来避免这两个线程竞争的。

ThreadLocal示例

相信看了上面的解释，大家已经搞懂 ThreadLocal 类是个什么东西了。


import java.text.SimpleDateFormat;
import java.util.Random;

public class ThreadLocalExample implements Runnable{

     // SimpleDateFormat 不是线程安全的，所以每个线程都要有自己独立的副本
    private static final ThreadLocal formatter = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyyMMdd HHmm"));

    public static void main(String[] args) throws InterruptedException {
        ThreadLocalExample obj = new ThreadLocalExample();
        for(int i=0 ; i<10; i++){
            Thread t = new Thread(obj, ""+i);
            Thread.sleep(new Random().nextInt(1000));
            t.start();
        }
    }

    @Override
    public void run() {
        System.out.println("Thread Name= "+Thread.currentThread().getName()+" default Formatter = "+formatter.get().toPattern());
        try {
            Thread.sleep(new Random().nextInt(1000));
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        //formatter pattern is changed here by thread, but it won't reflect to other threads
        formatter.set(new SimpleDateFormat());

        System.out.println("Thread Name= "+Thread.currentThread().getName()+" formatter = "+formatter.get().toPattern());
    }

}

Output:


Thread Name= 0 default Formatter = yyyyMMdd HHmm
Thread Name= 0 formatter = yy-M-d ah:mm
Thread Name= 1 default Formatter = yyyyMMdd HHmm
Thread Name= 2 default Formatter = yyyyMMdd HHmm
Thread Name= 1 formatter = yy-M-d ah:mm
Thread Name= 3 default Formatter = yyyyMMdd HHmm
Thread Name= 2 formatter = yy-M-d ah:mm
Thread Name= 4 default Formatter = yyyyMMdd HHmm
Thread Name= 3 formatter = yy-M-d ah:mm
Thread Name= 4 formatter = yy-M-d ah:mm
Thread Name= 5 default Formatter = yyyyMMdd HHmm
Thread Name= 5 formatter = yy-M-d ah:mm
Thread Name= 6 default Formatter = yyyyMMdd HHmm
Thread Name= 6 formatter = yy-M-d ah:mm
Thread Name= 7 default Formatter = yyyyMMdd HHmm
Thread Name= 7 formatter = yy-M-d ah:mm
Thread Name= 8 default Formatter = yyyyMMdd HHmm
Thread Name= 9 default Formatter = yyyyMMdd HHmm
Thread Name= 8 formatter = yy-M-d ah:mm
Thread Name= 9 formatter = yy-M-d ah:mm

从输出中可以看出，Thread-0已经改变了formatter的值，但仍然是thread-2默认格式化程序与初始化值相同，其他线程也一样。

上面有一段代码用到了创建 ThreadLocal 变量的那段代码用到了 Java8 的知识，它等于下面这段代码，如果你写了下面这段代码的话，IDEA会提示你转换为Java8的格式(IDEA真的不错！)。因为ThreadLocal类在Java 8中扩展，使用一个新的方法withInitial()，将Supplier功能接口作为参数。


private static final ThreadLocal formatter = new ThreadLocal(){
@Override
protected SimpleDateFormat initialValue()
{
return new SimpleDateFormat("yyyyMMdd HHmm");
}
};

ThreadLocal原理

从 Thread类源代码入手。


public class Thread implements Runnable {
 ......
//与此线程有关的ThreadLocal值。由ThreadLocal类维护
ThreadLocal.ThreadLocalMap threadLocals = null;

//与此线程有关的InheritableThreadLocal值。由InheritableThreadLocal类维护
ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;
 ......
}

从上面Thread类源代码可以看出Thread 类中有一个 threadLocals 和一个 inheritableThreadLocals 变量，它们都是 ThreadLocalMap 类型的变量,我们可以把 ThreadLocalMap 理解为ThreadLocal 类实现的定制化的 HashMap。默认情况下这两个变量都是null，只有当前线程调用 ThreadLocal 类的 set或get方法时才创建它们，实际上调用这两个方法的时候，我们调用的是ThreadLocalMap类对应的 get()、set() 方法。

ThreadLocal类的set()方法


public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
}
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}

通过上面这些内容，我们足以通过猜测得出结论：最终的变量是放在了当前线程的 ThreadLocalMap 中，并不是存在 ThreadLocal 上，ThreadLocal 可以理解为只是ThreadLocalMap的封装，传递了变量值。 ThrealLocal 类中可以通过Thread.currentThread()获取到当前线程对象后，直接通过getMap(Thread t)可以访问到该线程的ThreadLocalMap对象。

每个Thread中都具备一个ThreadLocalMap，而ThreadLocalMap可以存储以ThreadLocal为key的键值对。 比如我们在同一个线程中声明了两个 ThreadLocal 对象的话，会使用 Thread内部都是使用仅有那个ThreadLocalMap 存放数据的，ThreadLocalMap的 key 就是 ThreadLocal对象，value 就是 ThreadLocal 对象调用set方法设置的值。ThreadLocal 是 map结构是为了让每个线程可以关联多个 ThreadLocal变量。这也就解释了 ThreadLocal 声明的变量为什么在每一个线程都有自己的专属本地变量。

ThreadLocalMap是ThreadLocal的静态内部类。

ThreadLocal 内存泄露问题

ThreadLocalMap 中使用的 key 为 ThreadLocal 的弱引用,而 value 是强引用。所以，如果 ThreadLocal 没有被外部强引用的情况下，在垃圾回收的时候会 key 会被清理掉，而 value 不会被清理掉。这样一来，ThreadLocalMap 中就会出现key为null的Entry。假如我们不做任何措施的话，value 永远无法被GC 回收，这个时候就可能会产生内存泄露。ThreadLocalMap实现中已经考虑了这种情况，在调用 set()、get()、remove() 方法的时候，会清理掉 key 为 null 的记录。使用完 ThreadLocal方法后最好手动调用remove()方法


static class Entry extends WeakReference> {
/** The value associated with this ThreadLocal. */
Object value;

Entry(ThreadLocal k, Object v) {
super(k);
value = v;
}
}

弱引用介绍：

如果一个对象只具有弱引用，那就类似于可有可无的生活用品。弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。
弱引用可以和一个引用队列(ReferenceQueue)联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。

线程池

为什么要用线程池？

线程池提供了一种限制和管理资源(包括执行一个任务)。每个线程池还维护一些基本统计信息，例如已完成任务的数量。

这里借用《Java并发编程的艺术》提到的来说一下使用线程池的好处：

降低资源消耗。 通过重复利用已创建的线程降低线程创建和销毁造成的消耗。
提高响应速度。 当任务到达时，任务可以不需要的等到线程创建就能立即执行。
提高线程的可管理性。 线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。

实现Runnable接口和Callable接口的区别

如果想让线程池执行任务的话需要实现的Runnable接口或Callable接口。 Runnable接口或Callable接口实现类都可以被ThreadPoolExecutor或ScheduledThreadPoolExecutor执行。两者的区别在于 Runnable 接口不会返回结果但是 Callable 接口可以返回结果。

备注：工具类Executors可以实现Runnable对象和Callable对象之间的相互转换。(Executors.callable(Runnable task)或Executors.callable(Runnable task，Object resule))。

执行execute()方法和submit()方法的区别是什么呢？

1)execute() 方法用于提交不需要返回值的任务，所以无法判断任务是否被线程池执行成功与否；

2)submit() 方法用于提交需要返回值的任务。线程池会返回一个Future类型的对象，通过这个Future对象可以判断任务是否执行成功，并且可以通过future的get()方法来获取返回值，get()方法会阻塞当前线程直到任务完成，而使用 get(long timeout，TimeUnit unit)方法则会阻塞当前线程一段时间后立即返回，这时候有可能任务没有执行完。

如何创建线程池

《阿里巴巴Java开发手册》中强制线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险

Executors 返回线程池对象的弊端如下：
FixedThreadPool 和 SingleThreadExecutor ：允许请求的队列长度为 Integer.MAX_VALUE ，可能堆积大量的请求，从而导致OOM。
CachedThreadPool 和 ScheduledThreadPool ：允许创建的线程数量为 Integer.MAX_VALUE ，可能会创建大量线程，从而导致OOM。

方式一：通过构造方法实现

方式二：通过Executor 框架的工具类Executors来实现
我们可以创建三种类型的ThreadPoolExecutor：

FixedThreadPool ：该方法返回一个固定线程数量的线程池。该线程池中的线程数量始终不变。当有一个新的任务提交时，线程池中若有空闲线程，则立即执行。若没有，则新的任务会被暂存在一个任务队列中，待有线程空闲时，便处理在任务队列中的任务。
SingleThreadExecutor： 方法返回一个只有一个线程的线程池。若多余一个任务被提交到该线程池，任务会被保存在一个任务队列中，待线程空闲，按先入先出的顺序执行队列中的任务。
CachedThreadPool： 该方法返回一个可根据实际情况调整线程数量的线程池。线程池的线程数量不确定，但若有空闲线程可以复用，则会优先使用可复用的线程。若所有线程均在工作，又有新的任务提交，则会创建新的线程处理任务。所有线程在当前任务执行完毕后，将返回线程池进行复用。

对应Executors工具类中的方法如图所示：

Atomic 原子类

介绍一下Atomic 原子类

Atomic 翻译成中文是原子的意思。在化学上，我们知道原子是构成一般物质的最小单位，在化学反应中是不可分割的。在我们这里 Atomic 是指一个操作是不可中断的。即使是在多个线程一起执行的时候，一个操作一旦开始，就不会被其他线程干扰。

所以，所谓原子类说简单点就是具有原子/原子操作特征的类。

并发包 java.util.concurrent 的原子类都存放在java.util.concurrent.atomic下,如下图所示。

JUC 包中的原子类是哪4类?

基本类型

使用原子的方式更新基本类型

AtomicInteger：整形原子类
AtomicLong：长整型原子类
AtomicBoolean：布尔型原子类

数组类型

使用原子的方式更新数组里的某个元素

AtomicIntegerArray：整形数组原子类
AtomicLongArray：长整形数组原子类
AtomicReferenceArray：引用类型数组原子类

引用类型

AtomicReference：引用类型原子类
AtomicStampedReference：原子更新引用类型里的字段原子类
AtomicMarkableReference ：原子更新带有标记位的引用类型

对象的属性修改类型

AtomicIntegerFieldUpdater：原子更新整形字段的更新器
AtomicLongFieldUpdater：原子更新长整形字段的更新器
AtomicStampedReference：原子更新带有版本号的引用类型。该类将整数值与引用关联起来，可用于解决原子的更新数据和数据的版本号，可以解决使用 CAS 进行原子更新时可能出现的 ABA 问题。

讲讲 AtomicInteger 的使用

AtomicInteger 类常用方法


public final int get() //获取当前的值
public final int getAndSet(int newValue)//获取当前的值，并设置新的值
public final int getAndIncrement()//获取当前的值，并自增
public final int getAndDecrement() //获取当前的值，并自减
public final int getAndAdd(int delta) //获取当前的值，并加上预期的值
boolean compareAndSet(int expect, int update) //如果输入的数值等于预期值，则以原子方式将该值设置为输入值(update)
public final void lazySet(int newValue)//最终设置为newValue,使用 lazySet 设置之后可能导致其他线程在之后的一小段时间内还是可以读到旧的值。

AtomicInteger 类的使用示例

使用 AtomicInteger 之后，不用对 increment() 方法加锁也可以保证线程安全。


class AtomicIntegerTest {
        private AtomicInteger count = new AtomicInteger();
      //使用AtomicInteger之后，不需要对该方法加锁，也可以实现线程安全。
        public void increment() {
                  count.incrementAndGet();
        }
     
       public int getCount() {
                return count.get();
        }
}

简单介绍一下 AtomicInteger 类的原理

AtomicInteger 线程安全原理简单分析

AtomicInteger 类的部分源码：


// setup to use Unsafe.compareAndSwapInt for updates(更新操作时提供“比较并替换”的作用)
private static final Unsafe unsafe = Unsafe.getUnsafe();
private static final long valueOffset;

static {
try {
valueOffset = unsafe.objectFieldOffset
(AtomicInteger.class.getDeclaredField("value"));
} catch (Exception ex) { throw new Error(ex); }
}

private volatile int value;

AtomicInteger 类主要利用 CAS (compare and swap) + volatile 和 native 方法来保证原子操作，从而避免 synchronized 的高开销，执行效率大为提升。

CAS的原理是拿期望的值和原本的一个值作比较，如果相同则更新成新的值。UnSafe 类的 objectFieldOffset() 方法是一个本地方法，这个方法是用来拿到“原来的值”的内存地址，返回值是 valueOffset。另外 value 是一个volatile变量，在内存中可见，因此 JVM 可以保证任何时刻任何线程总能拿到该变量的最新值。

AQS

AQS 介绍

AQS的全称为(AbstractQueuedSynchronizer)，这个类在java.util.concurrent.locks包下面。

AQS是一个用来构建锁和同步器的框架，使用AQS能简单且高效地构造出应用广泛的大量的同步器，比如我们提到的ReentrantLock，Semaphore，其他的诸如ReentrantReadWriteLock，SynchronousQueue，FutureTask等等皆是基于AQS的。当然，我们自己也能利用AQS非常轻松容易地构造出符合我们自己需求的同步器。

AQS 原理分析

在面试中被问到并发知识的时候，大多都会被问到“请你说一下自己对于AQS原理的理解”。下面给大家一个示例供大家参加，面试不是背题，大家一定要加入自己的思想，即使加入不了自己的思想也要保证自己能够通俗的讲出来而不是背出来。

下面大部分内容其实在AQS类注释上已经给出了，不过是英语看着比较吃力一点，感兴趣的话可以看看源码。

AQS 原理概览

AQS核心思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制AQS是用CLH队列锁实现的，即将暂时获取不到锁的线程加入到队列中。

CLH(Craig,Landin,and Hagersten)队列是一个虚拟的双向队列(虚拟的双向队列即不存在队列实例，仅存在结点之间的关联关系)。AQS是将每条请求共享资源的线程封装成一个CLH锁队列的一个结点(Node)来实现锁的分配。

看个AQS(AbstractQueuedSynchronizer)原理图：

AQS使用一个int成员变量来表示同步状态，通过内置的FIFO队列来完成获取资源线程的排队工作。AQS使用CAS对该同步状态进行原子操作实现对其值的修改。

1	private volatile int state;//共享变量，使用volatile修饰保证线程可见性

状态信息通过protected类型的getState，setState，compareAndSetState进行操作


//返回同步状态的当前值
protected final int getState() {  
    return state;
}
 // 设置同步状态的值
protected final void setState(int newState) { 
    state = newState;
}
//原子地(CAS操作)将同步状态值设置为给定值update如果当前同步状态的值等于expect(期望值)
protected final boolean compareAndSetState(int expect, int update) {
    return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}

AQS 对资源的共享方式

AQS定义两种资源共享方式

Exclusive(独占)：只有一个线程能执行，如ReentrantLock。又可分为公平锁和非公平锁：
- 公平锁：按照线程在队列中的排队顺序，先到者先拿到锁
- 非公平锁：当线程要获取锁时，无视队列顺序直接去抢锁，谁抢到就是谁的
Share(共享)：多个线程可同时执行，如Semaphore/CountDownLatch。Semaphore、CountDownLatch、 CyclicBarrier、ReadWriteLock 我们都会在后面讲到。

ReentrantReadWriteLock 可以看成是组合式，因为ReentrantReadWriteLock也就是读写锁允许多个线程同时对某一资源进行读。

不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源 state 的获取与释放方式即可，至于具体线程等待队列的维护(如获取资源失败入队/唤醒出队等)，AQS已经在顶层实现好了。

AQS底层使用了模板方法模式

同步器的设计是基于模板方法模式的，如果需要自定义同步器一般的方式是这样(模板方法模式很经典的一个应用)：

使用者继承AbstractQueuedSynchronizer并重写指定的方法。(这些重写方法很简单，无非是对于共享资源state的获取和释放)
将AQS组合在自定义同步组件的实现中，并调用其模板方法，而这些模板方法会调用使用者重写的方法。

这和我们以往通过实现接口的方式有很大区别，这是模板方法模式很经典的一个运用。

AQS使用了模板方法模式，自定义同步器时需要重写下面几个AQS提供的模板方法：


isHeldExclusively()//该线程是否正在独占资源。只有用到condition才需要去实现它。
tryAcquire(int)//独占方式。尝试获取资源，成功则返回true，失败则返回false。
tryRelease(int)//独占方式。尝试释放资源，成功则返回true，失败则返回false。
tryAcquireShared(int)//共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
tryReleaseShared(int)//共享方式。尝试释放资源，成功则返回true，失败则返回false。

默认情况下，每个方法都抛出 UnsupportedOperationException。这些方法的实现必须是内部线程安全的，并且通常应该简短而不是阻塞。AQS类中的其他方法都是final ，所以无法被其他类使用，只有这几个方法可以被其他类使用。

以ReentrantLock为例，state初始化为0，表示未锁定状态。A线程lock()时，会调用tryAcquire()独占该锁并将state+1。此后，其他线程再tryAcquire()时就会失败，直到A线程unlock()到state=0(即释放锁)为止，其它线程才有机会获取该锁。当然，释放锁之前，A线程自己是可以重复获取此锁的(state会累加)，这就是可重入的概念。但要注意，获取多少次就要释放多么次，这样才能保证state是能回到零态的。

再以CountDownLatch以例，任务分为N个子线程去执行，state也初始化为N(注意N要与线程个数一致)。这N个子线程是并行执行的，每个子线程执行完后countDown()一次，state会CAS(Compare and Swap)减1。等到所有子线程都执行完后(即state=0)，会unpark()主调用线程，然后主调用线程就会从await()函数返回，继续后余动作。

一般来说，自定义同步器要么是独占方法，要么是共享方式，他们也只需实现tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared中的一种即可。但AQS也支持自定义同步器同时实现独占和共享两种方式，如ReentrantReadWriteLock。

AQS 组件总结

Semaphore(信号量)-允许多个线程同时访问： synchronized 和 ReentrantLock 都是一次只允许一个线程访问某个资源，Semaphore(信号量)可以指定多个线程同时访问某个资源。
CountDownLatch (倒计时器)： CountDownLatch是一个同步工具类，用来协调多个线程之间的同步。这个工具通常用来控制线程等待，它可以让某一个线程等待直到倒计时结束，再开始执行。
CyclicBarrier(循环栅栏)： CyclicBarrier 和 CountDownLatch 非常类似，它也可以实现线程间的技术等待，但是它的功能比 CountDownLatch 更加复杂和强大。主要应用场景和 CountDownLatch 类似。CyclicBarrier 的字面意思是可循环使用(Cyclic)的屏障(Barrier)。它要做的事情是，让一组线程到达一个屏障(也可以叫同步点)时被阻塞，直到最后一个线程到达屏障时，屏障才会开门，所有被屏障拦截的线程才会继续干活。CyclicBarrier默认的构造方法是 CyclicBarrier(int parties)，其参数表示屏障拦截的线程数量，每个线程调用await()方法告诉 CyclicBarrier 我已经到达了屏障，然后当前线程被阻塞。

JDK 提供的并发容器总结

JDK提供的这些容器大部分在 java.util.concurrent 包中。

ConcurrentHashMap: 线程安全的HashMap
CopyOnWriteArrayList: 线程安全的List，在读多写少的场合性能非常好，远远好于Vector.
ConcurrentLinkedQueue: 高效的并发队列，使用链表实现。可以看做一个线程安全的 LinkedList，这是一个非阻塞队列。
BlockingQueue: 这是一个接口，JDK内部通过链表、数组等方式实现了这个接口。表示阻塞队列，非常适合用于作为数据共享的通道。
ConcurrentSkipListMap: 跳表的实现。这是一个Map，使用跳表的数据结构进行快速查找。

ConcurrentHashMap

我们知道HashMap不是线程安全的，在并发场景下如果要保证一种可行的方式是使用 Collections.synchronizedMap() 方法来包装我们的HashMap。但这是通过使用一个全局的锁来同步不同线程间的并发访问，因此会带来不可忽视的性能问题。

所以就有了HashMap的线程安全版本ConcurrentHashMap的诞生。在ConcurrentHashMap中，无论是读操作还是写操作都能保证很高的性能：在进行读操作时(几乎)不需要加锁，而在写操作时通过锁分段技术只对所操作的段加锁而不影响客户端对其它段的访问。

CopyOnWriteArrayList

CopyOnWriteArrayList 简介


public class CopyOnWriteArrayList
extends Object
implements List, RandomAccess, Cloneable, Serializable

在很多应用场景中，读操作可能会远远大于写操作。由于读操作根本不会修改原有的数据，因此对于每次读取都进行加锁其实是一种资源浪费。我们应该允许多个线程同时访问List的内部数据，毕竟读取操作是安全的。

这和我们之前在多线程章节讲过 ReentrantReadWriteLock 读写锁的思想非常类似，也就是读读共享、写写互斥、读写互斥、写读互斥。JDK中提供了 CopyOnWriteArrayList 类比相比于在读写锁的思想又更进一步。为了将读取的性能发挥到极致，CopyOnWriteArrayList 读取是完全不用加锁的，并且更厉害的是：写入也不会阻塞读取操作。只有写入和写入之间需要进行同步等待。这样一来，读操作的性能就会大幅度提升。那它是怎么做的呢？

CopyOnWriteArrayList 是如何做到的？

CopyOnWriteArrayList 类的所有可变操作（add，set等等）都是通过创建底层数组的新副本来实现的。当 List 需要被修改的时候，我并不修改原有内容，而是对原有数据进行一次复制，将修改的内容写入副本。写完之后，再将修改完的副本替换原来的数据，这样就可以保证写操作不会影响读操作了。

从 CopyOnWriteArrayList 的名字就能看出CopyOnWriteArrayList 是满足CopyOnWrite 的ArrayList，所谓CopyOnWrite 也就是说：在计算机，如果你想要对一块内存进行修改时，我们不在原有内存块中进行写操作，而是将内存拷贝一份，在新的内存中进行写操作，写完之后呢，就将指向原来内存指针指向新的内存，原来的内存就可以被回收掉了。

CopyOnWriteArrayList 读取和写入源码简单分析

CopyOnWriteArrayList 读取操作的实现

读取操作没有任何同步控制和锁操作，理由就是内部数组 array 不会发生修改，只会被另外一个 array 替换，因此可以保证数据安全。


/** The array, accessed only via getArray/setArray. */
private transient volatile Object[] array;
public E get(int index) {
return get(getArray(), index);
}
@SuppressWarnings("unchecked")
private E get(Object[] a, int index) {
return (E) a[index];
}
final Object[] getArray() {
return array;
}

CopyOnWriteArrayList 写入操作的实现

CopyOnWriteArrayList 写入操作 add() 方法在添加集合的时候加了锁，保证了同步，避免了多线程写的时候会 copy 出多个副本出来。


/**
 * Appends the specified element to the end of this list.
 *
 * @param e element to be appended to this list
 * @return {@code true} (as specified by {@link Collection#add})
 */
public boolean add(E e) {
final ReentrantLock lock = this.lock;
lock.lock();//加锁
try {
Object[] elements = getArray();
int len = elements.length;
Object[] newElements = Arrays.copyOf(elements, len + 1);//拷贝新数组
newElements[len] = e;
setArray(newElements);
return true;
} finally {
lock.unlock();//释放锁
}
}

ConcurrentLinkedQueue

Java提供的线程安全的 Queue 可以分为阻塞队列和非阻塞队列，其中阻塞队列的典型例子是 BlockingQueue，非阻塞队列的典型例子是ConcurrentLinkedQueue，在实际应用中要根据实际需要选用阻塞队列或者非阻塞队列。 阻塞队列可以通过加锁来实现，非阻塞队列可以通过 CAS 操作实现。

从名字可以看出，ConcurrentLinkedQueue这个队列使用链表作为其数据结构．ConcurrentLinkedQueue 应该算是在高并发环境中性能最好的队列了。它之所有能有很好的性能，是因为其内部复杂的实现。

ConcurrentLinkedQueue 内部代码我们就不分析了，大家知道ConcurrentLinkedQueue 主要使用 CAS 非阻塞算法来实现线程安全就好了。

ConcurrentLinkedQueue 适合在对性能要求相对较高，同时对队列的读写存在多个线程同时进行的场景，即如果对队列加锁的成本较高则适合使用无锁的ConcurrentLinkedQueue来替代。

BlockingQueue

BlockingQueue 简单介绍

上面我们己经提到了 ConcurrentLinkedQueue 作为高性能的非阻塞队列。下面我们要讲到的是阻塞队列——BlockingQueue。阻塞队列（BlockingQueue）被广泛使用在“生产者-消费者”问题中，其原因是BlockingQueue提供了可阻塞的插入和移除的方法。当队列容器已满，生产者线程会被阻塞，直到队列未满；当队列容器为空时，消费者线程会被阻塞，直至队列非空时为止。

BlockingQueue 是一个接口，继承自 Queue，所以其实现类也可以作为 Queue 的实现来使用，而 Queue 又继承自 Collection 接口。下面是 BlockingQueue 的相关实现类：

下面主要介绍一下:ArrayBlockingQueue、LinkedBlockingQueue、PriorityBlockingQueue，这三个 BlockingQueue 的实现类。

ArrayBlockingQueue

ArrayBlockingQueue 是 BlockingQueue 接口的有界队列实现类，底层采用数组来实现。ArrayBlockingQueue一旦创建，容量不能改变。其并发控制采用可重入锁来控制，不管是插入操作还是读取操作，都需要获取到锁才能进行操作。当队列容量满时，尝试将元素放入队列将导致操作阻塞;尝试从一个空队列中取一个元素也会同样阻塞。

ArrayBlockingQueue 默认情况下不能保证线程访问队列的公平性，所谓公平性是指严格按照线程等待的绝对时间顺序，即最先等待的线程能够最先访问到 ArrayBlockingQueue。而非公平性则是指访问 ArrayBlockingQueue 的顺序不是遵守严格的时间顺序，有可能存在，当 ArrayBlockingQueue 可以被访问时，长时间阻塞的线程依然无法访问到 ArrayBlockingQueue。如果保证公平性，通常会降低吞吐量。如果需要获得公平性的 ArrayBlockingQueue，可采用如下代码：

1
2
3


private static ArrayBlockingQueue blockingQueue = new ArrayBlockingQueue(10,true);

LinkedBlockingQueue

LinkedBlockingQueue 底层基于单向链表实现的阻塞队列，可以当做无界队列也可以当做有界队列来使用，同样满足FIFO的特性，与ArrayBlockingQueue 相比起来具有更高的吞吐量，为了防止 LinkedBlockingQueue 容量迅速增，损耗大量内存。通常在创建LinkedBlockingQueue 对象时，会指定其大小，如果未指定，容量等于Integer.MAX_VALUE。

相关构造方法:


/**
 *某种意义上的无界队列
 * Creates a {@code LinkedBlockingQueue} with a capacity of
 * {@link Integer#MAX_VALUE}.
 */
public LinkedBlockingQueue() {
this(Integer.MAX_VALUE);
}

/**
 *有界队列
 * Creates a {@code LinkedBlockingQueue} with the given (fixed) capacity.
 *
 * @param capacity the capacity of this queue
 * @throws IllegalArgumentException if {@code capacity} is not greater
 *         than zero
 */
public LinkedBlockingQueue(int capacity) {
if (capacity <= 0) throw new IllegalArgumentException();
this.capacity = capacity;
last = head = new Node(null);
}

PriorityBlockingQueue

PriorityBlockingQueue 是一个支持优先级的无界阻塞队列。默认情况下元素采用自然顺序进行排序，也可以通过自定义类实现 compareTo() 方法来指定元素排序规则，或者初始化时通过构造器参数 Comparator 来指定排序规则。

PriorityBlockingQueue 并发控制采用的是 ReentrantLock，队列为无界队列（ArrayBlockingQueue 是有界队列，LinkedBlockingQueue 也可以通过在构造函数中传入 capacity 指定队列最大的容量，但是 PriorityBlockingQueue 只能指定初始的队列大小，后面插入元素的时候，如果空间不够的话会自动扩容）。

简单地说，它就是 PriorityQueue 的线程安全版本。不可以插入 null 值，同时，插入队列的对象必须是可比较大小的（comparable），否则报 ClassCastException 异常。它的插入操作 put 方法不会 block，因为它是无界队列（take 方法在队列为空的时候会阻塞）。

ConcurrentSkipListMap

为了引出ConcurrentSkipListMap，先带着大家简单理解一下跳表。

对于一个单链表，即使链表是有序的，如果我们想要在其中查找某个数据，也只能从头到尾遍历链表，这样效率自然就会很低，跳表就不一样了。跳表是一种可以用来快速查找的数据结构，有点类似于平衡树。它们都可以对元素进行快速的查找。但一个重要的区别是：对平衡树的插入和删除往往很可能导致平衡树进行一次全局的调整。而对跳表的插入和删除只需要对整个数据结构的局部进行操作即可。这样带来的好处是：在高并发的情况下，你会需要一个全局锁来保证整个平衡树的线程安全。而对于跳表，你只需要部分锁即可。这样，在高并发环境下，你就可以拥有更好的性能。而就查询的性能而言，跳表的时间复杂度也是 O(logn) 所以在并发数据结构中，JDK 使用跳表来实现一个 Map。

跳表的本质是同时维护了多个链表，并且链表是分层的，

最低层的链表维护了跳表内所有的元素，每上面一层链表都是下面一层的子集。

跳表内的所有链表的元素都是排序的。查找时，可以从顶级链表开始找。一旦发现被查找的元素大于当前链表中的取值，就会转入下一层链表继续找。这也就是说在查找过程中，搜索是跳跃式的。如上图所示，在跳表中查找元素18。

查找18 的时候原来需要遍历 18 次，现在只需要 7 次即可。针对链表长度比较大的时候，构建索引查找效率的提升就会非常明显。

从上面很容易看出，跳表是一种利用空间换时间的算法。

使用跳表实现Map 和使用哈希算法实现Map的另外一个不同之处是：哈希并不会保存元素的顺序，而跳表内所有的元素都是排序的。因此在对跳表进行遍历时，你会得到一个有序的结果。所以，如果你的应用需要有序性，那么跳表就是你不二的选择。JDK 中实现这一数据结构的类是ConcurrentSkipListMap。

锁相关问题

何谓悲观锁与乐观锁

乐观锁对应于生活中乐观的人总是想着事情往好的方向发展，悲观锁对应于生活中悲观的人总是想着事情往坏的方向发展。这两种人各有优缺点，不能不以场景而定说一种人好于另外一种人。

悲观锁

总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。

乐观锁

总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

两种锁的使用场景

从上面对两种锁的介绍，我们知道两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。

乐观锁常见的两种实现方式

乐观锁一般会使用版本号机制或CAS算法实现。

版本号机制

一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。

举一个简单的例子：
假设数据库中帐户信息表中有一个 version 字段，当前值为 1 ；而当前帐户余额字段（ balance ）为 $100 。

操作员 A 此时将其读出（ version=1 ），并从其帐户余额中扣除 $50（ $100-$50 ）。
在操作员 A 操作的过程中，操作员B 也读入此用户信息（ version=1 ），并从其帐户余额中扣除 $20 （ $100-$20 ）。
操作员 A 完成了修改工作，将数据版本号加一（ version=2 ），连同帐户扣除后余额（ balance=$50 ），提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。
操作员 B 完成了操作，也将版本号加一（ version=2 ）试图向数据库提交数据（ balance=$80 ），但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 2 ，数据库记录当前版本也为 2 ，不满足 “ 提交版本必须大于记录当前版本才能执行更新 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。

这样，就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作员A 的操作结果的可能。

CAS算法

即compare and swap（比较与交换），是一种有名的无锁算法。无锁编程，即不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。CAS算法涉及到三个操作数

需要读写的内存值 V
进行比较的值 A
拟写入的新值 B

当且仅当 V 的值等于 A时，CAS通过原子方式用新值B来更新V的值，否则不会执行任何操作（比较和替换是一个原子操作）。一般情况下是一个自旋操作，即不断的重试。

乐观锁的缺点

ABA 问题是乐观锁一个常见的问题

ABA 问题

如果一个变量V初次读取的时候是A值，并且在准备赋值的时候检查到它仍然是A值，那我们就能说明它的值没有被其他线程修改过了吗？很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回A，那CAS操作就会误认为它从来没有被修改过。这个问题被称为CAS操作的 “ABA”问题。

JDK 1.5 以后的 AtomicStampedReference 类就提供了此种能力，其中的 compareAndSet 方法就是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。

循环时间长开销大

自旋CAS（也就是不成功就一直循环执行直到成功）如果长时间不成功，会给CPU带来非常大的执行开销。 如果JVM能支持处理器提供的pause指令那么效率会有一定的提升，pause指令有两个作用，第一它可以延迟流水线执行指令（de-pipeline）,使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。第二它可以避免在退出循环的时候因内存顺序冲突（memory order violation）而引起CPU流水线被清空（CPU pipeline flush），从而提高CPU的执行效率。

只能保证一个共享变量的原子操作

CAS 只对单个共享变量有效，当操作涉及跨多个共享变量时 CAS 无效。但是从 JDK 1.5开始，提供了AtomicReference类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行 CAS 操作.所以我们可以使用锁或者利用AtomicReference类把多个共享变量合并成一个共享变量来操作。

CAS与synchronized的使用情景

简单的来说CAS适用于写比较少的情况下（多读场景，冲突一般较少），synchronized适用于写比较多的情况下（多写场景，冲突一般较多）

对于资源竞争较少（线程冲突较轻）的情况，使用synchronized同步锁进行线程阻塞和唤醒切换以及用户态内核态间的切换操作额外浪费消耗cpu资源；而CAS基于硬件实现，不需要进入内核，不需要切换线程，操作自旋几率较少，因此可以获得更高的性能。
对于资源竞争严重（线程冲突严重）的情况，CAS自旋的概率会比较大，从而浪费更多的CPU资源，效率低于synchronized。

Java并发编程这个领域中synchronized关键字一直都是元老级的角色，很久之前很多人都会称它为 “重量级锁” 。但是，在JavaSE 1.6之后进行了主要包括为了减少获得锁和释放锁带来的性能消耗而引入的 偏向锁 和 轻量级锁 以及其它各种优化之后变得在某些情况下并不是那么重了。synchronized的底层实现主要依靠 Lock-Free 的队列，基本思路是 自旋后阻塞，竞争切换后继续竞争锁，稍微牺牲了公平性，但获得了高吞吐量。在线程冲突较少的情况下，可以获得和CAS类似的性能；而线程冲突严重的情况下，性能远高于CAS。

Java String 源码分析

2019-08-25T17:35:45.000Z

定义

1 2	public final class String implements java.io.Serializable, Comparable, CharSequence {}

从定义可以看出

String 被 final 修饰(不允许被继承)

实现了如下接口：

Serializable（可以序列化和反序列化）
Comparable（可以进行自定义的字符串比较）
CharSequence（一个可读序列。此接口对许多不同种类的 char 序列提供统一的只读访问。StringBuilder 和StringBuffer也实现了这个接口）

属性

1
2
3

/** 用于存放字符串的数组 */
private final char value[];

由于被final修饰，故String对象一旦初始化后，其即为不可变（指其内容不能被修改，其引用还是可以指向其他的内容）。
String 是基于 char[] 实现的
频繁拼接字符串建议使用StringBuffer、StringBuilder、StringJoiner等

构造方法

无参构造器

public String() {
    this.value = "".value;
}

即 String str = new String(); 时，变量str的值为空字符串。

一个字符串类参数构造

public String(String original) {
    this.value = original.value;
    this.hash = original.hash;
}

这个方法会产生两个字符串对象，分别为参数original与新创建的字符串对象。

使用字符数组构造

public String(char value[]) {
    this.value = Arrays.copyOf(value, value.length);
}

带有offset与count的重载

public String(char value[], int offset, int count) {
    if (offset < 0) {
        throw new StringIndexOutOfBoundsException(offset);
    }
    if (count <= 0) {
        if (count < 0) {
            throw new StringIndexOutOfBoundsException(count);
        }
        if (offset <= value.length) {
           this.value = "".value;
           return;
       }
   }
     // Note: offset or count might be near -1>>>1.
     if (offset > value.length - count) {
         throw new StringIndexOutOfBoundsException(offset + count);
    }
    this.value = Arrays.copyOfRange(value, offset, offset+count);
}

使用字节数组构造

1
2
3

String(byte bytes[]);
String(byte bytes[], int offset, int length);

需要制定字符集的构造方法

String(byte bytes[], Charset charset);
String(byte bytes[], String charsetName);
String(byte bytes[], int offset, int length, Charset charset);
String(byte bytes[], int offset, int length, String charsetName);

使用`StringBuffer`或者`StringBuider`构造

很少用，因为StringBuffer::toString()或者StringBuider::toString()直接就可以生成一个String对象

特殊的构造方法

/*
 * Package private constructor which shares value array for speed.
 * this constructor is always expected to be called with share==true.
 * a separate constructor is needed because we already have a public
 * String(char[]) constructor that makes a copy of the given char[].
 */
String(char[] value, boolean share) {
    // assert share : "unshared not supported";
    this.value = value;
}

这个方法由Java7提供，直接饮用value[]的地址，并且share只能为true
提供这个方法的原因：性能好，节约空间，安全

一般方法

equals()方法

public boolean equals(Object anObject) {
    // 判断是否为同一对象
    if (this == anObject) {
        return true;
    }
    // 判断 anObject 是不是 String 类型
    if (anObject instanceof String) {
        String anotherString = (String)anObject;
        int n = value.length;
        // 判断长度是否相等
        if (n == anotherString.value.length) {
            char v1[] = value;
            char v2[] = anotherString.value;
            int i = 0;
            // 循环比较每一个 char 值
            while (n-- != 0) {
                if (v1[i] != v2[i])
                    return false;
                i++;
            }
            return true;
        }
    }
    return false;
}

一般默认是比较是否是同一个对象，此处默认重写，比较是否比较的是内容相同的两个字符串
比较是否是同一个对象
比较是否是字符串对象
循环比较每一位是否相同

hashCode()方法

public int hashCode() {
    int h = hash;
    if (h == 0 && value.length > 0) {
        char val[] = value;
        // 数学公式：s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]*31^0
        for (int i = 0; i < value.length; i++) {
            h = 31 * h + val[i];
        }
        hash = h;
    }
    return h;
}

常规hashCode方法

substring()方法

public String substring(int beginIndex, int endIndex) {
    if (beginIndex < 0) {
        throw new StringIndexOutOfBoundsException(beginIndex);
    }
    if (endIndex > value.length) {
        throw new StringIndexOutOfBoundsException(endIndex);
    }
    int subLen = endIndex - beginIndex;
    if (subLen < 0) {
        throw new StringIndexOutOfBoundsException(subLen);
    }
   // 将原来的 char[] 中的值逐一复制到新的 String 中
    return ((beginIndex == 0) && (endIndex == value.length)) ? this
            : new String(value, beginIndex, subLen);
}

Java 7 提供了一种新的实现方式牺牲一些性能，避免内存泄露。 Java 6 时，是同一个数组中操作。Java 7 是创建一个新的数组。

替换方法

replaceFirst、replaceAll、replace区别：
replace 的参数是 char 和 CharSequence，即可以支持字符的替换，也支持字符串的替换；
replaceAll 和 replaceFirst 的参数是 regex，即基于规则表达式的替换（如果所用的参数据不是基于规则表达式的，则与replace()替换字符串的效果一样。）

/**
 * value 为存储当前字符串对象的字符串数组名
 * 优化了比较次数
 * @param oldChar 将被替换掉的字符
 * @param newChar 新字符
 * @return
 */
public String replace(char oldChar, char newChar) {
    //如果新字符和老字符相同，直接返回当前字符串对象
    if (oldChar != newChar) {
        int len = value.length; //获取当前字符串长度
        int i = -1;
        char[] val = value; //目的：为了防止 getfield（获取指定类的实例域，并将其值压入到栈顶）这个操作码的执行
        //目的：找出将被替换的字符(oldChar)所在字符串数组中第一个字符的下标位置
        while (++i < len) {
            // 当找到第一个将被替换的字符时，跳出循环；i 就记录了下标位置
            // 如果没有找到，i==len 将不会进入下面的，直接返回当前字符串
            if (val[i] == oldChar) {
                break;
            }
        }
        if (i < len) {
            //将第一个将被替换的字符(oldChar)之前的不需要被替换的字符赋值给新数组buf
            char buf[] = new char[len];
            for (int j = 0; j < i; j++) {
                buf[j] = val[j];
            }
            // 从第一个将被替换的字符下标(i)开始，对字符进行替换操作
            while (i < len) {
                char c = val[i];
                buf[i] = (c == oldChar) ? newChar : c;
                i++;
            }
            return new String(buf, true);
        }
    }
    return this;
}

Java8新特性概览

2018-09-14T03:04:06.000Z

接口的默认实现

Java8允许我们通过使用default关键字在接口中添加一个非抽象方法。

interface Formula {
    double calculate(int a);

    default double sqrt(int a) {
        return Math.sqrt(a);
    }
}

除了抽象方法calculate外，接口Formula也定义了包含默认实现的sqrt方法。实现类只需要实现抽象方法calculate。默认方法sqrt可以做到开箱即用。

Formula formula = new Formula() {
    @Override
    public double calculate(int a) {
        return sqrt(a * 100);
    }
};

formula.calculate(100); // 100.0
formula.sqrt(16); // 4.0

formula被作为匿名对象实现。代码看起来比较冗长，6行代码职位了实现一个简单的计算sqrt(a * 100)。

Lambda表达式

首先是一个先前版本中对List进行排序的示例

List names = Arrays.asList("peter", "anna", "mike", "xenia");

Collections.sort(names, new Comparator() {
    @Override
    public int compare(String a, String b) {
        return b.compareTo(a);
    }
});

静态方法Collections.sort传入了一个list和Comparator对象用于对一直的列表进行排序。
为了不在频繁的创建匿名对象，Java8推出了更简短的语法:lambda表达式

1
2
3

Collections.sort(names, (String a, String b) -> {
    return b.compareTo(a);
});

改写成Labda表达式使得代码变得更加直观简短

1	Collections.sort(names, (String a, String b) -> b.compareTo(a));

对于方法体内只有一行代码的表达式，可以不使用{}和return关键字使得代码更加简短

1	Collections.sort(names, (a, b) -> b.compareTo(a));

因为Java编译器会自动推断传入参数的类型，所以参数表中的参数类型也可以省略。

函数式接口

lambda表达式如何匹配Java中的类型呢？每个lambda都由一个接口去指定类型。它(函数式接口)必须仅包含一个抽象方法的声明。每个该类型lambda表达式都会匹配这个抽象方法。

只要接口内只有一个抽象方法我们就可以把它当做lambda表达式使用。但是，为了确保接口是一定满足要求的，应当添加@FunctionalInterface注解。添加该注解后，当你再想接口内声明第二个抽象方法的时候，编译器会直接返回一个编译错误。

@FunctionalInterface
interface Converter {
    T convert(F from);
}

请注意，此处去掉@FunctionalInterface注解后该接口仍然可以作为lambda表达式使用。

1
2
3

Converter converter = (from) -> Integer.valueOf(from);
Integer converted = converter.convert("123");
System.out.println(converted); // 123

一个或多个static方法不会影响该接口成为函数式接口
接口中可以包含被default关键字修饰的默认实现
支持泛型与继承关系，只要继承后的接口仍然满足成为函数式接口的条件

方法与构造方法的引用

之前的代码可以通过静态方法引用进一步简化：

1
2
3

Converter converter = Integer::valueOf;
Integer converted = converter.convert("123");
System.out.println(converted); // 123

Java8可以使用::关键字传递对方法或构造方法的引用。上面的代码演示了如何引用静态方法，下面演示如何引用对象的方法。

class Something {
    String startsWith(String s) {
        return String.valueOf(s.charAt(0));
    }
}

Something something = new Something();
Converter converter = something::startsWith;
String converted = converter.convert("Java");
System.out.println(converted); // "J"

接下来演示调用构造方法的情况：

首先定义一个拥有不同构造方法Bean

class Person {
    String firstName;
    String lastName;

    Person() {}

    Person(String firstName, String lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }
}

然后创建一个Person类型的工厂的接口用来创建person对象

1
2
3

interface PersonFactoryextends Person> {
    P create(String firstName, String lastName);
}

使用示例
我们可以通过构造方法的引用去调用该接口而不用去实现其定义的抽象方法。
1
2
PersonFactory personFactory = Person::new;
Person person = personFactory.create("Peter", "Parker");
我们通过Person::new创建了对Person类构造方法的引用。Java编译器会根据PersonFactory.create中传入的参数重载构造方法。

Lambda作用域

Lambda在访问外层作用域的变量时，与匿名对象的方式类似。

访问局部变量

final int num = 1;
Converter stringConverter =
(from) -> String.valueOf(from + num);

stringConverter.convert(2); // 3

与匿名对象不同，变量num不是必须使用final修饰。下面代码仍然合理。

int num = 1;
Converter stringConverter =
(from) -> String.valueOf(from + num);

stringConverter.convert(2); // 3

但是在编译过程中num会隐式转换为被final修饰的，所以如下代码不能通过编译:

int num = 1;
Converter stringConverter =
(from) -> String.valueOf(from + num);
num = 3; /* 这里不同 */

并且在labda表达式中修改num的值也是被禁止的。

访问属性与静态变量

与匿名对象相同，在lambda作用域内，可以对外部的属性与静态变量进行访问与修改。

class Lambda4 {
    static int outerStaticNum;
    int outerNum;

    void testScopes() {
        Converter stringConverter1 = (from) -> {
        outerNum = 23;
        return String.valueOf(from);
    };

    Converter stringConverter2 = (from) -> {
        outerStaticNum = 72;
        return String.valueOf(from);
    };
}
}

访问接口的默认实现方法

在之前提到的Formula接口中声明的被default修饰的的sqrt方法可以直接使用。但是对于lambda表达式则不可以。

默认方法在lambda作用域中不能被访问，以下代码不能正常运行。

1	Formula formula = (a) -> sqrt( a * 100);

内建函数式接口

JDK1.8中包括了许多内建的函数式接口。有些源自早先版本的JDK比如Comparator或者Runnable。这些现有的接口都是使用@FunctionalInterface注解拓展用来支持Lambda表达式。

Java8同样也加入了一些新的函数式接口使得开发更加快捷。比如Google Guava库。如果经常使用这个库，建议查看它的源码，以便了解其中较为常用的方法是如何通过函数式接口进行拓展的。

断言接口(Predicates)

Predicates是一个仅传入一个参数返回boolean类型的方法。这个接口包含了许多默认方法用于判断复杂逻辑(且，或，非)。

Predicate predicate = (s) -> s.length() > 0;

predicate.test("foo"); // true
predicate.negate().test("foo"); // false

Predicate nonNull = Objects::nonNull;
Predicate isNull = Objects::isNull;

Predicate isEmpty = String::isEmpty;
Predicate isNotEmpty = isEmpty.negate();

Functions接口(Functions)

Functions接口传入一个参数并且有返回值。默认方法可以和链式方法一起使用(compose,andThen)

Function toInteger = Integer::valueOf;
Function backToString = toInteger.andThen(String::valueOf);

backToString.apply("123"); // "123"

生产者(Suppliers)

通过生产者能得到一个传入泛型的对象。与Functions接口不同，生产者不传入任何参数。

1 2	Supplier personSupplier = Person::new; personSupplier.get(); // new Person

消费者(Consumers)

消费者提供对单一输入参数的处理。

1 2	Consumer greeter = (p) -> System.out.println("Hello, " + p.firstName); greeter.accept(new Person("Luke", "Skywalker"));

比较器(Comparators)

Comparators在早先的Java版本中比较常用。Java8为他在接口中添加了大量的默认方法。

Optionals类(Optionals)

Optionals不是一个函数式接口，是一种为了避免NullPointerException的实用解决方案。

Optionals是一个简单的值容器，它可以为null或非空值。如果一个方法可能返回null也可能返回非空值就可以使用Optional。

Optional optional = Optional.of("bam");

optional.isPresent(); // true
optional.get(); // "bam"
optional.orElse("fallback"); // "bam"

optional.ifPresent((s) -> System.out.println(s.charAt(0))); // "b"

流(Streams)

java.util.Stream提供对一组元素进行一个或多个操作的方法。流操作不是intermediate(可以继续操作)就是terminal(不可以继续操作)的。terminal操作返回一个明确的类型结果，intermediate操作返回流本书以便于继续调用Stream方法进行处理。流处理的数据源可以来自java.util.Collection中的列表(list)或者集合set。流操作可以是连续的也可以是并行的。

List stringCollection = new ArrayList<>();
stringCollection.add("ddd2");
stringCollection.add("aaa2");
stringCollection.add("bbb1");
stringCollection.add("aaa1");
stringCollection.add("bbb3");
stringCollection.add("ccc");
stringCollection.add("bbb2");
stringCollection.add("ddd1");

在Java8中Collections已被拓展用于支持流操作，所以只需要调用Collection.stream()或Collection.parallelStream()就能得到流处理所需要的数据源。

过滤方法(Filter)

Filter传入一个Predicate对象用来过滤流中的所有元素。这个操作是intermediate(可继续操作的)。所以我们在调用filter后还可以继续调用forEach去遍历流中的元素。但是forEach是terminal(不可继续操作的)。它的返回值类型是void，所以不能再继续调用任何流处理方法。

stringCollection
    .stream()
    .filter((s) -> s.startsWith("a"))
    .forEach(System.out::println);

// "aaa2", "aaa1"

排序方法(Sorted)

Sorted是intermediate(可继续操作的)返回按照既定规则排序的流数据视图的方法。视图中的元素会按照自然序排序除非指定了Comparator。

stringCollection
    .stream()
    .sorted()
    .filter((s) -> s.startsWith("a"))
    .forEach(System.out::println);

// "aaa1", "aaa2"

Sorted仅创建了排序后元素的视图，并没有真正去更改集合中元素的位置，集合中元素位置不会受到该方法的影响

1 2	System.out.println(stringCollection); // ddd2, aaa2, bbb1, aaa1, bbb3, ccc, bbb2, ddd1

映射方法(Map)

Map是intermediate(可继续操作的)。它通过给定方法将元素放到另一个对象中。下面的例子把流中的元素转换为大写，当然也可以使用map方法把流中对象转换为另一个类型的对象。结果流的泛型类型取决于传递给map方法的泛型类型。

stringCollection
    .stream()
    .map(String::toUpperCase)
    .sorted((a, b) -> b.compareTo(a))
    .forEach(System.out::println);

// "DDD2", "DDD1", "CCC", "BBB3", "BBB2", "AAA2", "AAA1"

匹配方法(Match)

Match是terminal(可继续操作的)。Match可以用来检查流中是否存在复合匹配条件的数据，并返回true或false。

boolean anyStartsWithA =
stringCollection
    .stream()
    .anyMatch((s) -> s.startsWith("a"));

System.out.println(anyStartsWithA); // true

boolean allStartsWithA = 
    stringCollection 
        .stream() 
        .allMatch((s) -> s.startsWith("a"));

System.out.println(allStartsWithA); // false

boolean noneStartsWithZ =
    stringCollection
        .stream()
        .noneMatch((s) -> s.startsWith("z"));

System.out.println(noneStartsWithZ); // true

计数器(Count)

Count是terminal(不可继续操作的)。返回流中元素的数量，返回值类型为long。

long startsWithB =
    stringCollection
        .stream()
        .filter((s) -> s.startsWith("b"))
        .count();

System.out.println(startsWithB); // 3

合并(Reduce)

Reduce是terminal(不可继续操作的)。它按照给定的规则合并流内的元素，并且使用Optional承载结果值。

Optional reduced =
    stringCollection
        .stream()
        .sorted()
        .reduce((s1, s2) -> s1 + "#" + s2);

reduced.ifPresent(System.out::println);
// "aaa1#aaa2#bbb1#bbb2#bbb3#ccc#ddd1#ddd2"

并行流(Parallel Streams)

流可以是sequential(顺序的)也可以是parallel(并行的)。并行流是在多线程的基础上完成的。

下面的例子是展示使用并行流并且并行流的使用非常简单。

首先创建一个有序的并有很多元素的list

int max = 1000000;
List values = new ArrayList<>(max);
for (int i = 0; i < max; i++) {
    UUID uuid = UUID.randomUUID();
    values.add(uuid.toString());
}

然后我们来测试一下对这个list排序所消耗的时间。

顺序执行排序(Sequential Sort)

long t0 = System.nanoTime();

long count = values.stream().sorted().count();
System.out.println(count);

long t1 = System.nanoTime();

long millis = TimeUnit.NANOSECONDS.toMillis(t1 - t0);
System.out.println(String.format("sequential sort took: %d ms", millis));

// sequential sort took: 899 ms

并行执行排序(Parallel Sort)

long t0 = System.nanoTime();

long count = values.parallelStream().sorted().count();
System.out.println(count);

long t1 = System.nanoTime();

long millis = TimeUnit.NANOSECONDS.toMillis(t1 - t0);
System.out.println(String.format("parallel sort took: %d ms", millis));

// parallel sort took: 472 ms

根据演示可以很直观的看到，代码量上，两种方式几乎一样，但是并行执行的效率比顺序执行的效率要高出近50%，而在编码过程中需要做的仅仅是将stream()替换为parallelStream()。

Map类(Map)

虽然Map现在并不支持流操作，但是它也新加入了许多好用的方法去完成一些常用需求。

Map map = new HashMap<>();

for (int i = 0; i < 10; i++) {
    map.putIfAbsent(i, "val" + i);
}

map.forEach((id, val) -> System.out.println(val));

上面代码中的putIfAbsent避免了我们在进行新增操作时候的非空校验。forEach则传入了一个消费者去操作map中的每个值。

下面的例子将展示如何通过函数化接口操作map

map.computeIfPresent(3, (num, val) -> val + num);
map.get(3); // val33

map.computeIfPresent(9, (num, val) -> null);
map.containsKey(9); // false

map.computeIfAbsent(23, num -> "val" + num);
map.containsKey(23); // true

map.computeIfAbsent(3, num -> "bam");
map.get(3); // val33

下面例子展示在给定key并且当前map内的value与给定值相等时才执行删除操作：

map.remove(3, "val3");
map.get(3); // val33

map.remove(3, "val33");
map.get(3); // null

获取给定key内的值，当不存在时，返回给定的默认值：

1	map.getOrDefault(42, "not found"); // not found

合并merging

map.merge(9, "val9", (value, newValue) -> value.concat(newValue));
map.get(9); // val9

map.merge(9, "concat", (value, newValue) -> value.concat(newValue));
map.get(9); // val9concat

如果合并key不冲突则直接合并，否则调用合并方法。

日期API(Date API)

Java8在java.time包下包含全新的日期和时间API。新的日期API可以与Joda-time库进行比较运算，但是它们并不相同。下面的示例介绍了这个新API最重要的部分。

时钟类(Clock)

时钟类提供对当前日期和时间的访问。时钟类依赖时区，可以使用它代替System.currentTimeMillis()来检索当前毫秒。时间线上的这样一个瞬时点也由Instant类表示.实例可以用来创建原有的java.util.Date对象。

Clock clock = Clock.systemDefaultZone();
long millis = clock.millis();

Instant instant = clock.instant();
Date legacyDate = Date.from(instant);   // legacy java.util.Date

时区类(Timezones)

时区由ZoneId表示。可以通过静态工厂方法访问。时区定义了非常重要的offsets(偏移量)使得它能够在 instants、local dates 与 times之间进行转化。

System.out.println(ZoneId.getAvailableZoneIds());
// prints all available timezone ids

ZoneId zone1 = ZoneId.of("Europe/Berlin");
ZoneId zone2 = ZoneId.of("Brazil/East");
System.out.println(zone1.getRules());
System.out.println(zone2.getRules());

// ZoneRules[currentStandardOffset=+01:00]
// ZoneRules[currentStandardOffset=-03:00]

本地时间类(LocalTime)

本地时间类不使用时区表示(指显示不包含时区)，例如：10pm或者17:30:15。下面的例子使用上面定义的时区创建了两个LocalTime对象。

LocalTime now1 = LocalTime.now(zone1);
LocalTime now2 = LocalTime.now(zone2);

System.out.println(now1.isBefore(now2));  // false

long hoursBetween = ChronoUnit.HOURS.between(now1, now2);
long minutesBetween = ChronoUnit.MINUTES.between(now1, now2);

System.out.println(hoursBetween);       // -3
System.out.println(minutesBetween);     // -239

LocalTime可以使用很多工厂去简化实例的新建过程，包括转化成字符串。

LocalTime late = LocalTime.of(23, 59, 59);
System.out.println(late);       // 23:59:59

DateTimeFormatter germanFormatter =
    DateTimeFormatter
        .ofLocalizedTime(FormatStyle.SHORT)
        .withLocale(Locale.GERMAN);

LocalTime leetTime = LocalTime.parse("13:37", germanFormatter);
System.out.println(leetTime);   // 13:37

本地日期类(LocalDate)

LocalDate表示一个确定的日期，比如2014-03-11。它与LocalTime类似，也是不可变的。以下例子展示如何通过年月日的加减生成新的日期。
注意，每次操作都会返回一个新的实例。

LocalDate today = LocalDate.now();
LocalDate tomorrow = today.plus(1, ChronoUnit.DAYS);
LocalDate yesterday = tomorrow.minusDays(2);

LocalDate independenceDay = LocalDate.of(2014, Month.JULY, 4);
DayOfWeek dayOfWeek = independenceDay.getDayOfWeek();
System.out.println(dayOfWeek);    // FRIDAY

从String(需要是符合日期格式的)转换为LocalDate与LocalTime一样简单。

DateTimeFormatter germanFormatter =
    DateTimeFormatter
        .ofLocalizedDate(FormatStyle.MEDIUM)
        .withLocale(Locale.GERMAN);

LocalDate xmas = LocalDate.parse("24.12.2014", germanFormatter);
System.out.println(xmas);   // 2014-12-24

本地日期时间类(LocalDateTime)

LocalDateTime是日期与时间的组合。他讲上面提到的LocalDate与LocalTime组合成一个新的实例，与之相似，他也是不可变的。我们可以使用工具方法从实例中得到日期或时间相关的值。

LocalDateTime sylvester = LocalDateTime.of(2014, Month.DECEMBER, 31, 23, 59, 59);

DayOfWeek dayOfWeek = sylvester.getDayOfWeek();
System.out.println(dayOfWeek);      // WEDNESDAY

Month month = sylvester.getMonth();
System.out.println(month);          // DECEMBER

long minuteOfDay = sylvester.getLong(ChronoField.MINUTE_OF_DAY);
System.out.println(minuteOfDay);    // 1439

通过添加时区的操作可以使其很容易的转换为一个新的Instant 实例。而且Instant很容易转换成先前版本的java.util.Date。

Instant instant = sylvester
        .atZone(ZoneId.systemDefault())
        .toInstant();

Date legacyDate = Date.from(instant);
System.out.println(legacyDate);     // Wed Dec 31 23:59:59 CET 2014

格式化日期时间就像格式化日期或时间一样。我们可以根据自定义模式创建格式化程序，而无需使用预定义的格式。

DateTimeFormatter formatter =
    DateTimeFormatter
        .ofPattern("MMM dd, yyyy - HH:mm");

LocalDateTime parsed = LocalDateTime.parse("Nov 03, 2014 - 07:13", formatter);
String string = formatter.format(parsed);
System.out.println(string);     // Nov 03, 2014 - 07:13

与java.text.NumberFormat不同,DateTimeFormatter是不可变的且线程安全的。

注解(Annotations)

Annotations在Java8中是可以重复的(支持重载的)，比如下面的例子:

@interface Hints {
    Hint[] value();
}

@Repeatable(Hints.class)
@interface Hint {
    String value();
}

Java8能够通过声明注解@Repeable来使用相同类型的多个注解。

使用注解容器(老派)

1 2	@Hints({@Hint("hint1"), @Hint("hint2")}) class Person {}

使用Repeatable注解(新派)

1
2
3

@Hint("hint1")
@Hint("hint2")
class Person {}

在使用第二种方式的时候，Java编译器会隐式的声明@Hints注解。

通过反射的方式获取注解：

Hint hint = Person.class.getAnnotation(Hint.class);
System.out.println(hint);                   // null

Hints hints1 = Person.class.getAnnotation(Hints.class);
System.out.println(hints1.value().length);  // 2

Hint[] hints2 = Person.class.getAnnotationsByType(Hint.class);
System.out.println(hints2.length);          // 2

虽然我们从来没有在Person类上声明过@Hints注解，但它仍能通过getAnnotation(Hints.class)读取到。而更方便的方式是通过getAnnotationsByType,它能赋予所有@Hint注解的直接访问权限。

Java8中注解中拓展了两个新的使用目标(Target)：

1 2	@Target({ElementType.TYPE_PARAMETER, ElementType.TYPE_USE}) @interface MyAnnotation {}

文章翻译自以下地址：

深入理解Java虚拟机 - 第八章

2018-07-18T10:02:43.000Z

第八章虚拟机字节码执行引擎

概述

执行引擎是Java虚拟机最核心的组成之一。

运行时栈帧结构

栈帧（Stack Frame）是用于支持方法调用和方法执行的数据结构。它是虚拟机运行时数据区中的虚拟机栈的栈元素，存储了方法的局部变量表、操作数栈、动态链接和方法返回地址等信息。每一个方法从调用开始到执行完成的过程，就对应着一个栈帧在虚拟机栈里面从入栈道出栈的过程。
栈帧的概念结构图：

局部变量表

局部变量表是一组变量值存储空间，用于存放方法的参数和方法类定义的局部变量。
它是以变量槽（Variable Slot）为最小单位，每一个Slot（32位）都应该能放一个 boolean 、byte 、char 、float 、 reference 、 short 、 int 或 returnAddress 类型数据。而至于 long 、double 两种数据则被规定为是64位数据（连续两个32位）。
reference类型数据可能食32位，也可能是64位数据

操作数栈

也被称之为操作栈，是一个先进先出（FIFO）的栈。

操作数栈的最大深度也在编译的时候就被写入到code属性的 max_stacks 数据项之中。
在概念模型中，两个栈帧相互之间是完全独立的，但是大多数虚拟机会做一些优化处理，令两个栈帧出现一部分重叠，这样在方法调用时就可以公用一部分数据，无须进行额外的参数复制传递的操作。如下图示：

动态连接

每个栈帧都包含一个运行时常量池中指向该栈帧所属方法的引用，这是为了支持方法调用过程中的动态连接。

方法返回地址

当一个方法被执行时，有两种方式推出这个方法：

正常完成出口（Normal Method Invocation Completion）
异常完成出口（Abrupt Method Invocation Completion）

附加信息

虚拟机规范允许具体的虚拟机实现增加一些规范里没有描述的信息到栈帧之中。

方法调用

确定被调用方法的版本（即调用哪一个方法）。

方法解析

调用目标在程序写好、编译器进行编译时就确定下来，这种方法的调用称之为解析（Resolution）。
简单总结就是：编译器可知，运行期不可变。
在Java中符合这种要求的方法主要有：静态方法和私有方法

分派

静态分派

Human man = new Man();
静态类型：Human
实际类型：Man
在编译阶段，Javac编译器就根据参数的静态类型决定使用哪个重载版本。

动态分派

在运行期间根据实际类型确定方法执行版本的分配过程称为动态分派。

单分派与多分派

单分派是根据一个宗量对目标方法进行选择。
多分派则是根据多于一个的宗量对目标方法进行选择。

宗量：方法的接收者与方法的参数统称为方法的宗量。
单分派定义
根据一个宗量对目标方法进行选择，即为单分派。(动态分派属于单分派)
多分派
根据多于一个宗量对目标方法进行选择，即为多分派。(静态分派属于多分派)

深入理解Java虚拟机 - 第七章

2018-07-18T05:22:36.000Z

第七章虚拟机类的加载机制

7.1 概述

虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类的加载机制。

7.2 类的加载时机

加载（Loading）：按照虚拟机规范，有且只有以下四种情况下必须立即对类进行“初始化”：
遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有初始化，则需要先出发其初始化。生成这4条指令的典型场景是：使用 new 关键字实例化对象的时候、读取或设置一个类的静态字段的时候（被final修饰、已在编译期把结果放入常量池的静态字段除外）、以及调用一个类的静态方法的时候
使用 java.lang.reflect 包的方法对类进行反射调用的时候
当初始化一个类时，如果发现它的父类还没有进行初始化，则需要先触发其父类进行初始化
当虚拟机启动时，用户需要指定一个要执行的主类（包含main方法的类），虚拟机会先初始化这个类

7.3 类的加载过程

加载、验证、准备、解析、初始化

7.3.1 加载

加载（Loading）阶段，虚拟机需要完成以下三件事：

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

7.3.2 验证

验证是虚拟机对自身保护的一项重要工作。

大致完成以下四个阶段的检验过程：

文件格式验证，验证字节流是否符合Class文件格式规范，并且能被当前版本的虚拟机处理。
元数据验证，对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范要求。
字节码验证，主要工作是进行数据流和控制流分析，保证被校验类的方法不会危害到虚拟机的安全。
符号引用验证，可以看作是对类自身以外（常量池中的各种符号引用）的信息进行匹配性的校验。

7.3.3 准备

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

7.3.4 解析

是虚拟机将常量池中的符号引用替换为直接引用的过程。

解析动作主要针对类或接口、字段、类方法、接口方法四类符号引用分别进行。

7.3.5 初始化

真正开始执行类中定义的Java程序代码（或者说是字节码）。

7.4 类加载器

类加载过程中的 通过一个类的全限定名来获取描述这个类的二进制字节流” 这个动作是放在Java虚拟机的外部来实现的，以便于让应用程序自己来决定如何去获取所需要的类，实现这个动作的代码模块被称为 “类加载器”。

7.4.1 类和类加载器

类加载器 虽然只用于实现类的加载动作，但是它的作用却远远不限于此，比较两个类是否“相等”，不仅仅要确认这两个类是否来源于同一个class文件，还需要加载这两个类的类加载器相同。

7.4.2 双亲委派模型

站在虚拟机的角度，只存在两种类加载器：

启动类加载器（Bootstrap ClassLoader），使用C++实现，是虚拟机的一部分
其他类加载器，由Java语言实现，独立于虚拟机之外的，全部继承自抽象类 java.lang.ClassLoader

从开发人员的角度，类加载器可以划分得更细致一些：

启动类加载器（Bootstrap ClassLoader）：负责将存放在 \lib 目录中的，或者被 -Xbootclasspath 参数所指定的路径中的，并且是虚拟机识别的类库加载到虚拟机内存中。
扩展类加载器（Extension ClassLoader）：负责加载 \lib\ext 目录下的，或者被 java.ext.dirs 系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。
应用程序类加载器（Application ClassLoader）：负责加载用户类路径（ClassPath）上所指定的类库，一般情况下这个就是程序中默认的类加载器。

以上加载器互相配合来加载我们自己的应用程序，如果有必要，我们还可以加入自己定义的加载器。这些加载器之间的关系一般如下图示：

类加载器的双亲委派模型（Parent Delegation Model）：要求除了顶层的启动类加载器外，其余的类加载器都必须有自己的父类加载器。（这里类加载器之间的父子关系一般不会以继承（Inheritance）来实现，而是使用组合（Composition）来复用父加载器的代码）。这种模型被广泛使用于几乎所有的Java程序中，但是它并不是一个强制性的约束，只是Java设计者推荐给开发者使用的一种类加载器实现方式。

双亲委派模型的具体工作过程是：如果一个类收到了加载请求，它首先不会尝试自己去加载这个类，而是把这个请求委派给他的父类加载器去完成，每一层次的加载类都是如此，因此所有的加载请求都会传递给最顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围内找不到需要加载的类）时，子类才会尝试自己去加载。

好处：java类随着它的类加载器一起具备了一种带有优先层级的层次关系，保证了Java程序的稳定运行。

7.4.3 破坏双亲委派模型

OSGi

深入理解Java虚拟机 - 第六章

2018-07-18T00:59:28.000Z

第六章类文件结构

概述

现在越来越多的程序语言选择了与操作系统无关和机器指令无关的、平台中立的格式作为程序编译后的存储格式。

无关性的基石

Class类文件的结构

Class文件是一组以8位字节为基础单位的二进制流，各个数据项目严格按照顺序紧凑地排列在Class文件中，中间没有添加任何分隔符。当遇到需要占用8位字节以上空间的数据项时，则会按照高位在前的方式分割成若干个8位字节进行存储。

按照Java虚拟机规范，Class文件格式采用一种类似于C语言结构体的伪结构来存储，这种结构中只有两种数据类型：无符号数和表。

无符号数属于基本的数据类型，以u1、u2、u4、u8来分别代表1个字节、2个字节、4个字节、和8个字节的无符号数，无符号数可以用来描述数字、索引引用、数量值、或者按照UTF-8编码构成字符串值。
表是由多个无符号数或其他表作为数据项构成的复合数据类型，所有的表都习惯性地以"_info"结尾。表用于描述有层次关系的复合数据结构的数据，整个Class文件本质上就是一张表，它由如下所示的数据项构成：

无论是无符号数还是表，当需要描述同一类型单数量不定的多个数据时，经常会使用一个前置的容量计数器加若干个连续的数据项的形式，这时候称这一系列连续的某一类型的数据位某一类型的集合。

魔数与Class文件的版本

每个Class文件的头4个字节称为魔数（Magic Number），它的唯一作用时用语确定这个文件是否作为一个能被虚拟机接受的Class文件。Class文件的魔数值是0xCAFEBABE。

紧挨着魔数的4个字节存储的是Class文件的版本号：第5和6个字节是次版本号（Minor Version），第7和8个字节是主版本号（Major Version）。Java的版本号是从45开始的，以后每个大版本发布后，主版本号向上加1，高版本的JDK能向下兼容以前版本的Class文件，但不能运行以后版本的Class文件，即使文件格式并未发生变化。

常量池

紧接着主次版本号之后的是常量池入口，它是Class文件中与其它项目关联最紧密的数据类型，也是占用Class文件空间最大的数据项目之一，同时还是Class文件中第一个出现的表类型数据项目。

常量池中主要存放两大类常量：字面量（Literal）和符号引用（Symbolic Reference）。字面量比较接近Java语言的常量概念，如文本字符串、被声明为final的常量值等。而符号引用则属于编译原理方面的概念，包括了下面三类常量：

类和接口的全限定名（Fully Quaified Name）
字段的名称和描述
方法的名称和描述符

常量池中每一项常量都是一个表

每一项的表结构

访问标志

访问标志（access_flag）：用于识别一些类或接口层次的访问信息，包括：这个Class是类还是接口，是否定义为public类型，是否定义为abstract类型，如果是类的话，是否被声明为final，等等。

具体的标志位及含义，见下表：

类索引、父类索引、接口索引集合

类索引（this_class）和父类索引（super_class）都是一个u2类型的数据，而接口索引集合是一个u2类型的数据集合，class文件由这三个数据来确定这个类的继承关系。

字段表集合

字段表（field_info）：用于描述类或者接口的声明的变量，不包括方法的内部声明变量。

字段表（field_info）用于描述接口或者类中声明的变量
字段（field）包括类级变量以及实例级变量，但不包括在方法内部声明的局部变量

name_index是对常量池的引用，代表着字段的简单名称
descriptor_index是对常量池的引用，代表字段的描述符

Java中一个字段（field）可以包含的信息包括：字段的作用域（public、private、protected）、类级别还是实例级别（static）、可变性（final）、并发可见性（volatile是否强制从主内存读写）、可否序列化（transient）、字段数据类型（基本类型、对象、数组）、名称。

方法表集合

方法表的结构如同【Chapter 6.3.5 字段表集合】一样，一次包括了，访问标识（access_flag）、名称索引（name_index）、描述符索引（descriptor_index）、属性表集合（attributes）。

属性表集合

属性表集合（attribute_info）：用于描述某些场景（Class文件、字段表、方法表）的专有信息。

属性表（attribute_info）在前面的讲解之中已经出现过数次，在Class文件、字段表、方法表都可以携带自己的属性表集合，以用于描述某些场景专有的信息。

虚拟机规范定义的属性

Code属性Java程序方法体中的代码经过Javac编译器处理后，最终变为字节码指令存储在Code属性内。Code属性出现在方法表的属性集合之中，但并非所有的方法表都必须存在这个属性，譬如接口或者抽象类中的方法就不存在Code属性

Code属性
Java程序方法体里面的代码经过javac编译器处理之后，最终会变成字节码指令存储在Code属性内。
Exceptions属性
列举出方法体中可能抛出的受查异常（checked exception），也就是方法描述时在throws关键字后面的异常。
LineNumberTable属性
用于描述Java字节码行号与源代码行号之间的对应关系（字节码的偏移量）。
LocalVariableTable属性
用于描述栈帧中局部变量表中的变量和Java源代码中定义的变量之间的关系。
SourceFile属性
用于记录生成这个Class文件的源码文件的名称。
ConstantValue属性
通知虚拟机自动为静态变量赋值。
InnerClasses属性
用于记录内部类与宿主之间的关联。
Deprecated和Synthetic属性
Deprecated属性用于表示某个类、字段或者方法，已经被程序作者定位废弃不推荐使用，可以在代码中通过 @deprecated 注释来设置。
Synthetic属性代表字段或方法并不是由Java源代码直接产生的，而是由编译器自行添加的。

深入理解Java虚拟机 - 第五章

2018-07-18T00:45:26.000Z

第五章调优案例分析与实战

案例分析

高性能硬件上的程序部署策略

问题描述

一个每天15万PV左右的在线文档网站升级了硬件，4个CPU，16GB物理内存，操作系统为64位CentOS 5.4，使用Resin作为Web服务器，没有部署其他的应用。
管理员选用了64位的JDK 1.5，并通过-Xmx和-Xms参数将Java堆固定在12GB。
使用一段时间不定期出现长时间失去响应的情况；
问题分析
升级前使用32位系统，Java堆设置为1.5GB，只是感觉运行缓慢没有明显的卡顿；
通过监控发现是由于GC停顿导致的，虚拟机运行在Server模式，默认使用吞吐量优先收集器，回收12GB的堆，一次Full GC的停顿时间高达14秒；
并且由于程序设计的原因，很多文档从磁盘加载到内存中，导致内存中出现很多由文档序列化生成的大对象，这些大对象进入了老年代，没有在Minor GC中清理掉；
解决办法
在虚拟机上建立5个32位的JDK逻辑集群，每个进程按2GB内存计算（其中堆固定为1.5GB），另外建议一个Apache服务作为前端均衡代理访问门户；
另外考虑服务压力主要在磁盘和内存访问，CPU资源敏感度较低，因此改为CMS收集器；
最终服务没有再出现长时间停顿，速度比硬件升级前有较大提升；

集群间同步导致的内存溢出

问题描述

一个基于B/S的MIS系统，硬件为两台2个CPU、8GB内存的HP小型机，服务器为WebLogic 9.2，每台机器启动了3个WebLogic实例，构建一个6台节点的亲和式集群（一个固定的用户请求永远分配到固定的节点处理）。
由于有部分数据需要共享，原先采用数据库，后因为读写性能问题使用了JBossCache构建了一个全局缓存；
正常使用一段较长的时间，最近不定期出现了多次的内存溢出问题；
问题分析
监控发现，服务内存回收状况一直正常，每次内存回收后都能恢复到一个稳定的可用空间
此次未升级业务代码，排除新修改代码引入的内存泄漏问题；
服务增加-XX:+HeapDumpOnOutOfMemoryError参数，在最近一次内存溢出时，分析heapdump文件发现存在大量的org.jgroups.protocols.pbcast,NAKACK对象；
最终分析发现是由于JBossCache的NAKACK栈在页面产生大量请求时，有个负责安全校验的全局Filter导致集群各个节点之间网络交互非常频繁，当网络情况不能满足传输要求时，大量的需要失败重发的数据在内存中不断堆积导致内存溢出。
解决办法

JBossCache版本改进；
程序设计优化，JBossCahce集群缓存同步，不大适合有频繁写操作的情况；

堆外内存导致的溢出错误

问题描述

一个学校的小型项目，基于B/S的电子考试系统，服务器是Jetty 7.1.4，硬件是一台普通PC机，Core i5 CPU，4GB内存，运行32位Windows操作系统；
为了实现客户端能实时地从服务器端接收考试数据，使用了逆向AJAX技术（也称为Comet或Server Side Push），选用CometD 1.1.1作为服务端推送框架；
测试期间发现服务端不定期抛出内存溢出；加入-XX:+HeapDumpOnOutOfMemoryError后抛出内存溢出时什么问题都没有，采用jstat观察GC并不频繁且GC回收正常；最后在内存溢出后从系统日志发现如下异常堆栈：

问题分析
在第二章里曾经说过直接内存溢出的场景，垃圾收集时，虚拟机虽然会对直接内存进行回收，但它只能等老年代满了触发Full GC时顺便清理，否则只能等内存溢出时catch住然后调用System.gc()，如果虚拟机还是不听（比如打开了-XX:+DisableExplictGC）则只能看着堆中还有许多空闲内存而溢出；
本案例中的CometD框架正好有大量的NIO操作需要使用直接内存；

外部命令导致系统缓慢

问题描述

一个数字校园应用系统，运行在一个4个CPU的Solaris 10操作系统上，中间件为GlassFish服务器；
系统在做大并发压力测试时，发现请求响应时间比较慢，通过监控工具发现CPU使用率很高，并且系统占用绝大多数的CPU资源的程序并不是应用系统本身；
通过Dtrace脚本发现最消耗CPU的竟然是fork系统调用（Linux用来产生新进程的）；
问题分析
最终发现是每个用户请求需要执行一个外部的shell脚本来获取一些系统信息，是通过Runtime.getRuntime().exec()方法调用的；
Java虚拟机在执行这个命令时先克隆一个和当前虚拟机拥有一样环境变量的进程，再用这个新进程去执行外部命令，如果频繁地执行这个操作，系统消耗会很大；
最终修改时改用Java的API去获取这些信息，系统恢复了正常；

服务器JVM进程奔溃

问题描述

一个基于B/S的MIS系统，硬件为两台2个CPU、8GB内存的HP系统，服务器是WebLogic 9.2（和案例”集群间同步导致的内存溢出”相同的系统）；
正常运行一段时间后发现运行期间频繁出现集群节点的虚拟机进程自动关闭的现象，留下一个hs_err_pid###.log，奔溃前不久都发生大量相同的异常，日志如下所示：

问题分析
这是一个远端断开连接的异常，得知在MIS系统工作流的待办事项变化时需要通过Web服务通知OA门户系统；
通过SoapUI测试发现调用后竟然需要长达3分钟才能返回，并且返回结果都是连接中断；
由于MIS使用异步方式调用，两边处理速度不对等，导致在等待的线程和Socket连接越来越多，最终在超过虚拟机承受能力后进场奔溃；
解决方法：将异步调用修改为生产者/消费者模型的消息队列处理，系统恢复正常；

不恰当数据结构导致内存占用过大

问题描述

有一个后台RPC服务器，使用64位虚拟机，内存配置为-Xms4g -Xmx8g -Xmn1g，使用ParNew + CMS的收集器组合；
平时Minor GC时间约在20毫秒内，但业务需要每10分钟加载一个约80MB的数据文件到内存进行数据分析，这些数据会在内存中形成超过100万个HashMap Entry，在这段时间里Minor GC会超过500毫秒，这个时间过长，GC日志如下：

问题分析

在分析数据文件期间，800M的Eden空间在Minor GC后对象还是存活的，而ParNew垃圾收集器使用的是复制算法，把这些对象复制到Survivor并维持这些对象引用成为沉重的负担，导致GC时间变长；
从GC可以将Survivor空间去掉（加入参数-XX:SurvivorRatio=65536、-XX:MaxTenuringThreshold=0或者-XX:AlwaysTenure），让新生代存活的对象第一次Minor GC后立即进入老年代，等到Major GC再清理。这种方式可以治标，但也有很大的副作用。
另外一种是从程序设计的角度看，HashMap结构中，只有key和value所存放的两个长整形数据是有效数据，共16B（2 * 8B），而实际耗费的内存位88B（长整形包装为Long对象需要多8B的MarkWord、8B的Klass指针，Map.Entry多了16B的对象头、8B的next字段和4B的int型hash字段、为对齐添加的4B空白填充，另外还有8B的Entry引用），内存空间效率（18%）太低。

由Windows虚拟内存导致的长时间停顿

问题描述

有一个带心跳检测功能的GUI桌面程序，每15秒发送一次心跳检查信号，如果对方30秒内都没有信信号返回，则认为和对方已断开连接；
程序上线后发现有误报，查询日志发现误报是因为程序会偶尔出现间隔约1分钟左右的时间完全无日志输出，处于停顿状态；
另外观察到GUI程序最小化时，资源管理中显示的占用内存大幅减小，但虚拟内存没变化；
因为是桌面程序，所需内存不大（-Xmx256m），加入参数-XX:+PrintGCApplicationStoppedTime -XX：PrintGCDateStamps -Xloggc:gclog.log后，从日志文件确认是GC导致的，大部分的GC时间在100ms以内，但偶尔会出现一次接近1min的GC；
加入参数-XX：PrintReferenceGC参数查看GC的具体日志信息，发现执行GC动作的时间并不长，但从准备开始GC到真正GC直接却消耗了大部分时间，如下所示：

问题分析
初步怀疑是最小化时工作内存被自动交换到磁盘的页面文件中，这样发生GC时就有可能因为恢复页面文件的操作而导致不正常的GC停顿；
在MSDN查证确认了这种猜想，加入参数-Dsun.awt.keepWorkingSetOnMinimize=true来解决；这个参数在很多AWT程序如VisualVM都有应用。

实战：Eclipse运行速度调优

升级JDK；
设置-XX:MaxPermSize=256M解决Eclipse判断虚拟机版本的bug；
加入参数-Xverfify:none禁止字节码验证；
虚拟机运行在client模式，采用C1轻量级编译器；
把-Xms和-XX：PermSize参数设置为-Xmx和-XX:MaxPermSize一样，这样强制虚拟机启动时把老年代和永久代的容量固定下来，避免运行时自动扩展；
增加参数-XX：DisableExplicitGC屏蔽掉显式GC触发；
采用ParNew+CMS的垃圾收集器组合；
最终从Eclipse启动耗时15秒到7秒左右， eclipse.ini配置如下：

深入理解Java虚拟机 - 第四章

2018-07-18T00:30:13.000Z

第四章虚拟机性能监控与故障处理工具

概述

给一个系统定位问题时，知识、经验是关键基础，数据是依据，工具是运用知识处理数据的手段。

JDK命令行工具

jps: 虚拟机进程状况工具

功能：可以列出正在运行的虚拟机进程，并线上虚拟机执行的主类名称及其本地虚拟机唯一ID（LVMID）；
对于本地虚拟机来说，LVMID和操作系统的进程ID是一致的；
其他的工具通常都需要依赖jps获取LVMID；
主要选项：-q（只输出LVMID）、-m（输出传给main函数的参数）、-l（输出主类的全名）、-v（输出虚拟机启动JVM参数）；

jstat：虚拟机统计信息监视工具

功能：监视虚拟机各种运行状态信息，包括类装载、内存、垃圾收集、JIT等；
纯文本监控首选；

jinfo：Java配置信息工具

功能：实时地查看虚拟机各项参数。虽然jps -v可以查看虚拟机启动参数，但是无法查看一些系统默认的参数。
支持运行期修改参数的能力，格式为“jinfo -flag name=value pid”；

jmap：Java内存映像工具

功能：用于生成堆转储快照（一般称为heapdump或dump文件）；
其他可生成heapdump的方式：使用参数-XX:+HeapDumpOnOutOfMemoryError；使用参数-XX:+HeapDumpOnCtrlBreak然后使用Ctrl+Break生成；Linux系统使用kill -3生成；
另外它还可以查询finalize执行队列、Java堆和永久代的详细信息；

jhat：虚拟机堆转储快照分析工具

功能：用于分析jmap生成的heapdump。其内置了一个微型的HTTP服务器，可以在浏览器查看分析结果；
实际很少用jhat，主要有两个原因：一是分析工程会耗用服务器资源；功能相对BisualVM、IBM HeapAnalyzer较为简陋；

jstack：Java堆栈跟踪工具

功能：用于生成虚拟机当前时刻的线程快照（一般称为threaddump或javacore文件）。javacore主要目的是定位线程出现长时间停顿的原因，比如死锁、死循环、请求外部资源响应长等；
另外JDK 1.5后Thread类新增了getAllStackTraces()方法，可以基于此自己增加管理页面来分析；

HSDIS：JIT生成代码反编译

现代虚拟机的实现慢慢地和虚拟机规范产生差距，如果要分析程序如果执行，最常见的就是通过软件调试工具（GDB、Windbg等）断点调试，但是对于Java来说，很多执行代码是通过JIT动态生成到CodeBuffer中的；
功能：HSDIS是官方推荐的HotSpot虚拟机JIT编译代码的反汇编工具，它包含在HotSpot虚拟机的源码中但没有提供编译后的程序，可以自己下载放到JDK的相关目录里；

JDK的可视化工具

JConsole：Java监视与管理控制台

是一种基于JMX的可视化监控和管理工具，它管理部分的功能是针对MBean进行管理，由于MBean可以使用代码、中间件服务器或者所有符合JMX规范的软件进行访问，因此这里着重介绍JConsole的监控功能；
通过jconsole命令启动JConsole后，会自动搜索本机所有虚拟机进程。另外还支持远程进程的监控；
进入主界面，支持查看以下标签页：概述、内存、线程、类、VM摘要和MBean；

4.3.2 VisualVM：多合一故障处理工具

目前为止JDK发布的功能最强调的运行监控和故障处理程序，另外还支持性能分析；
VisualVM还有一个很大的优点：不需要被监视的程序基于特殊Agent运行，对应用程序的实际性能影响很小，可直接应用在生成环境中；
VisualVM基于NetBeans平台开发，具备插件扩展功能的特性，基于插件可以做到：显示虚拟机进程以及进程配置、环境信息（jps、jinfo）、监视应用程序的CPU、GC、堆、方法区以及线程的信息（jstat、jstack）、dump以及分析堆转储快照（jmap、jhat）、方法级的程序运行性能分析，找出被调用最多运行时间最长的方法、离线程序快照（收集运行时配置、线程dump、内存dump等信息建立快照）、其他plugins的无限可能。
使用jvisualvm首次启动时需要在线自动安装插件（也可手工安装）；
特色功能：生成浏览堆转储快照（摘要、类、实例标签页、OQL控制台）、分析程序性能（Profiler页签可以录制一段时间程序每个方法执行次数和耗时）、BTrace动态日志跟踪（不停止目标程序运行的前提下通过HotSwap技术动态加入调试代码）；

深入理解Java虚拟机 - 第三章

2018-07-17T08:43:22.000Z

第三章垃圾收集器与内存分配策略

概述

垃圾收集（Garbage Collection , GC）的历史远远比Java久远。它需要完成三件事：

哪些内存需要回收
什么时候回收
如何回收

程序计数器、虚拟机栈、本地方法栈三个区域随线程而生，随线程而灭；栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作，每一个栈帧需要分配多少内存基本上是在类结构确定下来时就已知的（尽管在运行期会由JIT编译器进行一些优化，但是大体上可以认为是编译器可知的），因此在这几个区域的内存分配和回收都具有确定性，这几个区域不太需要过多地考虑回收的问题。而Java堆和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间才能知道会创建哪些对象，这部分的内存分配和回收都是动态的，垃圾收集器需要关注的是这部分内存，我们所讨论的“内存”分配与回收也仅仅指着一部分。

对象已死？

堆中存放着Java世界中几乎所有的对象，垃圾收集器在对堆进行回收前，第一件事就是要确定哪些对象还“存活着”，哪些已经“死去”（即不可能再被任何途径使用的对象）。

引用计数算法

引用计数算法（Reference Counting）：给对象添加一个引用计数器，每当有一个地方引用它时，计数器的数值就加1；当引用失效时，计数器数值就减1；任何时刻计数器都为0的对象就是不可能再被使用的。
实际上，Java并没有采用引用计数算法，因为它很难解决对象之间的相互循环引用的问题。

根搜索算法

在主流的商业程序语言中（Java和C#），都是使用根搜索算法（GC Roots Tracing）来判定对象是否存活的。
这个算法的基本思路是：通过一系列的名字为“GC Roots”的对象作为起点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链对象相连（用图论的话说，就是从GC Roots到这个对象不可到达）时，则证明此对象不可用。
如下图示：

对象object5、object6和object7虽然互相关联，但是他们到GC Roots是不可到达的，所以它们会被判定为师可回收对象。
在Java中，可以作为GC Roots的对象有以下几种：
虚拟机栈（栈中的本地变量表）中的引用的对象
方法区中的类静态属性引用的对象
方法区中的常量引用的对象
本地方法栈中JNI（即一般说的Native方法）的引用的对象

再谈引用

在JDK1.2之前，Java中的引用（Reference）非常狭隘：

如果Reference类型的数据中存储的数值代表着另一块内存的起始地址，就称这块内存代表着一个引用。

在JDK1.2之后，Java对引用的概念进行了扩充，将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）和虚引用（Phantom Reference）。这四种引用强度依次减弱。

强引用，就是在程序代码中普遍存在的，类似Object obj = new Object()这类的引用，只要强引用还存在，垃圾回收器永远不会回收掉被引用的对象。
软引用，用来描述一些还有用，但是并非必需的对象。对于软引用关联的对象，在系统将要发生内存溢出异常之前，将会把这些对象放进回收范围之中并进行第二次的回收。如果这次回收还是没有足够的内存，才会抛出内存溢出异常。在JDK1.2之后，提供了SoftReference类来实现软引用。
弱引用，也是用来描述非必需对象的，但是它的强度要比软引用弱一些，被弱引用关联的对象只能生存到下一次垃圾回收之前。当垃圾回收器工作时，不论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK1.2之后，提供了WeakReference来实现弱引用。
虚引用，也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不影响其生存时间，也无法通过虚引用来获取一个对象的实例。为一个对象设置虚引用的唯一目的就是希望这个对象被收集器回收时收到一个系统通知。在JDK1.2之后，提供了PhantomReference类来实现虚引用。

生存还是死亡？

在根搜索算法不可达的对象，也并非是“非死不可”的，它们暂时处于“死缓”状态，要真正宣告对象的死亡，至少要经历两次标记：

如果对象在进行根搜索后发现没有与GC Roots相连接的引用链，那它就会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”。

如果这个对象被判定为有必要执行finalize()方法，那么这个对象就会被放在名为F-Queue的队列中，并在稍后有一条由虚拟机自动建立的、低优先级的Finalizer线程去执行。这里所说的“执行”是指虚拟机会触发这个方法，但是并不承诺会保证等待它运行结束。（这样做的目的是，如果一个对象在finalize()方法中执行缓慢或者是发生了死循环，将可能会导致F-Queue里的其他对象永久处于等待状态，甚至导致整个内存回收系统崩溃）。

finalize()方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模标记，如果对象要在finalize()方法中成功拯救自己，只要重新与引用链上的任何对象建立关联即可，譬如把自己（this关键字）复制给某个类变量或者对象的成员变量。

回收方法区

Java虚拟机规范不要求虚拟机在方法区实现垃圾收集，而且在方法区进行垃圾收集的“性价比”一般都比较低：在堆中，尤其是在新生代中，常规应用进行一次垃圾收集一般可回收70%～95%的空间，而永久代的垃圾收集效率远低于此。

永久代的垃圾收集主要分为两部分内容：废弃常量和无用的类。

回收废弃常量与回收Java堆中的对象非常类似，假如一个字符串“abc”已经进入常量池，但是当前系统没有任何一个String对象是叫做“abc”的，换句话说就是没有任何对象引用常量池的“abc”常量，也没有其他地方引用了这个字面量，如果这时候发生内存回收，而且有必要的话，这个“abc”就会被系统“请”出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。

类需要同时满足以下三个条件，才能算是“无用的”类：

该类所有的实例都被回收，也就是说Java堆中已经不存在该类的所有实例。
加载该类的ClassLoader已经被回收
该类对应的 java.lang.class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法

虚拟机在一个类同时满足以上三个条件时，可以对这个无用类进行回收。（这里说的仅仅是“可以”，而不是和对象一样，不使用了就必然会回收）。HotSpot虚拟机提供了 -Xnoclassgc 参数来进行控制，还可以使用 -verbose:class , -XX:+TraceClassLoading , -XX:+TraceClassUnLoading 查看类的加载和卸载信息。

在大量使用反射、动态代理、CGLib等bytecode框架的场景，以及动态生成JSP和OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。

垃圾收集算法

垃圾收集算法涉及到大量的程序细节，而且各个平台的虚拟机操作内存的方法又各不相同，因此本节着重介绍几种算法的思想和发展过程。

标记-清除算法

标记-清除（Mark-Sweep）算法，分为两个部分标记和清除，首先标记出所有需要回收的对象，在标记完成之后统一回收掉所有被标记的对象。

它是最基础的算法，是因为后续的算法都是基于这种思路并对其缺点进行改进而得到的。

它的主要缺点有两个：
1, 效率问题，标记或清除过程的效率都不高；
2, 空间问题，标记清除之后会产生大量的不连续的空间碎片，在以后需要分配大对象时无法找到足够的连续内存空间而不得不进行一次另一次垃圾清理。

复制算法

复制（Copying）算法的出现是为了解决“标记-清除算法”的效率问题，它将可用内存按照容量划分为大小相等的两块，每次只使用其中一块。当这一块内存使用完了，就将还存活着对象复制到另外一块上面，然后再将已使用过的内存空间一次清理掉。这样就使得每一次都是对其中一块进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只需要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。

现在的商业虚拟机都采用这种收集算法来回收新生代，新生代中的对象绝大部分都是朝生夕死的，所以并不需要按照1:1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor，每次使用Eden和其中一块Survivor，当回收时，将Eden和Survivor中存活的对象一次性地拷贝到另一块Survivor空间，最后清理掉Eden和Survivor空间。

HotSpot虚拟机默认的Eden和Survivor大小比例为8:1，也就是说每次新生代中可用空间为整个新生代空间的90%（80%+10%），只有10%的内存空间是被“浪费”的。当Survivor的空间不够用的时候，需要依赖其他内存（老年代）进行分配担保（Handle Promotion）。

标记-整理算法

标记-整理（Mark-Compact）算法：标记过程与“标记-清除”算法一样，但是后续步骤不是直接对可回收对象进行清理，而是让所有的存活对象都向一端移动，然后直接清理掉端边界以外的内存。

分代收集算法

当前商业虚拟机的垃圾收集都是采用“分代收集（Generational Collection）算法”，根据对象的存活周期的不同将内存划分为几块。

一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特定采用最适当的收集算法。在新生代，每次垃圾收集都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成省收集。而老年代中因为对象存活率高，没有额外的空间进行分配担保，就必须使用“标记-清理”或者“标记-整理”算法来进行回收。

垃圾收集器

垃圾收集器是内存回收的具体实现，Java虚拟机规范对垃圾收集器的实现并没有具体规定，因此不同厂商、不同版本的虚拟机所提供的垃圾收集器可能会有很大的区别。
以下是 HotSpot JVM 1.6 的垃圾收集器：

其中，如果两个收集器之间有连线，说明可以搭配使用。

Serial 收集器

特点：

单线程收集器
在进行垃圾收集时，必需暂停其他所有的工作线程（打扫卫生时，必需要求房间里停止工作产生垃圾）
简单而高效，专心做垃圾收集
虚拟机运行在Client模式下的默认新生代收集器

ParNew 收集器

ParNew收集器其实就是Serial收集器的多线程版本，是运行在Server模式下的虚拟机中首选的新生代收集器。

并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程处于等待状态。

并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替运行），用户程序继续运行，而垃圾收集线程运行在另一个CPU上。

Parallel Scavenge

Parallel Scavenge收集器是一个使用复制算法的并行的多线程收集器，它关注于提高吞吐量（Throughput，CPU用于运行用户代码的时间和CPU消耗时间的比值）。另外，自适应调节策略也是Parallel Scavenge和ParNew收集器的区别

Serial Old 收集器

是Serial收集器的老年版本。

Parallel Old 收集器

是Parallel Scavenge 收集器的老年版本。

CMS 收集器

CMS（Concurrent Mask Sweep）收集器是一个以获取最短回收停顿时间为目标的收集器。因此，此收集器特别适合现代的互联网或 B/S 架构的服务端上。

CMS 收集器是基于“标记-清除”算法实现的，整个过程分为4个步骤：

初始标记
并发标记
重新标记
并发清除

它是一种优秀的收集器。

优点是：并发收集、低停顿
缺点是：对CPU资源非常敏感、无法处理浮动垃圾、收集结束后会产生大量的空间碎片以致于在给大对象分配空间时带来麻烦

G1 收集器

G1（Garbage First）收集器是当前收集器技术发展的最新成果，相对于上文的 CMS 收集器有两个显著改进：

基于“标记-整理”算法，也就是说它不会产生空间碎片
非常精确地控制停顿

G1 收集器可以实现在基本不牺牲吞吐量的情况下完成低停顿的回收，它将整个Java堆划分为多个大小固定的独立区域（Region），并跟踪这些区域里面的垃圾堆积程度，在后台维护一个优先列表，每次根据允许的收集时间，优先回收垃圾最多的区域（这也是Garbage First名称的由来）。总而言之，区域划分和有优先级的区域回收，保证了G1收集器在有限的时间内可以获得最高的收集效率。

垃圾收集器参数总结

-XX:+UseSerialGC：在新生代和老年代使用串行收集器
-XX:SurvivorRatio：设置eden区大小和survivior区大小的比例
-XX:NewRatio:新生代和老年代的比
-XX:+UseParNewGC：在新生代使用并行收集器
-XX:+UseParallelGC ：新生代使用并行回收收集器
-XX:+UseParallelOldGC：老年代使用并行回收收集器
-XX:ParallelGCThreads：设置用于垃圾回收的线程数
-XX:+UseConcMarkSweepGC：新生代使用并行收集器，老年代使用CMS+串行收集器
-XX:ParallelCMSThreads：设定CMS的线程数量
-XX:CMSInitiatingOccupancyFraction：设置CMS收集器在老年代空间被使用多少后触发
-XX:+UseCMSCompactAtFullCollection：设置CMS收集器在完成垃圾收集后是否要进行一次内存碎片的整理
-XX:CMSFullGCsBeforeCompaction：设定进行多少次CMS垃圾回收后，进行一次内存压缩
-XX:+CMSClassUnloadingEnabled：允许对类元数据进行回收
-XX:CMSInitiatingPermOccupancyFraction：当永久区占用率达到这一百分比时，启动CMS回收
-XX:UseCMSInitiatingOccupancyOnly：表示只在到达阀值的时候，才进行CMS回收

内存分配与回收策略

Java 技术体系中的自动内存管理最终可以可以归结为自动化地解决了以下两个问题：给对象分配内存和回收分配给对象的内存。

其中，关于回收内存是上文介绍的虚拟机中垃圾收集体系及其工作原理所阐述的内容。

而，关于分配内存则是本节需要阐述的内容。

对象优先在Eden分配

大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够的空间进行分配时，虚拟机将发起一次Minor GC。

新生代GC（Minor GC）：指发生在新生代的垃圾收集动作，因为Java对象大多数都具有朝生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。
老年代GC（Major GC／Full GC）：指发生在老年代的GC，出现了Major GC，经常会伴随至少发生一次的Minor GC（但是并非绝对，在ParallelScavenge收集器的收集策略里，就有直接进行Major GC的策略选择过程）。Major GC的速度一般会比Minor GC慢10倍以上。

大对象直接进入老年代

大对象，是指需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串及数组。大对象对于虚拟机的内存分配来说，是一个坏消息，因为它的经常出现容易导致内存还有不少空间时就提前触发垃圾收集以获取足够的连续空间来“安置”它们。

虚拟机提供了-XX:PretenureSizeThreshold参数，让大于这个设置值的对象直接在老年代中分配，这样做的目的是避免在Eden区及两个Survivor区之间发生大量的内存拷贝（新生代采用复制算法来收集内存）。

PretenureSizeThreshold参数只对Serial和ParNew两款收集器有效，Parallel Scavenge收集器不认识这个参数，一般也没必要设置。如果遇到必需使用此参数的场合，可以考虑ParNew+CMS的收集器组合

长期存活的对象进入老年代

虚拟机采用了分代收集的思想来管理内存，那么回收时就必须能够识别哪些对象应当放在新生代，哪些对象应该放在老年代。为了达到这个目的，虚拟机给每个对象定义了一个对象年龄（Age）计数器。

如果对象在Eden出现并经过第一次MinorGC后仍然存活，并且能被Survivor容纳，将被移动到Survivor空间，对象年龄加1。对象在Survivor区每熬过一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认值是15）时，就会被晋升到老年代中。

对象晋升老年代的年龄阈值，可以通过参数-XX:MaxTenuringThreshold来设置

动态对象年龄判定

为了能够更好地适应不同程序的内存状况，虚拟机并不是总要求对象的年龄必需达到MaxTenuringThreshold 才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold 中要求的年龄。

空间分配担保

在发生Minor GC时，虚拟机会检测之前每次晋升到老年代的平均大小是否大于老年代的剩余空间大小，如果大于，则改为直接进行一次Full GC。如果小于，则查看HandlePromotionFailure设置是否允许担保失败；如果允许，那只会进行Minor GC；如果不允许，则也要改为进行一次Full GC。

深入理解Java虚拟机 - 第二章

2018-07-17T08:22:49.000Z

第二章 Java内存区域、内存溢出异常

概述

Java与C++之间有一堵由内存分配和垃圾收集技术所围成的高墙，墙外的人想进来，墙里面的人想出来。

Java运行时数据区

程序计数器

程序计数器（Program Counter Register）是一块儿较小的空间，用来指示当前线程所执行字节码的行号。

字节码解释器工作时就是通过改变这个计数器的值来选定下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。

Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的。在任一时刻，一个处理器（对于多核处理器来说，就是一个内核）只会执行一条线程中的指令。因此，为了能够恢复线程切换之前的线程状态到正确位置，每条线程都需要有一个独立的程序计数器，各条线程之间互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。

如果线程正在执行的是一个Java方法，这个计数器记录的是正在执行虚拟机字节码指令的地址；如果正在执行的是一个Native方法，这个计数器则是为空（Undefined）。
此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。

虚拟机栈

Java虚拟机栈（Java Virtual Machine Stack） 也是线程私有的，它的生命周期与线程相同。它描述的是Java方法执行的内存模型：每个方法执行的时候都会同时创建一个栈帧（Stack Frame）用于存储局部变量、操作栈、动态链接、方法出口等信息。
每一个方法被调用直至执行完成的过程，就对应着一个栈帧从虚拟机栈中从入栈到出栈的过程。
有人把Java内存区分为栈（Stack）和堆（Heap），这是比较粗糙的。实际上，这里的“栈”指的就是现在的这个虚拟机栈，或者确切点说，是虚拟机栈中的局部变量表部分。
局部变量表中存放了编译期可知的基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（refrence类型，可能是一个对象起始地址的应用指针、也可能是一个代表对象的句柄或者其它与此对象相关的地址）和returnAddress（指向了一条字节码指令的地址）。
其中，64位长度的long和double类型的数据会占用2个局部变量空间（Slot），其余数据类型会占用一个。局部变量所占用的空间在编译期间完成分配，当进入一个方法时，这个方法在帧中所需要分配的局部变量的空间时完全可以确定的，在运行期间也不会改变这个空间的大小。
如果线程请求的栈的深度大于虚拟机所能允许的深度，会触发StackOverflowError异常；如果虚拟机可以动态地扩展（当前大部分虚拟机都可以扩展，也可以指定固定长度），当扩展无法申请到足够的内存时，会抛出OutOfMemoryError异常。

本地方法栈

本地方法栈（Native Method Stack） 与虚拟机栈的作用非常相似，只不过虚拟机栈是为虚拟机执行字节码（Java方法）服务，而本地方法栈是用来服务于虚拟机使用的Native方法服务。
具体的虚拟机可以自由实现它，甚至可以把它和虚拟机栈合二为一（譬如Sun HotSpot 虚拟机）。
与虚拟机栈一样，本地方法栈也会抛出StackOverflowError和OutOfMemoryErroe异常。

Java堆

Java堆（Java Heap） 是Java虚拟机所管理的内存中最大的一块。是被所有的线程共享的一块内存区域，在虚拟机启动时创建。

此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在此分配内存。由于JIT编译器的发展与逃逸分析技术的发展，栈上分配、标量替换优化技术的进步，所有的对象实例都分配在堆上也不是那么绝对了。

Java堆是垃圾收集器管理的主要区域 ，因此也被称为“GC堆”（Garbage Collection Heap）。现在的收集器都是采用分代收集算法，所以Java堆中可以细分为：新生代和老生代。

根据Java虚拟机规范，Java堆可以是处于物理上不连续的内存空间中，只要逻辑上连续即可。在实现上可以是固定大小，也可以是可扩展的，主流的是可扩展方式。

方法区

方法区（Method Area） 与Java堆一样，都是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态常量、即时编译器编译后的代码等数据。

Java虚拟机规范对这个区域的限制非常松，除了和Java堆一样不需要连续的内存空间和可以选择固定大小或者可扩展外，还可以选择不实现垃圾收集。

当方法区的内存大小无法满足内存分配需要的时候，将抛出OutOfMemory异常。

运行时常量池

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

运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性，Java语言并不要求常量一定只能在编译期产生，也就是并非预置入Class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将将新的常量放入池中，这种特性被开发人员利用的比较多的便是String类的intern()方法。

既然运行时常量池是方法区的一部分，自然会受到方法区内存的限制，当常量池无法再申请到内存时将会抛出OutOfMemoryError异常。

直接内存

直接内存（Direct Memory） 并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域，但是这部分内存也被频繁地使用，而且有可能导致OutOfMemoryError异常。

在JDK1.4种新加入了NIO（New Iuput/Output）类，引入了一种基于通道（Channel）与缓冲区（Buffer）的I/O方式，它可以使用Native函数直接分配堆外内存，然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这快内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。

显然，本机直接内存非分配不会受到Java堆大小的限制，但是既然是内存，肯定会受到本机总内存的大小和处理器寻址空间的限制。所以也可能会抛出OutOfMemoryError异常。

对象访问

对象访问在Java语言中无处不在，是最普通的程序行为，即使是最简单的访问，也涉及到Java栈、Java堆、方法区这三个重要的内存区域之间的关联关系，如下一句代码：

```Object obj = new Object();```

假设这句代码出现在方法体中，那”Object obj”这部分的语义将会反映到Java栈的本地变量中，作为一个Reference类型数据出现。

而”new Object()”这部分的语义将会反映到Java堆中，形成一块儿存储了Object类型所有实例数据值（Instance Data，对象中各个实例字段的数据）的结构化内存，根据具体类型以及虚拟机实现的对象内存布局（Object Memory Layout）的不同，这块儿内存的大小是不固定的。

另外，在Java堆中，还必须包含能包括能查到此对象类型数据（如，对象类型、父类、实现的接口、方法等）的地址信息，这些数据存储在方法区中。

由于reference类型在Java虚拟机规范里只规定了一个指向对象的引用，并没有定义这个引用应该通过哪种方式去定位，以及访问到Java堆中的对象的具体位置，因此不同的虚拟机实现的对象访问方式会有所不同。

主流的访问方式有两种：使用句柄和直接指针。

句柄方式，Java堆中将会划分出一块内存作为句柄池，reference中存储的就是对象的句柄地址，而句柄中包含了对象实例数据和类型数据各自的具体地址信息，如下图：

指针方式，reference变量中直接存储的就是对象的地址，而Java堆对象的布局中就必须考虑如何防止访问类型数据的相关信息，如下图：

这两种对象的访问方式各有优势：

使用句柄访问方式的最大好处是reference中存贮的是稳定的句柄地址，在对象被移动（比如垃圾收集时，对象移动是非常普遍的行为）时只会改变句柄中的实例数据指针，而reference本身不需要被修改。
使用直接指针访问方式的最大好处就是速度更快，它节省了一次指针定位的时间开销，由于对象的访问在Java中非常频繁，因此这类开销积少成多也是一项非常可观的执行成本。
本书讨论的主要虚拟机Sun HotSpot，它是使用第二种方式进行对象访问的，但是从整个软件开发的范围来看，各种语言和框架使用句柄来访问的情况也十分常见。

实战：OutOfMemoryError异常

Java堆溢出

可以通过限制Java堆的大小，设置为不可扩展（将堆的最小值参数-Xms和最大值参数-Xmx设置成一样即可避免堆自动扩展），通过参数-XX:+HeapDumpOnOutOfMemoryError可以让虚拟机在出现内存溢出异常时Dump出当前的内存堆转储快照以便以后进行分析。
Java堆内存的OOM异常是实际应用中最常见的内存溢出异常情况。出现Java堆内存溢出时，异常堆栈信息“java.lang.OutOfMemoryError”会跟着进一步提示“Java heap space”。
要解决这个区域的异常，一般的手段是首先通过内存映像分析工具（如Eclipse Memory Analyzer）对dump出的堆转储快照进行分析，重点是确认内存中的对象是否是必要的，也就是要先分清楚到底是出现了内存泄漏（Memory Leak）还是内存溢出（Memory Overflow）。
如果是内存泄漏，可进一步通过工具查看泄漏对象到GC Roots的引用链。于是就能找到泄漏对象是通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收它们的。掌握了泄漏对象的类型信息，以及GC Roots引用链的信息，就可以比较准确地定位出泄漏代码的位置。
如果不存在泄漏，换句话说就是内存中的对象确实都还必须存活着，那就应当检查虚拟机的堆参数（Xmx和Xms），与机器物理内存对比看是否还可以调大，从代码上检查是否存在某些对象生命周期过长、持有状态时间过长的情况，尝试减少程序运行期间的内存消耗。

虚拟机栈和本地方法栈溢出

由于在HotSpot虚拟机中并不区分虚拟机栈和本地方法栈，因此对于HotSpot来说，-Xoss参数（设置本地方法栈大小）虽然存在，但实际上是无效的，栈容量只由-Xss参数设定。
关于虚拟机栈和本地方法栈，在Java虚拟机规范中描述了两种异常：

如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常。
如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常。

这里把异常分为两种情况，实际上却存在着一些互相重叠的地方：当栈空间无法分配时，到底是内存太小，还是已使用的栈空间太大，其本质只是对同一事件的两种表述而已。

运行时常量池溢出

如果要向运行时常量池中添加内容，最简单的方法是使用String.intern()这个Native方法。该方法的作用时：如果池中包含了一个等于此String对象的字符串，则返回代表池中这个字符串的String对象；否则，将此String对象包含的字符串添加到常量池中，并且返回此String对象的引用。由于常量池分配在方法区内，我们可以通过-XX:PermSize和-XX:MaxPermSize限制方法区的大小，从而间接限制其中常量池的容量。

方法区溢出

方法区用于存放Class相关的信息，如类名、访问修饰符、常量池、字段描述、方法描述等。生成大量的动态类区填充方法区，可以触发此区域的溢出异常。
方法区溢出是一种常见的内存溢出异常，一个类如果要被垃圾收集器回收，判定的条件比较苛刻。在经常动态生成大量Class的应用中，需要特别注意类的回收状况。这类场景出了CGLib字节码增强外，还有大量JSP或者基于OSGi的应用等。

本机直接内存溢出

DirectMemory可以通过-XX:MaxDirectMemorySize指定，如果不指定，则默认与Java堆的最大值（-Xmx指定）一样。

Docker基础环境搭建

2018-05-17T08:14:42.000Z

开始安装

由于apt官方库里的docker版本可能比较旧，所以先卸载可能存在的旧版本

1	sudo apt-get remove docker docker-engine docker-ce docker.io

添加backports源

# 编辑/etc/apt/sources.list文件,加入这句话
deb http://http.debian.net/debian jessie-backports main
# 或者
sudo add-apt-repository "deb http://http.debian.net/debian jessie-backports main"

更新apt-get索引

1	sudo apt-get update

安装Docker

1	sudo apt-get install docker.io

测试Docker安装结果

查看镜像列表

1	sudo docker images ls

使用非root用户运行Docker

将当前用户加入docker用户组

指定其他用户时只需要将${USER}改为对应用户名即可

1	sudo gpasswd -a ${USER} docker

重启Docker(命令在基于Debian的发布版上大都可用)

1	sudo systemctl restart docker

当前用户注销后再重新登录

1 2	# 注销 logout

Vue简单入门

2018-03-26T02:30:48.000Z

基本结构

template

基本HTML语法

script

实例化的Vue对象

1	var sth = new Vue({});

样式

Vue对象基本结构

data

数据域

methods

用来定义功能函数

watch

用来定义数据监视函数
Demo如下:

new Vue({
    data:{
        a:1,
        b:[]
    },
    props: [ '注册组件名称' ]，
    methods:{
        doSomething:function() {
            /* 调用此函数时候打印**a**的值 */
            console.log(this.a)
        }
    },
    watch:{
        'a' : function(val,oldVal) {
            /* 当**a**的值发生改变时，调用该方法，打印**a**的旧值与新值 */
            console.log(val,oldVal)
        }
    }
})

模版指令

数据渲染

v-text && v-html &&

1
2
3

<p>{{ a }}p>
<p v-text="a">p>
<p v-html="a">p>

脚本部分

new Vue({
    data : {
        a: 1
    }
})

模块显隐性

v-if && v-show
区别
v-if：为假时直接不渲染该块；
v-show：类似于CSS中display:none;

1 2	<p v-if="isShow">p> <p v-show="isShow">p>

脚本部分

new Vue({
data : {
   isShow: true
}
})

渲染循环列表

v-for

<ul>
    <li v-for="item in items">
        <p v-text="item.label">p>
    li>
ul>

脚本部分

new Vue({
data : {
    items : {
        {
            label: 'apple'
        },
        {
            label: 'banana'
        }
    }
}
})

事件绑定

v-on <==> @

1 2	<button v-on:click="doThis">button> <button @click="doThis">button>

methods: {
    doThis: function(sth) {
    }
}

属性绑定

v-bind <==> :


<img v-bind:src="imgSrc">


<div :class"{ red : isRed }">div>

<div :class"[classA, classB]">div>

<div :class"[classA, {classB: isB, classC: isC}]">div>

组件化

组件的引入与注册

引入组件后使用前需要注册，使用components

注册组件后使用时候将驼峰转为中线形式原因：
ComponentA之所以要转换成component-a
因为在HTML中，标签的标签名是大小写不敏感的，而在javascript中变量名是大小写敏感的
换句话说，在HTML中，ComponentA和componenta算是同一个标签
而在javascript中，ComponentA和componenta却不是同一个变量
要解决这种差异问题，就必须得在两种标准之间做一个转换，所以vuejs就使用了将驼峰法(camelCase)转换到短横线法(kebab-case)

父向子组件传值props传值(props与data，methods等同级)
子向父组件传值自定义事件 || $children || $refs

$on() 监听事件
$emit() 在他上面触发时间

考虑到树结构的层次复杂性

~~$dispatch() 派发事件，事件沿着父链冒泡~~（VUE2.0已弃用）
~~$broadcast() 广播事件，事件向下传到给所有后代~~（VUE2.0已弃用）

Vue环境配置

2018-03-26T02:25:48.000Z

环境安装配置

安装NodeJs

1 2	sudo apt install nodejs-legacy sudo apt install npm

升级npm为最新版本

1	sudo npm install npm@latest -g

此时通过npm -v可以发现npm版本号为最新版本xxx

安装用于安装nodejs的模块n

1	sudo npm install -g n

安装版本

#安装官方最新版本
sudo n latest
#安装官方稳定版本
sudo n stable
#安装官方最新LTS版本
sudo n lts

更换国内npm镜像

更换后npm将变成cnpm

安装webpack

1	sudo npm install webpack -g

安装vue脚手架

1	cnpm/npm install vue-cli -g

初始化项目

1	vue init webpack [项目名称]

运行项目

#安装项目依赖 （添加依赖或者删除时，须重新安装）
npm install
#运行开发环境
npm run dev
#运行运营环境
npm run build

运行成功可能调用浏览器或者在浏览器中输入http://localhost:8080访问项目。

效果图如下

Python集成环境Anaconda使用

2018-03-24T08:00:28.000Z

1. 安装

下载地址
Anaconda镜像链接-清华大学开源镜像站

2.windows下环境变量配置

默认添加到系统环境变量里面的路径是D:\Python\anaconda3（此处为我安装的根目录），建议更改为如下形式，方便目录转移。

#设置CONDA_HOME
%CONDA_HOME%
D:\Python\anaconda3
#环境中添加如下路径
%CONDA_HOME%;
%CONDA_HOME%\Scripts;

3. 多环境并存

3.1. 查看当前存在版本

1
2
3

conda info --envs
#或者
conda info -e

显示如下图

显示当前存在的python环境，带有星号的表示是当前活动的环境。可以发现环境的名称是以envs目录下文件夹名字命名的

3.2. 创建环境

通过anaconda-navigator或者命令新建环境。

1	conda create --name 环境别名 python=环境版本

3.3. 删除环境命令

1	conda remove --name 环境别名 --all

3.4. 切换版本

#Linux、Max OS下需要在前面加source
#激活版本
activate 版本别名
#取消激活，退回默认版本
deactivate 版本别名

4. 修改编码

python的默认编码是”ASCII“，修改为utf-8的方法：在Anaconda\Lib\site-packages目录下添加一个名字为sitecustomize.py文件，文件内容

1 2	import sys sys.setdefaultencoding('utf-8')

5. 设置国内源

1 2	conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/free/ conda config --set show_channel_urls yes

6. 安装其他组件

6.1. 安装spyder

先切换python版本然后在相应版本下操作。

1	conda install spyder

6.2. 安装spyder

先切换python版本然后在相应版本下操作。

1	conda install jupyter

7. 其他常用命令

7.1. 包管理

# 安装 matplotlib 
conda install matplotlib
# 查看已安装的包
conda list 
# 包更新
conda update matplotlib
# 删除包
conda remove matplotlib

设计模式-工厂模式

2018-03-24T04:46:04.000Z

简单工厂模式

使用简单工厂模式的优势

让对象的调用者和对象创建过程分离，当对象调用者需要对象时，直接向工厂请求即可。从而避免了对象的调用者与对象的实现类以硬编码方式耦合，以提高系统的可维护性，可扩展性。工厂模式也有一点缺陷：当产品修改时，工厂类也要做相应的修改。

下面实例

小张开车去东北

这里涉及到小张是乘坐什么交通工具去东北？汽车，飞机，火车…..都可以

Car类

public class Car implements Moveable{
    
    public void run() {
        System.out.println("冒着烟奔跑中car.......");
    }
}

Plane类

public class Plane implements Moveable {

    @Override
    public void run() {
        System.out.println("扇着翅膀前进中plane....");
    }

}

接口类Moveable

1
2
3

public interface Moveable {
    void run();
}

抽象类VehicleFactory

1
2
3

public abstract class VehicleFactory {
    abstract Moveable create();
}

CarFactory类

public class CarFactory extends VehicleFactory{
    public Moveable create() {
        return new Car();
    }
}

PlaneFactory类

public class PlaneFactory extends VehicleFactory{
    public Moveable create() {
        return new Plane();
    }
}

测试类

public class Test {
    public static void main(String[] args) {

        VehicleFactory factory = new CarFactory();
        Moveable m = factory.create();

        m.run();
    }
}

下图是类图之间的关系

此时如要换一种方式去东北，只需要按照上图给2个接口都添加实现即可。
由此我们可以想象，如果工厂中要产生大量的产品系列，那样的话，就需要各种添加大量的实现，容易造成工厂泛滥。

抽象工厂模式

定义及原因

因为使用简单工厂模式，使得客户端代码成功地与被调用对象的实现类分离，但却带来了另外一种耦合：客户端代码与不同的工厂类耦合，这依然是一个问题。
我们考虑在增加一个工厂类，该类不生产具体的Vehicle类，而是生产VehicleFactory实例——简而言之,该类不制造具体的被调用对象，而是制造不同的工厂对象。这就是抽象工厂模式。

如下实例

抽象工厂类：制造不同的工厂对象

public abstract class AbstractFactory {
    public abstract Vehicle createVehicle();
    public abstract Weapon createWeapon();
    public abstract Food createFood();
    
}

MagicFactory类：创建系列与魔法有关的食物，交通工具，武器对象

public class MagicFactory extends AbstractFactory {

    @Override
    public Food createFood() {
        return new MushRoom();
    }

    @Override
    public Vehicle createVehicle() {
        return new Broom();
    }

    @Override
    public Weapon createWeapon() {
        return new MagicStick();
    }
    
}

DefaultFactory类：创建默认类型的食物，交通工具，武器对象

public class DefaultFactory extends AbstractFactory{

    @Override
    public Food createFood() {
        return new Apple();
    }

    @Override
    public Vehicle createVehicle() {
        return new Car();
    }

    @Override
    public Weapon createWeapon() {
        return new AK47();
    }
    
}

Food类：生产Food

1
2
3

public abstract class Food {
    public abstract void printName();
}

继承Food的两个类

Apple类

public class Apple extends Food {
    public void printName() {
        System.out.println("apple");
    }
}

MushRoom类

public class MushRoom extends Food {

    @Override
    public void printName() {
        System.out.println("mushroom");
    }

}

Vehicle类

1
2
3

public abstract class Vehicle {
    public abstract void run();
}

继承Vehicle类的两个类

Car类

public class Car extends Vehicle {
        
    public void run() {
        System.out.println("冒着烟奔跑中car.......");
    }
}

Broom类

public class Broom  extends Vehicle{

    public void run() {
        System.out.println("一路沙尘暴飞奔而来broom.....");
    }

}

Weapon类

1
2
3

public abstract class Weapon {
    public abstract void shoot();
}

继承Weapon类的两个类

AK47类

public class AK47 extends Weapon{
    public void shoot() {
        System.out.println("哒哒哒...");
    }
}

MagicStick类

public class MagicStick extends Weapon {

    @Override
    public void shoot() {
        System.out.println("fire hu hu hu ...");
    }

}

下面是类图关系

可以用配置文件配置，具体用法原来已经讲过；
冒着烟奔跑中car…….
哒哒哒…
apple
在抽象工厂模式中，如要产生大量产品品种对象，容易泛滥。

设计模式-观察者模式

2018-03-24T03:51:44.000Z

前言

观察者模式定义了对象间的一对多依赖关系，让一个或者多个观察者对象观察一个主题对象。当主题对象的状态发生变化时，系统能通知所有的依赖于此对象的观察者对象，从而使得观察者对象能自动更新。
在观察者模式中，被观察的对象通常被称为主题(Subject),依赖的对象被称为观察者(Observer)。在java中其实就有经典的AWT，比如按钮单击监听等等。
请模拟下面的情形：
小孩在睡觉
醒来后要吃东西

版本1

主要思想：设计两个类Child和Dad，都是线程类，其中Dad类主动监测小孩是否还在睡觉，如果小孩一旦醒来，就喂它吃东西。

Child类:设置小孩的状态为睡着的，过了5秒，就醒来

public class Child implements Runnable {
    
    private boolean wakenUp = false;
        
    void wakeUp(){
        wakenUp = true;
    }

    @Override
    public void run() {
            try {
                Thread.sleep(5000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            
            wakeUp();
    }

    public boolean isWakenUp() {
        return wakenUp;
    }

    public void setWakenUp(boolean wakenUp) {
        this.wakenUp = wakenUp;
    }

}

Dad类：将Child的引用传给Dad，监听小孩一旦醒来，就喂他吃的

public class Dad implements Runnable{

    Child c;
    
    public Dad(Child c) {
        this.c = c;
    }

    void feed(Child c) {
       System.out.println("Child is feeded!");    
    }
    
    @Override
    public void run() {
        while(!c.isWakenUp()){
            try {
                Thread.sleep(5000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
            c.wakeUp();
            feed(c);
    }
}

监听测试

public class DadOberverChild {

    public static void main(String[] args) {
        Child c = new Child();
        new Thread(c).start();
        new Thread(new Dad(c)).start();

    }

}

该设计有些不合理，主动地监测，爸爸要不停地看着小孩，内存消耗严重，浪费时间。

版本2

修正版本1中cpu浪费的情形，现在不拿Dad来监控Child，反过来被动监测，让Child来监控Dad，比如你可以一边看欧洲杯，当儿子一醒来后，他就会用绳子拉着你去喂他。

Child类

public class Child implements Runnable {
    
    private boolean wakenUp = false;
    
    private Dad d;
    
    public Child(Dad d){
        this.d = d;
    }
    
    void wakeUp(){
        wakenUp = true;
    }

    @Override
    public void run() {
            try {
                Thread.sleep(5000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            
            wakeUp();
            d.feed(this);
    }

    public boolean isWakenUp() {
        return wakenUp;
    }

    public void setWakenUp(boolean wakenUp) {
        this.wakenUp = wakenUp;
    }

}

Dad类

public class Dad{

    void feed(Child c) {
       System.out.println("Child is feeded!");    
    }
}

监听测试类

public class DadOberverChild {

    public static void main(String[] args) {
        Dad d = new Dad();
        new Thread(new Child(d)).start();
    }

}

版本3

小孩一醒过来，触发一件事，就让爸爸对这件事做出反应，不管是喂他吃东西，还是抱他出去玩，都会使程序更灵活。

Child类

public class Child implements Runnable {
    
    private Dad d;
    
    public Child(Dad d){
        this.d = d;
    }
    
    void wakeUp(){
        //处理小孩从床上醒来的情况
        d.ActionToWakenUp(new WakenUpEvent(System.currentTimeMillis(),"bed",this));
    }
    
    public void run() {
            try {
                Thread.sleep(5000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            
        this.wakeUp();
    }

}

Dad类

public class Dad{

    void feed(Child c) {
       System.out.println("Child is feeded!");    
    }

    //处理可能发生的事件
    public void ActionToWakenUp(WakenUpEvent wakenUpEvent) {
        System.out.println("OK!");
    }
}

事件类：封装发生的事件对象

public class WakenUpEvent {
   private long wakenTime;    //醒来时间
   private String location;   //醒来地点
   private Child source;   //事件源对象
   
   public WakenUpEvent(long wakenTime, String location, Child source) 
   ......
   public Setter()/Getter()
   ......
}

版本4

对于小孩来说，一旦某件事发生，监听着这件事的人可能不只有一个，比如爸爸喂他吃东西，爷爷带他出去玩，奶奶给他开电视机.

Child类

public class Child implements Runnable {
    
    //存放监听者对象
    private List wakenUpListeners = new ArrayList();
    
    //为监听者对象添加监听器
    public void addWakenUpListener(WakenUpListener l){
        wakenUpListeners.add(l);
    }
    
    void wakeUp(){
        for(int i=0;i
            WakenUpListener l = wakenUpListeners.get(i);
            l.ActionToWakenUp(new WakenUpEvent(System.currentTimeMillis(),"bed",this));
        }
    }
    
    public void run() {
    //....
    }
}

Dad类

public class Dad implements WakenUpListener{

    public void ActionToWakenUp(WakenUpEvent wakenUpEvent) {
        System.out.println("Feed Child!");
        
    }
}

GrendFather类

public class GrendFather implements WakenUpListener {
    public void ActionToWakenUp(WakenUpEvent wakenUpEvent) {
        System.out.println("Hug Child!");
        
    }

}

监听者接口

1
2
3

public interface WakenUpListener {
    public void ActionToWakenUp(WakenUpEvent wakenUpEvent);
}

事件类之前就已经封转好了，不用改变。

监听测试类

public class DadOberverChild {

    public static void main(String[] args) {
        Child c = new Child();
        Dad d = new Dad();
        GrendFather gf = new GrendFather();
        c.addWakenUpListener(d);
        c.addWakenUpListener(gf);
        new Thread(c).start();
    }

}

测试结果

1 2	Feed Child! Hug Child!

程序改装到现在，灵活性非常高了，此时如果还有什么人要对小孩做什么事的话，只要再创建一个类就好，而且我们可以将要调用的类的信息放到配置文件中，在测试时，只需要读取配置文件中的信息就好，程序的可维护性变高了。

如：在程序中建立Observer.properties文件，随意添加对象名称。如：
1
observers = Dad,GrendFather

监听测试类：解析资源文件Observer.properties

public class DadOberverChild {
    
    //只加载一次
    static Properties  props = new Properties();
    static{
        try {
            //加载资源文件
            props.load(DadOberverChild.class.getClassLoader().getResourceAsStream("Observer.properties"));
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
    
    private DadOberverChild(){}

    public static void main(String[] args) {
         Child c = new Child();
        //取得文件中的内容并分解
        String[] observers = props.getProperty("observers").split(",");
        for(String s : observers){
            try {
                //创建对象，并添加监听者
                c.addWakenUpListener((WakenUpListener)(Class.forName(s).newInstance()));
            } catch (InstantiationException e) {
                e.printStackTrace();
            } catch (IllegalAccessException e) {
                e.printStackTrace();
            } catch (ClassNotFoundException e) {
                e.printStackTrace();
            }
        }
        new Thread(c).start();
    }
}

设计模式-单例模式

2018-03-24T03:40:57.000Z

意图

保证一个类仅有一个实例，并提供一个访问它的全局访问点。
我们怎么样才能保证一个类只有一个实例并且这个实例易于被访问呢？
如果将对象赋值给一个java静态变量，那么你必须在程序一开始就创建好对象。万一这个对象非常耗费资源，>而程序在这次的执行过程中又一直没有使用到它，不就形成浪费吗？
一个更好的办法是，让类自身负责保存它的唯一实例。这个类可以保证没有其他实例可以被创建（通过截取创建新对象的请求），并且它可以提供一个访问该实例的方法。这就是S i n g l e t o n模式，我们可以在需要时才创建对象。
在计算机系统中，线程池、缓存、日志对象、对话框、打印机、显卡的驱动程序对象常被设计成单例。

单例模式的实现

第一种：懒汉，线程不安全##

public class LazyNotSecurtySingleton {
    //使用静态变量来记录Singleton类的唯一实例
    private static LazyNotSecurtySingleton instance;
    // 私有构造，确保只有自类内部才能访问
    private LazyNotSecurtySingleton() {
    }
    //返回该类的实例， 有线程同步问题    
    public static  LazyNotSecurtySingleton getInstance() {
        if (instance == null) {
            instance = new LazyNotSecurtySingleton();
        }
        return instance;
    }
}

Singleton通过将构造方法限定为private避免了类在外部被实例化，在同一个虚拟机范围内，Singleton的唯一实例只能通过getInstance()方法访问。（事实上，通过Java反射机制是能够实例化构造方法为private的类的，那基本上会使所有的Java单例实现失效。此问题在此处不做讨论，姑且掩耳盗铃地认为反射机制不存在。）
但是以上实现没有考虑线程安全问题。所谓线程安全是指：如果你的代码所在的进程中有多个线程在同时运行，而这些线程可能会同时运行这段代码。如果每次运行结果和单线程运行的结果是一样的，而且其他的变量的值也和预期的是一样的，就是线程安全的。或者说：一个类或者程序所提供的接口对于线程来说是原子操作或者多个线程之间的切换不会导致该接口的执行结果存在二义性,也就是说我们不用考虑同步的问题。显然以上实现并不满足线程安全的要求，在并发环境下很可能出现多个Singleton实例。

第二种：懒汉线程安全

public class LazySecurtySingleton {
    
    private static LazySecurtySingleton instance;
    /**
     * 私有构造子，确保无法在类外实例化该类
     */
    private LazySecurtySingleton() {
    }
    /**
     * synchronized关键字解决多个线程的同步问题
     */
    public static synchronized LazySecurtySingleton getInstance() {
        if (instance == null) {
            instance = new LazySecurtySingleton();
        }
        return instance;
    }
}

静态工厂方法中synchronized关键字提供的同步是必须的，否则当多个线程同时访问该方法时，无法确保获得的总是同一个实例。然而我们也看到，在所有的代码路径中，虽然只有第一次引用的时候需要对instance变量进行实例化，但是synchronized同步机制要求所有的代码执行路径都必须先获取类锁。在并发访问比较低时，效果并不显著，但是当并发访问量上升时，这里有可能会成为并发访问的瓶颈。

第三种：饿汉式

public class EagerSingleton {  
    //私有的类成员常量  
    private static final EagerSingleton SINGLETON = new EagerSingleton();  
    //私有的默认构造方法，此类不能被继承  
    private EagerSingleton(){}  
    //静态工厂方法  
    public static EagerSingleton getInstance(){  
        return SINGLETON;  
    }  
  
}

这种方式，我们依赖JVM在加载这个类时马上创建该类的唯一实例，避免了线程安全问题。不过，instance在类装载时就实例化，没有达到lazy loading的效果.

第四种：双重校验锁

可以使用“双重检查加锁”的方式来实现，就可以既实现线程安全，又能够使性能不受很大的影响。那么什么是“双重检查加锁”机制呢？
所谓“双重检查加锁”机制，指的是：并不是每次进入getInstance方法都需要同步，而是先不同步，进入方法后，先检查实例是否存在，如果不存在才进行下面的同步块，这是第一重检查，
进入同步块过后，再次检查实例是否存在，如果不存在，就在同步的情况下创建一个实例，这是第二重检查。这样一来，就只需要同步一次了，从而减少了多次在同步情况下进行判断所浪费的时间。
“双重检查加锁”机制的实现会使用关键字volatile，它的意思是：被volatile修饰的变量的值，将不会被本地线程缓存，所有对该变量的读写都是直接操作共享内存，从而确保多个线程能正确的处理该变量。
注意：在java1.4及以前版本中，很多JVM对于volatile关键字的实现的问题，会导致“双重检查加锁”的失败，因此“双重检查加锁”机制只能用在java5及以上的版本。

public class TwoLockSingleton {
    private volatile static TwoLockSingleton singleton;
    private TwoLockSingleton() {
    }
    public static TwoLockSingleton getInstance() {
        //先检查实例是否存在，如果不存在才进入下面的同步块
        if (singleton == null) {
            //同步块，线程安全的创建实例
            synchronized (TwoLockSingleton.class) {
                //再次检查实例是否存在，如果不存在才真正的创建实例
                if (singleton == null) {
                    singleton = new TwoLockSingleton();
                }
            }
        }
        return singleton;
    }
}

这种实现方式既可以实现线程安全地创建实例，而又不会对性能造成太大的影响。它只是第一次创建实例的时候同步，以后就不需要同步了，从而加快了运行速度。
提示：由于volatile关键字可能会屏蔽掉虚拟机中一些必要的代码优化，所以运行效率并不是很高。
因此一般建议，没有特别的需要，不要使用。也就是说，虽然可以使用“双重检查加锁”机制来实现线程安全的单例，但并不建议大量采用，可以根据情况来选用。
根据上面的分析，常见的两种单例实现方式都存在小小的缺陷，那么有没有一种方案，既能实现延迟加载，又能实现线程安全呢？

第五种：静态内部类

这个模式综合使用了Java的类级内部类和多线程缺省同步锁的知识，很巧妙地同时实现了延迟加载和线程安全。

1. 相应的基础知识

什么是类级内部类
简单点说，类级内部类指的是，有static修饰的成员式内部类。如果没有static修饰的成员式内部类被称为对象级内部类。
类级内部类相当于其外部类的static成分，它的对象与外部类对象间不存在依赖关系，因此可直接创建。而对象级内部类的实例，是绑定在外部对象实例中的。
类级内部类中，可以定义静态的方法。在静态方法中只能够引用外部类中的静态成员方法或者成员变量。
类级内部类相当于其外部类的成员，只有在第一次被使用的时候才被会装载。
多线程缺省同步锁的知识
大家都知道，在多线程开发中，为了解决并发问题，主要是通过使用synchronized来加互斥锁进行同步控制。但是在某些情况中，JVM已经隐含地为您执行了同步，这些情况下就不用自己再来进行同步控制了。
这些情况包括：
由静态初始化器（在静态字段上或static{}块中的初始化器）初始化数据时
访问final字段时
在创建线程之前创建对象时
线程可以看见它将要处理的对象时

2. 解决方案的思路

要想很简单地实现线程安全，可以采用静态初始化器的方式，它可以由JVM来保证线程的安全性。比如前面的饿汉式实现方式。但是这样一来，不是会浪费一定的空间吗？因为这种实现方式，会在类装载的时候就初始化对象，不管你需不需要。
如果现在有一种方法能够让类装载的时候不去初始化对象，那不就解决问题了？一种可行的方式就是采用类级内部类，在这个类级内部类里面去创建对象实例。这样一来，只要不使用到这个类级内部类，那就不会创建对象实例，从而同时实现延迟加载和线程安全。

/**
 * Singleton类被装载了，instance不一定被初始化。因为SingletonHolder类没有被主动使用，
 * 只有显示通过调用getInstance方法时，才会显示装载SingletonHolder类，从而实例化instance。
 */
public class StaticInternalSingleton {
    /** 
     * 类级的内部类，也就是静态的成员式内部类，该内部类的实例与外部类的实例没有绑定关系
     * 而且只有被调用到时才会装载，从而实现了延迟加载。
     */
    private static class SingletonHolder {
        /**
         * 静态初始化器，由JVM来保证线程安全
         */
        private final static StaticInternalSingleton INSTANCE = new StaticInternalSingleton();
    }
    private StaticInternalSingleton() {
    }
    public static StaticInternalSingleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
}

JVM将推迟SingletonHolder 类的初始化,直到当getInstance方法第一次被调用的时候，它第一次读取SingletonHolder.instance，导致SingletonHolder类得到初始化；而这个类在装载并被初始化的时候，会初始化它的静态域，从而创建Singleton的实例，由于是静态的域，因此只会在虚拟机装载类的时候初始化一次，并由虚拟机来保证它的线程安全性。
这个模式的优势在于，getInstance方法并没有被同步，并且只是执行一个域的访问，因此延迟初始化并没有增加任何访问成本

第六种：枚举

/**
 * 避免多线程同步问题，而且还能防止反序列化重新创建新的对象
 */
public enum EnumSingleton {
    INSTANCE;
    public void whateverMethod() {
    }
}

这种方式是Effective Java作者Josh Bloch 提倡的方式，它不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象，使用枚举来实现单实例控制会更加简洁，而且无偿地提供了序列化机制，并由JVM从根本上提供保障，绝对防止多次实例化，是更简洁、高效、安全的实现单例的方式可以被继承的单例类，登记式单例类是为了克服饿汉式单例类和懒汉式单例类不可继承的缺点而设计的。

import java.util.HashMap;  
  
public class RegSingleton {  
    private static HashMap registry=new HashMap();  
    /**
     * 静态代码块 
     * 静态代码块优先于主方法执行，而在类中定义的静态代码会优先于构造块执行，而且不管产生多少对象，静态代码块只执行一次。 
     */  
    static{  
        RegSingleton singleton=new RegSingleton();  
        registry.put(singleton.getClass().getName(), singleton);  
    }  
      
    protected RegSingleton(){}  
      
    public static RegSingleton getInstance(String name){  
        if(name==null){  
            name="com.zzs.singleton.RegSingleton";  
        }  
        if(registry.get(name)==null){  
            try {  
                registry.put(name, Class.forName(name).newInstance());  
            } catch (Exception e) {  
                e.printStackTrace();  
            }  
        }  
        return (RegSingleton) registry.get(name);  
    }  
  
}

java代码

public class RegSingletonChild extends RegSingleton {  
    //由于子类必须允许父类以构造方法调用产生实例，所以它的构造方法必须是公开的，protected或public  
    protected RegSingletonChild() {  
    }  
    //静态方法工厂  
    public static RegSingletonChild getInstance() {  
        return (RegSingletonChild) RegSingleton  
                .getInstance("com.zzs.singleton.RegSingletonChild");  
    }  
}

Spring singleton

Spring容器最初提供了两种bean的scope类型：singleton和prototype，但发布2.0之后，又引入了另外三种scope类型，即request，session和global session类型。不过这三种类型有所限制，只能在web应用中使用，也就是说，只有在支持web应用的ApplicationContext中使用这三个scope才是合理的

1
2

beans---org.springframework.beans.factory.support.AbstractBeanFactory/doGetBean ---singleton---prototype
web---org.springframework.web.context.request.ServletRequestAttributes---request---session---global session

Centos上整合Apache + PHP + Tomcat7 + MySQL

2018-03-23T03:40:59.000Z

安装Apahce, PHP, MySQL以及php连接mysql库的组件

1
2
3

yum install httpd php mysql mysql-server php-mysql
#按照需要安装，我的服务器上已经有了tomcat 和 mysql ，所有就执行如下语句
yum install httpd php php-mysql

安装apache扩展

1	yum install httpd-manual mod_ssl mod_perl mod_auth_mysql

安装php的常用扩展

1	yum install php-gd php-xml php-mbstring php-ldap php-pear php-xmlrpc

安装MySQL的扩展

1	yum install mysql-connector-odbc mysql-devel libdbi-dbd-mysql

配置开机启动服务

1 2	/sbin/chkconfig httpd on [设置apache httpd服务开机启动] #按需要，我一般自己设置脚本，开机运行脚本去启动程序

安装Tomcat7

yum install java-1.6.0-openjdk java-1.6.0-openjdk-devel
wget http://mirrors.hust.edu.cn/apache/tomcat/tomcat-7/v7.0.42/bin/apache-tomcat-7.0.42.tar.gz
tar -zxvf apache-tomcat-7.0.42.tar.gz
mv apache-tomcat-7.0.42 /usr/local/tomcat7

启动Tomcat7

1	./usr/local/tomcat7/bin/startup.sh

测试tomcat

在浏览器地址栏输入http://你的IP:8080/，可以看到Apache

Tomcat的起始页，如果看不到，请确认是否是防火墙的问题。也可以修改tomcat的端口为80，此处不多说。

Apache与Tomcat整合

#这里我们使用简单的Proxy方式整合Apache与Tomcat
vi /etc/httpd/conf.d/proxy_ajp.conf
#添加 localhost 是你本机的IP 注意不要写错，如：12.34.56.78:8009
ProxyPass /转发地址 ajp://localhost:8009/php项目名
#（已有此文件的只需将相应内容前的注释符#删除即可）
#保存修改后，重启Apache
service httpd restart

测试整合结果

1	在浏览器地址栏输入http://你的IP/，如果看到的是Apache Tomcat的起始页，恭喜你，Apache和Tomcat的整合已经成功了！

关于无法绑定80端口

1 2	#修改conf/httpd.conf 文件内的监听ip地址为： ServerName 0.0.0.0:80

附：以上安装的软件文件及配置的路径如下：

apache的配置文件在/etc/httpd/conf下
apache的modules放在/usr/lib/httpd下
php的配置文件在/etc/php.d/下 和/etc/php.ini
php的modules放在/usr/lib/php/modules下
Tomcat7的安装目录位于/usr/local/tomcat7

公平锁	非公平锁
公平锁每次获取到锁为同步队列中的第一个节点，保证请求资源时间上的绝对顺序	非公平锁有可能刚释放锁的线程下次继续获取该锁，则有可能导致其他线程永远无法获取到锁，造成“饥饿”现象。
公平锁为了保证时间上的绝对顺序，需要频繁的上下文切换	非公平锁会降低一定的上下文切换，降低性能开销因此，ReentrantLock 默认选择的是非公平锁

呦呵丶晓晓的博客

LeetCode题解 - 01.两数之和

题目

题解

暴力法

哈希表

Java面试（阿里P6）

一面(技术面)

自我介绍和项目

Java的内存分区

执行过程

运行时数据区

运行时数据区的每部分存储了那些数据？

程序计数器

Java栈

本地方法栈

堆

方法区

Java对象的回收方式，回收算法

判定对象是否存活

引用计数法

可达性分析法

引用的种类

强引用（Strong Reference）

软引用（Soft Reference）

弱引用（Weak Reference）

虚引用（Phantom Reference）

回收堆中无效对象

判定finalize()是否有必要执行

对象重生或死亡

回收方法区内存

判定废弃常量

判定无用的类

垃圾收集算法

标记-清除算法

复制算法（新生代）

分配担保

标记-整理算法（老年代）

分代收集算法

CMS和G1了解么，CMS解决什么问题，说一下回收的过程。

CMS

CMS过程

CMS缺点

CMS的适用场景

G1

G1过程

CMS回收停顿了几次？为什么停顿？

Java栈什么时候会发生内存溢出，Java堆呢，说一种场景

Java栈溢出(StackOverflowError)

堆溢出(OutOfMemoryError:java heap space)

持久带溢出(OutOfMemoryError: PermGen space)

OutOfMemoryError:unable to create native thread

面试者的回答

软引用和弱引用的区别

Java里的锁了解哪些

并发关键字

volatile短见字

功能

底层原理

应用场景

synchronized关键字

功能

使用

原理

锁优化策略

自旋锁

锁消除

锁粗化

偏向锁

轻量级锁

volatile 与 synchronized 比较

Lock 体系

Condition 条件对象

AQS

可重入

公平锁与非公平锁

独占锁和共享锁

ReentrantLock

ReentrantLock 与 synchronized 的区别

LockSupport

判定`finalize()`是否有必要执行

`软引用`和`弱引用`的区别

使用`@DependsOn`