面试890

面·890试题记忆大作战

3.1 基础

1 Java有哪些数据类型？

Java 语言的数据类型分为两种：基本数据类型和引用数据类型。

1.基本数据类型包括 boolean（布尔型）、float（单精度浮点型）、char（字符型）、byte（字节型）、short（短整型）、int（整型）、long（长整型）和 double （双精度浮点型）共 8 种，如下表所示。

2.引用数据类型建立在基本数据类型的基础上，包括数组、类和接口。引用数据类型是由用户自定义，用来限制其他数据的类型。

2 final、finally、finalize的区别？

final 用于修饰变量、方法和类。

• final 变量：被修饰的变量不可变，不可变分为引用不可变和对象不可变，final 指的是引用不可变，final 修饰的变量必须初始化，通常称被修饰的变量为常量。
• final 方法：被修饰的方法不允许任何子类重写，子类可以使用该方法。
• final 类：被修饰的类不能被继承，所有方法不能被重写。

finally 作为异常处理的一部分，它只能在 try/catch 语句中，并且附带一个语句块表示这段语句最终一定被执行（无论是否抛出异常），经常被用在需要释放资源的情况下，System.exit (0) 可以阻断 finally 执行。

finalize 是在 java.lang.Object 里定义的方法，也就是说每一个对象都有这么个方法，这个方法在 gc 启动，该对象被回收的时候被调用。

3 重载（Overload）和重写（Override）的区别是什么？

方法的重载和重写都是实现多态的方式，区别在于前者实现的是编译时的多态性，而后者实现的是运行时的多态性。

• 重写发生在子类与父类之间, 重写方法返回值和形参都不能改变，与访问修饰符无关。即外壳不变，核心重写！
• 重载(overloading) 是在一个类里面，方法名字相同，而参数不同。返回类型可以相同也可以不同。每个重载的方法（或者构造函数）都必须有一个独一无二的参数类型列表。最常用的地方就是构造器的重载。

4 String,StringBuffer, StringBuilder 的区别是什么？

1.可变与不可变。String类中使用字符数组保存字符串，因为有“final”修饰符，所以string对象是不可变的。对于已经存在的String对象的修改都是重新创建一个新的对象,然后把新的值保存进去.

2.是否多线程安全。

String中的对象是不可变的，也就可以理解为常量，显然线程安全。

StringBuilder是非线程安全的。

StringBuffer对方法加了同步锁或者对调用的方法加了同步锁，所以是线程安全的。

3.性能

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

5、String为什么要设计成不可变的？

1.便于实现字符串池（String pool）

2.使多线程安全

3.避免安全问题

4.加快字符串处理速度

6、在使用 HashMap 的时候，用 String 做 key 有什么好处？

HashMap 内部实现是通过 key 的 hashcode 来确定 value 的存储位置，因为字符串是不可变的，所以当创建字符串时，它的 hashcode 被缓存下来，不需要再次计算，所以相比于其他对象更快。

7、包装类型是什么？

Java 为每一个基本数据类型都引入了对应的包装类型（wrapper class），int 的包装类就是 Integer，从 Java 5 开始引入了自动装箱/拆箱机制，把基本类型转换成包装类型的过程叫做装箱（boxing）；反之，把包装类型转换成基本类型的过程叫做拆箱（unboxing），使得二者可以相互转换。

Java 为每个原始类型提供了包装类型：

原始类型: boolean=false，char=，byte，short，int，long，float，double

包装类型：Boolean，Character，Byte，Short，Integer，Long，Float，Double

8、基本类型和包装类型有什么区别？

包装类型可以为 null，而基本类型不可以。

包装类型可用于泛型，而基本类型不可以。

基本类型比包装类型更高效。

9、什么是反射？

反射是在运行状态中，对于任意一个类，都能够知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意一个方法和属性；这种动态获取的信息以及动态调用对象的方法的功能称为 Java 语言的反射机制。

3.2 集合

1. 常见的集合有哪些？

Java集合类主要由两个根接口Collection和Map派生出来的，Collection派生出了三个子接口：List、Set、Queue（Java5新增的队列），因此Java集合大致也可分成List、Set、Queue、Map四种接口体系。

注意：Collection是一个接口，Collections是一个工具类，Map不是Collection的子接口。

List代表了有序可重复集合，可直接根据元素的索引来访问；Set代表无序不可重复集合，只能根据元素本身来访问；Queue是队列集合。

Map代表的是存储key-value对的集合，可根据元素的key来访问value。

2. 线程安全的集合有哪些？线程不安全的呢？

线程安全的：

• Hashtable：比HashMap多了个线程安全。
• ConcurrentHashMap:是一种高效但是线程安全的集合。
• Vector：比Arraylist多了个同步化机制。
• Stack：栈，也是线程安全的，继承于Vector。

线程不安全的：

• HashMap
• Arraylist
• LinkedList
• HashSet
• TreeSet
• TreeMap

3. Arraylist与 LinkedList 异同点？

• 是否保证线程安全： ArrayList 和 LinkedList 都是不同步的，也就是不保证线程安全；
• 底层数据结构： Arraylist 底层使用的是Object数组；LinkedList 底层使用的是双向循环链表数据结构；
• **插入和删除是否受元素位置的影响：**ArrayList 采用数组存储，所以插入和删除元素的时间复杂度受元素位置的影响。 LinkedList 采用链表存储，所以插入，删除元素时间复杂度不受元素位置的影响，都是近似 O（1）而数组为近似 O（n）。
• 是否支持快速随机访问： LinkedList 不支持高效的随机元素访问，而ArrayList 实现了RandmoAccess 接口，所以有随机访问功能。

4. 说一说ArrayList 的扩容机制？

ArrayList扩容的本质就是计算出新的扩容数组的size后实例化，并将原有数组内容复制到新数组中去。默认情况下，新的容量会是原容量的1.5倍。

5. Array 和 ArrayList 有什么区别？什么时候该应 Array 而不是 ArrayList 呢？

• Array 可以包含基本类型和对象类型，ArrayList 只能包含对象类型。
• Array 大小是固定的，ArrayList 的大小是动态变化的。
• ArrayList 提供了更多的方法和特性，比如：addAll()，removeAll()，iterator() 等等。

6. HashMap的底层数据结构是什么？

在JDK1.7 和JDK1.8 中有所差别：

在JDK1.7 中，由“数组+链表”组成，数组是 HashMap 的主体，链表则是主要为了解决哈希冲突而存在的。

在JDK1.8 中，由“数组+链表+红黑树”组成。当链表过长，则会严重影响 HashMap 的性能，红黑树搜索时间复杂度是 O(logn)，而链表是糟糕的 O(n)。因此，JDK1.8 对数据结构做了进一步的优化，引入了红黑树，链表和红黑树在达到一定条件会进行转换：

• 当链表超过 8 且数据总量超过 64 才会转红黑树。
• 将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容，而不是转换为红黑树，以减少搜索时间。

7. HashMap为什么线程不安全？

• 多线程下扩容死循环。JDK1.7中的 HashMap 使用头插法插入元素，在多线程的环境下，扩容的时候有可能导致环形链表的出现，形成死循环。因此，JDK1.8使用尾插法插入元素，在扩容时会保持链表元素原本的顺序，不会出现环形链表的问题。
• 多线程的put可能导致元素的丢失。多线程同时执行 put 操作，如果计算出来的索引位置是相同的，那会造成前一个 key 被后一个 key 覆盖，从而导致元素的丢失。此问题在JDK 1.7和 JDK 1.8 中都存在。
• put和get并发时，可能导致get为null。线程1执行put时，因为元素个数超出threshold而导致rehash，线程2此时执行get，有可能导致这个问题。此问题在JDK 1.7和 JDK 1.8 中都存在。

8. ConcurrentHashMap 的实现原理是什么？

ConcurrentHashMap是线程安全的Map集合，属于JUC下。

ConcurrentHashMap 在 JDK1.7 和 JDK1.8 的实现方式是不同的。

先来看下JDK1.7

JDK1.7中的ConcurrentHashMap 是由 Segment 数组结构和 HashEntry 数组结构组成，即ConcurrentHashMap 把哈希桶切分成小数组（Segment ），每个小数组有 n 个 HashEntry 组成。

其中，Segment 继承了 ReentrantLock，所以 Segment 是一种可重入锁，扮演锁的角色；HashEntry 用于存储键值对数据。

再来看下JDK1.8

在数据结构上， JDK1.8 中的ConcurrentHashMap 选择了与 HashMap 相同的数组+链表+红黑树结构；在锁的实现上，抛弃了原有的 Segment 分段锁，采用CAS + synchronized实现更加低粒度的锁。

将锁的级别控制在了更细粒度的哈希桶元素级别，也就是说只需要锁住这个链表头结点（红黑树的根节点），就不会影响其他的哈希桶元素的读写，大大提高了并发度。

9. JDK1.7与JDK1.8 中ConcurrentHashMap 的区别？

