蚂蚁 AI应用开发 二面

1. 你之前接触过的中间件里，挑一个最熟的讲讲它的核心设计，重点说为什么要这样设计

如果讲消息队列，比较容易拉开差距的不是背概念，而是把吞吐、可靠性、顺序性和扩展性之间的取舍讲清楚。比如一套高吞吐 MQ 通常会采用顺序写磁盘、分区模型、批量发送、批量拉取和零拷贝来提升吞吐，但这么设计以后，消费顺序只能在单分区内严格保证，跨分区顺序就必须交给业务自己兜底。再比如可靠性不是简单开个副本就完事了，生产端要考虑重试和幂等，Broker 要考虑刷盘和副本同步策略，消费端还要考虑重复消费和位点提交时机。真正难的是理解这些机制不是孤立存在的，而是围绕吞吐、延迟、可恢复性一起做平衡。

2. 软件工程里的设计原则你怎么理解，别只说 SOLID，讲讲你在复杂系统里怎么落地

真正有区分度的回答不是背单一原则，而是说在复杂系统里如何避免代码和架构一起失控。比如单一职责在业务代码里意味着服务不要又查库又编排流程又发消息，接口隔离意味着给不同调用方暴露不同语义边界的接口，而不是一个巨型 DTO 打天下。依赖倒置在工程里更常见的落地是核心流程依赖抽象能力，比如依赖统一的存储接口、统一的模型网关、统一的消息发送接口，这样底层实现替换时不会把上层逻辑一起拖垮。真正高级一点的理解是，这些原则不是为了“写得优雅”，而是为了在需求持续变化时让系统还能改得动。

public interface ModelGateway {
    ChatResult chat(ChatRequest request);
}

@Service
public class QaService {
    private final ModelGateway modelGateway;

    public QaService(ModelGateway modelGateway) {
        this.modelGateway = modelGateway;
    }

    public String ask(String question) {
        return modelGateway.chat(new ChatRequest(question)).getContent();
    }
}

3. JVM 调优的步骤是什么，如果线上已经抖动了，你会怎么排

JVM 调优不能从参数开始，而要从现象开始。先确定问题是吞吐下降、延迟毛刺、Full GC 频繁还是直接 OOM，再去看监控里的堆、元空间、线程数、对象分配速率和 GC 次数。接着再结合 GC 日志、jstat、jmap、jstack、Arthas、MAT 去判断到底是对象生命周期异常、老年代增长过快、线程池积压、缓存泄漏还是大对象进入老年代过早。最后才是调参数，比如堆大小、Region 比例、GC 策略或者停顿目标。真正能体现水平的是你能把“现象—原因—验证—修复”这条链路讲完整，而不是只会背 G1 参数。

4. JVM 的作用是什么，为什么业务系统不能脱离 JVM 这一层去理解

JVM 不只是一个“让 Java 跑起来”的虚拟机，它实际上承担了内存管理、字节码执行、即时编译、垃圾回收、线程调度协作、类加载隔离和运行时安全边界这些职责。业务系统的吞吐、稳定性、延迟，很多时候都和 JVM 行为直接相关。比如一个接口 RT 抖动，表面上看是业务代码慢，实际上可能是 Young GC 过于频繁，或者某批对象被过早晋升导致老年代压力升高。再比如一个类加载问题，也可能引起 Metaspa