1.什么是缓存雪崩？怎么解决？
通常，我们会使用缓存用于缓冲对 DB 的冲击，如果缓存宕机，所有请求将直接打在 DB，造成 DB 宕机——从而导致整个系统宕机。
如何解决呢？
2 种策略（同时使用）：
- 对缓存做高可用，防止缓存宕机
- 使用 断路器 ，如果缓存宕机，为了防止系统全部宕机，限制部分流量进入 DB，保证部分可用，其余的请求返回断路器的默认值。
2.什么是 缓存 和数据库双写不一致？怎么解决？
解释：连续写数据库和缓存，但是操作期间，出现并发了，数据不一致了。
通常，更新缓存和数据库有以下几种顺序：
- 先更新数据库，再更新缓存。
- 先删缓存，再更新数据库。
- 先更新数据库，再删除缓存。
三种方式的优劣来看一下：
先更新数据库，再更新缓存。
这么做的问题是：当有 2 个请求同时更新数据，那么如果不使用分布式锁，将无法控制最后缓存的值到底是多少。也就是并发写的时候有问题。
先删缓存，再更新数据库。
这么做的问题：如果在删除缓存后，有客户端读数据，将可能读到旧数据，并有可能设置到缓存中，导致缓存中的数据一直是老数据。
有 2 种解决方案：
- 使用“双删”，即删更删，最后一步的删除作为异步操作，就是防止有客户端读取的时候设置了旧值。
- 使用队列，当这个 key 不存在时，将其放入队列，串行执行，必须等到更新数据库完毕才能读取数据。
总的来讲，比较麻烦。
先更新数据库，再删除缓存
这个实际是常用的方案，但是有很多人不知道，这里介绍一下，这个叫 Cache Aside Pattern，老外发明的。如果先更新数据库，再删除缓存，那么就会出现更新数据库之前有瞬间数据不是很及时。
同时，如果在更新之前，缓存刚好失效了，读客户端有可能读到旧值，然后在写客户端删除结束后再次设置了旧值，非常巧合的情况。
有 2 个前提条件： 缓存在写之前的时候失效，同时，在写客户度删除操作结束后，放置旧数据 —— 也就是读比写慢。* *设置有的写操作还会锁表。**
所以，这个很难出现，但是如果出现了怎么办？使用双删！！！记录更新期间有没有客户端读数据库，如果有，在更新完数据库之后，执行延迟删除。
还有一种可能，如果执行更新数据库，准备执行删除缓存时，服务挂了，执行删除失败怎么办？？？
这就坑了！！！不过可以通过订阅数据库的 binlog 来删除。
3.说说 Hash Code() 和 equals() 之间的关系？
介绍
equals() 的作用是用来判断两个对象是否相等。
hashCode() 的作用是获取哈希码，也称为散列码；它实际上是返回一个int整数。这个哈希码的作用是确定该对象在哈希表中的索引位置。
关系
我们以“类的用途”来将“hashCode() 和 equals()的关系”分2种情况来说明。
1、不会创建“类对应的 散列表 ”
这里所说的“不会创建类对应的散列表”是说：我们不会在HashSet, Hashtable , hashMap 等等这些本质是散列表的数据结构中，用到该类。例如，不会创建该类的HashSet集合。
在这种情况下，该类的“hashCode() 和 equals() ”没有半毛钱关系的！ equals() 用来比较该类的两个对象是否相等。而hashCode() 则根本没有任何作用。
下面，我们通过示例查看类的两个对象相等以及不等时hashCode()的取值。
import java.util.*;
import Java .lang.Comparable;
/**
* @desc 比较equals() 返回true 以及 返回false时， hashCode()的值。
*
*/public class NormalHashCodeTest{
public static void main(String[] args) {
// 新建个相同内容的Person对象，
// 再用equals比较它们是否相等
Person p = new Person("eee", 100);
Person p = new Person("eee", 100);
Person p = new Person("aaa", 200);
System.out.printf("p.equals(p2) : %s; p1(%d) p2(%d)n", p1.equals(p2), p1.hashCode(), p2.hashCode());
System.out.printf("p.equals(p3) : %s; p1(%d) p3(%d)n", p1.equals(p3), p1.hashCode(), p3.hashCode());
}
/**
* @desc Person类。
*/ private static class Person {
int age;
String name;
public Person(String name, int age) {
this.name = name;
this.age = age;
}
public String toString() {
return name + " - " +age;
}
/**
* @desc 覆盖equals方法
*/
public boolean equals(Object obj){
if(obj == null){
return false;
}
//如果是同一个对象返回true，反之返回false
if(this == obj){
return true;
}
//判断是否类型相同
if(this.getClass() != obj.getClass()){
return false;
}
Person person = (Person)obj;
return name.equals(person.name) && age==person.age;
}
}
}
运行结果：
p.equals(p2) : true; p1(1169863946) p2(1901116749)
p.equals(p3) : false; p1(1169863946) p3(2131949076)
从结果也可以看出：p1和p2相等的情况下，hashCode()也不一定相等。
2、会创建“类对应的散列表”
这里所说的“会创建类对应的散列表”是说：我们会在HashSet, Hashtable, HashMap等等这些本质是散列表的数据结构中，用到该类。例如，会创建该类的HashSet集合。
在这种情况下，该类的“hashCode() 和 equals() ”是有关系的：
- 如果两个对象相等，那么它们的hashCode()值一定相同。 这里的相等是指，通过equals()比较两个对象时返回true。
- 如果两个对象hashCode()相等，它们并不一定相等 。因为在散列表中，hashCode()相等，即两个键值对的哈希值相等。然而哈希值相等，并不一定能得出键值对相等。补充说一句：“两个不同的键值对，哈希值相等”，这就是哈希冲突。
此外，在这种情况下。若要判断两个对象是否相等，除了要覆盖equals()之外，也要覆盖hashCode()函数。否则，equals()无效。
举例，创建Person类的HashSet集合，必须同时覆盖Person类的equals() 和 hashCode()方法。
如果单单只是覆盖equals()方法。我们会发现，equals()方法没有达到我们想要的效果。
import java.util.*;
import java.lang.Comparable;
/**
* @desc 比较equals() 返回true 以及 返回false时， hashCode()的值。
*
*/public class ConflictHashCodeTest{
public static void main(String[] args) {
// 新建Person对象，
Person p = new Person("eee", 100);
Person p = new Person("eee", 100);
Person p = new Person("aaa", 200);
// 新建HashSet对象
HashSet set = new HashSet();
set.add(p);
set.add(p);
set.add(p);
// 比较p 和 p2， 并打印它们的hashCode()
System.out.printf("p.equals(p2) : %s; p1(%d) p2(%d)n", p1.equals(p2), p1.hashCode(), p2.hashCode());
// 打印set
System.out.printf("set:%sn", set);
}
/**
* @desc Person类。
*/ private static class Person {
int age;
String name;
public Person(String name, int age) {
this.name = name;
this.age = age;
}
public String toString() {
return "("+name + ", " +age+")";
}
/**
* @desc 覆盖equals方法
*/
@ Override
public boolean equals(Object obj){
if(obj == null){
return false;
}
//如果是同一个对象返回true，反之返回false
if(this == obj){
return true;
}
//判断是否类型相同
if(this.getClass() != obj.getClass()){
return false;
}
Person person = (Person)obj;
return name.equals(person.name) && age==person.age;
}
}
}
运行结果：
p.equals(p2) : true; p1(1169863946) p2(1690552137)
set:[(eee,), (eee, 100), (aaa, 200)]
结果分析：
我们重写了Person的equals()。但是，很奇怪地发现：HashSet中仍然有重复元素：p1 和 p2。为什么会出现这种情况呢？
这是因为虽然p1 和 p2的内容相等，但是它们的hashCode()不等；所以，HashSet在添加p1和p2的时候，认为它们不相等。
那同时覆盖equals() 和 hashCode()方法呢？
import java.util.*;
import java.lang.Comparable;
/**
* @desc 比较equals() 返回true 以及 返回false时， hashCode()的值。
*
*/public class ConflictHashCodeTest{
public static void main(String[] args) {
// 新建Person对象，
Person p = new Person("eee", 100);
Person p = new Person("eee", 100);
Person p = new Person("aaa", 200);
Person p = new Person("EEE", 100);
// 新建HashSet对象
HashSet set = new HashSet();
set.add(p);
set.add(p);
set.add(p);
// 比较p 和 p2， 并打印它们的hashCode()
System.out.printf("p.equals(p2) : %s; p1(%d) p2(%d)n", p1.equals(p2), p1.hashCode(), p2.hashCode());
// 比较p 和 p4， 并打印它们的hashCode()
System.out.printf("p.equals(p4) : %s; p1(%d) p4(%d)n", p1.equals(p4), p1.hashCode(), p4.hashCode());
// 打印set
System.out.printf("set:%sn", set);
}
/**
* @desc Person类。
*/ private static class Person {
int age;
String name;
public Person(String name, int age) {
this.name = name;
this.age = age;
}
public String toString() {
return name + " - " +age;
}
/**
* @desc重写hashCode
*/
@Override
public int hashCode(){
int nameHash = name.toUpperCase().hashCode();
return nameHash ^ age;
}
/**
* @desc 覆盖equals方法
*/
@Override
public boolean equals(Object obj){
if(obj == null){
return false;
}
//如果是同一个对象返回true，反之返回false
if(this == obj){
return true;
}
//判断是否类型相同
if(this.getClass() != obj.getClass()){
return false;
}
Person person = (Person)obj;
return name.equals(person.name) && age==person.age;
}
}
}
运行结果：
p.equals(p2) : true; p1(68545) p2(68545)
p.equals(p4) : false; p1(68545) p4(68545)
set:[aaa -, eee - 100]
结果分析：
这下，equals()生效了，HashSet中没有重复元素。
比较p1和p2，我们发现：它们的hashCode()相等，通过equals()比较它们也返回true。所以，p1和p2被视为相等。
比较p1和p4，我们发现：虽然它们的hashCode()相等；但是，通过equals()比较它们返回false。所以，p1和p4被视为不相等。
原则
1.同一个对象（没有发生过修改）无论何时调用hashCode()得到的返回值必须一样。 如果一个key对象在put的时候调用hashCode()决定了存放的位置，而在get的时候调用hashCode()得到了不一样的返回值，这个值映射到了一个和原来不一样的地方，那么肯定就找不到原来那个键值对了。
2.hashCode()的返回值相等的对象不一定相等，通过hashCode()和equals()必须能唯一确定一个对象。 不相等的对象的hashCode()的结果可以相等。hashCode()在注意关注碰撞问题的时候，也要关注生成速度问题，完美hash不现实。
3.一旦重写了equals()函数（重写equals的时候还要注意要满足自反性、对称性、传递性、一致性），就必须重写hashCode()函数。 而且hashCode()的生成哈希值的依据应该是equals()中用来比较是否相等的字段。
如果两个由equals()规定相等的对象生成的hashCode不等，对于hashMap来说，他们很可能分别映射到不同位置，没有调用equals()比较是否相等的机会，两个实际上相等的对象可能被插入不同位置，出现错误。其他一些基于哈希方法的集合类可能也会有这个问题
4.说说Object类下面有几种方法呢？
Object有几种方法呢？
分析
Object类是Java中所有类的基类。位于java.lang包中，一共有13个方法。如下图：
具体解答
1.Object()
这个没什么可说的，Object类的构造方法。(非重点)
2.registerNatives()
为了使 JVM 发现本机功能，他们被一定的方式命名。例如，对于java.lang.Object.registerNatives，对应的C函数命名为Java_java_lang_Object_registerNatives。
通过使用registerNatives（或者更确切地说， JNI 函数RegisterNatives），可以命名任何你想要你的 C函数 。(非重点)
3.clone()
clone()函数的用途是用来另存一个当前存在的对象。只有实现了Cloneable接口才可以调用该方法，否则抛出CloneNotSupportedException异常。（注意：回答这里时可能会引出设计模式的提问）
4.getClass()
final方法，用于获得运行时的类型。该方法返回的是此Object对象的类对象/运行时类对象Class。效果与Object.class相同。（注意：回答这里时可能会引出类加载，反射等知识点的提问）
5.equals()
equals用来比较两个对象的内容是否相等。默认情况下(继承自Object类)，equals和==是一样的，除非被覆写(override)了。（注意：这里可能引出更常问的“equals与==的区别”及hashmap实现原理的提问）
6.hashCode()
该方法用来返回其所在对象的物理地址（哈希码值），常会和equals方法同时重写，确保相等的两个对象拥有相等的hashCode。（同样，可能引出hashmap实现原理的提问）
7. toString ()
toString()方法返回该对象的字符串表示，这个方法没什么可说的。
8.wait()
导致当前的线程等待，直到其他线程调用此对象的 notify() 方法或 notifyAll() 方法。（引出线程通信及“wait和sleep的区别”的提问）
9.wait(long timeout)
导致当前的线程等待，直到其他线程调用此对象的 notify() 方法或 notifyAll() 方法，或者超过指定的时间量。（引出线程通信及“wait和sleep的区别”的提问）
10.wait(long timeout, int nanos)
导致当前的线程等待，直到其他线程调用此对象的 notify() 方法或 notifyAll() 方法，或者其他某个线程中断当前线程，或者已超过某个实际时间量。（引出线程通信及“wait和sleep的区别”的提问）
11.notify()
唤醒在此对象监视器上等待的单个线程。（引出 线程 通信的提问）
12. notifyAll()
唤醒在此对象监视器上等待的所有线程。（引出线程通信的提问）
13. finalize ()
当垃圾回收器确定不存在对该对象的更多引用时，由对象的垃圾回收器调用此方法。（非重点，但小心引出垃圾回收的提问）
5.Redis中是如何实现分布式锁的？
分布式锁常见的三种实现方式：
- 数据库 乐观锁 ；
- 基于 Redis 的分布式锁；
- 基于 ZooKeeper 的分布式锁。
本地面试考点是，你对Redis使用熟悉吗？Redis中是如何实现分布式锁的。
要点
Redis要实现分布式锁，以下条件应该得到满足
互斥性
- 在任意时刻，只有一个客户端能持有锁。
不能死锁
- 客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。
容错性
- 只要大部分的Redis节点正常运行，客户端就可以加锁和解锁。
实现
可以直接通过 set key value px milliseconds nx 命令实现加锁， 通过Lua脚本实现解锁。
//获取锁（unique_value可以是UUID等）
SET resource_name unique_value NX PX
//释放锁（lua脚本中，一定要比较value，防止误解锁）
if redis.call("get",KEYS[]) == ARGV[1] then
return redis.call("del",KEYS[])
else
return
end
代码解释
- set 命令要用 set key value px milliseconds nx ，替代 setnx + expire 需要分两次执行命令的方式，保证了原子性，
- value 要具有唯一性，可以使用 UUID.randomUUID().toString() 方法生成，用来标识这把锁是属于哪个请求加的，在解锁的时候就可以有依据；
- 释放锁时要验证 value 值，防止误解锁；
- 通过 Lua 脚本来避免 Check And Set 模型的并发问题，因为在释放锁的时候因为涉及到多个Redis操作 （利用了eval命令执行Lua脚本的原子性）；
加锁代码分析
首先，set()加入了NX参数，可以保证如果已有key存在，则函数不会调用成功，也就是只有一个客户端能持有锁，满足互斥性。其次，由于我们对锁设置了过期时间，即使锁的持有者后续发生崩溃而没有解锁，锁也会因为到了过期时间而自动解锁（即key被删除），不会发生死锁。最后，因为我们将value赋值为requestId，用来标识这把锁是属于哪个请求加的，那么在客户端在解锁的时候就可以进行校验是否是同一个客户端。
解锁代码分析
将Lua代码传到jedis.eval()方法里，并使参数KEYS[1]赋值为lockKey，ARGV[1]赋值为requestId。在执行的时候，首先会获取锁对应的value值，检查是否与requestId相等，如果相等则解锁（删除key）。
存在的风险
如果存储锁对应key的那个节点挂了的话，就可能存在丢失锁的风险，导致出现多个客户端持有锁的情况，这样就不能实现资源的独享了。
- 客户端A从master获取到锁
- 在master将锁同步到slave之前，master宕掉了（Redis的主从同步通常是异步的）。 主从切换，slave节点被晋级为master节点
- 客户端B取得了同一个资源被客户端A已经获取到的另外一个锁。导致存在同一时刻存不止一个线程获取到锁的情况。
redlock算法出现
这个场景是假设有一个 redis cluster，有 5 个 redis master 实例。然后执行如下步骤获取一把锁：
- 获取当前时间戳，单位是毫秒；
- 跟上面类似，轮流尝试在每个 master 节点上创建锁，过期时间较短，一般就几十毫秒；
- 尝试在大多数节点上建立一个锁，比如 5 个节点就要求是 3 个节点 n / 2 + 1；
- 客户端计算建立好锁的时间，如果建立锁的时间小于超时时间，就算建立成功了；
- 要是锁建立失败了，那么就依次之前建立过的锁删除；
- 只要别人建立了一把分布式锁，你就得不断轮询去尝试获取锁。
Redisson实现
Redisson是一个在Redis的基础上实现的Java驻内存数据网格（In-Memory Data Grid）。它不仅提供了一系列的分布式的Java常用对象，还实现了可重入锁（Reentrant Lock）、公平锁（Fair Lock、联锁（MultiLock）、 红锁（RedLock）、 读写锁（ReadWriteLock）等，还提供了许多分布式服务。
Redisson提供了使用Redis的最简单和最便捷的方法。Redisson的宗旨是促进使用者对Redis的关注分离（Separation of Concern），从而让使用者能够将精力更集中地放在处理业务逻辑上。
Redisson 分布式重入锁用法
Redisson 支持单点模式、主从模式、哨兵模式、集群模式，这里以单点模式为例：
//.构造redisson实现分布式锁必要的Config
Config config = new Config();
config.useSingleServer().setAddress("redis://.0.0.1:5379").setPassword("123456").setDatabase(0);
//.构造RedissonClient
RedissonClient redissonClient = Redisson.create(config);
//.获取锁对象实例（无法保证是按线程的顺序获取到）
RLock rLock = redissonClient.getLock(lockKey);
try {
/**
*.尝试获取锁
* waitTimeout 尝试获取锁的最大等待时间，超过这个值，则认为获取锁失败
* leaseTime 锁的持有时间,超过这个时间锁会自动失效（值应设置为大于业务处理的时间，确保在锁有效期内业务能处理完）
*/ boolean res = rLock.tryLock((long)waitTimeout, (long)leaseTime, TimeUnit.SECONDS);
if (res) {
//成功获得锁，在这里处理业务
}
} catch (Exception e) {
throw new RuntimeException("aquire lock fail");
}finally{
//无论如何, 最后都要解锁
rLock.unlock();
}
加锁流程图
解锁流程图
我们可以看到，RedissonLock是可重入的，并且考虑了失败重试，可以设置锁的最大等待时间， 在实现上也做了一些优化，减少了无效的锁申请，提升了资源的利用率。
需要特别注意的是，RedissonLock 同样没有解决 节点挂掉的时候，存在丢失锁的风险的问题。而现实情况是有一些场景无法容忍的，所以 Redisson 提供了实现了redlock算法的 RedissonRedLock，RedissonRedLock 真正解决了单点失败的问题，代价是需要额外的为 RedissonRedLock 搭建Redis环境。
所以，如果业务场景可以容忍这种小概率的错误，则推荐使用 RedissonLock， 如果无法容忍，则推荐使用 RedissonRedLock。
6.单例模式有几种写法？
“你知道茴香豆的‘茴’字有几种写法吗？”
纠结单例模式有几种写法有用吗？有点用，面试中经常选择其中一种或几种写法作为话头，考查设计模式和coding style的同时，还很容易扩展到其他问题。
这里讲解几种笔者常用的写法，但切忌生搬硬套，去记“茴香豆的写法”。编程最大的乐趣在于“know everything, control everything”。
JDK版本：oracle java 1.8.0_102
大体可分为4类，下面分别介绍他们的基本形式、变种及特点。
饱汉模式
饱汉是变种最多的单例模式。我们从饱汉出发，通过其变种逐渐了解实现单例模式时需要关注的问题。
基础的饱汉
饱汉，即已经吃饱，不着急再吃，饿的时候再吃。所以他就先不初始化单例，等第一次使用的时候再初始化，即“懒加载”。
// 饱汉
// UnThreadSafe
public class Singleton {
private static Singleton singleton = null;
private Singleton() {
}
public static Singleton getInstance() {
if (singleton == null) {
singleton = new Singleton();
}
return singleton;
}
}
饱汉模式的核心就是懒加载。好处是更启动速度快、节省资源，一直到实例被第一次访问，才需要初始化单例；小坏处是写起来麻烦，大坏处是线程不安全，if语句存在竞态条件。
写起来麻烦不是大问题，可读性好啊。因此，单线程环境下，基础饱汉是笔者最喜欢的写法。但多线程环境下，基础饱汉就彻底不可用了。下面的几种变种都在试图解决基础饱汉线程不安全的问题。
饱汉 – 变种 1
最粗暴的犯法是用synchronized关键字修饰getInstance()方法，这样能达到绝对的线程安全。
// 饱汉
// ThreadSafe
public class Singleton_1 {
private static Singleton_1 singleton = null;
private Singleton_1() {
}
public synchronized static Singleton_1 getInstance() {
if (singleton == null) {
singleton = new Singleton_1();
}
return singleton;
}
}
变种1的好处是写起来简单，且绝对线程安全；坏处是并发性能极差，事实上完全退化到了串行。单例只需要初始化一次，但就算初始化以后，synchronized的锁也无法避开，从而getInstance()完全变成了串行操作。性能不敏感的场景建议使用。
饱汉 – 变种 2
变种2是“臭名昭著”的DCL 1.0。
针对变种1中单例初始化后锁仍然无法避开的问题，变种2在变种1的外层又套了一层check，加上synchronized内层的check，即所谓“双重检查锁”（Double Check Lock，简称DCL）。
// 饱汉
// UnThreadSafe
public class Singleton_2 {
private static Singleton_2 singleton = null;
public int f = 1; // 触发部分初始化问题
public int f = 2;
private Singleton_2() {
}
public static Singleton_2 getInstance() {
// may get half object
if (singleton == null) {
synchronized (Singleton_2.class) {
if (singleton == null) {
singleton = new Singleton_2();
}
}
}
return singleton;
}
}
变种2的核心是DCL，看起来变种2似乎已经达到了理想的效果：懒加载+线程安全。可惜的是，正如注释中所说，DCL仍然是线程不安全的，由于指令重排序，你可能会得到“半个对象”，即”部分初始化“问题。
饱汉 – 变种 3
变种3专门针对变种2，可谓DCL 2.0。
针对变种3的“半个对象”问题，变种3在instance上增加了volatile关键字，原理见上述参考。
// 饱汉
// ThreadSafe
public class Singleton_3 {
private static volatile Singleton_3 singleton = null;
public int f = 1; // 触发部分初始化问题
public int f = 2;
private Singleton_3() {
}
public static Singleton_3 getInstance() {
if (singleton == null) {
synchronized (Singleton_3.class) {
// must be a complete instance
if (singleton == null) {
singleton = new Singleton_3();
}
}
}
return singleton;
}
}
多线程环境下，变种3更适用于性能敏感的场景。但后面我们将了解到，就算是线程安全的，还有一些办法能破坏单例。
当然，还有很多方式，能通过与volatile类似的方式防止部分初始化。读者可自行阅读内存屏障相关内容，但面试时不建议主动装B。
饿汉模式
与饱汉相对，饿汉很饿，只想着尽早吃到。所以他就在最早的时机，即类加载时初始化单例，以后访问时直接返回即可。
// 饿汉
// ThreadSafe
public class Singleton {
private static final Singleton singleton = new Singleton2();
private Singleton() {
}
public static Singleton getInstance() {
return singleton;
}
}
饿汉的好处是天生的线程安全（得益于类加载机制），写起来超级简单，使用时没有延迟；坏处是有可能造成资源浪费（如果类加载后就一直不使用单例的话）。
值得注意的时，单线程环境下，饿汉与饱汉在性能上没什么差别；但多线程环境下，由于饱汉需要加锁，饿汉的性能反而更优。
Holder模式
我们既希望利用饿汉模式中静态变量的方便和线程安全；又希望通过懒加载规避资源浪费。Holder模式满足了这两点要求：核心仍然是静态变量，足够方便和线程安全；通过静态的Holder类持有真正实例，间接实现了懒加载。
// Holder模式
// ThreadSafe
public class Singleton {
private static class SingletonHolder {
private static final Singleton singleton = new Singleton3();
private SingletonHolder() {
}
}
private Singleton() {
}
/**
* 勘误：多写了个synchronized。。
public synchronized static Singleton getInstance() {
return SingletonHolder.singleton;
}
*/ public static Singleton getInstance() {
return SingletonHolder.singleton;
}
}
相对于饿汉模式，Holder模式仅增加了一个静态内部类的成本，与饱汉的变种3效果相当（略优），都是比较受欢迎的实现方式。同样建议考虑。
枚举模式
用枚举实现单例模式，相当好用，但可读性是不存在的。
基础的枚举
将枚举的静态成员变量作为单例的实例：
// 枚举
// ThreadSafe
public enum Singleton {
SINGLETON;
}
代码量比饿汉模式更少。但用户只能直接访问实例Singleton4.SINGLETON——事实上，这样的访问方式作为单例使用也是恰当的，只是牺牲了静态工厂方法的优点，如无法实现懒加载。
丑陋但好用的语法糖
Java的枚举是一个“丑陋但好用的语法糖”。
枚举型单例模式的本质
通过反编译打开语法糖，就看到了枚举类型的本质，简化如下：
// 枚举
// ThreadSafe
public class Singleton extends Enum<Singleton4> {
...
public static final Singleton SINGLETON = new Singleton4();
...
}
本质上和饿汉模式相同，区别仅在于公有的静态成员变量。
用枚举实现一些trick
这一部分与单例没什么关系，可以跳过。如果选择阅读也请认清这样的事实：虽然枚举相当灵活，但如何恰当的使用枚举有一定难度。一个足够简单的典型例子是TimeUnit类，建议有时间耐心阅读。
上面已经看到，枚举型单例的本质仍然是一个普通的类。实际上，我们可以在枚举型型单例上增加任何普通类可以完成的功能。要点在于枚举实例的初始化，可以理解为实例化了一个匿名内部类。为了更明显，我们在Singleton4_1中定义一个普通的私有成员变量，一个普通的公有成员方法，和一个公有的抽象成员方法，如下：
// 枚举
// ThreadSafe
public enum Singleton_1 {
SINGLETON("enum is the easiest singleton pattern, but not the most readable") {
public void testAbsMethod() {
print();
System.out.println("enum is ugly, but so flexible to make lots of trick");
}
};
private String comment = null;
Singleton_1(String comment) {
this.comment = comment;
}
public void print() {
System.out.println("comment=" + comment);
}
abstract public void testAbsMethod();
public static Singleton_1 getInstance() {
return SINGLETON;
}
}
这样，枚举类Singleton4_1中的每一个枚举实例不仅继承了父类Singleton4_1的成员方法print()，还必须实现父类Singleton4_1的抽象成员方法testAbsMethod()。
总结
上面的分析都忽略了反射和序列化的问题。通过反射或序列化，我们仍然能够访问到私有构造器，创建新的实例破坏单例模式。此时，只有枚举模式能天然防范这一问题。反射和序列化笔者还不太了解，但基本原理并不难，可以在其他模式上手动实现。
下面继续忽略反射和序列化的问题，做个总结回味一下：
单例模式是面试中的常考点，写起来非常简单。
7.消息队列中，如何保证消息的顺序性？
问：如何保证消息的顺序性？
面试官心理分析
其实这个也是用 MQ 的时候必问的话题，第一看看你了不了解顺序这个事儿？第二看看你有没有办法保证消息是有顺序的？这是生产系统中常见的问题。
面试题剖析
我举个例子，我们以前做过一个 mysql binlog 同步的系统，压力还是非常大的，日同步数据要达到上亿，就是说数据从一个 mysql 库原封不动地同步到另一个 mysql 库里面去（mysql -> mysql）。常见的一点在于说比如大数据 team，就需要同步一个 mysql 库过来，对公司的业务系统的数据做各种复杂的操作。
你在 mysql 里增删改一条数据，对应出来了增删改 3 条 binlog 日志，接着这三条 binlog 发送到 MQ 里面，再消费出来依次执行，起码得保证人家是按照顺序来的吧？不然本来是：增加、修改、删除；你楞是换了顺序给执行成删除、修改、增加，不全错了么。
本来这个数据同步过来，应该最后这个数据被删除了；结果你搞错了这个顺序，最后这个数据保留下来了，数据同步就出错了。
先看看顺序会错乱的俩场景：
- RabbitMQ ：一个 queue，多个 consumer。比如，生产者向 RabbitMQ 里发送了三条数据，顺序依次是 data1/data2/data3，压入的是 RabbitMQ 的一个内存队列。有三个消费者分别从 MQ 中消费这三条数据中的一条，结果消费者2先执行完操作，把 data2 存入数据库，然后是 data1/data3。这不明显乱了。
- Kafka ：比如说我们建了一个 topic，有三个 partition。生产者在写的时候，其实可以指定一个 key，比如说我们指定了某个订单 id 作为 key，那么这个订单相关的数据，一定会被分发到同一个 partition 中去，而且这个 partition 中的数据一定是有顺序的。消费者从 partition 中取出来数据的时候，也一定是有顺序的。到这里，顺序还是 ok 的，没有错乱。接着，我们在消费者里可能会搞 多个线程来并发处理消息 。因为如果消费者是单线程消费处理，而处理比较耗时的话，比如处理一条消息耗时几十 ms，那么 1 秒钟只能处理几十条消息，这吞吐量太低了。而多个线程并发跑的话，顺序可能就乱掉了。
解决方案
RabbitMQ
拆分多个 queue，每个 queue 一个 consumer，就是多一些 queue 而已，确实是麻烦点；或者就一个 queue 但是对应一个 consumer，然后这个 consumer 内部用内存队列做排队，然后分发给底层不同的 worker 来处理。
Kafka
- 一个 topic，一个 partition，一个 consumer，内部单线程消费，单线程吞吐量太低，一般不会用这个。
- 写 N 个内存 queue，具有相同 key 的数据都到同一个内存 queue；然后对于 N 个线程，每个线程分别消费一个内存 queue 即可，这样就能保证顺序性。
8.你能说说Spring框架中Bean的生命周期吗？
1、实例化一个Bean－－也就是我们常说的new；
2、按照Spring上下文对实例化的Bean进行配置－－也就是IOC注入；
3、如果这个Bean已经实现了BeanNameAware接口，会调用它实现的setBeanName(String)方法，此处传递的就是Spring配置文件中Bean的id值
4、如果这个Bean已经实现了BeanFactoryAware接口，会调用它实现的setBeanFactory(setBeanFactory(BeanFactory)传递的是Spring工厂自身（可以用这个方式来获取其它Bean，只需在Spring配置文件中配置一个普通的Bean就可以）；
5、如果这个Bean已经实现了ApplicationContextAware接口，会调用setApplicationContext(ApplicationContext)方法，传入Spring上下文（同样这个方式也可以实现步骤4的内容，但比4更好，因为ApplicationContext是BeanFactory的子接口，有更多的实现方法）；
6、如果这个Bean关联了BeanPostProcessor接口，将会调用postProcessBeforeInitialization(Object obj, String s)方法，BeanPostProcessor经常被用作是Bean内容的更改，并且由于这个是在Bean初始化结束时调用那个的方法，也可以被应用于内存或缓存技术；
7、如果Bean在Spring配置文件中配置了init-method属性会自动调用其配置的初始化方法。
8、如果这个Bean关联了BeanPostProcessor接口，将会调用postProcessAfterInitialization(Object obj, String s)方法、；
注：以上工作完成以后就可以应用这个Bean了，那这个Bean是一个Singleton的，所以一般情况下我们调用同一个id的Bean会是在内容地址相同的实例，当然在Spring配置文件中也可以配置非Singleton，这里我们不做赘述。
9、当Bean不再需要时，会经过清理阶段，如果Bean实现了DisposableBean这个接口，会调用那个其实现的destroy()方法；
10、最后，如果这个Bean的Spring配置中配置了destroy-method属性，会自动调用其配置的销毁方法。
结合代码理解一下
1、Bean的定义
Spring通常通过配置文件定义Bean。如：
<?xml version=”.0″ encoding=”UTF-8″?>
<beans xmlns=””
xmlns:xsi=””
xsi:schemaLocation=” ”>
<bean id=”HelloWorld” class=”com.pqf.beans.HelloWorld”>
<property name=”msg”>
<value>HelloWorld</value>
</property>
</bean>
</beans>
这个配置文件就定义了一个标识为 HelloWorld 的Bean。在一个配置文档中可以定义多个Bean。
2、Bean的初始化
有两种方式初始化Bean。
1、在配置文档中通过指定init-method 属性来完成
在Bean的类中实现一个初始化Bean属性的方法，如init()，如：
public class HelloWorld{
public String msg=null;
public Date date=null;
public void init() {
msg=”HelloWorld”;
date=new Date();
}
……
}
然后，在配置文件中设置init-mothod属性：
2、实现 org.springframwork.beans.factory.InitializingBean接口
Bean实现InitializingBean接口，并且增加 afterPropertiesSet() 方法：
public class HelloWorld implement InitializingBean {
public String msg=null;
public Date date=null;
public void afterPropertiesSet() {
msg="向全世界问好！";
date=new Date();
}
……
}
那么，当这个Bean的所有属性被Spring的BeanFactory设置完后，会自动调用afterPropertiesSet()方法对Bean进行初始化，于是，配置文件就不用指定 init-method属性了。
3、Bean的调用
有三种方式可以得到Bean并进行调用：
1、使用BeanWrapper
HelloWorld hw=new HelloWorld();
BeanWrapper bw=new BeanWrapperImpl(hw);
bw.setPropertyvalue(”msg”,”HelloWorld”);
system.out.println(bw.getPropertyCalue(”msg”));
2、使用BeanFactory
InputStream is=new FileInputStream(”config.xml”);
XmlBeanFactory factory=new XmlBeanFactory(is);
HelloWorld hw=(HelloWorld) factory.getBean(”HelloWorld”);
system.out.println(hw.getMsg());
3、使用ApplicationConttext
ApplicationContext actx=new FleSystemXmlApplicationContext(”config.xml”);
HelloWorld hw=(HelloWorld) actx.getBean(”HelloWorld”);
System.out.println(hw.getMsg());
4、Bean的销毁
1、使用配置文件中的 destory-method 属性
与初始化属性 init-methods类似，在Bean的类中实现一个撤销Bean的方法，然后在配置文件中通过 destory-method指定，那么当bean销毁时，Spring将自动调用指定的销毁方法。
2、实现 org.springframwork.bean.factory.DisposebleBean接口
如果实现了DisposebleBean接口，那么Spring将自动调用bean中的Destory方法进行销毁，所以，Bean中必须提供Destory方法。
图解
9.Spring，SpringMVC，SpringBoot，SpringCloud有什么区别和联系？
Spring是一个轻量级的控制反转(IoC)和面向切面(AOP)的容器框架。Spring使你能够编写更干净、更可管理、并且更易于测试的代码。
Spring MVC是Spring的一个模块，一个web框架。通过Dispatcher Servlet, ModelAndView 和 View Resolver，开发web应用变得很容易。主要针对的是网站应用程序或者服务开发——URL路由、Session、模板引擎、静态Web资源等等。
Spring配置复杂，繁琐，所以推出了Spring boot，约定优于配置，简化了spring的配置流程。
Spring Cloud构建于Spring Boot之上，是一个关注全局的服务治理框架。
Spring VS SpringMVC：
Spring是一个一站式的轻量级的java开发框架，核心是控制反转（IOC）和面向切面（AOP），针对于开发的WEB层(springMvc)、业务层(Ioc)、持久层(jdbcTemplate)等都提供了多种配置解决方案；
SpringMVC是Spring基础之上的一个MVC框架，主要处理web开发的路径映射和视图渲染，属于Spring框架中WEB层开发的一部分；
SpringMVC VS SpringBoot：
SpringMVC属于一个企业WEB开发的MVC框架，涵盖面包括前端视图开发、文件配置、后台接口逻辑开发等，XML、config等配置相对比较繁琐复杂；
SpringBoot框架相对于SpringMVC框架来说，更专注于开发微服务后台接口，不开发前端视图；
SpringBoot和SpringCloud：
SpringBoot使用了默认大于配置的理念，集成了快速开发的Spring多个插件，同时自动过滤不需要配置的多余的插件，简化了项目的开发配置流程，一定程度上取消xml配置，是一套快速配置开发的脚手架，能快速开发单个微服务；
SpringCloud大部分的功能插件都是基于SpringBoot去实现的，SpringCloud关注于全局的微服务整合和管理，将多个SpringBoot单体微服务进行整合以及管理；SpringCloud依赖于SpringBoot开发，而SpringBoot可以独立开发；
总结下来：
- Spring是核心，提供了基础功能；
- Spring MVC 是基于Spring的一个 MVC 框架 ；
- Spring Boot 是为简化Spring配置的快速开发整合包；
- Spring Cloud是构建在Spring Boot之上的服务治理框架。
10.分布式系统接口，如何避免表单的重复提交？
关于怎么实现承载更多用户量的系统，一直是我重点关注的一个技术方向。改造架构提高承载力，通常来讲分为两个大方向，互相配合实现。
硬件架构改进， 主要是使用阿里云这种多组件的云环境：通过负载均衡SLB，模版克隆的云服务器ECS，云数据库RDS，共享对象存储OSS等不同职责的云产品组合实现。
软件架构优化， 主要是软件代码开发的规范：业务解耦合，架构微服务，单机无状态化，文件存储共享等
在分布式系统的学习途中也不断见识新的知识点，今天要说的就是软件开发时候对于接口服务的“幂等性”实现！
幂等性
效果： 系统对某接口的多次请求，都应该返回同样的结果！（网络访问失败的场景除外）
目的： 避免因为各种原因，重复请求导致的业务重复处理
重复请求场景案例：
1，客户端第一次请求后，网络异常导致收到请求执行逻辑但是没有返回给客户端，客户端的重新发起请求
2，客户端迅速点击按钮提交，导致同一逻辑被多次发送到服务器
简单来划分，业务逻辑无非都可以归纳为增删改查！
对于查询 ，内部不包含其他操作，属于只读性质的那种业务必然符合幂等性要求的。
对于删除 ，重复做删除请求至少不会造成数据杂乱，不过也有些场景更希望重复点击提示的是删除成功，而不是目标不存在的提示。
对于新增和修改 ，这里是今天要重点关注的部分：新增，需要避免重复插入；修改，避免进行无效的重复修改；
幂等性的实现方式
实现方法： 客户端做某一请求的时候带上识别参数标识，服务端对此标识进行识别，重复请求则重复返回第一次的结果即可。
举个栗子： 比如添加请求的表单里，在打开添加表单页面的时候，就生成一个AddId标识，这个AddId跟着表单一起提交到后台接口。
后台接口根据这个AddId，服务端就可以进行缓存标记并进行过滤，缓存值可以是AddId作为缓存key，返回内容作为缓存Value，这样即使添加按钮被多次点下也可以识别出来。
这个AddId什么时候更新呢？只有在保存成功并且清空表单之后，才变更这个AddId标识，从而实现新数据的表单提交