• 数据结构：取消了Segment分段锁的数据结构，取而代之的是数组+链表+红黑树的结构。
• 保证线程安全机制：JDK1.7采用Segment的分段锁机制实现线程安全，其中segment继承自ReentrantLock。JDK1.8 采用CAS+Synchronized保证线程安全。
• 锁的粒度：原来是对需要进行数据操作的Segment加锁，现调整为对每个数组元素加锁（Node）。
• 链表转化为红黑树:定位结点的hash算法简化会带来弊端,Hash冲突加剧,因此在链表节点数量大于8时，会将链表转化为红黑树进行存储。
• 查询时间复杂度：从原来的遍历链表O(n)，变成遍历红黑树O(logN)。

10. ConcurrentHashMap 和Hashtable的效率哪个更高？为什么？

ConcurrentHashMap 的效率要高于Hashtable，因为Hashtable给整个哈希表加了一把大锁从而实现线程安全。而ConcurrentHashMap 的锁粒度更低，在JDK1.7中采用分段锁实现线程安全，在JDK1.8 中采用CAS+Synchronized实现线程安全。

11. HashSet 和 HashMap 区别?

HashSet的底层其实就是HashMap，只不过我们HashSet是实现了Set接口并且把数据作为K值，而V值一直使用一个相同的虚值来保存。

12 HashMap多线程下扩容死循环

​ JDK1.7中的 HashMap 使用头插法插入元素，在多线程的环境下，扩容的时候有可能导致环形链表的出现，形成死循环。因此，JDK1.8使用尾插法插入元素，在扩容时会保持链表元素原本的顺序，不会出现环形链表的问题

3.3 Java并发相关

1. 创建线程的三种方式的对比？

1）采用实现Runnable. Callable接口的方式创建多线程。

优势是：

线程类只是实现了Runnable接口或Callable接口，还可以继承其他类。

在这种方式下，多个线程可以共享同一个target对象，所以非常适合多个相同线程来处理同一份资源的情况，从而可以将CPU. 代码和数据分开，形成清晰的模型，较好地体现了面向对象的思想。

劣势是：

编程稍微复杂，如果要访问当前线程，则必须使用Thread.currentThread()方法。

2）使用继承Thread类的方式创建多线程

优势是：

编写简单，如果需要访问当前线程，则无需使用Thread.currentThread()方法，直接使用this即可获得当前线程。

劣势是：

线程类已经继承了Thread类，所以不能再继承其他父类。

3）Runnable和Callable的区别

• Callable规定（重写）的方法是call()，Runnable规定（重写）的方法是run()。
• Callable的任务执行后可返回值，而Runnable的任务是不能返回值的。
• Call方法可以抛出异常，run方法不可以。
• 运行Callable任务可以拿到一个Future对象，表示异步计算的结果。它提供了检查计算是否完成的方法，以等待计算的完成，并检索计算的结果。通过Future对象可以了解任务执行情况，可取消任务的执行，还可获取执行结果。

2. 线程的状态流转

线程的生命周期及五种基本状态：

Java线程具有五中基本状态

1）新建状态（New）：当线程对象对创建后，即进入了新建状态，如：Thread t = new MyThread();

2）就绪状态（Runnable）：当调用线程对象的start()方法（t.start();），线程即进入就绪状态。处于就绪状态的线程，只是说明此线程已经做好了准备，随时等待CPU调度执行，并不是说执行了t.start()此线程立即就会执行；

3）运行状态（Running）：当CPU开始调度处于就绪状态的线程时，此时线程才得以真正执行，即进入到运行状态。注：就 绪状态是进入到运行状态的唯一入口，也就是说，线程要想进入运行状态执行，首先必须处于就绪状态中；

4）阻塞状态（Blocked）：处于运行状态中的线程由于某种原因，暂时放弃对CPU的使用权，停止执行，此时进入阻塞状态，直到其进入到就绪状态，才 有机会再次被CPU调用以进入到运行状态。根据阻塞产生的原因不同，阻塞状态又可以分为三种：

1.等待阻塞：运行状态中的线程执行wait()方法，使本线程进入到等待阻塞状态；

2.同步阻塞 — 线程在获取synchronized同步锁失败(因为锁被其它线程所占用)，它会进入同步阻塞状态；

3.其他阻塞 — 通过调用线程的sleep()或join()或发出了I/O请求时，线程会进入到阻塞状态。当sleep()状态超时. join()等待线程终止或者超时. 或者I/O处理完毕时，线程重新转入就绪状态。

5）死亡状态（Dead）：线程执行完了或者因异常退出了run()方法，该线程结束生命周期。

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

死锁

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

死锁必须具备以下四个条件：

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

如何避免线程死锁?

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

• 破坏互斥条件 这个条件我们没有办法破坏，因为我们用锁本来就是想让他们互斥的（临界资源需要互斥访问）
• 破坏请求与保持条件 一次性申请所有的资源。
• 破坏不剥夺条件 占用部分资源的线程进一步申请其他资源时，如果申请不到，可以主动释放它占有的资源。
• 破坏循环等待条件 靠按序申请资源来预防。按某一顺序申请资源，释放资源则反序释放。破坏循环等待条件。
• 锁排序法：（必须回答出来的点） 指定获取锁的顺序，比如某个线程只有获得A锁和B锁，才能对某资源进行操作，在多线程条件下，如何避免死锁？ 通过指定锁的获取顺序，比如规定，只有获得A锁的线程才有资格获取B锁，按顺序获取锁就可以避免死锁。这通常被认为是解决死锁很好的一种方法。
• 使用显式锁中的ReentrantLock.try(long,TimeUnit)来申请锁

4. CAS了解吗？

• CAS：全称 Compare and swap，即比较并交换，它是一条 CPU 同步原语。是一种硬件对并发的支持，针对多处理器操作而设计的一种特殊指令，用于管理对共享数据的并发访问。
• CAS 是一种无锁的非阻塞算法的实现。
• CAS 包含了 3 个操作数：
• • 需要读写的内存值 V
  • 旧的预期值 A
  • 要修改的更新值 B
• 当且仅当 V 的值等于 A 时，CAS 通过原子方式用新值 B 来更新 V 的 值，否则不会执行任何操作（他的功能是判断内存某个位置的值是否为预期值，如果是则更改为新的值，这个过程是原子的。）

CAS 并发原语体现在 Java 语言中的 sum.misc.Unsafe 类中的各个方法。调用 Unsafe 类中的 CAS 方法， JVM 会帮助我们实现出 CAS 汇编指令。这是一种完全依赖于硬件的功能，通过它实现了原子操作。再次强调，由于 CAS是一种系统原语，原语属于操作系统用于范畴，是由若干条指令组成的，用于完成某个功能的一个过程，并且原语的执行必须是连续的，在执行过程中不允许被中断，CAS 是一条 CPU 的原子指令，不会造成数据不一致问题。

5. CAS有什么缺陷？

1. ABA 问题

并发环境下，假设初始条件是A，去修改数据时，发现是A就会执行修改。但是看到的虽然是A，中间可能发生了A变B，B又变回A的情况。此时A已经非彼A，数据即使成功修改，也可能有问题。

可以通过AtomicStampedReference解决ABA问题，它，一个带有标记的原子引用类，通过控制变量值的版本来保证CAS的正确性。

2. 循环时间长开销

自旋CAS，如果一直循环执行，一直不成功，会给CPU带来非常大的执行开销。

很多时候，CAS思想体现，是有个自旋次数的，就是为了避开这个耗时问题~

3. 只能保证一个变量的原子操作。

CAS 保证的是对一个变量执行操作的原子性，如果对多个变量操作时，CAS 目前无法直接保证操作的原子性的。

可以通过这两个方式解决这个问题：

• 使用互斥锁来保证原子性；
• 将多个变量封装成对象，通过AtomicReference来保证原子性。

6. synchronized 和 Lock 有什么区别？

• synchronized 可以给类. 方法. 代码块加锁；而 lock 只能给代码块加锁。
• synchronized 不需要手动获取锁和释放锁，使用简单，发生异常会自动释放锁，不会造成死锁；而 lock 需要自己加锁和释放锁，如果使用不当没有 unLock()去释放锁就会造成死锁。
• 通过 Lock 可以知道有没有成功获取锁，而 synchronized 却无法办到。

7. synchronized的用法有哪些?

• 修饰普通方法:作用于当前对象实例，进入同步代码前要获得当前对象实例的锁
• 修饰静态方法:作用于当前类，进入同步代码前要获得当前类对象的锁,synchronized 关键字加到 static 静态方法和 synchronized(class)代码块上都是是给 Class 类上锁
• 修饰代码块:指定加锁对象，对给定对象加锁，进入同步代码库前要获得给定对象的锁

特别注意：

①如果一个线程A调用一个实例对象的非静态 synchronized 方法，而线程B需要调用这个实例对象所属类的静态 synchronized 方法，是允许的，不会发生互斥现象，因为访问静态 synchronized 方法占用的锁是当前类的锁

②尽量不要使用 synchronized(String s) ,因为JVM中，字符串常量池具有缓冲功能

8. ThreadLocal是什么?

ThreadLocal，即线程本地变量。如果你创建了一个ThreadLocal变量，那么访问这个变量的每个线程都会有这个变量的一个本地拷贝，多个线程操作这个变量的时候，实际是操作自己本地内存里面的变量，从而起到线程隔离的作用，避免了线程安全问题。

存在的问题：内存泄漏（弱引用），避免：使用之后，记得remove

