美团面试题

待我称王封你为后i 2023-10-13 11:44 81阅读 0赞

#### 文章目录 ####

*  HashMap 的底层数据结构是怎样的 ？
 *  HashMap 的扩容机制是怎样的？
 *  ConcurrentHashMap 的存储结构是怎样的？
 *  你有哪些手段来排查 OOM 的问题？
 *  请你谈谈 MySQL 事务隔离级别，MySQL 的默认隔离级别是什么？
 *  可重复读解决了哪些问题？
 *  对 SQL 慢查询会考虑哪些优化 ？
 *  谈一谈缓存穿透、缓存击穿和缓存雪崩，以及解决办法？
 *  什么是堆内存？参数如何设置？
 *  MySQL 索引底层结构为什么使用 B+树？
 *  B+ 树的叶子节点链表是单向还是双向？
 *  MVCC 是什么？它的底层原理是什么？
 *  undo log 具体怎么回滚事务 ？
 *  如何查询慢 SQL 产生的原因
 *  索引失效的情况有哪些？
 *  Redis 数据结构 压缩列表和跳跃表的区别
 *  Redis 主从同步是怎么实现的？
 *  Redis 持久化 RDB 和 AOF 优缺点
 *   *  RDB
     *  AOF
 *  谈谈自己对于Spring AOP的了解？
 *  Spring Bean容器的生命周期是什么样的？
 *  RabbitMQ 如何保证消息不丢失 ？

## HashMap 的底层数据结构是怎样的 ？ ##

*  JDK1.8 之前
    
     *  JDK1.8 之前 HashMap 底层是 **数组和链表** 结合在一起使用也就是 **链表散列**。
     *  HashMap 通过 key 的 hashCode 经过扰动函数处理过后得到 hash 值，然后通过 (n - 1) & hash 判断当前元素存放的位置（这里的 n 指的是数组的长度），如果当前位置存在元素的话，就判断该元素与要存入的元素的 hash 值以及 key 是否相同，如果相同的话，直接覆盖，不相同就通过拉链法解决冲突。
     *  所谓扰动函数指的就是 HashMap 的 hash 方法。使用 hash 方法也就是扰动函数是为了防止一些实现比较差的`hashCode()` 方法 换句话说使用扰动函数之后可以减少碰撞。
 *  JDK1.8 之后  
    当链表长度大于阈值（默认为 8）时，会首先调用 `treeifyBin()`方法。这个方法会根据`HashMap` 数组来决定是否转换为红黑树。只有当数组长度大于或者等于 64 的情况下，才会执行转换红黑树操作，以减少搜索时间。否则，就是只是执行 `resize()` 方法对数组扩容。

## HashMap 的扩容机制是怎样的？ ##

一般情况下，当元素数量超过阈值时便会触发扩容。每次扩容的容量都是之前容量的 2 倍。HashMap 的容量是有上限的，必须小于 1<<30，即 1073741824。如果容量超出了这个数，则不再增长，且阈值会被设置为 Integer.MAX\_VALUE。

*  JDK7 中的扩容机制
    
     *  空参数的构造函数：以默认容量、默认负载因子、默认阈值初始化数组。内部数组是空数组。
     *  有参构造函数：根据参数确定容量、负载因子、阈值等。
     *  第一次 put 时会初始化数组，其容量变为不小于指定容量的 2 的幂数，然后根据负载因子确定阈值。
     *  如果不是第一次扩容，则 新容量=旧容量 x 2 ，新阈值=新容量 x 负载因子 。
 *  JDK8 的扩容机制
    
     *  空参数的构造函数：实例化的 HashMap 默认内部数组是 null，即没有实例化。第一次调用 put 方法时，则会开始第一次初始化扩容，长度为 16。
     *  有参构造函数：用于指定容量。会根据指定的正整数找到不小于指定容量的 2 的幂数，将这个数设置赋值给阈值（threshold）。第一次调用 put 方法时，会将阈值赋值给容量，然后让 阈值 = 容量 x 负载因子。
     *  如果不是第一次扩容，则容量变为原来的 2 倍，阈值也变为原来的 2 倍。（容量和阈值都变为原来的 2 倍时，负载因子还是不变）。  
        此外还有几个细节需要注意：
     *  首次 put 时，先会触发扩容（算是初始化），然后存入数据，然后判断是否需要扩容；
     *  不是首次 put，则不再初始化，直接存入数据，然后判断是否需要扩容

