我是谢飞机一个在中小厂写了五年 Java 的后端开发。那天晚上十一点半我盯着屏幕上的复习笔记笔记本最后一页只写了两个词JVM、DDD。两个月里我刷了无数大厂面经发现面试官最爱的两个深水区一个是底层虚拟机一个是领域驱动设计一个在堆栈世界里抠细节一个在业务抽象里找边界。这篇文章就是记录我从被 JVM 连环问问到冒汗又在 DDD 上差点翻车最后总算把这两座山都翻过去的过程。如果你也正在准备大厂面试或者被“jvm内存模型”“ddd架构”“六边形架构和ddd”这些词搞到头大可以拿着我的经历当参考至少知道该往哪儿使劲。1. 面试前夜为什么 JVM 和 DDD 让我睡不着1.1 五年 CRUD 换来的清醒我不怕说句实话工作前五年我对 JVM 的理解停留在“出问题就加内存”对 DDD 的理解停留在“领域驱动设计的缩写”。平时写接口、改表、部署日子过得挺顺。但大厂面试不一样它不会问你“MyBatis 里 # 和 $ 的区别”这种能靠背解决的东西而是直接问“线上 FullGC 频繁你怎么排查”“如果让你从零设计一个订单中台你会怎么拆”。这两个问题一个从 JVM 的堆和栈出发一个从 DDD 的限界上下文出发本质上都在考一件事你对自己的系统有没有立体认知。那天晚上我重新把知识树捋了一遍突然意识到JVM 和 DDD 看起来一个偏底层、一个偏业务但它们有个共同点——都是在给复杂度建立模型。JVM 用内存模型来管理对象的生死DDD 用领域模型来管理业务规则的变化。想清楚了这一点后面准备的方向就清晰多了。1.2 我的两线复习路线图我不建议按面经的零散问题去刷那样刷完也是散的。我的做法是先把主线框架画出来再往里面填肉。JVM 这条线我按“内存模型 → 类加载与双亲委派 → 垃圾回收与调优 → 编译器家族 → 排查工具”的顺序走。DDD 这条线我按“核心概念 → 战略建模 → 战术建模 → 落地架构 → 反模式”的顺序走。两条线最后汇合在一个点上你能不能把一个业务问题用代码组织成一台每个零件都知道自己职责的机器。面试真正考的不是你背了多少名词而是你能不能把一个名词展开成一个可以执行的决策过程。比如“jvm调优”背参数没有意义有意义的是推导“为什么这个参数要这样调”。同样“ddd架构”也不是画几张分层图就完事而是你能不能说清楚“聚合根为什么需要仓储接口”。带着这个思路复习效率会高很多。2. 第一轮技术面JVM 的连环追问2.1 开场就让我画内存模型面试官第一题就是“说说 JVM 内存模型”。我没有直接背八股而是顺手在纸上画了一张图左边是线程私有的程序计数器、虚拟机栈、本地方法栈右边是线程共享的堆和方法区。这个方法是我复习时用的一个土办法——把概念画出来比默念一百遍都管用。画完之后我开始讲。程序计数器用来记录当前线程执行到的字节码行号是线程切换后能恢复执行的关键虚拟机栈里装的是栈帧每个方法调用对应一个栈帧栈帧里有局部变量表、操作数栈、动态连接、方法返回地址。讲到这儿面试官插了一句“那什么情况会触发 StackOverflowError”我心想这题我会。递归没写终止条件、无限递归时每个递归调用都会往虚拟机栈里压栈帧栈深度超过默认值就直接抛溢出。反过来如果递归深度不算特别大但方法里开了太多局部变量也可能把栈帧撑大缩短能容纳的栈帧数量。堆这块我讲得更细一点。年轻代和老年代是经典分代模型年轻代里又分 Eden 区和两个 Survivor 区默认比例是 8:1:1。对象一般先在 Eden 区分配Minor GC 后存活对象进入 Survivor反复熬过几次 GC 且年龄达到阈值默认通常是 15后晋升到老年代。但这个比例和晋升年龄不是拍脑袋定的它基于一个统计事实绝大多数对象朝生夕灭活过第一轮 GC 的很少能活过 15 轮的更少。面试官听我说完点了点头追问了一句“那大对象会怎样”我补了一句大对象会直接进老年代避免在 Eden 区和两个 Survivor 之间来回复制这是 JVM 的一个空间分配策略但很考验调参经验因为阈值设小了会导致老年代空间被频繁占用。2.2 双亲委派到底防的是什么第二个问题来得也很快“类加载过程是什么样的为什么要有双亲委派模型”我把加载、链接、初始化三个阶段先梳理了一遍。加载是找到字节码并生成 Class 对象链接包含验证、准备、解析验证是检查字节码安全性准备是为静态变量分配内存和设置默认值解析是把符号引用替换成直接引用初始化是执行静态代码块和静态变量赋值。双亲委派模型这个点我讲得比较久。我的理解是当一个类加载器收到加载请求时它不会先自己尝试加载而是先把请求委派给父类加载器逐级向上直到引导类加载器。只有父类加载器反馈找不到类子加载器才会自己尝试。这样做最直接的好处是安全。我举了个例子如果自己写一个 java.lang.String没有双亲委派的话应用类加载器很可能直接加载了你的冒牌 String然后整个系统就乱了。双亲委派保证了核心类库只能由引导类加载器加载你想搞破坏也插不进去。面试官接着问我“那怎么打破双亲委派”。我说常见手段是自定义类加载器并重写 loadClass像 Tomcat 为了加载不同 Web 应用的类就要打破双亲委派实现隔离。还有一个技巧是线程上下文类加载器JDBC 这种由启动类加载器加载的代码需要反过来用线程上下文加载器去加载厂商提供的驱动实现。这个答案说完我能感觉到面试官在看我不只是背概念而是真的理解机制存在的理由。2.3 编译器到底有几种JIT 和 AOT 的对决后来面试官翻到简历上我写过“熟悉 JVM 编译机制”直接抛了个问题“Java 编译器有几种JIT 和 AOT 有什么区别”这题在网络热词里也经常出现但很多人只能答出“javac 和 JIT”。我把三层拆开讲。第一层是 javac前端编译器把 .java 源码编译成 .class 字节码这一步只做语法分析、语义分析和字节码生成不做真正的优化。第二层是 JIT 编译器HotSpot 在运行时检测到热点代码后把字节码编译成本地机器码C1 编译器注重编译速度适合客户端场景C2 编译器注重优化深度适合服务端场景现在还有 Graal JIT 这种新选择。第三层是 AOT 编译器比如 jaotc 和 GraalVM 的 native-image提前把字节码编译成机器码启动快、占内存少但失去了运行时基于实际执行路径做优化的机会。有一句话我记得特别清楚JVM 之所以不把所有代码都做 JIT是因为代码量太大全部编译太慢而且大多数代码执行不了几次不值得编译。热点代码才需要深度优化这就是基于采样和计数的热点探测存在的意义。面试官听完没有追问细节而是让我把 javac 和 JIT 的关系用一句话总结。我按下慌乱的节奏说“javac 负责把 Java 变成字节码JIT 负责在运行时把热点字节码变成机器码两者是流水线上的不同工位目标都是让程序更快跑起来。”2.4 OOM 和 FullGC 频繁的现场排查光讲理论不够面试官很快上了场景题“如果线上服务 FullGC 频繁接口越来越慢你怎么排查”我先把听过的套路组织成一个步骤链实际干活也是这么干的。第一步先看 JVM 启动参数确认堆内存设置、GC 收集器是不是匹配比如 -Xms 和 -Xmx 是否相等。这里有个经验生产环境尽量让初始堆和最大堆一致避免 JVM 在运行中反复扩展堆空间引发额外开销。第二步用 jstat -gcutil 观察 Eden、Survivor、老年代的使用率以及 FullGC 次数和耗时如果老年代涨得很快说明对象不正常晋升。第三步用 jmap 或者 jcmd 导出堆 dump再用 MAT 分析看哪些对象占用了大量堆空间什么线程引用着它们。我顺便讲了一个真实踩过的坑。有一回我负责的系统每次大促后老年代就飙到 95% 以上拉出 dump 发现一个静态 Map 里缓存了用户积分明细一直在往里 put没有移除策略。这类问题不是 JVM 参数调不好是代码把不该长期持有的对象塞进了静态区。所以排查 OOM 时我会先看代码里有没有全局缓存、有没有不释放的连接、有没有把大对象存在 ThreadLocal 里的情况然后再琢磨参数。面试官补充了一句“你能意识到 JVM 调优首先是代码审阅而不是调参这比背参数重要。”2.5 JRE 和 JVM 的关系也能埋坑有几个基础题看着简单答错直接减分比如“JRE 和 JVM 之间有什么关系”。我的回答是JDK 是 Java 开发工具包包含 JRE 和开发工具JRE 是 Java 运行时环境包含 JVM 和运行时类库JVM 是 JRE 的核心负责执行字节码。有些人只会背“JDK JRE JVM”但没想过为什么。我补充了一句没有 JVMJRE 里的类库再全也没有执行引擎没有 JREJVM 连基础类库都找不到谈何运行 Java 程序。这种层级关系我不是靠背的是每次配置环境变量时看着 JAVA_HOME 下的目录结构慢慢想通的。3. 中场切换面试官突然转向 DDD3.1 “DDD 你了解吗”——这是灵魂拷问JVM 这一块聊了大概四十分钟气氛其实还行。面试官放下笔喝了口水突然换了个语气“看来 JVM 基础还行那咱们聊点业务建模你了解 DDD 吗”那一刻我脑子里闪过了“领域驱动设计”“聚合根”“限界上下文”“事件风暴”这些词但说实话任何一个词我都没有“从零到一做过”的底气。我深吸一口气决定不能背概念而是先讲自己真正做过的事。我说“DDD 是一套建模方法论不是一种框架我理解它的核心目标是让代码结构成为业务结构的映射。我还没在一个完整系统里从零落地过 DDD但我用它分析过一个模块也踩过一些坑。”面试官眼睛亮了一下示意我继续说。3.2 为什么 DDD 总让人“搞不懂”我接着讲了自己对“ddd搞不懂”这个现象的理解。这不是我一个人的困惑很多同事提到 DDD 也是这个反应。我总结出三个原因。第一DDD 的术语密度太高。实体、值对象、聚合、聚合根、限界上下文、防腐层、领域事件每个词单独看都懂合在一起就懵。第二它不是一个 starter没有一个官方框架告诉你“第一步点这里第二步选那个配置”它要求你先具备业务分析和架构设计能力再把能力固化到代码结构里。第三很多教程一上来就讲高屋建瓴的理论缺少一个从“普通三层架构的烂代码”到“DDD 风格代码”的完整重构演示。打个不恰当的比方就像教人开车第一课不是讲打火和挂挡而是先讲汽车动力学能不懵吗面试官听完反而笑了说“你这个解释比很多没做过的人也清楚不少”。我知道自己不可能靠这句话过关接下来才进入真正的硬仗。3.3 我当时的现场回答结构面对“那你说说 DDD 到底会把代码变成什么样”这个追问我让自己的回答走了一个结构化路线。首先DDD 会先把业务领域拆成一个个限界上下文每个上下文有明确的边界和通用语言。其次在同一个上下文内系统会被划分成应用层、领域层、基础设施层和接口层领域层是核心业务规则全部沉淀在领域层。然后领域层由实体、值对象、聚合根、领域服务和领域事件构成聚合根是保证一致性的入口外部不能绕过聚合根去改内部对象。最后领域层通过仓储接口和外部基础设施解耦数据库、MQ、缓存都只是实现细节。这是我当时脑子里比较完整的框架虽然没有详细的案例支撑但至少让面试官看到了我有成体系的思考。4. DDD 落地与六边形架构差点翻车的一段4.1 战术建模和战略建模到底差在哪面试官听完我的框架总结抛出了一个问题“战略建模和战术建模你能不能区分一下它们分别解决什么问题”这个问题我复习时准备过但真到现场要讲明白还是得靠例子。我先把定义摆出来。战略建模解决的是“系统和大系统之间的关系”问题比如怎么划分限界上下文、怎么画上下文映射图、怎么设计防腐层来隔离外部系统的模型污染。战术建模解决的是“单个限界上下文内部怎么做代码设计”的问题比如哪些概念该建模成实体、哪些该建模成值对象、聚合怎么划定边界、仓储接口怎么定义。光说概念不够我拿电商订单举了个例子。在一个订单上下文里订单本身是聚合根它内部包含了订单项、收货地址、支付信息等。这个上下文和支付上下文之间通过防腐层隔离不直接依赖支付系统的实体模型。而在订单上下文内部金额我建议建模成值对象而不是直接用一个 BigDecimal 字段因为它有单位、有精度而且金额的相等性比较应该基于数值而不是对象引用。这些就是战略和战术各管一摊的实际体现。4.2 六边形架构和 DDD 到底是什么关系面试官又追了一刀“那六边形架构呢是不是 DDD 的另一种说法”这题我太熟了因为网上总有人把六边形架构和 DDD 画等号。我说不是同一个级别的东西。DDD 是一套建模方法论六边形架构是一种具体代码架构风格。六边形架构关注的是端口和适配器——核心业务逻辑处于中心位置通过端口接口和外部世界交互数据库、Web 框架、消息队列都只是挂在适配器上的可替换细节。把六边形架构放进 DDD 里就是让领域层成为六边形的中心应用层负责编排用例领域层负责业务规则。向外看Repository 接口是输出端口Controller 或 API 接口是输入端口。向内看领域模型不依赖任何框架注解不用继承任何基础类它只依赖自己的领域规则。这样做最大的价值是让核心逻辑可以被单元测试哪怕是换了数据库、换了 HTTP 框架领域模型几乎不用动。我补充了一个对比传统三层架构里Service 层直接依赖 MyBatis 的 Mapper数据库字段一变领域逻辑也跟着改最终得到一个贫血模型一张表对应一个对象业务规则散落在 Service 里。六边形架构再加 DDD是把散落的规则重新搬回领域模型内部用集合、值对象、聚合不变量来保证业务一致性。4.3 这一轮我靠一个订单状态机翻回局面面试官看到我讲得具体了开始追问落地细节“如果你现在要设计个订单系统你具体怎么做 DDD 落地”我意识到空泛的架构图不管用了必须给出一个能动手的路径。我按当时的真实思路回答。第一步先和业务方坐在一起梳理业务收集“下单、支付、发货、签收、退款、取消”这些核心流程里有哪些关键动作和状态变化找出真正的业务骨干而不是一上来就画表设计ER图。第二步根据业务变化频率和团队边界划分限界上下文。我简单分出了订单上下文、支付上下文、库存上下文、用户上下文每个上下文有一组独立的模型。第三步在每个上下文里做战术设计比如订单上下文里确定聚合根是订单订单项和收货信息是订单内部的实体或值对象订单状态不能随便被 setter 修改必须通过 changeStatus 这样的领域方法来改变。我举了个状态机例子订单从“已支付”到“已发货”必须经过一个领域服务校验支付回调已经完成、库存已经锁定然后才允许状态流转。这种规则写成领域代码会让业务边界非常清晰。面试官点了点头但马上又皱起眉头问“那你觉得 DDD 在什么情况下是过度设计”我给出的答案很简单“当一个系统的业务规则几乎只有增删改查、不存在复杂状态变化和跨聚合一致性时硬上 DDD 就是给自己挖坑。”这句话说出来时我知道这一轮稳了。4.4 我踩过的三个 DDD 坑既然聊到落地我把真实踩过的坑也倒了出来。第一个坑太执着于把一切对象都建模成实体。我早期设计一个会员模块把手机号、地址、标签全都设计成实体结果每个实体都对应一个表一个仓储为了改一个地址要连带好几个类一起改。后来我才明白这些概念大多是值对象应该用不可变对象去表达不需要独立的仓储和生命周期。第二个坑听说了领域事件的好处后我在一个下单流程里塞了七八个事件结果一个简单的创建订单行为触发了一长串异步任务出了问题都不知道从哪个环节开始排查。现在的经验是领域事件要少而精只有在“发生的事”对整个上下文或另一个上下文有业务价值时才用不能把事件当通知用。第三个坑忽略了通用语言。有一次业务方管“订单创建成功”叫“成交”但代码里叫“createOrder”技术评审会上大家各说各的后来对模型名和状态名做了统一调整才顺畅。DDD 强调技术语言和业务语言保持一致这不是形式主义是为了减少沟通损耗。5. JVM 与 DDD 之外的加分项新的技术触点5.1 Kotlin 在 JVM 上跑 Agent值得聊聊聊到这里技术面其实已经快结束了。面试官突然问了一句“你平时除了 Java还关注 JVM 生态里的新东西吗”我说有的最近我在看 Kotlin还尝试在一个 Agent 开发工具链里用 Kotlin 快速上手跑通了一个 Agent 程序。这里说的 Agent不是传统的代理模式而是现在很火的人工智能体能通过工具调用完成一些任务。这类应用的开发工具里adk.dev 这类平台已经开始支持 Kotlin一个亮点是能在 JVM 上跑通 Agent 的逻辑让 Kotlin 和 Java 生态里大量成熟的库可以继续复用。我提到这个不是想显得自己追热点而是想说JVM 的价值不只属于 Java 语言本身任何能编译成字节码的语言都能享受 JVM 成熟的垃圾回收、性能监控和庞大的类库生态。面试官对这个话题来了兴趣问我“那你怎么看 JIT 和 AOT 在 Agent 应用里的取舍”。我给了一个结合场景的回答Agent 应用涉及大量 JSON 解析、模型调用和工具编排如果追求动态优化JVM 的 JIT 很适合因为它能针对热点调用路径深度优化如果追求毫秒级冷启动云端函数场景下 AOT 可能更合适。这题没有标准答案但能把 JVM 机制和新场景结合起来本身就是加分项。5.2 怎么回答你不会的东西面到后半段面试官问了一个我确实没准备过的问题“你对 JDK 21 的虚拟线程怎么看”我当场没有硬编而是给了个“结构化不知道”的回答。我说“虚拟线程这个概念我了解得不深但我可以讲讲我的理解模型。它把海量并发任务映射到少量平台线程上阻塞操作不再白白占着操作系统线程。具体到实现细节我还没看源码但如果连这个模型的基本盘都不对希望您纠正我。”这种回答的好处在于面试官能看到你在面对未知问题时的反应模式。没有人什么都懂但你需要有一种办法让对方觉得给你一个新问题你能在有限时间里找到靠谱答案。我后来把这种回答方式总结成三步先承认这个东西我没深入研究过再用已知概念搭一个大致框架最后主动询问“我这样理解对吗”。5.3 面试复盘清单和速查表从面试现场出来我当天晚上就做了一次复盘。我把所有被问到的问题列成一张表分为四列面试官问了什么、我当时怎么答的、标准答案的要点有哪些、差距在什么地方。这个方法我用了几次发现效率比盲目刷题高得多。这里整理一张我从 JVM 到 DDD 的速查表给准备面试的同学参考主题高频问题核心回答结构JVM 内存模型说说运行时数据区线程私有区和线程共享区堆内年轻代老年代结构类加载双亲委派为什么保护核心类库安全避免重复加载JVM 编译器有几种javac 前端编译、JIT、AOT各有适用场景JVM 调优FullGC 频繁怎么排查先看代码引用再看堆栈日志最后用 dump 分析JRE 与 JVM什么关系JDK 包含 JREJRE 包含 JVMJVM 是执行核心DDD 核心DDD 和普通分层区别领域层为核心数据库依赖被倒转DDD 建模聚合根怎么定找业务不变量和一致性边界拒绝过度建模DDD 架构六边形架构是什么端口与适配器核心不依赖外部技术DDD 落地订单系统怎么设计事件风暴、限界上下文、战术建模、端口实现这张表看起来很朴素但每一条背后都值得单独展开写一篇文章。JVM 和 DDD 的深度都不是一次面试能挖完的关键是先建立主框架再用真实项目把框架填满。最后再分享一个小体会。面试结束后我最大的感悟是JVM 和 DDD 看似隔得很远其实都在训练同一种能力——用模型表达现实。JVM 的堆和栈是机器对内存分配的现实建模DDD 的聚合和限界上下文是代码对业务规则的现实建模。你能不能在两者之间建立清晰的映射才是面试官真正想看到的东西。如果你也在准备大厂面试别光刷面经用 jstat 盯着 GC 日志看一天再用一个真实模块按 DDD 从头到尾捋一遍比我背十篇笔记都管用。