//创建一个ThreadLocal变量
static ThreadLocal<String> localVariable = new ThreadLocal<>();

ThreadLocal的应用场景有

• 数据库连接池
• 会话管理中使用

9. 你说下线程池核心参数？

• corePoolSize ： 核心线程大小。线程池一直运行，核心线程就不会停止。

• maximumPoolSize ：线程池最大线程数量。非核心线程数量=maximumPoolSize-corePoolSize

• keepAliveTime ：非核心线程的心跳时间。如果非核心线程在keepAliveTime内没有运行任务，非核心线程会消亡。

• workQueue ：阻塞队列。ArrayBlockingQueue，LinkedBlockingQueue等，用来存放线程任务。

• defaultHandler ：饱和策略(拒绝策略)。ThreadPoolExecutor类中一共有4种饱和策略。通过实现

  RejectedExecutionHandler

  接口。

  • AbortPolicy ： 线程任务丢弃报错。默认饱和策略。
  • DiscardPolicy ： 线程任务直接丢弃不报错。
  • DiscardOldestPolicy ： 将workQueue队首任务丢弃，将最新线程任务重新加入队列执行。
  • CallerRunsPolicy ：线程池之外的线程直接调用run方法执行。

• ThreadFactory ：线程工厂，新建线程工厂。

10. 线程池执行任务的流程？

1. 线程池执行execute/submit方法向线程池添加任务，当任务小于核心线程数corePoolSize，线程池中可以创建新的线程。
2. 当任务大于核心线程数corePoolSize，就向阻塞队列添加任务。
3. 如果阻塞队列已满，需要通过比较参数maximumPoolSize，在线程池创建新的线程，当线程数量大于maximumPoolSize，说明当前设置线程池中线程已经处理不了了，就会执行饱和策略。

11. 常用的JAVA线程池有哪几种类型？

1、newCachedThreadPool

创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程。

这种类型的线程池特点是：

工作线程的创建数量几乎没有限制(其实也有限制的,数目为Interger. MAX_VALUE), 这样可灵活的往线程池中添加线程。

如果长时间没有往线程池中提交任务，即如果工作线程空闲了指定的时间(默认为1分钟)，则该工作线程将自动终止。终止后，如果你又提交了新的任务，则线程池重新创建一个工作线程。

在使用CachedThreadPool时，一定要注意控制任务的数量，否则，由于大量线程同时运行，很有会造成系统OOM。

2、newFixedThreadPool

创建一个指定工作线程数量的线程池。每当提交一个任务就创建一个工作线程，如果工作线程数量达到线程池初始的最大数，则将提交的任务存入到池队列中。

FixedThreadPool是一个典型且优秀的线程池，它具有线程池提高程序效率和节省创建线程时所耗的开销的优点。但是，在线程池空闲时，即线程池中没有可运行任务时，它不会释放工作线程，还会占用一定的系统资源。

3、newSingleThreadExecutor

创建一个单线程化的Executor，即只创建唯一的工作者线程来执行任务，它只会用唯一的工作线程来执行任务，保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行。如果这个线程异常结束，会有另一个取代它，保证顺序执行。单工作线程最大的特点是可保证顺序地执行各个任务，并且在任意给定的时间不会有多个线程是活动的。

4、newScheduleThreadPool

创建一个定长的线程池，而且支持定时的以及周期性的任务执行，支持定时及周期性任务执行。

3.4 JVM和GC

1. 什么是JVM内存结构？

jvm将虚拟机分为5大区域，程序计数器、虚拟机栈、本地方法栈、java堆、方法区（元空间）；

2. 什么是JVM内存模型？

Java 内存模型（下文简称 JMM）就是在底层处理器内存模型的基础上，定义自己的多线程语义。它明确指定了一组排序规则，来保证线程间的可见性。

这一组规则被称为 Happens-Before, JMM 规定，要想保证 B 操作能够看到 A 操作的结果（无论它们是否在同一个线程），那么 A 和 B 之间必须满足 Happens-Before 关系

3. 如何判断一个对象是否存活？

判断一个对象是否存活，分为两种算法1：引用计数法；2：可达性分析算法；

4. Java中的垃圾回收算法有哪些？

Java中有四种垃圾回收算法，分别是标记清除法、标记整理法、复制算法、分代收集算法；

标记清除法： 第一步：利用可达性去遍历内存，把存活对象和垃圾对象进行标记； 第二步：在遍历一遍，将所有标记的对象回收掉； 特点：效率不行，标记和清除的效率都不高；标记和清除后会产生大量的不连续的空间分片，可能会导致之后程序运行的时候需分配大对象而找不到连续分片而不得不触发一次GC；

标记整理法： 第一步：利用可达性去遍历内存，把存活对象和垃圾对象进行标记； 第二步：将所有的存活的对象向一段移动，将端边界以外的对象都回收掉； 特点：适用于存活对象多，垃圾少的情况；需要整理的过程，无空间碎片产生；

复制算法： 将内存按照容量大小分为大小相等的两块，每次只使用一块，当一块使用完了，就将还存活的对象移到另一块上，然后在把使用过的内存空间移除； 特点：不会产生空间碎片；内存使用率极低；

分代收集算法： 根据内存对象的存活周期不同，将内存划分成几块，java虚拟机一般将内存分成新生代和老生代，在新生代中，有大量对象死去和少量对象存活，所以采用复制算法，只需要付出少量存活对象的复制成本就可以完成收集；老年代中因为对象的存活率极高，没有额外的空间对他进行分配担保，所以采用标记清理或者标记整理算法进行回收；

5. JVM中一次完整的GC是什么样子的？

先描述一下Java堆内存划分。

在 Java 中，堆被划分成两个不同的区域：新生代 ( Young )、老年代 ( Old )，新生代默认占总空间的 1/3，老年代默认占 2/3。 新生代有 3 个分区：Eden、To Survivor、From Survivor，它们的默认占比是 8:1:1。

新生代的垃圾回收（又称Minor GC）后只有少量对象存活，所以选用复制算法，只需要少量的复制成本就可以完成回收。

老年代的垃圾回收（又称Major GC）通常使用“标记-清理”或“标记-整理”算法。

6. Minor GC 和 Full GC 有什么不同呢？

Minor GC：只收集新生代的GC。

Full GC: 收集整个堆，包括 新生代，老年代，永久代(在 JDK 1.8及以后，永久代被移除，换为metaspace 元空间)等所有部分的模式。

**Minor GC触发条件：**当Eden区满时，触发Minor GC。

7. 什么是类加载器，常见的类加载器有哪些？

类加载器是指：通过一个类的全限定性类名获取该类的二进制字节流叫做类加载器；类加载器分为以下四种：

• 启动类加载器（BootStrapClassLoader）：用来加载java核心类库，无法被java程序直接引用；
• 扩展类加载器（Extension ClassLoader）：用来加载java的扩展库，java的虚拟机实现会提供一个扩展库目录，该类加载器在扩展库目录里面查找并加载java类；
• 系统类加载器（AppClassLoader）：它根据java的类路径来加载类，一般来说，java应用的类都是通过它来加载的；
• 自定义类加载器：由java语言实现，继承自ClassLoader；

8. 什么是双亲委派模型？为什么需要双亲委派模型？

当一个类加载器收到一个类加载的请求，他首先不会尝试自己去加载，而是将这个请求委派给父类加载器去加载，只有父类加载器在自己的搜索范围类查找不到给类时，子加载器才会尝试自己去加载该类；

为了防止内存中出现多个相同的字节码；因为如果没有双亲委派的话，用户就可以自己定义一个java.lang.String类，那么就无法保证类的唯一性。

补充：那怎么打破双亲委派模型？

自定义类加载器，继承ClassLoader类，重写loadClass方法和findClass方法。

9. 说一下 JVM 调优的命令？

jps: JVM Process Status Tool,显示指定系统内所有的HotSpot虚拟机进程。

jstat: 用于监视虚拟机运行时状态信息的命令。

jstack: 用于生成java虚拟机当前时刻的线程快照。

jps：JVM Process Status Tool,显示指定系统内所有的HotSpot虚拟机进程。

jstat：jstat(JVM statistics Monitoring)是用于监视虚拟机运行时状态信息的命令，它可以显示出虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据。

jmap：jmap(JVM Memory Map)命令用于生成heap dump文件，如果不使用这个命令，还阔以使用-XX:+HeapDumpOnOutOfMemoryError参数来让虚拟机出现OOM的时候·自动生成dump文件。 jmap不仅能生成dump文件，还阔以查询finalize执行队列、Java堆和永久代的详细信息，如当前使用率、当前使用的是哪种收集器等。

jhat：jhat(JVM Heap Analysis Tool)命令是与jmap搭配使用，用来分析jmap生成的dump，jhat内置了一个微型的HTTP/HTML服务器，生成dump的分析结果后，可以在浏览器中查看。在此要注意，一般不会直接在服务器上进行分析，因为jhat是一个耗时并且耗费硬件资源的过程，一般把服务器生成的dump文件复制到本地或其他机器上进行分析。

jstack：jstack用于生成java虚拟机当前时刻的线程快照。jstack来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做什么事情，或者等待什么资源。 如果java程序崩溃生成core文件，jstack工具可以用来获得core文件的java stack和native stack的信息，从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。