## ConcurrentHashMap 的存储结构是怎样的？ ##

*  Java7 中 `ConcurrnetHashMap` 使用的分段锁，也就是每一个 `Segment` 上同时只有一个线程可以操作，每一个 `Segment` 都是一个类似 `HashMap` 数组的结构，它可以扩容，它的冲突会转化为链表。但是 Segment 的个数一但初始化就不能改变，默认 `Segment`  
    的个数是 16 个。
 *  Java8 中的 `ConcurrnetHashMap` 使用的 `Synchronized` 锁加 `CAS` 的机制。结构也由Java7 中的 **Segment 数组 + HashEntry 数组 + 链表** 进化成了 **Node 数组 + 链表 / 红黑树**，Node 是类似于一个 HashEntry 的结构。它的冲突再达到一定大小时会转化成红黑树，在冲突小于一定数量时又退回链表。

## 你有哪些手段来排查 OOM 的问题？ ##

*  增加两个参数 -XX:+HeapDumpOnOutOfMemoryError - XX:HeapDumpPath=/tmp/heapdump.hprof，当 OOM 发生时自动 dump 堆内存信息到指定目录。
 *  同时 jstat 查看监控 JVM 的内存和 GC 情况，先观察问题大概出在什么区域。
 *  使用 MAT 工具载入到 dump 文件，分析大对象的占用情况，比如 HashMap 做缓存未清理，时间长了就会内存溢出，可以把改为弱引用。

## 请你谈谈 MySQL 事务隔离级别，MySQL 的默认隔离级别是什么？ ##

为了达到事务的四大特性，数据库定义了 4 种不同的事务隔离级别：

*  READ-UNCOMMITTED（读取未提交）：最低的隔离级别，允许脏读，也就是可能读取到其他会话中未提交事务修改的数据，可能会导致脏读、幻读或不可重复读。
 *  READ-COMMITTED（读取已提交）： 只能读取到已经提交的数据。Oracle 等多数数据库默认都是该级别 （不重复读），可以阻止脏读，但是幻读或不可重复读仍有可能发生。
 *  REPEATABLE-READ（可重复读）：对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。
 *  SERIALIZABLE（可串行化）：最高的隔离级别，完全服从 ACID 的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。
 *  MySQL 默认采用的 REPEATABLE\_READ 隔离级别

## 可重复读解决了哪些问题？ ##

*  可重复读的核心就是一致性读(consistent read);保证多次读取同一个数据时，其值都和事务开始时候的内容是一致，禁止读取到别的事务未提交的数据，会造成幻读。
 *  而事务更新数据的时候，只能用当前读。如果当前的记录的行锁被其他事务占用的话，就需要进入锁等待。
 *  查询只承认在事务启动前就已经提交完成的数据。
 *  可重复读解决的是重复读的问题，可重复读在快照读的情况下是不会有幻读，但当前读的时候会有幻读

## 对 SQL 慢查询会考虑哪些优化 ？ ##

*  分析语句，是否加载了不必要的字段/数据。
 *  分析 SQL 执行计划（explain extended），思考可能的优化点，是否命中索引等。
 *  查看 SQL 涉及的表结构和索引信息。
 *  如果 SQL 很复杂，优化 SQL 结构。
 *  按照可能的优化点执行表结构变更、增加索引、SQL 改写等操作。
 *  查看优化后的执行时间和执行计划。
 *  如果表数据量太大，考虑分表。
 *  利用缓存，减少查询次数。

## 谈一谈缓存穿透、缓存击穿和缓存雪崩，以及解决办法？ ##

