美团OC了，给的挺多！很满意！！

一直以来，美团在网友口中常被戏称为"开水团"，意指除了开水管够，其他福利相对平平。然而，从今年 25 届的校招薪资来看，美团这次给出的诚意还是不错的。

根据目前收集到的信息，美团 25 届校招的部分薪资爆料如下：

后端：23K*15.5，硕士 211，北京，白菜
后端：25K*15.5，硕士 985，北京，小 SP
后端：28K*15.5，硕士 211，北京，大 SP
前端：23K*15.5，硕士 985，北京，白菜
算法：28K*15.5，硕士双一流，北京，白菜
算法：30K*15.5，硕士海归，北京，小 SP

接下来，分享一位球友的美团+华为校招面经，大家感受一下难度如何。

因为实习结束得比较晚，我的秋招直到 10 月中下旬才正式拉开序幕。当时看到有分享说大厂秋招已近尾声，心里着实凉了半截。后来的求职经历也印证了这一点，在众多投递中，最终只收到了美团和华为的面试邀约。幸运的是，前几天顺利拿到了美团的 Offer，华为还在池子里"泡澡"。在这里，我想把这段经历分享出来，希望能给还在路上的同学们一些参考。

完整面经地址：美团 OC 了！给的挺多！！，下面这些面试问题都摘自这篇面经。

计算机基础

请说明产生死锁的四个必要条件，以及有哪些预防死锁的策略？

互斥：资源必须处于非共享模式，即一次只有一个进程可以使用。如果另一进程申请该资源，那么必须等待直到该资源被释放为止。
占有并等待：一个进程至少应该占有一个资源，并等待另一资源，而该资源被其他进程所占有。
非抢占：资源不能被抢占。只能在持有资源的进程完成任务后，该资源才会被释放。
循环等待 ：有一组等待进程 {P0, P1,..., Pn}， P0 等待的资源被 P1 占有，P1 等待的资源被 P2 占有，......，Pn-1 等待的资源被 Pn 占有，Pn 等待的资源被 P0 占有。

注意 ⚠️ ：这四个条件是产生死锁的 必要条件 ，也就是说只要系统发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。

下面是百度百科对必要条件的解释：

如果没有事物情况 A，则必然没有事物情况 B，也就是说如果有事物情况 B 则一定有事物情况 A，那么 A 就是 B 的必要条件。从逻辑学上看，B 能推导出 A，A 就是 B 的必要条件，等价于 B 是 A 的充分条件。

死锁四大必要条件上面都已经列出来了，很显然，只要破坏四个必要条件中的任何一个就能够预防死锁的发生。

破坏第一个条件 互斥条件 ：使得资源是可以同时访问的，这是种简单的方法，磁盘就可以用这种方法管理，但是我们要知道，有很多资源 往往是不能同时访问的 ，所以这种做法在大多数的场合是行不通的。

破坏第三个条件 非抢占 ：也就是说可以采用 剥夺式调度算法 ，但剥夺式调度方法目前一般仅适用于 主存资源 和 处理器资源 的分配，并不适用于所有的资源，会导致 资源利用率下降。

所以一般比较实用的 预防死锁的方法，是通过考虑破坏第二个条件和第四个条件。

1、静态分配策略

静态分配策略可以破坏死锁产生的第二个条件（占有并等待）。所谓静态分配策略，就是指一个进程必须在执行前就申请到它所需要的全部资源，并且知道它所要的资源都得到满足之后才开始执行。进程要么占有所有的资源然后开始执行，要么不占有资源，不会出现占有一些资源等待一些资源的情况。

静态分配策略逻辑简单，实现也很容易，但这种策略 严重地降低了资源利用率 ，因为在每个进程所占有的资源中，有些资源是在比较靠后的执行时间里采用的，甚至有些资源是在额外的情况下才使用的，这样就可能造成一个进程占有了一些 几乎不用的资源而使其他需要该资源的进程产生等待 的情况。

2、层次分配策略

层次分配策略破坏了产生死锁的第四个条件(循环等待)。在层次分配策略下，所有的资源被分成了多个层次，一个进程得到某一次的一个资源后，它只能再申请较高一层的资源；当一个进程要释放某层的一个资源时，必须先释放所占用的较高层的资源，按这种策略，是不可能出现循环等待链的，因为那样的话，就出现了已经申请了较高层的资源，反而去申请了较低层的资源，不符合层次分配策略，证明略。

进程间的通信方式有哪些？