3.5 数据库

1. 如何定位及优化SQL语句的性能问题？

对于低性能的SQL语句的定位，最重要也是最有效的方法就是使用执行计划，MySQL提供了explain命令来查看语句的执行计划。

大表数据查询的优化

• 优化shema、sql语句+索引；
• 第二加缓存，memcached, redis；
• 主从复制，读写分离；
• 通过分库分表的方式进行优化，主要有垂直分表和水平分表

优化查询过程中的数据访问

• 访问数据太多导致查询性能下降
• 确认MySQL服务器是否在分析大量不必要的数据行
• 查询不需要的数据。解决办法：使用limit解决
• 多表关联返回全部列。解决办法：指定列名
• 总是返回全部列。解决办法：避免使用SELECT *
• 重复查询相同的数据。解决办法：可以缓存数据，下次直接读取缓存
• 改变数据库和表的结构，修改数据表范式
• 重写SQL语句，让优化器可以以更优的方式执行查询。

优化关联查询

• 确定ON或者USING子句中是否有索引。
• 确保GROUP BY和ORDER BY只有一个表中的列，这样MySQL才有可能使用索引。

数据库结构优化 一个好的数据库设计方案对于数据库的性能往往会起到事半功倍的效果。

需要考虑数据冗余、查询和更新的速度、字段的数据类型是否合理等多方面的内容。

1. 将字段很多的表分解成多个表
2. 增加中间表
3. 增加冗余字段

2. MySQL中myisam与innodb的区别?

• InnoDB支持事物，而MyISAM不支持事物
• InnoDB支持行级锁，而MyISAM支持表级锁
• InnoDB支持MVCC, 而MyISAM不支持
• InnoDB支持外键，而MyISAM不支持
• InnoDB不支持全文索引，而MyISAM支持。

3. 事务的特性

• 原子性：
• 一致性：
• 隔离性：
• 持久性：

4. 索引是什么？

索引是表的目录，在查找内容之前可以先在目录中查找索引位置，以此快速定位查询数据。对于索引，会保存在额外的文件中。

索引是帮助MySQL高效获取数据的数据结构。

5. 索引能干什么?有什么好处？

当表中的数据量越来越大时，索引对于性能的影响愈发重要。索引能够轻易将查询性能提高好几个数量级，总的来说就是可以明显的提高查询效率。

6. 索引的种类有哪些？

1、从存储结构上来划分：BTree索引（B-Tree或B+Tree索引），Hash索引，full-index全文索引，R-Tree索引。这里所描述的是索引存储时保存的形式， 2、从应用层次来分：普通索引，唯一索引，复合索引 3、根据中数据的物理顺序与键值的逻辑（索引）顺序关系：聚集索引，非聚集索引。

平时讲的索引类型一般是指在应用层次的划分。

• 普通索引
• 复合索引
• 唯一索引

7. 为什么 MySQL 的索引要使用 B+树

B-tree：因为B树不管叶子节点还是非叶子节点，都会保存数据，这样导致在非叶子节点中能保存的指针数量变少（有些资料也称为扇出），指针少的情况下要保存大量数据，只能增加树的高度，导致IO操作变多，查询性能变低；

Hash：虽然可以快速定位，但是没有顺序，IO复杂度高。

二叉树：树的高度不均匀，不能自平衡，查找效率跟数据有关（树的高度），并且IO代价高。

红黑树：树的高度随着数据量增加而增加，IO代价高。

8. 哪些列上适合创建索引？创建索引有哪些开销？

经常需要作为条件查询的列上适合创建索引，并且该列上也必须有一定的区分度。创建索引需要维护，在插入数据的时候会重新维护各个索引树（数据页的分裂与合并），对性能造成影响

9. 索引这么多优点，为什么不对表中的每一个列创建一个索引呢？

1. 当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。
2. 索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大。
3. 创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。

10. 什么情况下不走索引（索引失效）？

1、使用!= 或者 <> 导致索引失效

2、类型不一致导致的索引失效

3、函数导致的索引失效

4、运算符导致的索引失效

5、OR引起的索引失效

6、模糊搜索导致的索引失效

7、NOT IN、NOT EXISTS导致索引失效

11. MySQL建表的约束条件有哪些？

• 主键约束（Primay Key Coustraint） 唯一性，非空性
• 唯一约束 （Unique Counstraint）唯一性，可以空，但只能有一个
• 检查约束 (Check Counstraint) 对该列数据的范围、格式的限制
• 默认约束 (Default Counstraint) 该数据的默认值
• 外键约束 (Foreign Key Counstraint) 需要建立两表间的关系并引用主表的列

12. 什么是最左匹配原则？

最左优先，以最左边的为起点任何连续的索引都能匹配上。同时遇到范围查询(>、<、between、like)就会停止匹配。

最左匹配原则的原理

MySQL中的索引可以以一定顺序引用多列，这种索引叫作联合索引.最左匹配原则都是针对联合索引来说的

优点：最左前缀原则的利用也可以显著提高查询效率，是常见的MySQL性能优化手段。

3.6 SSM+SpringBoot

1. 什么是 Spring IOC 容器？

Spring 框架的核心是 Spring 容器。容器创建对象，将它们装配在一起，配置它们并管理它们的完整生命周期。Spring 容器使用依赖注入来管理组成应用程序的组件。

2.可以通过多少种方式完成依赖注入？

依赖注入可以通过三种方式完成，即：

• 构造函数注入
• setter 注入
• 接口注入

3. spring 提供了哪些配置方式？

• 基于 xml 配置
• 基于注解配置
• 基于 Java API 配置

4. 如何理解IoC和DI？

IOC就是控制反转，通俗的说就是我们不用自己创建实例对象，这些都交给Spring的bean工厂帮我们创建管理。这也是Spring的核心思想，通过面向接口编程的方式来是实现对业务组件的动态依赖。这就意味着IOC是Spring针对解决程序耦合而存在的。

DI：DI—Dependency Injection，即“依赖注入”：组件之间依赖关系由容器在运行期决定，形象的说，即由容器动态的将某个依赖关系注入到组件之中。

5. 将一个类声明为Spring的 bean 的注解有哪些?

我们一般使用 @Autowired 注解自动装配 bean，要想把类标识成可用于 @Autowired 注解自动装配的 bean 的类,采用以下注解可实现：

• @Component ：通用的注解，可标注任意类为 Spring 组件。如果一个Bean不知道属于哪个层，可以使用@Component 注解标注。 8 @Repository : 对应持久层即 Dao 层，主要用于数据库相关操作。
• @Service : 对应服务层，主要涉及一些复杂的逻辑，需要用到 Dao层。
• @Controller : 对应 Spring MVC 控制层，主要用户接受用户请求并调用 Service 层返回数据给前端页面。

6. spring 支持几种 bean scope？

Spring bean 支持 5 种 scope：

• Singleton - 每个 Spring IoC 容器仅有一个单实例。
• Prototype - 每次请求都会产生一个新的实例。
• Request
• Session
• Global-session

仅当用户使用支持 Web 的 ApplicationContext 时，最后三个才可用

7. Spring 中的 bean 生命周期?

Bean的生命周期是由容器来管理的。主要在创建和销毁两个时期。

8. Spring 怎么解决循环依赖问题？

spring对循环依赖的处理有三种情况： ①构造器的循环依赖：这种依赖spring是处理不了的，直接抛出BeanCurrentlylnCreationException异常。 ②单例模式下的setter循环依赖：通过“三级缓存”处理循环依赖。 ③非单例循环依赖：无法处理。

9. 什么是 AOP？

AOP(Aspect-Oriented Programming), 即 面向切面编程, 它与 OOP( Object-Oriented Programming, 面向对象编程) 相辅相成, 提供了与 OOP 不同的抽象软件结构的视角. 在 OOP 中, 我们以类(class)作为我们的基本单元, 而 AOP 中的基本单元是 Aspect(切面)

10. AOP 有哪些实现方式？

实现 AOP 的技术，主要分为两大类：

• 静态代理
• 动态代理 - 在运行时在内存中“临时”生成 AOP 动态代理类，因此也被称为运行时增强。
  • JDK 动态代理：通过反射来接收被代理的类，并且要求被代理的类必须实现一个接口
  • CGLIB动态代理： 如果目标类没有实现接口，那么 Spring AOP 会选择使用 CGLIB 来动态代理目标类

11. SpringMVC 工作原理了解吗?

流程说明（重要）：

1. 客户端（浏览器）发送请求，直接请求到 DispatcherServlet。
2. DispatcherServlet 根据请求信息调用 HandlerMapping，解析请求对应的 Handler。
3. 解析到对应的 Handler（也就是我们平常说的 Controller 控制器）后，开始由 HandlerAdapter 适配器处理。
4. HandlerAdapter 会根据 Handler来调用真正的处理器开处理请求，并处理相应的业务逻辑。
5. 处理器处理完业务后，会返回一个 ModelAndView 对象，Model 是返回的数据对象，View 是个逻辑上的 View。
6. ViewResolver 会根据逻辑 View 查找实际的 View。
7. DispaterServlet 把返回的 Model 传给 View（视图渲染）。
8. 把 View 返回给请求者（浏览器）