*  缓存穿透
    
     *  问题：大量并发查询不存在的 KEY，在缓存和数据库中都不存在，同时给缓存和数据库带来压力。
     *  原因：一般而言，缓存穿透有 2 种可能性：业务数据被误删，导致缓存和数据库中都没有数据。恶意进行 ddos 攻击。
     *  分析：为什么会多次透传呢？不存在 一直为空，需要注意让缓存能够区分 KEY 不存在和查询到一个空值。
     *  解决办法：缓存空值的 KEY，这样第一次不存在也会被加载会记录，下次拿到有这个key。Bloom 过滤或 RoaingBitmap 判断 KEY 是否存在，如果布隆过滤器中没有查到这个数据，就不去数据库中查。在处理请求前增加恶意请求检查，如果检测到是恶意攻击，则拒绝进行服务。完全以缓存为准，使用延迟异步加载的策略（异步线程负责维护缓存的数据，定期或根据条件触发更新），这样就不会触发更新。
 *  缓存击穿
    
     *  问题：某个 KEY 失效的时候，正好有大量并发请求访问这个 KEY。
     *  分析：跟穿透其实很像，属于比较偶然的。
     *  解决办法：KEY 的更新操作添加全局互斥锁。完全以缓存为准，使用延迟异步加载的策略（异步线程负责维护缓存的数据，定期或根据条件触发更新），这样就不会触发更新。
 *  缓存雪崩
    
     *  问题：当某一时刻发生大规模的缓存失效情况，导致大量的请求无法获取数据，从而将流量压力传导到数据库上，导致数据库压力过大甚至宕机。
     *  原因：一般而言，缓存雪崩有 2 种可能性：大量的数据同一个时间失效：比如业务关系强相关的数据要求同时失效 Redis 宕机
     *  分析：一般来说，由于更新策略、或者数据热点、缓存服务宕机等原因，可能会导致缓存数据同一个时间点大规模不可用，或者都更新。所以，需要我们的更新策略要在时间上合适，数据要均匀分享，缓存服务器要多台高可用。
     *  解决办法：更新策略在时间上做到比较平均。如果数据需要同一时间失效，可以给这批数据加上一些随机值，使得这批数据不要在同一个时间过期，降低数据库的压力。使用的热数据尽量分散到不同的机器上。多台机器做主从复制或者多副本，实现高可用。做好主从的部署，当主节点挂掉后，能快速的使用从结点顶上。实现熔断限流机制，对系统进行负载能力控制。对于非核心功能的业务，拒绝其请求，只允许核心功能业务访问数据库获取数据。服务降价：提供默认返回值，或简单的提示信息。

## 什么是堆内存？参数如何设置？ ##

堆内存是指由程序代码自由分配的内存，与栈内存作区分。  
在 Java 中，堆内存主要用于分配对象的存储空间，只要拿到对象引用，所有线程都可以访问堆内存。

*  \-Xmx, 指定最大堆内存。 如 -Xmx4g. 这只是限制了 Heap 部分的最大值为 4g。这个内统实际分配的初始值，而是 GC 先规划好，用到才分配。 专用服务器上需要保持 –Xms和 –Xmx 一致，否则应用刚启动可能就有好几个 FullGC。当两者配置不一致时，堆内存扩容可能会导致性能抖动。
 *  \-Xmn, 等价于 -XX:NewSize，使用 G1 垃圾收集器 不应该 设置该选项，在其他的某存不包括栈内存，也不包括堆外使用的内存。
 *  \-Xms, 指定堆内存空间的初始大小。 如 -Xms4g。 而且指定的内存大小，并不是操作系些业务场景下可以设置。官方建议设置为 -Xmx 的 1/2 ~ 1/4.  -XX：MaxPermSize=size, 这是 JDK1.7 之前使用的。Java8 默认允许的 Meta 空间无限大，此参数无效。
 *  \-XX：MaxMetaspaceSize=size, Java8 默认不限制 Meta 空间, 一般不允许设置该选项。
 *  \-XX：MaxDirectMemorySize=size，系统可以使用的最大堆外内存，这个参数跟 -Dsun.nio.MaxDirectMemorySize 效果相同。
 *  \-Xss, 设置每个线程栈的字节数。 例如 -Xss1m 指定线程栈为 1MB，与- XX:ThreadStackSize=1m 等

## MySQL 索引底层结构为什么使用 B+树？ ##

*  哈希虽然能够提供 O(1) 的单数据行操作性能，但是对于范围查询和排序却无法很好地支持，最终导致全表扫描；B 树能够在非叶节子点中存储数据，但是这也导致在查询连续数据时可能会带来更多的随机 I/O，而 B+树的所有叶节点可以通过指针相互连接，能够减少顺序遍历时产生的额外随机 I/O；
 *  第一，B 树一个节点里存的是数据，而 B+树存储的是索引（地址），所以 B 树里一个节点存不了很多个数据，但是 B+树一个节点能存很多索引，B+树叶子节点存所有的数据。
 *  第二，B+树的叶子节点是数据阶段用了一个链表串联起来，便于范围查找。

