饿了么 Java面试
饿了么 Java面试
阿里巴巴 集团有很多，比如阿里云、淘宝、饿了么 、灵犀互娱等等 ，现在面试都是每个集团各自负责 ，都有各自的招聘官方招聘网。因此，每个集团的校招开奖时间也不 同。
目前看到饿了么 率先开奖了，饿了么 25 届校招 Java 岗位的薪资开奖情况：
普通 offer ：24k x 16 =38w
sp offer ：26k x 16 + 2w 签字费（部分同学有） = 41w+
这薪资待遇其实已经很不错了，妥妥 的是大厂水平了，不过也有一些同学反馈不及预期。
我觉得主要是因为美团和京东今 年校招薪资比去年多了不 少，对比下来的话，可能就相对不够看了。
实在太卷了，各大厂相互卷校招薪资，都在用极具有竞争力的待遇来招优秀的人才，当然受益的 就是 25 届同学啦，妥妥 羡慕了。
这次跟大家分享一位同学今年秋招饿了么 的Java 后端面经，这是一面的面就，是电话面试的方式，主要是考察技术八股为主 ，涉及到的范围是Java 、MySQL 、Redis 的知识。
饿了么 （电话一面）
ArrayList 和LinkedList 区别？
ArrayList 和LinkedList 都是Java 中常见的集合类，它们都实现了List 接口。
底层数据结构不同：ArrayList 使用数组实现，通过索引进行快速访问元素。LinkedList 使用链表实现，通过节点之间的指针进行元素的访问和操作。
插入和删除操作的效率不同：ArrayList 在尾部的插入和删除操作效率较高，但在中间或开头的插入和删除操作效率较低，需要移动元素。LinkedList 在任意位置的插入和删除操作效率都比较高，因为只需要调整节点之间的指针。
随机访问的效率不同：ArrayList 支持通过索引进行快速随机访问，时间复杂度为O(1) 。
LinkedList 需要从头或尾开始遍历链表，时间复杂度为O(n) 。
空间占用：ArrayList 在创建时需要分配一段连续的内存空间，因此会占用较大的空间。
LinkedList 每个节点只需要存储元素和指针，因此相对较小。
使用场景：ArrayList 适用于频繁随机访问和尾部的插入删除操作，而LinkedList 适用于频繁的中间插入删除操作和不需要随机访问的场景。
线程安全：这两个 集合都不是线程安全的，Vector 是线程安全的
讲下HashMap ？
在 JDK 1.7 版本之前， HashMap 数据结构是数组和链表，HashMap 通过哈希算法将元素的键
（Key ）映射到数组中的槽位（Bucket ）。如果多个键映射到同一个槽位，它们会以 链表的形式 存储在同一个槽位上，因为链表的查询时间是O(n) ，所以冲突很严重，一个索引上的链表非常长，效率就很低了。
所以在 JDK 1.8 版本的时候做 了优化，当一个链表的长度超过8的时候就转换数据结构，不再使用链表存储，而是使用红黑树，查找时使用红黑树，时间复杂度O（log n ），可以提高查询性能，但是在数量较少时，即数量小于6时，会将红黑树转换回链表。
讲下ConcurrentHashMap ？
JDK 1.7 ConcurrentHashMap
在 JDK 1.7 中它使用的是数组加链表的形式 实现的，而数组又分为：大数组 Segment 和小数组
HashEntry 。 Segment 是一种可重入锁（ReentrantLock ），在 ConcurrentHashMap 里扮演锁的角色；HashEntry 则用于存储键值对数据。一个 ConcurrentHashMap 里包含一个 Segment 数组，一个 Segment 里包含一个 HashEntry 数组，每个 HashEntry 是一个链表结构的元素。
JDK 1.7 ConcurrentHashMap 分段锁技术将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问，能够实 现真正的并发访问。
JDK 1.8 ConcurrentHashMap
在 JDK 1.7 中，ConcurrentHashMap 虽然是线程安全的，但因为它的底层实现是数组 + 链表的形式，所以在数比较多的情况下访问是很慢的，因为要遍历整个链表，而 JDK 1.8 则使用了数组 +链表/红黑树的方式优化了 ConcurrentHashMap 的实现，具体实现结构如下：
JDK 1.8 ConcurrentHashMap 主要通过 volatile + CAS 或者 synchronized 来实现的线程安全的。
添加元素时首先会判断容器是否为空：
如果为空则使用 volatile 加 CAS 来初始化
如果容器不为 空，则根据存储的元素计算该位置是否为空。
如果根据存储的元素计算结果为空，则利 用 CAS 设置该节点；
如果根据存储的元素计算结果不为 空，则使用 synchronized ，然后，遍历桶中的数据，并替换或新增节点到桶中，最后再判断是否需要转为红黑树，这样就能保证并发访问时的线程安全了。
如果把上面的执行用一句话归纳的话，就相当于是ConcurrentHashMap 通过对头结点加锁来保证线程安全的，锁的粒度相比 Segment 来说更小了，发生冲突和加锁的频率降低了，并发操作的性能就提高了。
而且 JDK 1.8 使用的是红黑树优化了之 前的固定链表，那么当数据量比较大的时候，查询性能也得到了很大的提升，从之 前的 O(n) 优化到了 O(logn) 的时间复杂度。
讲下阻塞队列？
阻塞队列是一个支持两个 附加操作的队列。这两个 附加操作是：
在队列为空时，获取元素的线程会等待队列变为非空。
当队列满时，存储元素的线程会等待队列可用。 阻塞队列常用于生产者-消费者模式中，生产者线程生成数据并将其放入队列，而消费者线程则从队列中取出数据进行处理。阻塞队列使得生产者和消费者之间无需显式地进行同步，因为队列会自动处理等待和通知逻辑。
以下是Java 中 java.util.concurrent 包中一些常用的阻塞队列实现：
ArrayBlockingQueue : 基于数组的阻塞队列，其大小在创建时被固定。
LinkedBlockingQueue : 基于链表的阻塞队列，其大小默认为 Integer.MAX_VALUE ，也可以在创建时指定。
PriorityBlockingQueue : 一个无界阻塞队列，它使用与类 java.util.PriorityQueue 相同的优先级队列算法，并且提供了阻塞队列的所有操作。
DelayQueue : 一个无界阻塞队列，只有在延迟期满时才能从中 获取元素。
SynchronousQueue : 一个不 存储元素的阻塞队列，每个插入操作必须等待另一个线程的对应移除操作。
讲下线程安全的List ？
常见的线程安全的List 实现包括 Collections.synchronizedList 和 CopyOnWriteArrayList 。
Collections.synchronizedList 方法可以将任何 普通List 转换为线程安全的List 。它通过在访问方法时加锁来保证线程安全。这意味着所有对这个列表的操作都是原子性的，但使 用起来需要
注意：如果需要频繁的读写操作且希望保持简单，可以使 用 Collections.synchronizedList 。
CopyOnWriteArrayList 是一个支持线程安全操作的动态数组实现。它在修改操作（如添加、删除）时会创建一个新的数组副本，这样可以确保读取操作不受影响。如果读操作远多于写操作，可以选择 CopyOnWriteArrayList 。
讲下JVM 内存区域？
根据 JVM8 规范，JVM 运行时内存共分为虚拟机栈、堆、元空间、程序计数器、本地方法栈五个 部分。还有一部分内存叫直接内存，属于操作系统的本地内存，也是可以直接操作的。
JVM 的内存结构主要分为以下几个部分：
元空间： 元空间的本质和永久代类似，都是对JVM 规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。
**Java 虚拟机栈： **每个线程有一个私有的栈，随着线程的创建而创建。栈里面存着的是一种叫“栈帧”的东西，每个方法会创建一个栈帧，栈帧中存放了局部变量表（基本数据类型和对象引用）、操作数栈、方法出口等信息。栈的大小可以固定也可以动态扩展。
本地方法栈： 与虚拟机栈类似，区别是虚拟机栈执行java 方法，本地方法站执行native 方法。在虚拟机规范中对本地方法栈中方法使用的语言、使用方法与数据结构没有强制规定，因此虚拟机可以自由实现它。
程序计数器： 程序计数器可以看成是当前线程所执 行的字节码的行号指示器。在任何 一个确定的时刻，一个处理器（ 对于多内核来说是一个内核）都只会执行一条线程中的指令。因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要一个独立的程序计数器， 我们称这类内存区域为“线程私有”内存。
堆内存： 堆内存是 JVM 所有线程共享的部分，在虚拟机启动的时候就已经创建。所有的对象和数组都在堆上进行分配。这部分空间可通过 GC 进行回收。当申请不到空间时会抛出OutOfMemoryError 。堆是JVM 内存占用最大，管理最复杂的一个区域。其唯一的用途就是存放对象实例：所有的对象实例及数组都在对上进行分配。jdk1.8 后，字符串常量池从永久代中剥离出来，存放在队中。
直接内存： 直接内存并不是虚拟机运行时数据区的一部分，也不 是Java 虚拟机规范中农定义的内存区域。在JDK1.4 中新加入了NIO(New Input/Output) 类，引入了一种基于通道 (Channel) 与缓冲区（Buffer ）的I/O 方式，它可以使 用native 函数库直接分配堆外内存，然后通脱一个存储在Java 堆中的DirectByteBuffer 对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java 堆和Native 堆中来回复制数据。
spring 里@Autowired 和 @Resource 注解有什么 区别？
在Spring 框架中， @Autowired 和 @Resource 都是用来实现依赖注入的注解，区别如下：
来源不同: @Autowired 是Spring 框架提供的注解。 @Resource 是Java EE 的JSR-250 规范的一部分，由Java 本身提供。
注入方式： @Autowired 默认是通过类型（byType ）进行注入。如果容器中存在多个相同类型的实例，它还可以与 @Qualifier 注解一起使用，通过指定bean 的id 来注入特定的实例。
@Resource 默认是通过名称（byName ）进行注入。如果未 指定名称，则会尝试通过类型进行匹配。
属性: @Autowired 可以不指定任何 属性，仅通过类型自动装配。 @Resource 可以指定一个名为name 的属性，该属性表示要注入的bean 的名称。
依赖性：使用 @Autowired 时，通常需要依赖Spring 的框架。使用 @Resource 时，即使不在Spring 框架下，也可以在任何 符合Java EE 规范的环境中工作。
使用场景：当你需要更细粒度的控制注入过程，或者你需要支持Spring 框架之外的Java EE 环境时， @Resource 注解可能是一个更好的选择；如果你完全在Spring 的环境下工作，并且希望通过类型自动装配， @Autowired 是更常见的选择。
介绍一下类加载器过程？
类从被加载到虚拟机内存开始，到卸载出内存为止，它的整个生命周 期包括以下 7 个阶段：
加载：通过类的全限定名（包名 + 类名），获取到该类的.class 文件的二进制字节流，将二进制字节流所代表的静态存储结构，转化为方法区运行时的数据结构，在内存中生成一个代表该类的java.lang.Class 对象，作为方法区这个类的各种数据的访问入口
连接：验证、准备、解析 3 个阶段统称为连接。
验证：确保class 文件中的字节流包含的信息，符合当前虚拟机的要求，保证这个被加载的class 类的正确性，不会危害到虚拟机的安全。验证阶段大致会完成以下四个阶段的检验动作：文件格式校验、元数据验证、字节码验证、符号引用验证
准备：为类中的静态字段分配内存，并设置默认的初始值，比如int 类型初始值是0。被final 修饰的static 字段不会设置，因为final 在编译的时候就分配了
解析：解析阶段是虚拟机将常量池的「符号引用」直接替换为「直接引用」的过程。符号引用是以一组符号来描述所引用的目标，符号可 以是任何 形式 的字面量，只要使用的时候可以无歧义地定位到目标即可。直接引用可以是直接指 向目标的指针、相对偏移量或是一个能间接定位到目标的句柄，直接引用是和虚拟机实现的内存布局相关的。如果有 了直接引用， 那引用的目标必定已经存在在 内存中了 。
初始化：初始化是整个类加载过 程的最后一个阶段，初始化阶段简单来说就是执行类的构造器方法，要注意的是这里的构造器方法() 并不是开发者写的，而是编译器自动生成的。
使用：使用类或者创建对象
卸载：如果有 下面的情况，类就会被卸载：1. 该类所有的实例都已经被回收，也就是java 堆中不存在该类的任何 实例。2. 加载该类的ClassLoader 已经被回收。 3. 类对应的java.lang.Class 对象没有任何 地方被引用，无法在任何 地方通过反射访问该类的方法。
mysql 如何避免全 表扫描？
可以考虑建立索引，让 sql 查询的时候，能通过索引快 速查询到数据。
我们可以针对下面这些情况的字段增加索引：
字段有唯一性限制的，比如商品编码；
经常用于 WHERE 查询条件的字段，这样能够提高整个表的查询速度，如果查 询条件不是一个字段，可以建立联合索引。
经常用于 GROUP BY 和 ORDER BY 的字段，这样在查询的时候就不需要再去做一次排序了，因为我们都已经知道了建立索引之后在 B+Tree 中的记录都是排序好的。
mysql 如何实现如果不存在就插入如果存在就更新？
可以使 用 INSERT ... ON DUPLICATE KEY UPDATE 语句来实现“如果不存在就插入，如果存在就更新”的功能。这种语句首先尝试执行插入，如果因为主 键或唯一索引冲突而插入失败，则执行更新操作。
这里是一个基本的例子，假设有一个表 users ，包含 id （主键）和 name 字段：
CREATE TABLE users (
id INT PRIMARY KEY,
name VARCHAR(255)
);要插入一个用户，如果该用户已经存在（根据 id 主键），则更新其 name ，可以使 用以下语
句：
INSERT INTO users (id, name) VALUES (1, 'Alice')
ON DUPLICATE KEY UPDATE name = VALUES(name);在这个例子中：
如果 id 为 1 的用户不存在，则新插入一条记录， name 为 'Alice' 。
如果 id 为 1 的用户已经存在，则更新其 name 为 'Alice' 。
数据库访问量过大怎么办？
创建或优化索引：根据查询条件创建合适的索引，特别是经常用于WHERE 子句的字段、Orderby 排序的字段、Join 连表查询的字典、 group by 的字段，并且如果查 询中经常涉及多个字段，考虑创建联合索引，使用联合索引要符合最左匹配原则，不然会索引失效
查询优化： 避免使用SELECT * ，只查询真正需要的列；使用覆盖索引，即索引包含所有查 询的字段；联表查询最好要以小表驱动大表，并且被驱动表的字段要有索引，当然最好通过冗余字段的设计 ，避免联表查询。
避免索引失效： 比如不要用左模糊匹配、函数计算、表达式计算等等 。
读写分离： 搭建主从 架构 ， 利用数据库的读写分离，Web 服务器在写数据的时候，访问主数据库（master ），主数据库通过主从 复制将数据更新同步到从数据库（slave ），这样当Web 服务器读数据的时候，就可以通过从数据库获得数据。这一方案使得在大量读操作的Web 应用可以轻松地读取数据，而主数据库也只会承受少量的写入操作，还可以实现数据热备份，可谓是一举两得。
优化数据库表： 如果单表的数据超过了千万级别，考虑是否需要将大表拆分为小表，减轻单个表的查询压力。也可以将字段多的表分解成多个表，有些字段使用频率高，有些低，数据量大时，会由于使用频率低的存在而变慢，可以考虑分开。
使用缓存技术： 引入缓存层，如Redis ，存储热点 数据和频繁查询的结果，但是要考虑缓存一致性的问题，对于读请 求会选择旁路缓存策略，对于写请求会选择先更新 db ，再删除缓存的策略。
redis hotkey 用什么 查，怎么解决hotkey ？
Redis 提供了 Monitor 监控命令，使用 Monitor 命令可以实时监控 Redis 数据库的所有命令操作，包括对 Hotkey 的读取和写入操作，通过对返回的执行命令进行统计来分析 Hotkey 的分布。
优点：
可以清楚的知道 key 的操作行为（写入还是读取）。
准确定位客户端来源。
缺点：
Monitor 命令本身会影响 Redis 的性能，特别是在高负载环境中。它会占用部分 Redis 服务器的CPU 资源和网络带宽，在 Redis 官方文档 中描述如下，运行单个 Monitor 客户端可能会使 吞吐量减少50% 以上：
从 Redis 4.0.3 版本开始，Redis 引入了 hotkeys 的命令来帮助定位 Hotkey 。该命令可用于识别在 Redis 数据库中访问频率最高的键。
对性能要求不是太高的业务场景下，建议使用该进行 Hotkey 的定位与分析。使用前需要先配置Redis 的内存淘汰策略。
优点：
易用性：内置命令直接调用即可。
实时性：该命令提供的信息是实时的，能够及时反映当前的热点 键。
缺点：
性能影响：由于它是一个全量的Hotkey 数据，特别是存在大量hotkey 的场景下会对性能产生较大影响，因此不推荐在生产环境频繁执行；
局限性：该命令返回的结果是基于Redis 自身内部的采样与统计算法，根据机器资源的或预期场景的不同，该结果可能并不是100% 符合预期的；
完整性：该命令只提供了热点 键的基本信息，无法知道更详细的统计和分析信息，需要向业务侧确认；
通常以其接收到的Key 被请求频率来判定是否为 hotkey ，例如：
QPS 集中在特定的Key ：Redis 实例的总QPS （每秒查询率）为10,000 ，而其中一个Key 的每秒访问量达到了7,000 。
带宽使用率集中在特定的Key ：对一个拥有上千个成员且总大小为1 MB 的HASH Key 每秒发送大量的HGETALL 操作请求。
CPU 使用时间占比集中在特定的Key ：对一个拥有数万个 成员的Key （ZSET 类型）每秒发送大量的ZRANGE 操作请求。
解决 hotkey 的方式：
在Redis 集群架构 中对热Key 进行复制。在Redis 集群架构 中，由于热Key 的迁移粒度问题，无法将请求分散至其他数据分片，导致单个数据分片的压力无法下降。此时，可以将对 应热Key 进行复制并迁移至其他数据分片，例如将热Key foo 复制出 3个内容完 全一样的Key 并名为foo2 、foo3 、foo4 ，将这三个 Key 迁移到其他数据分片来解决单个数据分片的热Key 压力。
使用读写分离架构 。如果热Key 的产生来自于读请 求，您可以将实例改造成读写分离架构来 降低每个数据分片的读请 求压力，甚至可以不断地增加从节点。但是读写分离架构 在增加业务代码复杂度的同时，也会增加Redis 集群架构 复杂度。不仅 要为多个从 节点提供转发层（如Proxy ， LVS 等）来实现负载均衡，还要考虑从节点数量显著增加后带来故障率增加的问题。Redis 集群架构 变更会为监控、运维、故障处理带来了更大的挑战。
讲一个中 间件吧，讲讲 他的作用？
我还熟悉消息队列，消息队列的三大作用是：
**解耦：**可以在多个系统之间进行解耦，将原本通过网络之间的调用的方式改为使用MQ 进行消息的异步通讯，只要该操作不是需要同步的，就可以改为使用MQ 进行不同系统之间的联系，这样项目之间不会存在耦合，系统之间不会产生太大的影响，就算一个系统挂了，也只是消息挤压在MQ 里面没人进行消费而已，不会对其他的系统产生影响。
**异步：**加入一个操作设计 到好几个步骤，这些步骤之间不需要同步完成，比如客户去创建了一个订单，还要去客户轨迹系统添加一条轨迹、去库存系统更新库存、去客户系统修改客户的状态等等 。这样如果这个系统都直接进行调用，那么将会产生大量的时间，这样对于客户是无法接收的；并且像添加客户轨迹这种操作是不需要去同步操作的，如果使用MQ 将客户创建订单时，将后面的轨迹、库存、状态等信息的更新全都放到MQ 里面然后去异步操作，这样就可加快系统的访问速度，提供更好的客户体验。
**削峰：**一个系统访问流量有高峰时期，也有低峰时期，比如说，中午整点有一个抢购活动等等。比如系统平时流量并不高，一秒钟只有100 多个并发请求，系统处理没有任何 压力，一切风平浪静，到了某个抢购活动时间，系统并发访问了剧增，比如达到了每秒5000 个并发请求，而我们的系统每秒只能处理2000 个请求，那么由于流量太大，我们的系统、数据库可能就会崩溃。这时如果使用MQ 进行流量削峰，将用户的大量消息直接放到MQ 里面，然后我们的系统去按自己的最大消费能力去消费这些消息，就可以保 证系统的稳定，只是可能要跟进业务逻辑，给用户返回特定页面或者稍后通过其他方式通知其结果。