12. Spring Boot 的自动装配原理

以前在Spring使用到某个组件的时候，需要在xml中对配置好各个属性，之后被Spring扫描后注入进容器。

而有了SpringBoot后，我们仅仅需要引入一个starter，就可以直接使用该组件，如此方便、快捷，得益于自动装配机制。

启动类上面的注解是@SpringBootApplication，它也是 Spring Boot 的核心注解，主要组合包含了以下 3 个注解：

@SpringBootConfiguration：组合了 @Configuration 注解，实现配置文件的功能。

@EnableAutoConfiguration：打开自动配置的功能，也可以关闭某个自动配置的选项，如关闭数据源自动配置功能： @SpringBootApplication(exclude = { DataSourceAutoConfiguration.class })。

@ComponentScan：Spring组件扫描。

Spring Boot 在启动的时候会干这几件事情：

• Spring Boot 在启动时会去依赖的 Starter 包中寻找 resources/META-INF/spring.factories 文件，然后根据文件中配置的 Jar 包去扫描项目所依赖的 Jar 包。
• 根据 spring.factories 配置加载 AutoConfigure 类
• 根据 @Conditional 注解的条件，进行自动配置并将 Bean 注入 Spring Context

总结一下，其实就是 Spring Boot 在启动的时候，按照约定去读取 Spring Boot Starter 的配置信息，再根据配置信息对资源进行初始化，并注入到 Spring 容器中。这样 Spring Boot 启动完毕后，就已经准备好了一切资源，使用过程中直接注入对应 Bean 资源即可

13. #{}和${}的区别？

• #{}是占位符，预编译处理；${}是拼接符，字符串替换，没有预编译处理。
• Mybatis在处理#{}时，#{}传入参数是以字符串传入，会将SQL中的#{}替换为?号，调用PreparedStatement的set方法来赋值。
• 变量替换后，#{} 对应的变量自动加上单引号 ‘’；变量替换后，${} 对应的变量不会加上单引号 ‘’
• #{} 可以有效的防止SQL注入，提高系统安全性；${} 不能防止SQL 注入
• #{} 的变量替换是在DBMS 中；${} 的变量替换是在 DBMS 外

14. 在Mapper中如何传递多个参数？

1、若Dao层函数有多个参数，那么其对应的xml中，#{0}代表接收的是Dao层中的第一个参数，#{1}代表Dao中的第二个参数，以此类推。

2、使用@Param注解：在Dao层的参数中前加@Param注解,注解内的参数名为传递到Mapper中的参数名。

3、多个参数封装成Map，以HashMap的形式传递到Mapper中。

15. Mybatis动态sql有什么用？执行原理是什么？有哪些动态sql？

Mybatis动态sql可以在xml映射文件内，以标签的形式编写动态sql，执行原理是根据表达式的值完成逻辑判断，并动态拼接sql的功能。

Mybatis提供了9种动态sql标签：trim、where、set、foreach、if、choose、when、otherwise、bind

3.7 SpringCloud

1 什么是微服务

微服务是一种架构思想，它是有多个组件组合而成—>任何一个微服务都是一个独立的进程（独立开发、独立维护、独立部署等）

2 微服务框架的优势

1 一个微服务只关注一个特定的业务功能，业务清晰，代码量少。开发和维护相对简单。（整个应用是由若干个微服务构建而成 所以整个应用也在可控状态）

2 单个微服务代码量少，启动快

3 技术栈不受限制，每个小微服务都有他合理的技术栈

3 SpringCloud 和微服务的关系

SpringCloud是一系列框架的集合体 nacos注册中心 Sentinel 熔断/降流 Gateway网关 Sleuth 链路追踪 Seata 分布式事务 Redisson—Redlock分布式锁

4 SpringBoot 和 SpringCloud 的区别

1 SpringBoot专注于开发单体项目

2 SpringCloud 专注于微服务的协调、整理、治理的框架，，它将SpringBoot开发的单体 项目联合管理起来

3 springBoot可以单体开发，，，SpringCloud不能离开SpringBoot开发，，属于依赖关系

5 什么是 CAP

Consistency（一致性）、Availability（可用性）、Partitiontolerance(分区容忍性) 1 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是一样的值 （所有节点访问的都是同一分，最新的数据副本）

2 可用性（A）：在集群中一部分节点故障后，集群整体是否还能正常使用 （对数据更新具备，高可用性）

3 分区容忍性（P）：相当于队通信段时间限制 ，如果时间不能在时限内达到一致性，就 会发生分区的情况，，（必须在C，A之间做出选择）

CAP只能同时满足两个 取舍： 1 如果保证强一致性 采用 CA 放弃P 系统的扩展性降低（mysql采用CA模式）

2 如果不保证A采用CP的情况下 P的分区会无限延长，可能会造成数据丢失（故障）（Reids）

3 AP模式 放弃C的一致性，一旦放生分区，数据就会不一致（抢购活动）

6 Nacos 注册中心

1 为什么使用 Nacos

首先，服务器越来越多，不方便维护和管理，也容易造成代码冲突

可以将配置信息都交由nacos进行集中管理，，统一分配，

同时启动类上需要加上 @EnableDiscoveryClient 开启服务的注册与发现功能

7 Sentinel 熔断 / 降流

什么是熔断，什么是降流

1 熔断：指的是我调用别人，出现了问题，怎么办，返回什么数据，报错等，

2 降流：指别人调用我请求量太大的话，需要对其限流

8 怎么设置降流

1 流量监控其原理是 受监控应用流量的被设置的QPS到达指定的阔值的时候 对其进行流量控制，避免瞬间被大批的流量冲垮， 保障了应用的可用性

使用@SentinelResource的blockHandler可以指定限流后的异常处理方法

9 熔断

在我们 一个服务调用另一个服务如果出现了异常 或其他特殊情况的话 会进行熔断处理

1 一段熔断，断路器的状态是Open打开的

2 当熔断时间结束后，断路器的状态时 half-Open（可以允许一个进来）

3 如果接下啦的请求正常的话 断路器的状态是 close （资源就自恢复），

4 如果失败，断路器的状态还是Open

使用@SentinelResource的fallBack可以指定熔断后的异常处理方法

10 Gateway 网关

为什么使用 Gateway 网关

1 可以对微服务系统起到很好的性能优化

2 Gateway网关可以起到很好的作用，比如：路由、过滤、限流、监控等。。

11 什么是分布式事务

1 在spring中声明事务 通过spring的AOP实现 @TranSactional 中的rollbackFor、notRoolbackFor来实现事务的提交、回滚等

单服务的情况下 是一个service去访问两个不同的数据库

在多服务的进程中 可能有多个service 来回调用 来同时访问不同的数据库

在分布式事务中，它也是遵循了ACID的规范 原子性：要么全部成功，要么全部失败

一致性：从事务开始-到事务结束，数据库的完整性没有被破坏

隔离性：在多个事务并行进行 读写、修改等操作是不会交叉而导致数据不一致，

持久性：事务结束后，对数据的修改是永久性的，不会因为系统故障而造成数据丢失。

12 而在seata中有AT、TCC、SAGA和 XA 事务模式

AT模式两阶段提交协议的演变：

一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。 二阶段： 提交异步化，非常快速地完成。 回滚通过一阶段的回滚日志进行反向补偿。

TCC编程模式：Try、Confirm和Cancel三个操作。以在线下单为例，Try阶段会去扣库存， Confirm阶段则是去更新订单状态，如果更新订单失败，则进入Cancel阶段，会去恢复库存。

13 分布式锁

可以使用Redisson中的RedLock锁来实现分布式锁

《RedLock是基于redis实现的分布式锁，它能够保证以下特性》 互斥锁：在任何时候只能有一个客户端持有锁 避免死锁：当客户拿到锁之后，即便是发生了异常或者服务器宕机的情况下， 利用key的存活时间避免死锁

3.8 Redis

1. Redis是什么？

Redis本质上是一个Key-Value类型的内存数据库，很像Memcached，整个数据库加载在内存当中操作，定期通过异步操作把数据库中的数据flush到硬盘上进行保存。

因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value 数据库。

2. Redis的常用场景有哪些?

1、缓存 2、排行榜 3、计数器 4、分布式会话 5、分布式锁 6、 社交网络 7、最新列表 8、消息系统

1、缓存

缓存现在几乎是所有中大型网站都在用的必杀技，合理的利用缓存不仅能够提升网站访问速度，还能大大降低数据库的压力。Redis提供了键过期功能，也提供了灵活的键淘汰策略，所以，现在Redis用在缓存的场合非常多。

2、排行榜

很多网站都有排行榜应用的，如京东的月度销量榜单、商品按时间的上新排行榜等。Redis提供的有序集合数据类构能实现各种复杂的排行榜应用。

3、计数器

什么是计数器，如电商网站商品的浏览量、视频网站视频的播放数等。为了保证数据实时效，每次浏览都得给+1，并发量高时如果每次都请求数据库操作无疑是种挑战和压力。Redis提供的incr命令来实现计数器功能，内存操作，性能非常好，非常适用于这些计数场景。

4、分布式会话

