MoMo - Fuwari

笔试#

数据库#

表 t 结构为 (id INT PRIMARY KEY, age INT)。现有记录(1, 10), (5, 20), (10, 30)

分析下面的事务执行，在 RR 隔离级别下，事务 A 会采取哪种方案？

事务 A 执行：UPDATE t SET age = 21 WHERE id = 5;

索引轴加锁方案：方案 1（普通索引）：锁定 (1, 5] 和 (5, 10) 方案 2（唯一索引/主键）：只锁定 id = 5 这一行

A 方案 1

B 方案 2

C 先执行方案 1，发现是主键后再降级为方案 2

D 同时执行两个方案

相关知识：

隔离级别：Repeatable Read（RR），通过Gap Lock+Next-Key Lock 解决幻读（在同一个事务内，多次执行相同的查询语句，得到的结果集行数不一样）问题。
三种锁：
- Record Lock（行锁）：锁住索引记录。
- Gap Lock（间隙锁）：锁住索引记录之间的间隙，不锁数据本身。
- Next-Key Lock（临键锁）：锁住索引记录和索引记录之间的间隙，锁范围：左开右闭区间 (a, b]。
- exp: 数据：1，5，10 临键锁区间： (-∞,1]、(1,5]、(5,10]、(10,+∞)
  
  如果命中 id=5：锁住 (1,5]，锁住 5 这行（记录锁）锁住 1~5 之间的空隙（间隙锁）→ 别人不能修改 5，也不能插入 2、3、4
- Gap Lock 锁间隙，不让插入；Next-Key Lock = 锁行 + 锁间隙（默认）；唯一索引 / 主键等值命中 → 降级为单行记录锁

在 EXPLAIN 的 Extra 字段中，出现 Using index condition 代表：

A 使用了覆盖索引

B 使用了索引下推（Index Condition Pushdown）优化

C 进行了全表扫描

D 索引失效

计算机基础#

Java 反射机制不能实现的功能是（）

A 在运行时判断对象所属的类

B 在运行时修改常量的值

C 在运行时构造类的对象

D 在运行时调用私有方法

相关知识：

A：通过 Object.getClass() 方法可以获取对象的运行时类，obj.getClass().getName() 可以得到类的全限定名。
B: 常量通常用 static final 修饰，Java 编译时会进行常量折叠（Constant Folding），将常量的值直接内联到字节码中。
C: 通过 Class.newInstance() 方法可以创建类的对象。
D: 通过反射可以调用私有方法，通过 Method.setAccessible(true) 可以绕过 Java 的访问控制检查。

在 TCP 三次握手过程中，服务端收到客户端发送的 SYN 包并回复 SYN+ACK 后，服务端进入什么状态？

A ESTABLISHED

B SYN_SENT

C SYN_RCVD

D LISTEN

相关知识：

StringBuilder 和 StringBuffer 都是用于拼接字符串的类，但 StringBuffer 是线程安全的，而 StringBuilder 不是。
StringBuilder 和 StringBuffer 都是可变的，它们的方法不会创建新的对象，而是直接修改原对象。
在单线程循环内拼接大量字符串时，推荐使用 StringBuilder，因为它效率更高。

HashMap 在扩容（Resize）时，下列描述正确的是：

A 扩容后，每个元素在数组中的索引位置一定保持不变。

B 扩容后的容量是原来的 1.5 倍。

C 扩容过程涉及所有 key 的重新 Hash 计算。

D 扩容是为了减少 Hash 冲突带来的性能下降。

相关知识：

HashMap 在扩容时，会将数组长度扩大为原来的两倍，并且重新计算每个元素在数组中的索引位置。因此，扩容后，每个元素在数组中的索引位置不一定保持不变。
HashMap 的扩容容量是原来的两倍，而不是 1.5 倍，ArrayList是1.5倍。
扩容过程不需要重新计算 hash，只判断新增 bit。
扩容是为了解决 Hash 冲突带来的性能下降。

Java中

其他#

AI提示词的5C原则：
- Character
- Cause
- Constraint
- Contingency
- Calibration
example
- “帮我重构这段300行的订单处理代码。”
- 1. Character（角色）你是一位拥有10年经验的Java架构师，专注于领域驱动设计（DDD）和可测试性。
  2. Cause（原因）当前订单处理代码有以下问题（请基于这些原因进行重构）：
    
    一个方法内包含：参数校验、数据库查询、折扣计算、库存扣减、邮件发送、日志记录。
    
    单元测试几乎无法写（mock依赖过多）。
    
    新增一种支付方式需要修改核心类（违反开闭原则）。
  3. Constraint（约束）不能改数据库表结构。
    
    不能引入新的消息队列或外部中间件。
    
    必须保持对外接口的签名不变。
    
    重构后代码行数不超过350行（可适度增加但不膨胀）。
  4. Contingency（条件 / 边界）如果某一步重构会导致性能下降超过10%（对比原代码的简单压测），请标明并提出替代方案。
    
    如果某些逻辑必须保持顺序执行（如先扣库存后扣款），请注明不能并发的部分。
  5. Calibration（校准 / 验证）重构后请提供：
    
    新代码的目录结构或类职责说明（几句话即可）。
    
    一个单元测试示例（仅针对折扣计算逻辑）。
    
    指出哪里体现了单一职责原则。
    
    对比原代码：可维护性提升的具体表现（3个要点）。

笔试#

数据库#

计算机基础#

其他#

算法题#