## B+ 树的叶子节点链表是单向还是双向？ ##

双向链表

## MVCC 是什么？它的底层原理是什么？ ##

MVCC，多版本并发控制,它是通过读取历史版本的数据，来降低并发事务冲突，从而提高并发性能的一种机制。

*  事务版本号
 *  表的隐藏列
 *  undo log
 *  read view

## undo log 具体怎么回滚事务 ？ ##

举个例子：

*  对于 insert 类型的 sql，会在 undo log 中记录下刚才你 insert 进来的数据的 ID，当你想 roll back 时，根据 ID 完成精准的删除。
 *  对于 delete 类型的 sql，会在 undo log 中记录刚才你删除的数据，当你回滚时会将删除前的数据 insert 进去。
 *  对于 update 类型的 sql，会在 undo log 中记录下修改前的数据，回滚时只需要反向update 即可。
 *  对于 select 类型的 sql，别费心了，select 不需要回滚

## 如何查询慢 SQL 产生的原因 ##

*  分析 SQL 执行计划（explain extended），思考可能的优化点，是否命中索引等。
 *  没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷)。
 *  内存不足。
 *  网络速度慢。
 *  是否查询出的数据量过大（可以采用多次查询，其他的方法降低数据量）。
 *  是否返回了不必要的行和列。
 *  锁或者死锁。
 *  I/O 吞吐量小，形成了瓶颈效应。
 *  sp\_lock,sp\_who,活动的用户查看,原因是读写竞争资源。

## 索引失效的情况有哪些？ ##

*  like 以%开头索引无效，当 like 以&结尾，索引有效。
 *  or 语句前后没有同时使用索引，当且仅当 or 语句查询条件的前后列均为索引时，索引生效。
 *  组合索引，使用的不是第一列索引时候，索引失效，即最左匹配规则。
 *  数据类型出现隐式转换，如 varchar 不加单引号的时候可能会自动转换为 int 类型，这得。
 *  在索引字段上使用，NOT、 <>、！= 、时候是不会使用索引的，对于这样的处理只会个时候索引失效。
 *  在索引列上使用 IS NULL 或者 IS NOT NULL 时候，索引失效，因为索引是不索引空值进行全表扫描。
 *  对索引字段进行计算操作，函数操作时不会使用索引。
 *  当全表扫描速度比索引速度快的时候不会使用索引。

## Redis 数据结构 压缩列表和跳跃表的区别 ##

*  压缩列表（ziplist）本质上就是一个字节数组，是 Redis 为了节约内存而设计的一种线性数据结构，可以包含多个元素，每个元素可以是一个字节数组或一个整数。
 *  跳跃表（skiplist）是一种有序数据结构，它通过在每个节点中维持多个指向其他节点的指针，从而达到快速访问节点的目的。跳跃表支持平均 O（logN）、最坏 O（N）复杂度的节点查找，还可以通过顺序性操作来批量处理节点。

## Redis 主从同步是怎么实现的？ ##

*  全量同步  
    master 服务器会开启一个后台进程用于将 redis 中的数据生成一个 rdb 文件，与此同时，服务器会缓存所有接收到的来自客户端的写命令（包含增、删、改），当后台保存进程处理完毕后，会将该 rdb 文件传递给 slave 服务器，而 slave 服务器会将 rdb 文件保存在磁盘并通过读取该文件将数据加载到内存，在此之后 master 服务器会将在此期间缓存的命令通过 redis 传输协议发送给 slave 服务器，然后 slave 服务器将这些命令依次作用于自己本地的数据集上最终达到数据的一致性。
 *  增量同步  
    从 redis 2.8 版本以前，并不支持部分同步，当主从服务器之间的连接断掉之后，master 服务器和 slave 服务器之间都是进行全量数据同步。  
    从 redis 2.8 开始，即使主从连接中途断掉，也不需要进行全量同步，因为从这个版本开始融入了部分同步的概念。部分同步的实现依赖于在 master 服务器内存中给每个 slave 服务器维护了一份同步日志和同步标识，每个slave服务器在跟master服务器进行同步时都会携带自己的同步标识和上次同步的最后位置。当主从连接断掉之后，slave服务器隔断时间（默认 1s）主动尝试和master 服务器进行连接，如果从服务器携带的偏移量标识还在master 服务器上的同步备份日志中，那么就从 slave 发送的偏移量开始继续上次的同步操作，如果 slave 发送的偏移量已经不再 master 的同步备份日志中（可能由于主从之间断掉的时间比较长或者在断掉的短暂时间内 master 服务器接收到大量的写操作），则必须进行一次全量更新。在部分同步过程中，master 会将本地记录的同步备份日志中记录的指令依次发送给 slave 服务器从而达到数据一致。
 *  Redis 主从同步策略  
    主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，  
    slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，  
    如不成功，要求从机进行全量同步。