集群模式下，在应用不多的情况下一般使用容器自带的session复制功能就能满足，当应用增多相对复杂的系统中，一般都会搭建以Redis等内存数据库为中心的session服务，session不再由容器管理，而是由session服务及内存数据库管理。

5、分布式锁

在很多互联网公司中都使用了分布式技术，分布式技术带来的技术挑战是对同一个资源的并发访问，如全局ID、减库存、秒杀等场景，并发量不大的场景可以使用数据库的悲观锁、乐观锁来实现，但在并发量高的场合中，利用数据库锁来控制资源的并发访问是不太理想的，大大影响了数据库的性能。可以利用Redis的setnx功能来编写分布式的锁，如果设置返回1说明获取锁成功，否则获取锁失败，实际应用中要考虑的细节要更多。

6、 社交网络

点赞、踩、关注/被关注、共同好友等是社交网站的基本功能，社交网站的访问量通常来说比较大，而且传统的关系数据库类型不适合存储这种类型的数据，Redis提供的哈希、集合等数据结构能很方便的的实现这些功能。如在微博中的共同好友，通过Redis的set能够很方便得出。

7、最新列表

Redis列表结构，LPUSH可以在列表头部插入一个内容ID作为关键字，LTRIM可用来限制列表的数量，这样列表永远为N个ID，无需查询最新的列表，直接根据ID去到对应的内容页即可。

8、消息系统

消息队列是大型网站必用中间件，如ActiveMQ、RabbitMQ、Kafka等流行的消息队列中间件，主要用于业务解耦、流量削峰及异步处理实时性低的业务。Redis提供了发布/订阅及阻塞队列功能，能实现一个简单的消息队列系统。另外，这个不能和专业的消息中间件相比。

3. Redis的数据类型有哪些？

有五种常用数据类型：String、Hash、Set、List、SortedSet。以及三种特殊的数据类型：Bitmap、HyperLogLog、Geospatial ，其中HyperLogLog、Bitmap的底层都是 String 数据类型，Geospatial 的底层是 Sorted Set 数据类型。

五种常用的数据类型： 1、String：String是最常用的一种数据类型，普通的key- value 存储都可以归为此类。

2、Hash：Hash 是一个键值(key => value)对集合。Redis hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象，并且可以像数据库中update一个属性一样只修改某一项属性值。

3、Set：Set是一个无序的天然去重的集合，即Key-Set。此外还提供了交集、并集等一系列直接操作集合的方法，对于求共同好友、共同关注什么的功能实现特别方便。

4、List：List是一个有序可重复的集合，其遵循FIFO的原则，底层是依赖双向链表实现的，因此支持正向、反向双重查找。通过List，我们可以很方面的获得类似于最新回复这类的功能实现。

5、SortedSet：类似于java中的TreeSet，是Set的可排序版。此外还支持优先级排序，维护了一个score的参数来实现。适用于排行榜和带权重的消息队列等场景。

三种特殊的数据类型： 1、Bitmap：位图，Bitmap想象成一个以位为单位数组，数组中的每个单元只能存0或者1，数组的下标在Bitmap中叫做偏移量。使用Bitmap实现统计功能，更省空间。如果只需要统计数据的二值状态，例如商品有没有、用户在不在等，就可以使用 Bitmap，因为它只用一个 bit 位就能表示 0 或 1。

2、Hyperloglog。HyperLogLog 是一种用于统计基数的数据集合类型。

3、Geospatial ：主要用于存储地理位置信息，并对存储的信息进行操作，适用场景如朋友的定位、附近的人、打车距离计算等。

4. Redis过期键的删除策略

Redis的过期删除策略就是：惰性删除和定期删除两种策略配合使用。

惰性删除：惰性删除不会去主动删除数据，而是在访问数据的时候，再检查当前键值是否过期，如果过期则执行删除并返回 null 给客户端，如果没有过期则返回正常信息给客户端。它的优点是简单，不需要对过期的数据做额外的处理，只有在每次访问的时候才会检查键值是否过期，缺点是删除过期键不及时，造成了一定的空间浪费。

定期删除：Redis会周期性的随机测试一批设置了过期时间的key并进行处理。测试到的已过期的key将被删除。

5. 如何保证缓存与数据库双写时的数据一致性？

背景：使用到缓存，无论是本地内存做缓存还是使用 Redis 做缓存，那么就会存在数据同步的问题，因为配置信息缓存在内存中，而内存时无法感知到数据在数据库的修改。这样就会造成数据库中的数据与缓存中数据不一致的问题。

共有四种方案：

1. 先更新数据库，后更新缓存
2. 先更新缓存，后更新数据库
3. 先删除缓存，后更新数据库
4. 先更新数据库，后删除缓存

第一种和第二种方案，没有人使用的，因为第一种方案存在问题是：并发更新数据库场景下，会将脏数据刷到缓存。

第二种方案存在的问题是：如果先更新缓存成功，但是数据库更新失败，则肯定会造成数据不一致。

目前主要用第三和第四种方案。

6. 什么是缓存击穿?

缓存击穿跟缓存雪崩有点类似，缓存雪崩是大规模的key失效，而缓存击穿是某个热点的key失效，大并发集中对其进行请求，就会造成大量请求读缓存没读到数据，从而导致高并发访问数据库，引起数据库压力剧增。这种现象就叫做缓存击穿。

从两个方面解决，第一是否可以考虑热点key不设置过期时间，第二是否可以考虑降低打在数据库上的请求数量。

解决方案：

• 在缓存失效后，通过互斥锁或者队列来控制读数据写缓存的线程数量，比如某个key只允许一个线程查询数据和写缓存，其他线程等待。这种方式会阻塞其他的线程，此时系统的吞吐量会下降
• 热点数据缓存永远不过期。永不过期实际包含两层意思：
  • 物理不过期，针对热点key不设置过期时间
  • 逻辑过期，把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建

7. 什么是缓存穿透?

缓存穿透是指用户请求的数据在缓存中不存在即没有命中，同时在数据库中也不存在，导致用户每次请求该数据都要去数据库中查询一遍。如果有恶意攻击者不断请求系统中不存在的数据，会导致短时间大量请求落在数据库上，造成数据库压力过大，甚至导致数据库承受不住而宕机崩溃。

缓存穿透的关键在于在Redis中查不到key值，它和缓存击穿的根本区别在于传进来的key在Redis中是不存在的。假如有黑客传进大量的不存在的key，那么大量的请求打在数据库上是很致命的问题，所以在日常开发中要对参数做好校验，一些非法的参数，不可能存在的key就直接返回错误提示。

解决方法：

• 将无效的key存放进Redis中：
• 使用布隆过滤器：

8. 什么是缓存雪崩?

如果缓在某一个时刻出现大规模的key失效，那么就会导致大量的请求打在了数据库上面，导致数据库压力巨大，如果在高并发的情况下，可能瞬间就会导致数据库宕机。这时候如果运维马上又重启数据库，马上又会有新的流量把数据库打死。这就是缓存雪崩。

造成缓存雪崩的关键在于同一时间的大规模的key失效，主要有两种可能：第一种是Redis宕机，第二种可能就是采用了相同的过期时间。

解决方案：

1、事前：

• 均匀过期：设置不同的过期时间，让缓存失效的时间尽量均匀，避免相同的过期时间导致缓存雪崩，造成大量数据库的访问。

2、事中：

• 互斥锁：在缓存失效后，通过互斥锁或者队列来控制读数据写缓存的线程数量
• 使用熔断机制，限流降级

3、事后：

开启Redis持久化机制，尽快恢复缓存数据，一旦重启，就能从磁盘上自动加载数据恢复内存中的数据。

9. 什么是缓存预热?

缓存预热是指系统上线后，提前将相关的缓存数据加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题，用户直接查询事先被预热的缓存数据。

如果不进行预热，那么Redis初始状态数据为空，系统上线初期，对于高并发的流量，都会访问到数据库中， 对数据库造成流量的压力。

10. Redis高可用方案具体怎么实施？

1.主从复制

2.哨兵+主从复制

3.哨兵+Redis-Cluster+主从复制

11. 什么是分布式锁？为什么用分布式锁？

锁在程序中的作用就是同步工具，保证共享资源在同一时刻只能被一个线程访问，Java中的锁我们都很熟悉了，像synchronized 、Lock都是我们经常使用的，但是Java的锁只能保证单机的时候有效，分布式集群环境就无能为力了，这个时候我们就需要用到分布式锁。

分布式锁，顾名思义，就是分布式项目开发中用到的锁，可以用来控制分布式系统之间同步访问共享资源。

思路是：在整个系统提供一个全局、唯一的获取锁的“东西”，然后每个系统在需要加锁时，都去问这个“东西”拿到一把锁，这样不同的系统拿到的就可以认为是同一把锁。至于这个“东西”，可以是Redis、Zookeeper，也可以是数据库。

一般来说，分布式锁需要满足的特性有这么几点：

1、互斥性：在任何时刻，对于同一条数据，只有一台应用可以获取到分布式锁；

2、高可用性：在分布式场景下，一小部分服务器宕机不影响正常使用，这种情况就需要将提供分布式锁的服务以集群的方式部署；

3、防止锁超时：如果客户端没有主动释放锁，服务器会在一段时间之后自动释放锁，防止客户端宕机或者网络不可达时产生死锁；

