Java工程师想要拿到理想的Offer需要知道的面试题

 《Java 工程师必知的道面试题 》

一、Java优化篇

1、在项目开发的过程中尽量减少iterator()方法的使用

这条建议不适用于一般的场合，仅适用于在 N.O.P.E 分支深处的场景。尽管如此也应该有所了解。Java 5格式的循环写法非常的方便，以至于我们可以忘记内部的循环方法，比如：
for (String value : strings) {
    // Do something useful here
}
当每次代码运行到这个循环时，如果 strings 变量是一个 Iterable 的话，代码将会自动创建一个Iterator 的实例。如果使用的是 ArrayList 的话，虚拟机会自动在堆上为对象分配3个整数类型大小的内存。
private class Itr implements Iterator {
    int cursor;
    int lastRet = -1;
    int expectedModCount = modCount;
    // ...
也可以用下面等价的循环方式来替代上面的 for 循环，仅仅是在栈上“浪费”了区区一个整形，相当划算。
int size = strings.size();
for (int i = 0; i < size; i++) {
    String value : strings.get(i);
    // Do something useful here
}
如果循环中字符串的值是不怎么变化，也可用数组来实现循环。

for (String value : stringArray) {
    // Do something useful here
}

关于iterator()：无论是从易读写的角度来说，还是从API设计的角度来说迭代器、Iterable接口和 foreach 循环都是非常好用的。但代价是，使用它们时是会额外在堆上为每个循环子创建一个对象。如果循环要执行很多很多遍，请注意避免生成无意义的实例，最好用基本的指针循环方式来代替上述迭代器、Iterable接口和 foreach 循环。

2、尽可能少的调用高开销的方法

有些方法的开销很大。以 N.O.P.E 分支为例，我们没有提到叶子的相关方法，不过这个可以有。假设我们的JDBC驱动需要排除万难去计算 ResultSet.wasNull() 方法的返回值。我们自己实现的SQL框架可能像下面这样：
if (type == Integer.class) {
    result = (T) wasNull(rs,
        Integer.valueOf(rs.getInt(index)));
}
// And then...
static final T wasNull(ResultSet rs, T value)
throws SQLException {
    return rs.wasNull() ? null : value;
}
在上面的逻辑中，每次从结果集中取得 int 值时都要调用 ResultSet.wasNull() 方法，但是 getInt() 的方法定义为：
返回类型：变量值；如果SQL查询结果为NULL，则返回0。
所以一个简单有效的改善方法如下：
static final T wasNull(
    ResultSet rs, T value
)
throws SQLException {
    return (value == null ||
           (value.intValue() == 0 && rs.wasNull()))
        ? null : value;
}
这是轻而易举的事情。
关于高开销方法的调用：将方法调用缓存起来替代在叶子节点的高开销方法，或者在方法约定允许的情况下避免调用高开销方法。

3、减少正则表达式的使用

正则表达式给人的印象是快捷简便。但是在 N.O.P.E 分支中使用正则表达式将是最糟糕的决定。如果万不得已非要在计算密集型代码中使用正则表达式的话，至少要将 Pattern 缓存下来，避免反复编译Pattern。
static final Pattern HEAVY_REGEX =
    Pattern.compile("(((X)*Y)*Z)*");
如果仅使用到了如下这样简单的正则表达式的话：
String[] parts = ipAddress.split("\\.");
这是最好还是用普通的 char[] 数组或者是基于索引的操作。比如下面这段可读性比较差的代码其实起到了相同的作用。
int length = ipAddress.length();
int offset = 0;
int part = 0;
for (int i = 0; i < length; i++) {
    if (i == length - 1 ||
            ipAddress.charAt(i + 1) == '.') {
        parts[part] =
            ipAddress.substring(offset, i + 1);
        part++;
        offset = i + 2;
    }
}
关于正则表达式上面的代码同时表明了过早的优化是没有意义的。虽然与 split() 方法相比较，这段代码的可维护性比较差。

4、用StringBuilder替代StringBuffer

StingBuilder 应该是在我们的Java代码中默认使用的，应该避免使用 + 操作符。或许你会对 StringBuilder 的语法糖（syntax sugar）持有不同意见，比如：
String x = "a" + args.length + "b";
将会被编译为：
0  new java.lang.StringBuilder [16]
 3  dup
 4  ldc [18]
 6  invokespecial java.lang.StringBuilder(java.lang.String) [20]
 9  aload_0 [args]
10  arraylength
11  invokevirtual java.lang.StringBuilder.append(int) : java.lang.StringBuilder [23]
14  ldc [27]
16  invokevirtual java.lang.StringBuilder.append(java.lang.String) : java.lang.StringBuilder [29]
19  invokevirtual java.lang.StringBuilder.toString() : java.lang.String [32]
22  astore_1 [x]
但究竟发生了什么？接下来是否需要用下面的部分来对 String 进行改善呢？
String x = "a" + args.length + "b";
 
if (args.length == 1)
    x = x + args[0];
现在使用到了第二个 StringBuilder，这个 StringBuilder 不会消耗堆中额外的内存，但却给 GC 带来了压力。
StringBuilder x = new StringBuilder("a");
x.append(args.length);
x.append("b");
if (args.length == 1);
    x.append(args[0]);
关于StringBuilder在上面的样例中，如果你是依靠Java编译器来隐式生成实例的话，那么编译的效果几乎和是否使用了 StringBuilder 实例毫无关系。请记住：在  N.O.P.E 分支中，每次CPU的循环的时间到白白的耗费在GC或者为 StringBuilder 分配默认空间上了，我们是在浪费 N x O x P 时间。
一般来说，使用 StringBuilder 的效果要优于使用 + 操作符。如果可能的话请在需要跨多个方法传递引用的情况下选择 StringBuilder，因为 String 要消耗额外的资源。JOOQ在生成复杂的SQL语句便使用了这样的方式。在整个抽象语法树（AST Abstract Syntax Tree）SQL传递过程中仅使用了一个 StringBuilder 。
更加悲剧的是，如果你仍在使用 StringBuffer 的话，那么用 StringBuilder 代替 StringBuffer 吧，毕竟需要同步字符串的情况真的不多。

5、使用原始类型替代包装类型，使用栈替代堆

上面介绍了来自 jOOQ的例子中使用了大量的泛型，导致的结果是使用了 byte、 short、 int 和 long 的包装类。但至少泛型在Java 10或者Valhalla项目中被专门化之前，不应该成为代码的限制。因为可以通过下面的方法来进行替换：
//存储在堆上
Integer i = 817598;
// 存储在栈上
int i = 817598;
在使用数组时情况可能会变得更加糟糕：
//在堆上生成了三个对象
Integer[] i = { 1337, 424242 };
// 仅在堆上生成了一个对象
int[] i = { 1337, 424242 };
关于原始类型使用的建议：当我们处于 N.O.P.E. 分支的深处时，应该极力避免使用包装类。这样做的坏处是给GC带来了很大的压力。GC将会为清除包装类生成的对象而忙得不可开交。
所以一个有效的优化方法是使用基本数据类型、定长数组，并用一系列分割变量来标识对象在数组中所处的位置。
遵循LGPL协议的 trove4j 是一个Java集合类库，它为我们提供了优于整形数组 int[] 更好的性能实现。
例如下面的情况：
对这条规则例外：因为 boolean 和 byte 类型不足以让JDK为其提供缓存方法。我们可以这样写：
Boolean a1 = true; // syntax sugar for:
Boolean a2 = Boolean.valueOf(true);
Byte b1 = (byte) 123; // syntax sugar for:
Byte b2 = Byte.valueOf((byte) 123);
其它整数基本类型也有类似情况，比如 char、short、int、long。
不要在调用构造方法时将这些整型基本类型自动装箱或者调用 TheType.valueOf() 方法。
也不要在包装类上调用构造方法，除非你想得到一个不在堆上创建的实例。这样做的好处是为你为同事献上一个巨坑的愚人节笑话。
非堆存储
当然了，如果你还想体验下堆外函数库的话，尽管这可能参杂着不少战略决策，而并非最乐观的本地方案。一篇由Peter Lawrey和 Ben Cotton撰写的关于非堆存储的很有意思文章请点击： OpenJDK与HashMap——让老手安全地掌握（非堆存储！）新技巧。

6、除了在 N.O.P.E 分支尽量使用迭代来代替递归

现在，类似Scala这样的函数式编程语言都鼓励使用递归。因为递归通常意味着能分解到单独个体优化的尾递归（tail-recursing）。如果你使用的编程语言能够支持那是再好不过。不过即使如此，也要注意对算法的细微调整将会使尾递归变为普通递归。
希望编译器能自动探测到这一点，否则本来我们将为只需使用几个本地变量就能搞定的事情而白白浪费大量的堆栈框架（stack frames）。

7、迭代键值对形式的Map时一定要用 entrySet() 方法

当我们想遍历一个用键值对形式保存的 Map 时，必须要为下面的代码找到一个很好的理由：
for (K key : map.keySet()) {
    V value : map.get(key);
}
更不用说下面的写法：
for (Entry entry : map.entrySet()) {
    K key = entry.getKey();
    V value = entry.getValue();
}
在我们使用 N.O.P.E. 分支应该慎用map。因为很多看似时间复杂度为 O(1) 的访问操作其实是由一系列的操作组成的。而且访问本身也不是免费的。至少，如果不得不使用map的话，那么要用 entrySet() 方法去迭代！这样的话，我们要访问的就仅仅是Map.Entry的实例。

8、将键值声明为枚举类型

在某些情况下，比如在使用配置map时，我们可能会预先知道保存在map中键值。如果这个键值非常小，我们就应该考虑使用 EnumSet 或 EnumMap，而并非使用我们常用的 HashSet 或 HashMap。下面的代码给出了很清楚的解释：
private transient Object[] vals;
public V put(K key, V value) {
    // TODO
    int index = key.ordinal();
    vals[index] = maskNull(value);
    // TODO
}
上段代码的关键实现在于，我们用数组代替了哈希表。尤其是向map中插入新值时，所要做的仅仅是获得一个由编译器为每个枚举类型生成的常量序列号。如果有一个全局的map配置（例如只有一个实例），在增加访问速度的压力下，EnumMap 会获得比 HashMap 更加杰出的表现。原因在于 EnumMap 使用的堆内存比 HashMap 要少 一位（bit），而且 HashMap 要在每个键值上都要调用 hashCode() 方法和 equals() 方法。

9、优化自定义hasCode()方法和equals()方法

在不能使用EnumMap的情况下，至少也要优化 hashCode() 和 equals() 方法。一个好的 hashCode() 方法是很有必要的，因为它能防止对高开销 equals() 方法多余的调用。
在每个类的继承结构中，需要容易接受的简单对象。让我们看一下jOOQ的 org.jooq.Table 是如何实现的？
最简单、快速的 hashCode() 实现方法如下：
// AbstractTable一个通用Table的基础实现：
@Override
public int hashCode() {
 
    // [#1938] 与标准的QueryParts相比，这是一个更加高效的hashCode()实现
    return name.hashCode();
}
name即为表名。我们甚至不需要考虑schema或者其它表属性，因为表名在数据库中通常是唯一的。并且变量 name 是一个字符串，它本身早就已经缓存了一个 hashCode() 值。


这段代码中注释十分重要，因继承自 AbstractQueryPart 的 AbstractTable 是任意抽象语法树元素的基本实现。普通抽象语法树元素并没有任何属性，所以不能对优化 hashCode() 方法实现抱有任何幻想。覆盖后的 hashCode() 方法如下：


// AbstractQueryPart一个通用抽象语法树基础实现：
@Override
public int hashCode() {
    // 这是一个可工作的默认实现。
    // 具体实现的子类应当覆盖此方法以提高性能。
    return create().renderInlined(this).hashCode();
}
换句话说，要触发整个SQL渲染工作流程（rendering workflow）来计算一个普通抽象语法树元素的hash代码。


equals() 方法则更加有趣：
// AbstractTable通用表的基础实现：
@Override
public boolean equals(Object that) {
    if (this == that) {
        return true;
    }
 
    // [#2144] 在调用高开销的AbstractQueryPart.equals()方法前，
    // 可以及早知道对象是否不相等。
    if (that instanceof AbstractTable) {
        if (StringUtils.equals(name,
            (((AbstractTable) that).name))) {
            return super.equals(that);
        }
 
        return false;
    }
 
    return false;
}
首先，不要过早使用 equals() 方法（不仅在N.O.P.E.中），如果：


this == argument
this“不兼容：参数
注意：如果我们过早使用 instanceof 来检验兼容类型的话，后面的条件其实包含了argument == null。我在以前的博客中已经对这一点进行了说明，请参考10个精妙的Java编码最佳实践。


在我们对以上几种情况的比较结束后，应该能得出部分结论。比如jOOQ的 Table.equals() 方法说明是，用来比较两张表是否相同。不论具体实现类型如何，它们必须要有相同的字段名。比如下面两个元素是不可能相同的：


com.example.generated.Tables.MY_TABLE
DSL.tableByName(“MY_OTHER_TABLE”)
如果我们能方便地判断传入参数是否等于实例本身（this），就可以在返回结果为 false 的情况下放弃操作。如果返回结果为 true，我们还可以进一步对父类（super）实现进行判断。在比较过的大多数对象都不等的情况下，我们可以尽早结束方法来节省CPU的执行时间。
一些对象的相似度比其它对象更高。
在jOOQ中，大多数的表实例是由jOOQ的代码生成器生成的，这些实例的 equals() 方法都经过了深度优化。而数十种其它的表类型（衍生表 （derived tables）、表值函数（table-valued functions）、数组表（array tables）、连接表（joined tables）、数据透视表（pivot tables）、公用表表达式（common table expressions）等，则保持 equals() 方法的基本实现。

10、考虑使用set而并非单个元素

最后，还有一种情况可以适用于所有语言而并非仅仅同Java有关。除此以外，我们以前研究的 N.O.P.E. 分支也会对了解从 O(N3) 到 O(n log n)有所帮助。
不幸的是，很多程序员的用简单的、本地算法来考虑问题。他们习惯按部就班地解决问题。这是命令式（imperative）的“是/或”形式的函数式编程风格。这种编程风格在由纯粹命令式编程向面对象式编程向函数式编程转换时，很容易将“更大的场景（bigger picture）”模型化，但是这些风格都缺少了只有在SQL和R语言中存在的：
声明式编程。
在SQL中，我们可以在不考虑算法影响下声明要求数据库得到的效果。数据库可以根据数据类型，比如约束（constraints）、键（key）、索引（indexes）等不同来采取最佳的算法。
在理论上，我们最初在SQL和关系演算（relational calculus）后就有了基本的想法。在实践中，SQL的供应商们在过去的几十年中已经实现了基于开销的高效优化器CBOs (Cost-Based Optimisers) 。然后到了2010版，我们才终于将SQL的所有潜力全部挖掘出来。
但是我们还不需要用set方式来实现SQL。所有的语言和库都支持Sets、collections、bags、lists。使用set的主要好处是能使我们的代码变的简洁明了。比如下面的写法：
SomeSet INTERSECT SomeOtherSet
// Java 8以前的写法
Set result = new HashSet();
for (Object candidate : someSet)
    if (someOtherSet.contains(candidate))
        result.add(candidate);
 
// 即使采用Java 8也没有很大帮助
someSet.stream()
       .filter(someOtherSet::contains)
       .collect(Collectors.toSet());
有些人可能会对函数式编程和Java 8能帮助我们写出更加简单、简洁的算法持有不同的意见。但这种看法不一定是对的。我们可以把命令式的Java 7循环转换成Java 8的Stream collection，但是我们还是采用了相同的算法。但SQL风格的表达式则是不同的：
SomeSet INTERSECT SomeOtherSet
上面的代码在不同的引擎上可以有1000种不同的实现。我们今天所研究的是，在调用 INTERSECT 操作之前，更加智能地将两个set自动的转化为 EnumSet 。甚至我们可以在不需要调用底层的 Stream.parallel() 方法的情况下进行并行 INTERSECT 操作。

关于Java优化：

主要针对N.O.P.E.分支的优化。比如深入高复杂性的算法。

jOOQ处在“食物链的底端”，因为它是在离开JVM进入到DBMS时，被我们电脑程序所调用的最后一个API。位于食物链的底端意味着任何一条线路在jOOQ中被执行时都需要 N x O x P 的时间，所以需要尽早进行优化。

在业务逻辑可能没有N.O.P.E.分支那么复杂。但是基础框架有可能十分复杂（本地SQL框架、本地库等）。所以需要按照我们今天提到的原则，用Java Mission Control 或其它工具进行复查，确认是否有需要优化的地方。

二、JVM优化篇

1、 JVM的类加载机制是什么？有哪些实现方式？

类加载机制：
类的加载指的是将类的.class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法去
内，然后在堆区创建一个java.lang.Class对象，用来封装在方法区内的数据结构。类的加载最终是
在堆区内的Class对象，Class对象封装了类在方法区内的数据结构，并且向Java程序员提供了访问
方法区内的数据结构的接口。
类加载有三种方式：
1）命令行启动应用时候由JVM初始化加载
2）通过Class.forName（）方法动态加载
3）通过ClassLoader.loadClass（）方法动态加载

2、JVM的常见垃圾回收算法？

1）标记-清楚算法：前后线标记处所有需要回收的对象，在标记完成后统一回收有被标记的对象。
2）复制算法：将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当一块内存用
完了，将其存在另外一块上面，然后再把已使用过的内存空间一次清理掉。
3）标记-整理算法：标记过程与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清
理，而是让所一端移动，然后直接清理掉端边界以外的内存。
4）分代收集算法：一般是把Java堆分为新生代和老年代，根据各个年代的特点采用最适当的收集
算法。新生代都发现有大批对象死去，选用复制算法。老年代中因为对象存活率高，必须使用“标
记-清理”或“标记-整理”算法来进行回收。

3、JVM调优的常见命令行工具有哪些？JVM常见的调优参数有哪些？

（1）JVM调优的常见命令工具包括：
1）jps命令用于查询正在运行的JVM进程，
2）jstat可以实时显示本地或远程JVM进程中类装载、内存、垃圾收集、JIT编译等数据
3）jinfo用于查询当前运行这的JVM属性和参数的值。
4）jmap用于显示当前Java堆和永久代的详细信息
5）jhat用于分析使用jmap生成的dump文件，是JDK自带的工具
6）jstack用于生成当前JVM的所有线程快照，线程快照是虚拟机每一条线程正在执行的方法,目的
是定位线程出现长时间停顿的原因。
（2）JVM常见的调优参数包括：
-Xmx
指定java程序的最大堆内存, 使用java -Xmx5000M -version判断当前系统能分配的最大堆内
存 -X
ms
指定最小堆内存, 通常设置成跟最大堆内存一样，减少GC
-Xmn
设置年轻代大小。整个堆大小=年轻代大小 + 年老代大小。所以增大年轻代后，将会减小年老
代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。
-Xss
指定线程的最大栈空间, 此参数决定了java函数调用的深度, 值越大调用深度越深, 若值太小则容
易出栈溢出错误(StackOverflowError)
-XX:PermSize
指定方法区(永久区)的初始值,默认是物理内存的1/64， 在Java8永久区移除, 代之的是元数据
区， 由-XX:MetaspaceSize指定
-XX:MaxPermSize
指定方法区的最大值, 默认是物理内存的1/4， 在java8中由-XX:MaxMetaspaceSize指定元数
据区的大小
-XX:NewRatio=n
年老代与年轻代的比值，-XX:NewRatio=2, 表示年老代与年轻代的比值为2:1
-XX:SurvivorRatio=n
Eden区与Survivor区的大小比值，-XX:SurvivorRatio=8表示Eden区与Survivor区的大小比值
是8:1:1，因为Survivor区有两个(from, to)

4、ConcurrentHashMap加锁机制是什么，详细说一下？

HashTable容器在竞争激烈的并发环境下表现出效率低下的原因，是因为所有访问HashTable的线
程都必须竞争同一把锁，那假如容器里有多把锁，每一把锁用于锁容器其中一部分数据，那么当多
线程访问容器里不同数据段的数据时，线程间就不会存在锁竞争，从而可以有效的提高并发访问效
率，这就是ConcurrentHashMap所使用的锁分段技术，首先将数据分成一段一段的存储，然后给
每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线
程访问。

5、G1收集器简介？以及它的内存划分怎么样的？

（1）简介：
Garbage-First（G1，垃圾优先）收集器是服务类型的收集器，目标是多处理器机器、大内存机
器。它高度符合垃圾收集暂停时间的目标，同时实现高吞吐量。Oracle JDK 7 update 4 以及更新
发布版完全支持G1垃圾收集器
（2）G1的内存划分方式：
它是将堆内存被划分为多个大小相等的 heap 区,每个heap区都是逻辑上连续的一段内存(virtual
memory). 其中一部分区域被当成老一代收集器相同的角色(eden, survivor, old), 但每个角色的区
域个数都不是固定的。这在内存使用上提供了更多的灵活性。

6、在重写equals方法时，需要遵循哪些约定，具体介绍一下？

重写equals方法时需要遵循通用约定：自反性、对称性、传递性、一致性.、非空性
1）自反性
对于任何非null的引用值x,x.equals(x)必须返回true。—这一点基本上不会有啥问题
2）对称性
对于任何非null的引用值x和y，当且仅当x.equals(y)为true时，y.equals(x)也为true。
3）传递性
对 于 任 何 非 null 的 引 用 值 x 、 y 、 z 。 如 果 x.equals(y)==true,y.equals(z)==true, 那 么
x.equals(z)==true。
4） 一致性
对于任何非null的引用值x和y，只要equals的比较操作在对象所用的信息没有被修改，那么多次调
用x.eqals(y)就会一致性地返回true,或者一致性的返回false。
5）非空性
所有比较的对象都不能为空。

7、Synchronized优化后的锁机制简单介绍一下，包括自旋锁、偏向锁、轻量级锁、重量级锁？

自旋锁：
线程自旋说白了就是让cup在做无用功，比如：可以执行几次for循环，可以执行几条空的汇编指
令，目的是占着CPU不放，等待获取锁的机会。如果旋的时间过长会影响整体性能，时间过短又达
不到延迟阻塞的目的。
偏向锁
偏向锁就是一旦线程第一次获得了监视对象，之后让监视对象“偏向”这个线程，之后的多次调用
则可以避免CAS操作，
说白了就是置个变量，如果发现为true则无需再走各种加锁/解锁流程。
轻量级锁：
轻量级锁是由偏向所升级来的，偏向锁运行在一个线程进入同步块的情况下，当第二个线程加入锁
争用的时候，偏向锁就会升级为轻量级锁；
重量级锁
重量锁在JVM中又叫对象监视器（Monitor），它很像C中的Mutex，除了具备Mutex(0|1)互斥的
功能，它还负责实现了Semaphore(信号量)的功能，也就是说它至少包含一个竞争锁的队列，和一
个信号阻塞队列（wait队列），前者负责做互斥，后一个用于做线程同步。
偏向锁、轻量级锁、重量级锁的对比：

锁级别的对比

锁	优点	缺点	使用场景
偏向锁	加锁和解锁不需要额外的消耗，和执行非同步方法比仅在纳秒级的差距。	如果线程存在锁竞争，会带来额外的锁撤销的消耗。	适用于只有一个线程同步块的场景。
轻量级锁	竞争的线程不会阻塞，提高了程序的响应速度。	如果始终得不到锁竞争的线程使用自旋会消耗CPU。	最求响应时间，锁占用时间很短。
重量级锁	竞争线程不适用自旋，不会消耗CPU。	线程阻塞，响应时间缓慢。	追求吞吐量，锁占用时间较长。

8、Redis和Memcache区别对比？如何选择这两个技术？

区别：
1） Redis和Memcache都是将数据存放在内存中，都是内存数据库。不过memcache还可用于缓
存其他东西，例如图片、视频等等。
2）Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，hash等数据结构的存储。
3）虚拟内存–Redis当物理内存用完时，可以将一些很久没用到的value 交换到磁盘
4）过期策略–memcache在set时就指定，例如set key1 0 0 8,即永不过期。Redis可以通过例如
expire 设定，例如expire name 10
5）分布式–设定memcache集群，利用magent做一主多从;redis可以做一主多从。都可以一主一从
6）存储数据安全–memcache挂掉后，数据没了；redis可以定期保存到磁盘（持久化）
7）灾难恢复–memcache挂掉后，数据不可恢复; redis数据丢失后可以通过aof恢复
8）Redis支持数据的备份，即master-slave模式的数据备份。
选型：
若是简单的存取key-value这样的数据用memcache好一些
若是要支持数据持久化，多数据类型(如集合、散列之类的)，用列表类型做队列之类的高级应用，
就用redis
想学习的，Java工程化、高性能及分布式、高性能、深入浅出。高架构，性能调优、Spring，
MyBatis，Netty源码分析和大数据等多个知识点。如果你想拿高薪的，想跟别人竞争能取得优势
的，想进阿里面试但担心面试不过的，你都可以来，群号为：521479582一起交流。针对工作1–5
年工作人员提升自己。

9、Redis的持久化机制是什么？各自的优缺点？

redis提供两种持久化机制RDB和AOF机制。
1）RDB持久化方式：
是指用数据集快照的方式记录redis数据库的所有键值对。
优点：
1.只有一个文件dump.rdb，方便持久化。
2.容灾性好，一个文件可以保存到安全的磁盘。
3.性能最大化，fork子进程来完成写操作，让主进程继续处理命令，所以是IO最大化。
4.相对于数据集大时，比AOF的启动效率更高。
缺点：
1.数据安全性低。
2）AOF持久化方式：
是指所有的命令行记录以redis命令请求协议的格式保存为aof文件。
优点：
1.数据安全，aof持久化可以配置appendfsync属性，有always，每进行一次命令操作就记录
到aof文件中一次。
2.通过append模式写文件，即使中途服务器宕机，可以通过redis-check-aof工具解决数据一
致性问题。
3.AOF机制的rewrite模式。
缺点：
1.文件会比RDB形式的文件大。
2.数据集大的时候，比rdb启动效率低。

10. Mysql的数据库表锁、行锁、页级锁？

表级，直接锁定整张表，在你锁定期间，其它进程无法对该表进行写操作。如果你是写锁，则其它
进程则读也不允许
行级,，仅对指定的记录进行加锁，这样其它进程还是可以对同一个表中的其它记录进行操作。
页级，表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折衷的页级，一次锁定相邻的
一组记录。

11. 数据库的四大特征，数据库的隔离级别？

数据库的四大特征：
（1）原子性（Atomicity）
原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚。
（2）一致性（Consistency）
一个事务执行之前和执行之后都必须处于一致性状态。
（3）隔离性（Isolation）
隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，
不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。
4）持久性（Durability）
持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的。
数据库的隔离级别：
1）Serializable (串行化)：可避免脏读、不可重复读、幻读的发生。2）Repeatable read (可重复
读)：可避免脏读、不可重复读的发生。3）Read committed (读已提交)：可避免脏读的发生。4）
Read uncommitted (读未提交)：最低级别，任何情况都无法保证。