管道/匿名管道(Pipes) ：用于具有亲缘关系的父子进程间或者兄弟进程之间的通信。
有名管道(Named Pipes) : 匿名管道由于没有名字，只能用于亲缘关系的进程间通信。为了克服这个缺点，提出了有名管道。有名管道严格遵循 先进先出(First In First Out) 。有名管道以磁盘文件的方式存在，可以实现本机任意两个进程通信。
信号(Signal) ：信号是一种比较复杂的通信方式，用于通知接收进程某个事件已经发生；
消息队列(Message Queuing) ：消息队列是消息的链表,具有特定的格式,存放在内存中并由消息队列标识符标识。管道和消息队列的通信数据都是先进先出的原则。与管道（无名管道：只存在于内存中的文件；命名管道：存在于实际的磁盘介质或者文件系统）不同的是消息队列存放在内核中，只有在内核重启(即，操作系统重启)或者显式地删除一个消息队列时，该消息队列才会被真正的删除。消息队列可以实现消息的随机查询,消息不一定要以先进先出的次序读取,也可以按消息的类型读取.比 FIFO 更有优势。消息队列克服了信号承载信息量少，管道只能承载无格式字节流以及缓冲区大小受限等缺点。
信号量(Semaphores) ：信号量是一个计数器，用于多进程对共享数据的访问，信号量的意图在于进程间同步。这种通信方式主要用于解决与同步相关的问题并避免竞争条件。
共享内存(Shared memory) ：使得多个进程可以访问同一块内存空间，不同进程可以及时看到对方进程中对共享内存中数据的更新。这种方式需要依靠某种同步操作，如互斥锁和信号量等。可以说这是最有用的进程间通信方式。
套接字(Sockets) : 此方法主要用于在客户端和服务器之间通过网络进行通信。套接字是支持 TCP/IP 的网络通信的基本操作单元，可以看做是不同主机之间的进程进行双向通信的端点，简单的说就是通信的两方的一种约定，用套接字中的相关函数来完成通信过程。

更多操作系统面试题总结，可以阅读笔者写的这几篇文章：

请描述 TCP 的三次握手过程

建立一个 TCP 连接需要"三次握手"，缺一不可：

一次握手 :客户端发送带有 SYN（SEQ=x）标志的数据包 -> 服务端，然后客户端进入 SYN_SEND 状态，等待服务端的确认；
二次握手 :服务端发送带有 SYN+ACK(SEQ=y,ACK=x+1) 标志的数据包 --> 客户端,然后服务端进入 SYN_RECV 状态；
三次握手 :客户端发送带有 ACK(ACK=y+1) 标志的数据包 --> 服务端，然后客户端和服务端都进入ESTABLISHED 状态，完成 TCP 三次握手。

当建立了 3 次握手之后，客户端和服务端就可以传输数据啦！

为什么需要三次握手，两次握手可以吗？

三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常
第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常
第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常

三次握手就能确认双方收发功能都正常，缺一不可。

详细介绍可以看看这篇文章：TCP 三次握手和四次挥手（传输层）。

Java

请描述一下 LinkedHashMap 的底层数据结构

LinkedHashMap 是 Java 提供的一个集合类，它继承自 HashMap，并在 HashMap 基础上维护一条双向链表，使得具备如下特性:

支持遍历时会按照插入顺序有序进行迭代。
支持按照元素访问顺序排序,适用于封装 LRU 缓存工具。
因为内部使用双向链表维护各个节点，所以遍历时的效率和元素个数成正比，相较于和容量成正比的 HashMap 来说，迭代效率会高很多。

LinkedHashMap 逻辑结构如下图所示，它是在 HashMap 基础上在各个节点之间维护一条双向链表，使得原本散列在不同 bucket 上的节点、链表、红黑树有序关联起来。

Java 中的 Integer 类型是否存在缓存机制？它的范围是多少？

Java 基本数据类型的包装类型的大部分都用到了缓存机制来提升性能。

Byte,Short,Integer,Long 这 4 种包装类默认创建了数值 [-128，127] 的相应类型的缓存数据，Character 创建了数值在 [0,127] 范围的缓存数据，Boolean 直接返回 TRUE or FALSE。

对于 Integer，可以通过 JVM 参数 -XX:AutoBoxCacheMax=<size> 修改缓存上限，但不能修改下限 -128。实际使用时，并不建议设置过大的值，避免浪费内存，甚至是 OOM。

Integer 缓存源码：

java 复制代码

public static Integer valueOf(int i) {
    if (i >= IntegerCache.low && i <= IntegerCache.high)
        return IntegerCache.cache[i + (-IntegerCache.low)];
    return new Integer(i);
}
private static class IntegerCache {
    static final int low = -128;
    static final int high;
    static {
        // high value may be configured by property
        int h = 127;
    }
}