4、独占性：加锁解锁必须由同一台服务器进行，也就是锁的持有者才可以释放锁，不能出现你加的锁，别人给你解锁了。

12. 常见的分布式锁有哪些解决方案？

实现分布式锁目前有三种流行方案，即基于关系型数据库、Redis、ZooKeeper 的方案

1、基于关系型数据库，如MySQL 基于关系型数据库实现分布式锁，是依赖数据库的唯一性来实现资源锁定，比如主键和唯一索引等。

2、基于Redis实现

优点：

Redis 锁实现简单，理解逻辑简单，性能好，可以支撑高并发的获取、释放锁操作。

3、基于zookeeper

3.9 MQ

1.为什么使用MQ？

使用MQ的场景很多，主要有三个：解耦、异步、削峰。

2.消息队列的缺点

1、 系统可用性降低

系统引入的外部依赖越多，越容易挂掉。

2、 系统复杂度提高

加入了消息队列，要多考虑很多方面的问题，比如：一致性问题、如何保证消息不被重复消费、如何保证消息可靠性传输等。因此，需要考虑的东西更多，复杂性增大。

3、 一致性问题

A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，这就数据不一致了

3 RocketMQ由哪些角色组成，每个角色作用和特点是什么？

角色	作用
Nameserver	无状态，动态列表；这也是和zookeeper的重要区别之一。zookeeper是有状态的。
Producer	消息生产者，负责发消息到Broker。
Broker	就是MQ本身，负责收发消息、持久化消息等。
Consumer	消息消费者，负责从Broker上拉取消息进行消费，消费完进行ack。

3. RocketMQ消费模式有几种？

消费模型由Consumer决定，消费维度为Topic。

1、集群消费-共享

• 一条消息只会被同Group中的一个Consumer消费
• 多个Group同时消费一个Topic时，每个Group都会有一个Consumer消费到数据

2、广播消费

消息将对一 个Consumer Group 下的各个 Consumer 实例都消费一遍。即即使这些 Consumer 属于同一个Consumer Group ，消息也会被 Consumer Group 中的每个 Consumer 都消费一次。

4. RocketMQ消费消息是push还是pull？

RocketMQ没有真正意义的push，都是pull，虽然有push类，但实际底层实现采用的是长轮询机制，即拉取方式

broker端属性 longPollingEnable 标记是否开启长轮询。默认开启

追问：为什么要主动拉取消息而不使用事件监听方式？

事件驱动方式是建立好长连接，由事件（发送数据）的方式来实时推送。

如果broker主动推送消息的话有可能push速度快，消费速度慢的情况，那么就会造成消息在consumer端堆积过多，同时又不能被其他consumer消费的情况。而pull的方式可以根据当前自身情况来pull，不会造成过多的压力而造成瓶颈。所以采取了pull的方式。

5. broker如何处理拉取请求的？

Consumer首次请求Broker

• Broker中是否有符合条件的消息
• 有
• • 响应Consumer
  • 等待下次Consumer的请求
• 没有
• • DefaultMessageStore#ReputMessageService#run方法
  • PullRequestHoldService 来Hold连接，每个5s执行一次检查pullRequestTable有没有消息，有的话立即推送
  • 每隔1ms检查commitLog中是否有新消息，有的话写入到pullRequestTable
  • 当有新消息的时候返回请求
  • 挂起consumer的请求，即不断开连接，也不返回数据
  • 使用consumer的offset，

6. 如何让RocketMQ保证消息的顺序消费？

首先多个queue只能保证单个queue里的顺序，queue是典型的FIFO，天然顺序。多个queue同时消费是无法绝对保证消息的有序性的。所以总结如下：

同一topic，同一个QUEUE，发消息的时候一个线程去发送消息，消费的时候 一个线程去消费一个queue里的消息。

7. RocketMQ如何保证消息不丢失？

首先在如下三个部分都可能会出现丢失消息的情况：

• Producer端
• Broker端
• Consumer端

1 Producer端如何保证消息不丢失

• 采取send()同步发消息，发送结果是同步感知的。
• 发送失败后可以重试，设置重试次数。默认3次。
• 集群部署，比如发送失败了的原因可能是当前Broker宕机了，重试的时候会发送到其他Broker上。

2 Broker端如何保证消息不丢失

• 修改刷盘策略为同步刷盘。默认情况下是异步刷盘的。
• 集群部署，主从模式，高可用。

3 Consumer端如何保证消息不丢失

• 完全消费正常后在进行手动ack确认。

7. rocketMQ的消息堆积如何处理？

首先要找到是什么原因导致的消息堆积，是Producer太多了，Consumer太少了导致的还是说其他情况，总之先定位问题。

然后看下消息消费速度是否正常，正常的话，可以通过上线更多consumer临时解决消息堆积问题

8 如果Consumer和Queue不对等，上线了多台也在短时间内无法消费完堆积的消息怎么办？

• 准备一个临时的topic
• queue的数量是堆积的几倍
• queue分布到多Broker中
• 上线一台Consumer做消息的搬运工，把原来Topic中的消息挪到新的Topic里，不做业务逻辑处理，只是挪过去
• 上线N台Consumer同时消费临时Topic中的数据
• 改bug
• 恢复原来的Consumer，继续消费之前的Topic

堆积时间过长消息超时了？

RocketMQ中的消息只会在commitLog被删除的时候才会消失，不会超时。也就是说未被消费的消息不会存在超时删除这情况。

堆积的消息会不会进死信队列？

不会，消息在消费失败后会进入重试队列（%RETRY%+ConsumerGroup），18次（默认18次，网上所有文章都说是16次，无一例外。但是我没搞懂为啥是16次，这不是18个时间吗 ？）才会进入死信队列（%DLQ%+ConsumerGroup）。

9. RocketMQ为什么自研nameserver而不用zk？

1. RocketMQ只需要一个轻量级的维护元数据信息的组件，为此引入zk增加维护成本还强依赖另一个中间件了。
2. RocketMQ追求的是AP，而不是CP，也就是需要高可用。
   • zk是CP，因为zk节点间通过zap协议有数据共享，每个节点数据会一致，但是zk集群当挂了一半以上的节点就没法使用了。
   • nameserver是AP，节点间不通信，这样会导致节点间数据信息会发生短暂的不一致，但每个broker都会定时向所有nameserver上报路由信息和心跳。当某个broker下线了，nameserver也会延时30s才知道，而且不会通知客户端（生产和消费者），只能靠客户端自己来拉，rocketMQ是靠消息重试机制解决这个问题的，所以是最终一致性。但nameserver集群只要有一个节点就可用。

3.10 设计模式

1 Spring中8种设计模式

Spring框架中常用到的8种设计模式清单如下

设计模式	使用地方	备注
工厂模式	BeanFactory ApplicationContext
单例模式	Spring中的Bean
代理模式	Spring AOP	java反射实现动态代理
模板方法模式	Spring中以Template结尾的类	使用继承的方式实现
观察者模式	Spring事件驱动模型
适配器模式	Spring AOP中的AdvisorAdapter Spring MVC中的HandlerAdapter
装饰器模式	Spring中含有Wrapper和含有Decorator的类
策略模式	资源访问Resource接口

2 Mybatis10种设计模式

Mybatis中使用了哪些设计模式

Mybatis 中使用了10种设计模式，其中创建型模式3种（工厂、单例、建造者），结构型模式4种（适配器、代理、组合、装饰器），行为型模式3种（模板、策略、迭代器）

3 设计模式之创建型模式

1、工厂模式

DefaultSqlSession DefaultSqlSessionFactory
PooledDataSource PooledDataSourceFactory
UnpooledDataSource UnpooledDataSourceFactory

工厂模式：简单工厂，是一种创建型设计模式，其在父类中提供一个创建对象的方法，允许子类决定实例对象的类型。

场景介绍：SqlSessionFactory 是获取会话的工厂，每次我们使用 Mybatis 操作数据库的时候，都会开启一个新的会话。在会话工厂的实现中负责获取数据源环境配置信息、构建事务工厂、创建操作SQL的执行器，并最终返回会话实现类。

2、单例模式

Configuration 配置类

单例模式：是一种创建型模式，让你能够保证一个类只有一个实例，并提供一个访问该实例的全局节点。

场景介绍：Configuration贯穿整个会话的生命周期，有以的配置对象：映射、缓存、入参、出参、拦截器、注册机、对象工厂等，都在 Configuration 配置项中初始化。并随着 SqlSessionFactoryBuilder 构建阶段完成实例化操作。

3、建造者模式

XMLConfigBuilder
SqlSessionFactoryBuilder

建造者模式：使用多个简单的对象一步一步构建成一个复杂的对象，这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。

场景介绍：关于建造者模式在 Mybatis 框架里的使用，到处都是 XxxxBuilder，所有关于 XML 文件的解析到各类对象的封装，都使用建造者以及建造者助手来完成对象的封装。它的核心目的就是不希望把过多的关于对象的属性设置，写到其他业务流程中，而是用建造者的方式提供最佳的边界隔离。

4 设计模式之二结构型模式

1、适配器模式