## Redis 持久化 RDB 和 AOF 优缺点 ##

### RDB ###

RDB 持久化方式，是将 Redis 某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。

*  RDB 优点：
    
     *  RDB 是一个非常紧凑（有压缩）的文件,它保存了某个时间点的数据,非常适用于数据的备份。
     *  RDB 作为一个非常紧凑（有压缩）的文件，可以很方便传送到另一个远端数据中心 ，非常适用于灾难恢复。
     *  RDB 在保存 RDB 文件时父进程唯一需要做的就是 fork 出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他 IO 操作，所以 RDB 持久化方式可以最大化redis 的性能。
     *  与 AOF 相比，在恢复大的数据集的时候，RDB 方式会更快一些。
 *  RDB 缺点：
    
     *  Redis 意外宕机时，会丢失部分数据。
     *  当 Redis 数据量比较大时，fork 的过程是非常耗时的，fork 子进程时是会阻塞的，在这期间 Redis 是不能响应客户端的请求的。

### AOF ###

AOF 方式是将执行过的写指令记录下来，在数据恢复时按照从前到后的顺序再将指令都执行一遍。

*  AOF 优点：
    
     *  使用 AOF 会让你的 Redis 更加持久化。
     *  AOF 文件是一个只进行追加的日志文件，不需要在写入时读取文件。
     *  Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写 。
     *  AOF 文件可读性高，分析容易。
 *  AOF 缺点：
    
     *  对于相同的数据来说，AOF 文件大小通常要大于RDB文件。
     *  根据所使用的fsync策略，AOF的速度可能慢于RDB。

## 谈谈自己对于Spring AOP的了解？ ##

AOP(Aspect-Oriented Programming:面向切面编程)能够将那些与业务无关，却为业务模块所共同调用的逻辑或责任（例如事务处理、日志管理、权限控制等）封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可拓展性和可维护性。

## Spring Bean容器的生命周期是什么样的？ ##

Bean 容器找到配置文件中 Spring Bean 的定义。

*  Bean 容器利用 Java Reflection API 创建一个 Bean 的实例。
 *  如果涉及到一些属性值 利用 set()方法设置一些属性值。
 *  如果 Bean 实现了 BeanNameAware 接口，调用 setBeanName()方法，传入 Bean 的名字。
 *  如果 Bean 实现了 BeanClassLoaderAware 接口，调用 setBeanClassLoader()方法，传入 ClassLoader 对象的实例。
 *  如果 Bean 实现了 BeanFactoryAware 接口，调用 setBeanFactory()方法，传入BeanFactory 对象的实例。
 *  与上面的类似，如果实现了其他 \*.Aware 接口，就调用相应的方法。
 *  如果有和加载这个 Bean 的 Spring 容器相关的 `BeanPostProcessor` 对象，执行`postProcessBeforeInitialization()` 方法
 *  如果 Bean 实现了 InitializingBean 接口，执行 afterPropertiesSet()方法。
 *  如果 Bean 在配置文件中的定义包含 init-method 属性，执行指定的方法。
 *  如果有和加载这个 Bean 的 Spring 容器相关的 BeanPostProcessor 对象，执行  
    postProcessAfterInitialization() 方法
 *  当要销毁 Bean 的时候，如果 Bean 实现了 DisposableBean 接口，执行 destroy() 方法。
 *  当要销毁 Bean 的时候，如果 Bean 在配置文件中的定义包含 destroy-method 属性，执行指定的方法。

## RabbitMQ 如何保证消息不丢失 ？ ##

生产者：  
方案 1：开启 RabbitMQ 事务(同步，性能差)  
方案 2：开启 confirm 模式(异步，性能较好)  
MQ：(1)exchange 持久化 (2)queue 持久化 (3)消息持久化  
消费者：关闭自动 ACK