存储最多 100 个元素到 HashMap 中，初始容量应该设置为多大不库容？

HashMap 的扩容机制是由其容量和负载因子 （默认为 0.75）决定的。当 size >= capacity * loadFactor 时就会扩容。为了避免这种情况，我们需要让 capacity * 0.75 的值始终大于 100。也就是说，理论容量必须大于 133.33。同时，HashMap 的实际容量总是 2 的幂次方。当我们传入一个初始容量值时，它会内部调整为大于等于该值的最小的 2 的幂。因此，当我们传入 134 时，HashMap 的实际容量会被设置为 256。

MySQL

请解释一下 MySQL 的联合索引及其最左前缀原则

使用表中的多个字段创建索引，就是 联合索引 ，也叫 组合索引 或 复合索引。

以 score 和 name 两个字段建立联合索引：

sql 复制代码

ALTER TABLE `cus_order` ADD INDEX id_score_name(score, name);

最左前缀匹配原则指的是在使用联合索引时，MySQL 会根据索引中的字段顺序，从左到右依次匹配查询条件中的字段。如果查询条件与索引中的最左侧字段相匹配，那么 MySQL 就会使用索引来过滤数据，这样可以提高查询效率。

最左匹配原则会一直向右匹配，直到遇到范围查询（如 >、<）为止。对于 >=、<=、BETWEEN 以及前缀匹配 LIKE 的范围查询，不会停止匹配（相关阅读：联合索引的最左匹配原则全网都在说的一个错误结论）。

假设有一个联合索引 (column1, column2, column3)，其从左到右的所有前缀为 (column1)、(column1, column2)、(column1, column2, column3)（创建 1 个联合索引相当于创建了 3 个索引），包含这些列的所有查询都会走索引而不会全表扫描。

我们在使用联合索引时，可以将区分度高的字段放在最左边，这也可以过滤更多数据。

我们这里简单演示一下最左前缀匹配的效果。

1、创建一个名为 student 的表，这张表只有 id、name、class 这 3 个字段。

sql 复制代码