Log4jImpl、Slf4jImpl
Slf4jLocationAwareLoggerImpl 适配
Log接口

适配器模式：是一种结构型设计模式，它能使接口不兼容的对象能够相互合作。

场景介绍：正是因为有太多的日志框架，包括：Log4j、Log4j2、Slf4J等等，而这些日志框架的使用接口又都各有差异，为了统一这些日志工具的接口，Mybatis 定义了一套统一的日志接口，为所有的其他日志工具接口做相应的适配操作。

2、代理模式

MapperProxy、DriverProxy

代理模式：是一种结构型模式，让你能够提供对象的替代品或其占位符。代理控制着对原对象的访问，并允许在将请求提交给对象前进行一些处理。

场景介绍：没有代理模式，就不会有各类的框架存在。就像 Mybatis 中的 MapperProxy 映射器代理实现类，它所实现的功能就是帮助我们完成 DAO 接口的具体实现类的方法操作，你的任何一个配置的 DAO 接口所调用的 CRUD 方法，都会被 MapperProxy 接管，调用到方法执行器等一系列操作，并返回最终的数据库执行结果

3、组合模式

SqlNode、IfSqlNode、WhereSqlNode等

组合模式：是一种结构型设计模式，你可以使用它将对象组合成树状结构，并且能独立使用对象一样使用它们。

场景介绍：在 Mybatis XML 动态的 SQL 配置中，共提供了9种(trim/where/set/foreach/if/choose/when/otherwise/bind)标签的使用，让使用者可以组合出各类场景的 SQL 语句。而 SqlNode 接口的实现就是每一个组合结构中的规则节点，通过规则节点的组装完成一颗规则树组合模式的使用。

4、装饰器模式

Configuration.newExecutor();

装饰器模式：是一种结构型设计模式，允许你通过将对象放入包含行为的特殊封装对象中来为原对象绑定新的行为。

场景介绍：Mybatis 的所有 SQL 操作，都是经过 SqlSession 会话调用 SimpleExecutor 简单实现的执行器完成的，而一级缓存的操作也是在简单执行器中处理。那么这里二级缓存因为是基于一级缓存刷新操作的，所以在实现上，通过创建一个缓存执行器，包装简单执行器的处理逻辑，实现二级缓存操作。

6 设计模式之三行为型模式

1、模板模式

执行器
Executor接口 --> BaseExecutor抽象类 --> SimpleExecutor继承抽象类 

模板模式：是一种行为设计模式，它在超类中定义了一个算法的框架，允许子类在不修改结构的情况下重写算法的特定步骤。

场景介绍：只要存在一系列可被标准定义的流程，在流程的步骤大部分是通用逻辑，只有一少部分是需要子类实现的，那么通常会采用模板模式来定义出这个标准的流程。就像 Mybatis 的 BaseExecutor 就是一个用于定义模板模式的抽象类，在这个类中把查询、修改的操作都定义出了一套标准的流程。

2、策略模式

类型转换
TypeHandler、LongTypeHandler、StringTypeHandler

策略模式：是一种行为设计模式，它能定义一系列算法，并将每种算法分别放入独立的类中，以使算法的对象能够互相替换。

场景介绍：在 Mybatis 处理 JDBC 执行后返回的结果时，需要按照不同的类型获取对应的值，这样就可以避免大量的 if 判断。所以这里基于 TypeHandler 接口对每个参数类型分别做了自己的策略实现。

3、迭代器模式

PropertyTokenizer implements Iterable<PropertyTokenizer>, Iterator<PropertyTokenizer>

迭代器模式：是一种行为设计模式，让你能在不暴露集合底层表现形式的情况下遍历集合中所有的元素。

场景介绍：PropertyTokenizer 是用于 Mybatis 框架 MetaObject 反射工具包下，用于解析对象关系的迭代操作。这个类在 Mybatis 框架中使用的非常频繁，包括解析数据源配置信息并填充到数据源类上，以及参数的解析、对象的设置都会使用到这个类

7. 单例模式

1. 概述

java单例模式是一种常见的设计模式。

单例模式有以下特点：

1. 单例类只能有一个实例；
2. 单例类必须自己创建自己的唯一实例；
3. 单例类必须给所有其他对象提供这一实例；

2. 优缺点

优点：由于单例模式只生成了一个实例，所以能够节约系统资源，减少性能开销，提高系统运行效率。 缺点：因为系统中只有一个实例，导致了单例类的职责过重，违背了“单一职责原则”，同时不利于扩展。

3. 单例模式实现方式

常见的单例模式实现方式有五种：饿汉式、懒汉式、双重检测锁、静态内部类和枚举单例。

3.1 饿汉式

public class SingletonDemoInHunger {
    
    // 私有实例，类初始化就加载
    private static SingletonDemoInHunger instance = new SingletonDemoInHunger();
    
    // 私有构造方法
    private SingletonDemoInHunger() {}
    
    // 公共的、静态的获取实例方法
    public static SingletonDemoInHunger getInstance() {
        return instance;
    }
}

饿汉式：

1. 类加载时就初始化，浪费内存，不能延迟加载；
2. 基于 classloader 机制避免了多线程的同步问题，线程安全；
3. 没有加锁，调用效率高。

3.2 懒汉式

public class SingletonDemoInLazy {
    
    // 私有实例,初始化的时候不加载（延迟加载）
    private static SingletonDemoInLazy instance;
    
    // 私有构造
    private SingletonDemoInLazy() {}
    
    // 公共获取实例方法（线程不安全）
    public static SingletonDemoInLazy getInstance() {
        if(instance == null ) { // 使用的时候加载
            instance = new SingletonDemoInLazy();
        }
        return instance;
    }
}

上面这种写法，是线程不安全的，但是可以做到延迟加载。

下面是线程安全的懒汉模式：

public class SingletonDemoInLazy {
   
    // 私有实例,初始化的时候不加载（延迟加载）
    private static SingletonDemoInLazy instance;
    
    // 私有构造
    private SingletonDemoInLazy() {}
    
    // 公共获取实例方法（线程安全，调用效率低）
    public synchronized static SingletonDemoInLazy getInstance() {
        if(instance == null ) {
            instance = new SingletonDemoInLazy();
        }
        return instance;
    }
}

上面代码中，通过关键字synchronized声明公共的获取实例的方法getInstance()，可以确保线程安全，能做到延迟加载，但是效率不高。

double-checked locking（双重检查锁）

public class SingletonDemoInDoubleCheckLock {

    // 私有实例，volatile关键字，禁止指令重排。
    private volatile static SingletonDemoInDoubleCheckLock instance;

    // 私有构造
    private SingletonDemoInDoubleCheckLock() {}

    // 公共获取实例方法（线程安全）
    public static SingletonDemoInDoubleCheckLock getInstance() {

        if(instance == null ) { // 一重检查
            synchronized (SingletonDemoInDoubleCheckLock.class) {
                if(instance == null) { // 二重检查
                    instance = new SingletonDemoInDoubleCheckLock();
                }
            }
        }
        return instance;
    }
}

在加锁之前判断是否为空，可以确保 instance 不为空的情况下，不用加锁，可以直接返回。

加锁之后，还需要判断 instance 是否为空，是为了防止在多线程并发的情况下，会实例化多个对象。例如：线程 a 和线程 b 同时调用 getInstance 方法，假如同时判断 instance 都为空，这时会同时进行抢锁。假如线程 a 先抢到锁，开始执行 synchronized 关键字包含的代码，此时线程 b 处于等待状态。线程 a 创建完新实例了，释放锁了，此时线程 b 拿到锁，进入 synchronized 关键字包含的代码，如果没有再判断一次 instance 是否为空，则可能会重复创建实例。

双重检查锁：

1. 双重判断，延迟加载；
2. 线程安全；
3. JDK 版本要求1.5起。

静态内部类-IoDH

public class SingletonDemoInStaticInnerClass {
    // 静态内部类
    private static class InnerClass{
    // 初始化实例
    private final static SingletonDemoInStaticInnerClass INSTANCE = new SingletonDemoInStaticInnerClass();

    }

    // 私有构造
    private SingletonDemoInStaticInnerClass() {}

    // 公关获取实例方法（线程安全，延迟加载）
    public static SingletonDemoInStaticInnerClass getInstance() {
        return InnerClass.INSTANCE;
    }
}

静态内部类：

1. 利用了classloader机制来保证初始化 instance 时只有一个线程，线程安全；
2. 只有通过显式调用 getInstance 方法时，才会显式装载静态内部类，从而实例化instance，延迟加载。

枚举

public enum SingletonEnum {
    // 枚举元素本身就是单例 
    INSTANCE;
    // 其他要执行的方法
    public void sayHello() {
        System.out.println("你好");
    }
}

枚举：这是实现单例模式的最佳方法。它更简洁，不仅能避免多线程同步问题，而且还自动支持序列化机制，防止反序列化重新创建新的对象，绝对防止多次实例化。但是不是延迟加载的。

如何选用哪种方式实现单例模式？ 一般情况下，不建议懒汉式，建议使用饿汉式；只有在要明确实现延迟加载效果时，才会使用静态内部类；如果涉及到反序列化创建对象时，可以尝试使用枚举；如果有其他特殊的需求，可以考虑使用双重检查锁。