1. Spring Boot启动时，SpringApplication构造方法初始化了哪些关键组件？

思路

按“环境准备、上下文配置、监听器/初始化器加载、推断应用类型”的逻辑梳理核心初始化项，突出构造方法的核心职责是“启动前的基础配置”。

回答示例

SpringApplication构造方法的核心作用是初始化启动所需的基础组件和配置，关键初始化内容：

1. 推断应用类型：判断当前应用是Servlet/WebFlux/普通Java应用（通过Classpath是否存在核心类）；
2. 加载初始化器（ApplicationContextInitializer）：从META-INF/spring.factories加载所有初始化器，用于启动时初始化ApplicationContext；
3. 加载监听器（ApplicationListener）：从spring.factories加载所有事件监听器，监听启动过程中的核心事件（如启动中、启动完成、失败）；
4. 推断主类：通过栈轨迹找到包含main()方法的主启动类；
5. 配置环境：初始化默认的Environment（包含系统属性、环境变量、命令行参数等）；
6. 设置Banner模式：默认启用启动Banner，可通过构造参数调整。

核心总结：构造方法不启动应用，仅完成“启动前的组件收集和基础配置”，为后续run()方法做准备。

2. MySQL的redo log和binlog如何通过两阶段提交保证一致性？

思路

围绕“prepare阶段+commit阶段”的核心流程，解释两阶段提交如何解决“redo log和binlog写入顺序不一致”导致的数据不一致问题。

回答示例

MySQL通过两阶段提交（2PC） 保证redo log（崩溃恢复）和binlog（主从同步/数据恢复）的一致性，核心流程：

事务提交时的两步操作：

1. prepare阶段：
2. commit阶段：

异常恢复逻辑：

• 若prepare后崩溃：重启后检测到redo log为prepare状态，检查binlog是否完整：
• 若commit后崩溃：redo log已标记为commit，直接恢复事务。

核心目的：确保redo log和binlog“要么都成功，要么都失败”，避免单日志写入失败导致的数据不一致。

3. 一个B+树索引，假设每页存1000个键值，三层结构最多支撑多少数据量？

思路

明确B+树的结构特性（叶子节点存数据/指针，非叶子节点存索引/指针），按“层序计算”推导总数据量。

回答示例

B+树三层结构（根节点→中间节点→叶子节点）的容量计算核心规则：

• 非叶子节点：存“键值+子节点指针”，每页1000个键值 → 对应1001个指针（子节点数）；
• 叶子节点：存数据行指针（或数据本身），每页1000个数据项。

分步计算：

1. 第一层（根节点）：1页 → 1001个指针 → 指向1001个第二层节点；
2. 第二层（中间节点）：1001页 × 1001个指针 = 1,002,001个指针 → 指向1,002,001个第三层节点；
3. 第三层（叶子节点）：1,002,001页 × 1000个数据项 = 1,002,001,000条数据（约10亿）。

核心总结：三层B+树最多支撑约10亿条数据（计算式：1001×1001×1000）。

4. JVM中Young GC和Full GC的触发条件分别是什么？

思路

分两类GC分别梳理核心触发条件，突出Young GC的“Eden区满”和Full GC的多场景触发逻辑。

回