CREATE TABLE `student` (
  `id` int NOT NULL,
  `name` varchar(100) DEFAULT NULL,
  `class` varchar(100) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `name_class_idx` (`name`,`class`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

2、下面我们分别测试三条不同的 SQL 语句。

sql 复制代码

# 可以命中索引
SELECT * FROM student WHERE name = 'Anne Henry';
EXPLAIN SELECT * FROM student WHERE name = 'Anne Henry' AND class = 'lIrm08RYVk';
# 无法命中索引
SELECT * FROM student WHERE class = 'lIrm08RYVk';

再来看一个常见的面试题：如果有索引 联合索引（a，b，c），查询 a=1 AND c=1 会走索引么？c=1 呢？b=1 AND c=1 呢？ b = 1 AND a = 1 AND c = 1 呢？

先不要往下看答案，给自己 3 分钟时间想一想。

查询 a=1 AND c=1：根据最左前缀匹配原则，查询可以使用索引的前缀部分。因此，该查询仅在 a=1 上使用索引，然后对结果进行 c=1 的过滤。
查询 c=1：由于查询中不包含最左列 a，根据最左前缀匹配原则，整个索引都无法被使用。
查询 b=1 AND c=1：和第二种一样的情况，整个索引都不会使用。
查询 b=1 AND a=1 AND c=1：这个查询是可以用到索引的。查询优化器分析 SQL 语句时，对于联合索引，会对查询条件进行重排序，以便用到索引。会将 b=1 和 a=1 的条件进行重排序，变成 a=1 AND b=1 AND c=1。

MySQL 8.0.13 版本引入了索引跳跃扫描（Index Skip Scan，简称 ISS），它可以在某些索引查询场景下提高查询效率。在没有 ISS 之前，不满足最左前缀匹配原则的联合索引查询中会执行全表扫描。而 ISS 允许 MySQL 在某些情况下避免全表扫描，即使查询条件不符合最左前缀。不过，这个功能比较鸡肋，和 Oracle 中的没法比，MySQL 8.0.31 还报告了一个 bug：Bug #109145 Using index for skip scan cause incorrect result（后续版本已经修复）。个人建议知道有这个东西就好，不需要深究，实际项目也不一定能用上。

请说明事务的四大特性是什么？

关系型数据库（例如：MySQL、SQL Server、Oracle 等）事务都有 ACID 特性：

原子性 （Atomicity）：事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用；
一致性 （Consistency）：执行事务前后，数据保持一致，例如转账业务中，无论事务是否成功，转账者和收款人的总额应该是不变的；
隔离性 （Isolation）：并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的；
持久性 （Durability）：一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。

🌈 这里要额外补充一点：只有保证了事务的持久性、原子性、隔离性之后，一致性才能得到保障。也就是说 A、I、D 是手段，C 是目的！ 想必大家也和我一样，被 ACID 这个概念被误导了很久! 我也是看周志明老师的公开课《周志明的软件架构课》才搞清楚的（多看好书！！！）。

MySQL 是如何保证事务的持久性（Durability）的？

MySQL InnoDB 引擎使用 redo log 来保证事务的持久性。redo log 主要做的事情就是记录页的修改，比如某个页面某个偏移量处修改了几个字节的值以及具体被修改的内容是什么。redo log 中的每一条记录包含了表空间号、数据页号、偏移量、具体修改的数据，甚至还可能会记录修改数据的长度（取决于 redo log 类型）。

在事务提交时，我们会将 redo log 按照刷盘策略刷到磁盘上去，这样即使 MySQL 宕机了，重启之后也能恢复未能写入磁盘的数据，从而保证事务的持久性。也就是说，redo log 让 MySQL 具备了崩溃恢复能力。

请介绍一下你了解的 MySQL 日志类型及其作用

MySQL 中常见的日志类型主要有下面几类（针对的是 InnoDB 存储引擎）：

错误日志（error log） ：对 MySQL 的启动、运行、关闭过程进行了记录。
二进制日志（binary log，binlog） ：主要记录的是更改数据库数据的 SQL 语句。
一般查询日志（general query log） ：已建立连接的客户端发送给 MySQL 服务器的所有 SQL 记录，因为 SQL 的量比较大，默认是不开启的，也不建议开启。
慢查询日志（slow query log） ：执行时间超过 long_query_time秒钟的查询，解决 SQL 慢查询问题的时候会用到。
事务日志(redo log 和 undo log) ：redo log 是重做日志，可以保证事务持久性。undo log 是回滚日志，可以保证事务原子性。
中继日志(relay log) ：relay log 是复制过程中产生的日志，很多方面都跟 binary log 差不多。不过，relay log 针对的是主从复制中的从库。
DDL 日志(metadata log) ：DDL 语句执行的元数据操作。

更多 MySQL 面试题总结可以阅读笔者写的这篇文章：MySQL 常见面试题总结（MySQL 基础、存储引擎、事务、索引、锁、性能优化等）

其他

布隆过滤器的原理和应用场景

当一个元素加入布隆过滤器中的时候，会进行如下操作：

使用布隆过滤器中的哈希函数对元素值进行计算，得到哈希值（有几个哈希函数得到几个哈希值）。
根据得到的哈希值，在位数组中把对应下标的值置为 1。

当我们需要判断一个元素是否存在于布隆过滤器的时候，会进行如下操作：

对给定元素再次进行相同的哈希计算；
得到值之后判断位数组中的每个元素是否都为 1，如果值都为 1，那么说明这个值在布隆过滤器中，如果存在一个值不为 1，说明该元素不在布隆过滤器中。

Bloom Filter 的简单原理图如下：

如图所示，当字符串存储要加入到布隆过滤器中时，该字符串首先由多个哈希函数生成不同的哈希值，然后将对应的位数组的下标设置为 1（当位数组初始化时，所有位置均为 0）。当第二次存储相同字符串时，因为先前的对应位置已设置为 1，所以很容易知道此值已经存在（去重非常方便）。

如果我们需要判断某个字符串是否在布隆过滤器中时，只需要对给定字符串再次进行相同的哈希计算，得到值之后判断位数组中的每个元素是否都为 1，如果值都为 1，那么说明这个值在布隆过滤器中，如果存在一个值不为 1，说明该元素不在布隆过滤器中。

不同的字符串可能哈希出来的位置相同，这种情况我们可以适当增加位数组大小或者调整我们的哈希函数。

综上，我们可以得出：布隆过滤器说某个元素存在，小概率会误判。布隆过滤器说某个元素不在，那么这个元素一定不在。

布隆过滤器使用场景：

判断给定数据是否存在：比如判断一个数字是否存在于包含大量数字的数字集中（数字集很大，上亿）、防止缓存穿透（判断请求的数据是否有效避免直接绕过缓存请求数据库）等等、邮箱的垃圾邮件过滤（判断一个邮件地址是否在垃圾邮件列表中）、黑名单功能（判断一个 IP 地址或手机号码是否在黑名单中）等等。
去重：比如爬给定网址的时候对已经爬取过的 URL 去重、对巨量的 QQ 号/订单号去重。

去重场景也需要用到判断给定数据是否存在，因此布隆过滤器主要是为了解决海量数据的存在性问题。

了解一致性哈希算法吗？解决了什么问题？

先说两个常见的场景：

负载均衡：由于访问人数太多，我们的网站部署了多台服务器个共同提供相同的服务，但每台服务器上存储的数据不同。为了保证请求的正确响应，相同参数（key）的请求（比如同个 IP 的请求、同一个用户的请求）需要发到同一台服务器处理。
分布式缓存：由于缓存数据量太大，我们部署了多台缓存服务器共同提供缓存服务。缓存数据需要尽可能均匀地分布式在这些缓存服务器上，通过 key 可以找到对应的缓存服务器。

这两种场景本质上都是需要建立 key 到服务器/节点的唯一映射关系。

为了应对这种需求，你会有什么方案呢？

相信大家很快就能想到 哈希算法+取模 。通过哈希算法得到哈希值，再用取模来将哈希值映射到固定的范围内。

公式也很简单：

java 复制代码

node_number = hash(key) % N

hash(key): 使用哈希函数（建议使用性能较好的非加密哈希函数，例如 SipHash、MurMurHash3、CRC32、DJB）对唯一键进行哈希。
% N: 对哈希值取模，将哈希值映射到一个介于 0 到 N-1 之间的值，N 为节点数/服务器数。

然而，传统的哈希取模算法有一个比较大的缺陷就是：无法很好的解决机器/节点动态减少（比如某台机器宕机）或者增加的场景（比如又增加了一台机器）。

举个例子：服务器的初始数量为 4 台（N = 4），由于某台服务器宕机，导致服务器数 N 变为 3 。这个时候计算出来的数据存放的位置就改变了。这样的话，就会导致 key 和服务器的映射关系错乱了。

实际开发中，这是非常不可取的，可能会导致严重的错误。例如，分布式缓存场景下会导致大量缓存无法命中、负载均衡场景下会导致大量请求被转发到错误的服务器上。

解决也确实可以解决，直接按照新的映射关系做数据迁移即可。但这么做的成本太高了，需要迁移的数据太多，太复杂。

为了更好地解决这个问题，一致性哈希算法诞生了。

一致性哈希算法将哈希空间组织成一个环形结构，将数据和节点都映射到这个环上，然后根据顺时针的规则确定数据或请求应该分配到哪个节点上。通常情况下，哈希环的起点是 0，终点是 2^32 - 1，并且起点与终点连接，故这个环的整数分布范围是 [0, 2^32-1]。

传统哈希算法是对服务器数量取模，一致性哈希算法是对哈希环的范围取模，固定值，通常为 2^32：

java 复制代码

node_number = hash(key) % 2^32

服务器/节点如何映射到哈希环上呢？也是哈希取模。例如，一般我们会根据服务器的 IP 或者主机名进行哈希，然后再取模。

java 复制代码

hash（服务器ip）% 2^32

如下图所示：

我们将数据和节点都映射到哈希环上，环上的每个节点都负责一个区间。对于上图来说，每个节点负责的数据情况如下：

Node1:value6
Node2:value1,value2
Node3:value3
Node4:value5,value5

新增节点和移除节点的情况下，哈希环的引入可以避免影响范围太大，减少需要迁移的数据。

虚拟节点就是对真实的物理节点在哈希环上虚拟出几个它的分身节点。数据落到分身节点上实际上就是落到真实的物理节点上，通过将虚拟节点均匀分散在哈希环的各个部分。

虚拟节点越多，哈希环上的节点就越多，数据被均匀分布的概率就越大。通常，每个真实节点对应的虚拟节点数在 100 到 200 之间，例如 Nginx 选择为每个权重分配 160 个虚拟节点。这里的权重的是为了区分服务器，例如处理能力更强的服务器权重越高，进而导致对应的虚拟节点越多，被命中的概率越大。

可以看到，通过引入虚拟节点+权重，还平衡了不同节点的处理能力。

如下图所示，Node1、Node2、Node3、Node4 这 4 个节点都对应 3 个虚拟节点（下图只是为了演示，实际情况节点分布不会这么有规律）。

对于上图来说，每个节点最终负责的数据情况如下：

Node1:value4
Node2:value1,value3
Node3:value5
Node4:value2,value6