第 01 篇 · JVM 内存与类加载

这道题考察的是对 JVM 内存规范的整体架构理解：能否区分线程私有与线程共享区域、能否说清每个区域存放什么、以及能否准确对应每种 OOM 的触发位置。它是所有 JVM 调优、故障排查的认知地基——不知道内存在哪、是什么结构，就无从谈 GC 与泄漏排查。

JDK 1.0 ~ 1.1（1996-1997）：内存区域划分原始，堆不分代，方法区概念尚未明确，GC 只有 Serial。

JDK 1.2（1998）：引入分代收集理论，堆被划分为新生代（Eden + 2 个 Survivor）与老年代，弱/软/虚引用体系建立。

JDK 1.6（2006）：方法区由"永久代（PermGen）"实现，字符串常量池位于永久代中。-XX:MaxPermSize（JDK 8 已随永久代移除，现使用 -XX:MaxMetaspaceSize）成为高频调优参数，但永久代大小固定、易 OOM 成为痛点。

JDK 1.7（2011）：符号引用、静态变量移出永久代；字符串常量池从永久代整体迁移到 Java 堆。这是永久代废除的前奏。

JDK 1.8（2014）：彻底移除永久代，方法区改由本地内存的"元空间（Metaspace）"实现。类元数据只受本地内存上限约束，解决了永久代易溢出的问题。

JDK 10（2018）：引入容器感知（-XX:+UseContainerSupport），JVM 自动识别 cgroup 内存限制，避免容器内 OOM Killed。

JDK 16：JEP 387 弹性元空间（Elastic Metaspace），元空间可归还内存给操作系统，解决早期元空间只增不减的问题。

JDK 17 LTS / JDK 21 LTS：继承弹性元空间等优化；ZGC/Shenandoah 支持大堆与低延迟，堆内存管理从"固定分代"走向"弹性 Region"。

JDK 25 LTS（2025-09）：现行最新 LTS。ScopedValue 正式；可选紧凑对象头（JEP 519，-XX:+UseCompactObjectHeaders）；分代 Shenandoah 等继续演进。生产基线：存量可稳在 21，新系统/大版本窗口优先评估 25；细节见 C01.10。

未来趋势：内存模型向"弹性化、容器原生"演进，元空间可动态伸缩并归还，堆 Region 化（G1/ZGC）使分代边界模糊化，配合 GraalVM Native Image / Leyden / CRaC 将冷启与驻留内存进一步压降。

JVM 规范（JLS/JVMS）将运行时数据区按线程私有 / 线程共享两类划分，HotSpot 实现如下：

各区域 OOM 触发原理：

• 程序计数器：唯一不会 OOM 的区域。若执行 native 方法则为 undefined，是纯粹的线程私有寄存器，不分配堆内存。
• 虚拟机栈：栈深度超限抛 StackOverflowError（如无限递归）；无法扩展时抛 OutOfMemoryError（线程数过多或 -Xss 过大）。
• 堆：对象分配无法满足时抛 java.lang.OutOfMemoryError: Java heap space；GC 花费超过 98% 时间且回收不到 2% 时抛 GC overhead limit exceeded。
• 方法区/元空间：加载类过多（如动态代理生成大量类）时抛 OutOfMemoryError: Metaspace。
• 直接内存：NIO DirectByteBuffer 超出 -XX:MaxDirectMemorySize 抛 OutOfMemoryError: Direct buffer memory。
• 无法创建新线程：操作系统线程数或内存不足时抛 OutOfMemoryError: unable to create new native thread。

高级开发 · 编码实战：

• 容器化部署必设 -XX:+UseContainerSupport（JDK10+ 默认开），并配合 -XX:MaxRAMPercentage=75.0 让堆按容器内存比例分配，而非写死 -Xmx。
• 栈溢出排查：递归深度过深时调大 -Xss（默认 512K~1M），但要权衡线程数上限（线程数 ≈ (进程内存 - 堆 - 元空间) / Xss）。
• 元空间溢出先查 -XX:MaxMetaspaceSize 是否设过小，再排查动态字节码生成（CGLIB/ASM 动态代理类无限增长）。

架构师 · 设计决策：

• 内存容量规划：堆占容器内存的 60-75%，预留 25-40% 给元空间、线程栈、直接内存、JIT CodeCache 与操作系统页缓存。直接内存场景（Netty/Kafka 客户端）需单独评估。
• 堆与元空间隔离：微服务动态类加载多（热部署、规则引擎），元空间应设上限 -XX:MaxMetaspaceSize=512m，防止类加载器泄漏拖垮整个容器。
• Native Image 场景：GraalVM Native Image 无运行时元空间概念，类元数据在构建时 AOT 固化，内存占用降低 5-10 倍，是 Serverless 冷启动优化的架构选型依据。

追问 1：为什么 JDK 8 要把永久代替换为元空间？

永久代有两个根本缺陷：一是大小固定（-XX:MaxPermSize），无法动态伸缩，容易 OOM；二是它与堆使用不同的内存管理，GC 效率低。元空间使用本地内存，大小仅受 OS 限制，且类元数据按 ClassLoader 隔离管理，回收粒度更精细。另外，JRockit 与 HotSpot 融合（JRockit 无永久代）也是推动因素。

追问 2：字符串常量池为什么从永久代移到堆？

永久代 GC 效率低（Full GC 才回收），而 String.intern() 调用频繁，大量字符串常量堆积在永久代易 OOM。移到堆后可被年轻代 GC 及时回收，且堆内存更大更弹性。JDK 7 将字符串常量池从永久代整体迁到堆（可被年轻代 GC 及时回收）；JDK 8 进一步移除永久代，方法区改由元空间实现——这是两件不同的事，不要混为一谈。

追问 3：程序计数器为什么不会 OOM？

PC 寄存器只存当前线程执行的字节码地址（一个整数），由 CPU 寄存器直接承载，不涉及堆内存分配，因此不存在内存不足的场景。

字符串常量池与堆内存优化还可以延伸到 GC 层面的自动去重机制，这是 G1 的一个低调但实用的特性：

• G1 字符串去重（String Deduplication）：JDK 8u20+ 引入 -XX:+UseStringDeduplication，必须配合 G1 使用（-XX:+UseG1GC），ZGC/Shenandoah 不支持。
• 原理：G1 在并发标记阶段扫描 String 对象，通过比较底层 char[] 引用发现内容重复的字符串，将冗余的 char[] 指向同一份数据，原 char[] 随后被 GC 回收——注意去重的是底层数组，String 对象本身不合并。
• 适用场景：堆中存在大量重复字符串（缓存 key、JSON 反序列化结果、日志消息模板），典型可降低 10-30% 堆内存占用；CPU 开销轻微（通常 <5%）。
• 与 String.intern() 的区别：String.intern() 在 JDK 7+ 已从永久代移到堆中，是"手动去重"（开发者显式调用、去重后共享常量池条目）；UseStringDeduplication 是"GC 自动去重"（无需改代码、只合并 char[] 不合并 String 对象），两者是不同层面的优化，可同时使用。
• 生产实践：某交易系统开启后年轻代 GC 频率下降约 15%；上线后需监控 dedup 相关线程的 CPU 占比，若字符串重复率低则收益不明显，可关闭以省去标记开销。

上线门禁：堆/Metaspace/CodeCache 阈值与 GC 日志采集；变更前后对比分配速率与停顿。表达提纲：现象→参数/日志证据→根因分层→回滚与容量。

考察对象从 new 关键字到可用状态的完整生命周期，以及对象在堆中的二进制存储结构。它串联了类加载、内存分配、并发安全（指针碰撞/TLAB）、对象头（锁状态/哈希码/GC 分代年龄）等多个知识点，是理解 synchronized 锁升级与 GC 的前置基础。

句柄访问 → 直接指针：早期 JVM（如部分实现）使用句柄池，对象引用指向句柄，句柄再指向对象实例与类数据。优点是对象移动（GC 时）只需改句柄，缺点是多一次指针跳转。HotSpot 最终选择直接指针，引用直接指向堆中对象，访问更快，代价是 GC 移动对象时需更新所有引用。

无 TLAB → TLAB：早期堆分配全局竞争（CAS 指针碰撞），多线程分配高并发下性能差。引入 TLAB（Thread Local Allocation Buffer）后，每个线程在 Eden 区预分配一块私有内存，线程内分配无锁，全局仅当 TLAB 耗尽时才同步申请新块。

Mark Word 演进：32 位 HotSpot 的 Mark Word 是 4 字节；64 位 HotSpot 通常用 8 字节。偏向锁布局只适用于支持它的版本：JEP 374 在 JDK 15 将其废弃并默认关闭；JDK 18 起相关支持被移除。因此不能把某一代 Mark Word 的位图当作所有 JDK 的通用布局。

未来趋势：JEP 454（Foreign Function & Memory API，JDK 22 正式）解决的是受控堆外/native 内存访问；Project Valhalla 的 Value Objects 才可能改变对象头开销。两者目标不同，不能混为一谈。

对象创建五步（HotSpot InstanceKlass::allocate_instance 流程）：

内存分配的两种方式：

• 指针碰撞（Bump the Pointer）：堆规整（已用/空闲分界指针），分配只需移动指针。适用于 Serial、ParNew（带压缩的 GC）。
• 空闲列表（Free List）：堆不规整，维护空闲块链表，分配时查找合适块。适用于 CMS（标记清除，有碎片）。
• 并发安全：指针碰撞下用 CAS 或 TLAB 解决并发；空闲列表下用 CAS 更新链表。

对象内存布局（64 位 HotSpot，开启压缩指针）：

Mark Word 64 位布局（JDK 15+ 现行；按锁状态复用比特，非 Hash 与 ThreadID 同时常驻）：

Mark Word 通过状态复用解释同一组比特，是 synchronized 锁升级的物理基础。JDK 25+ 可选 -XX:+UseCompactObjectHeaders（JEP 519）进一步压缩对象头，位布局再变——生产以目标 JDK + JOL 实测为准，勿背死某一代位图。锁升级现行路径见 C03.02。

高级开发 · 编码实战：

• 对象大小估算：用 jol-core（Java Object Layout）打印对象布局，排查内存占用。一个空 Object 在 64 位压缩指针下占 16 字节（12 字节头 + 4 字节对齐）。
• 避免创建过多小对象：每个对象至少 16 字节头开销，高频小对象（如包装类 Integer/Long）建议用原始类型数组或 LongAdder 替代。

// 使用 jol 查看对象布局
import org.openjdk.jol.info.ClassLayout;
System.out.println(ClassLayout.parseInstance(new Object()).toPrintable());
// 输出示例（64位 + 压缩指针）:
// java.lang.Object object internals:
//  OFFSET  SIZE   TYPE DESCRIPTION               VALUE
//       0     4        (object header)           01 00 00 00
//       4     4        (object header)           00 00 00 00
//       8     4        (object header)           e5 01 00 f8
//      12     4        (alignment padding)
//  Instance size: 16 bytes

架构师 · 设计决策：

• 对象头成本优化：海量对象场景（如缓存亿级 Key）下，对象头占比可能超过 50%。架构上可考虑堆外内存（如Chronicle Map、自定义 ByteBuffer 序列化）或 Value 类型来消除对象头开销。
• TLAB 调优：高并发分配场景可调 -XX:TLABSize 与 -XX:+ResizeTLAB，减少 TLAB 重分配导致的同步开销。默认 TLAB 占 Eden 的约 1%。
• 逃逸分析配合：开启 -XX:+DoEscapeAnalysis（默认开）后，未逃逸对象可栈上分配或标量替换，避免堆分配与 GC 压力，是微服务高频短生命周期对象的隐形优化。

追问 1：为什么需要 TLAB，CAS 指针碰撞不行吗？

CAS 指针碰撞在多线程高频分配时竞争激烈，CAS 失败重试开销大。TLAB 让每个线程在自己的 Eden 私有块内无锁分配（纯指针移动），仅在 TLAB 耗尽时才 CAS 申请新块，将竞争频率从"每次分配"降到"每 TLAB 耗尽一次"，性能提升数量级。

追问 2：对象头为什么是 12 字节而不是 8 字节？

64 位 JVM 下 Mark Word 固定 8 字节，类型指针 8 字节（开启压缩指针 -XX:+UseCompressedOops 后变 4 字节），合计 12 字节。由于对象必须 8 字节对齐，12 字节会填充到 16 字节。若关闭压缩指针（堆 >32GB）则对象头 16 字节。

追问 3：对象分配一定在堆上吗？

不一定。逃逸分析（JIT 阶段）若判定对象未逃逸出方法/线程，可进行栈上分配（直接在栈帧分配，方法结束即释放）或标量替换（将对象拆解为基本类型字段分散存储，不生成完整对象）。这是 JVM 对"所有对象都在堆上"规范的优化性突破。

压缩指针是对象内存布局中最重要的工程权衡，32G 阈值是大堆容量规划的核心依据：

• 原理：压缩指针（CompressedOops）用"32 位偏移 + 堆基址"寻址。因为对象 8 字节对齐，地址低 3 位恒为 0 可以省略，所以 32 位地址可寻址 8 字节 × 2^32 = 32GB 堆。
• 自动开启条件：JDK 8 堆 < 32G 时自动开启 -XX:+UseCompressedOops，对象头从 12 字节压缩到 8 字节（Mark Word 4 + Class Pointer 4）。
• 超过 32G 的退化：堆 ≥ 32G 时退化为 64 位指针，对象头膨胀至 16 字节，引用、字段指针全面膨胀，实际可用内存反而可能不如 31G 堆——内存利用率下降约 40-50%。
• 零基压缩（zero-based compression）：JVM 尽量把堆基址安排在 0 开始的地址空间，解引用时无需加基址偏移，一条指令完成寻址；若操作系统不允许（地址被占用），则退化为普通偏移压缩，多一次加法。
• 容量规划结论：32G 是单实例压缩指针的性能甜点上限。超过 32G 的需求要么拆成两个 32G 实例（横向扩展），要么选 ZGC（原生支持 TB 级堆，指针着色方案天然无压缩指针问题）。
• 验证命令：java -XX:+PrintFlagsFinal -version | grep CompressedOops，查看当前堆配置下是否生效。

考察类加载的全生命周期（加载-验证-准备-解析-初始化）与双亲委派的设计动机。核心不是背流程，而是回答"为什么要委派给父加载器"——安全性（核心类不被篡改）与唯一性（同全限定名类在层级中只加载一次）。同时要掌握"何时、为何、如何"打破双亲委派。

JDK 1.0（1996）：只有原始类加载器，ClassLoader 概念雏形，无委派模型。

JDK 1.2（1998）：正式确立双亲委派模型，引入 Bootstrap → Extension → Application 三级层次，解决核心类被恶意替换的安全问题。

JDK 1.3-1.4：SPI 机制（ServiceLoader）出现，但 SPI 接口在 rt.jar（Bootstrap 加载），实现在 classpath（Application 加载），导致双亲委派无法向上找到实现类，引入"线程上下文类加载器（TCCL）"绕过，这是第一次系统性地打破双亲委派。

JDK 1.5-1.7：Tomcat/Jetty 等 Web 容器为隔离不同应用，设计 WebAppClassLoader，先自己加载再委派父（部分反转），打破双亲委派实现应用隔离。OSGi 更进一步用网状类加载模型实现模块热部署。

JDK 9（2017）：JPMS 模块系统对类加载产生根本影响：扩展加载器（ExtClassLoader）被替换为平台加载器（PlatformClassLoader），模块路径引入新的可见性规则，反射访问受限。双亲委派仍是基础但被模块化层（ModuleLayer）增强。

未来趋势：GraalVM Native Image 在构建期完成所有类加载与解析，运行时无动态类加载（除反射配置外），双亲委派在 Native 场景退化为构建时静态分析。模块化与 AOT 共同推动 Java 向"封闭、安全、原生"演进。

类加载五阶段：

双亲委派模型（ClassLoader.loadClass 源码逻辑）：

protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    synchronized (getClassLoadingLock(name)) {
        // 1. 检查是否已加载
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            try {
                // 2. 委派给父加载器
                if (parent != null) {
                    c = parent.loadClass(name, false);
                } else {
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) { }
            // 3. 父加载不到，自己加载
            if (c == null) {
                c = findClass(name);
            }
        }
        return c;
    }
}

设计动机（为什么委派）：

• 安全性：用户无法自定义 java.lang.String 替换核心类（Bootstrap 优先加载自己的），防止恶意篡改。
• 唯一性：同一全限定名类只被层级中最顶端的加载器加载一次，避免重复加载与类型不一致（不同加载器加载的同类 equals 返回 false）。
• 层次清晰：核心类、扩展类、应用类的加载职责分明，符合关注点分离。

打破双亲委派的三大经典场景：

• SPI/JDBC：接口在 Bootstrap，实现在 classpath。用线程上下文类加载器（TCCL）反向加载实现类。DriverManager 用 TCCL 加载 com.mysql.cj.jdbc.Driver。
• Tomcat：每个 Web 应用独立 WebAppClassLoader，先自己找再委派父（对非 javax.servlet 等共享类），实现应用间隔离。
• OSGi/热部署：网状类加载模型，每个 bundle 独立加载器，支持模块级卸载与热替换。

高级开发 · 编码实战：

自定义类加载器的标准做法：继承 ClassLoader，重写 findClass（而非 loadClass，以保留双亲委派），从自定义来源（网络、加密文件）读取字节流后 defineClass。

public class CustomClassLoader extends ClassLoader {
    private final String classDir;

    public CustomClassLoader(String classDir) {
        this.classDir = classDir;
    }

    // 重写 findClass 而非 loadClass，保留双亲委派
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        String path = name.replace('.', '/') + ".class";
        try {
            byte[] bytes = Files.readAllBytes(Paths.get(classDir, path));
            return defineClass(name, bytes, 0, bytes.length);
        } catch (IOException e) {
            throw new ClassNotFoundException(name, e);
        }
    }
}

架构师 · 设计决策：

• 插件化架构：微内核 + 插件系统中，每个插件用独立 ClassLoader 实现隔离与热卸载，需设计好插件间依赖的类加载器可见性（parent-last 或双亲委派）。
• 类隔离防冲突：多版本依赖共存场景（如同一应用需 Hadoop 2.x 与 3.x 客户端），用隔离 ClassLoader 加载不同版本，避免 NoSuchMethodError。
• 避免 ClassLoader 泄漏：动态生成的 ClassLoader（线程池、热部署）若被长期引用，其加载的类与元空间无法回收，导致 Metaspace OOM。架构上要确保 ClassLoader 生命周期与业务模块绑定，可被 GC 回收。

追问 1：为什么 JDBC 要用 TCCL 打破双亲委派？

java.sql.DriverManager 在 rt.jar 中由 Bootstrap 加载，而 MySQL 驱动 com.mysql.cj.jdbc.Driver 在 classpath 由 Application 加载。若严格双亲委派，Bootstrap 加载器看不见 classpath 上的实现类。TCCL 让核心类能"借"子加载器的眼去加载实现类，是 SPI 的标准解法。

追问 2：Tomcat 的类加载器结构是怎样的？

Tomcat 为每个 Web 应用创建 WebAppClassLoader，其加载顺序：缓存 → JVM 缓存 → 加载 javax.servlet 等共享类（委派 CommonClassLoader）→ 自己加载 WEB-INF/classes 与 WEB-INF/lib → 委派 CommonClassLoader。即对共享 API 走双亲委派，对应用私有类"先自己后父"，实现应用隔离又不破坏核心类安全。

追问 3：两个不同 ClassLoader 加载同一个 class 文件，得到的 Class 对象 equals 吗？

不相等。JVM 中类的唯一性由类加载器 + 全限定名共同确定。不同加载器加载的同类被视为不同类型，instanceof 返回 false，equals 返回 false，互相赋值会抛 ClassCastException。

类加载的反面是类卸载——理解类何时能被卸载，才能诊断 Metaspace 无限膨胀类故障：

• 类卸载三条件（缺一不可）：① 该类所有实例已被回收；② 加载该类的 ClassLoader 已被回收；③ 该类对应的 java.lang.Class 对象无任何引用。
• 触发时机：类卸载在 Full GC 时触发（G1 在 mixed GC / Full GC 时扫描 ClassLoaderData），因此"元空间只涨不降"先看是否长期没有 Full GC。
• Metaspace 膨胀常见原因：CGLib/ASM 动态代理无限生成类（每次调用生成新 Enhancer 类）、Groovy 脚本每次动态编译、JSP 热部署、OSGi bundle 反复加载、自定义类加载器泄漏（被静态集合/线程持有无法回收）。
• Metaspace OOM 排查步骤（报错 OutOfMemoryError: Metaspace）：
  1. 加 -XX:+TraceClassLoading -XX:+TraceClassUnloading 观察类加载/卸载是否配平；
  2. jcmd <pid> GC.class_stats 查看类元数据分布（需 diagnostic 参数）；
  3. arthas classloader 命令查看各 ClassLoader 加载的类数量，找出异常增长的加载器；
  4. dump 堆后用 MAT 分析 ClassLoader 的 GC Root 引用链，定位持有者。
• 预防措施：设置 -XX:MaxMetaspaceSize=512m 上限（防拖垮整个进程），并对 Metaspace 使用率配置监控告警（如超过 80% 告警）。

上线门禁：堆/Metaspace/CodeCache 阈值与 GC 日志采集；变更前后对比分配速率与停顿。表达提纲：现象→参数/日志证据→根因分层→回滚与容量。

考察对 Java 内存模型（JMM）抽象的理解深度：JMM 为何存在（多核缓存与指令重排导致可见性/有序性问题），happens-before 如何作为偏序关系提供跨线程的可见性与有序性保证，以及底层如何用内存屏障实现。这是并发编程的理论根基，架构师必须理解"为什么 volatile/synchronized 能保证可见性"的本质。

早期（C/C++ 时代）：无内存模型概念，线程可见性与有序性完全依赖硬件内存模型（x86 强有序 / ARM 弱有序），同一段代码在不同 CPU 上行为不同，跨平台并发极难正确。

JDK 1.0-1.4（1996-2002）：Java 早期 JMM 存在严重缺陷——volatile 语义不够强（不禁止重排），final 字段初始化可见性无保证，导致 DCL 单例在多核下失效。这些缺陷在 The Java Memory Model is Broken（Pugh, 2000）等论文中被揭露。

JSR-133 修订（2004，JDK 1.5）：重新定义 JMM，引入 happens-before 规则体系，增强 volatile 语义（禁止 volatile-普通变量重排），保证 final 初始化安全可见。这是 Java 并发正确性的基石。

JDK 1.5-8：java.util.concurrent（Doug Lea）基于新 JMM 构建，Atomic*、AQS、ConcurrentHashMap 等并发工具依赖 happens-before 语义保证正确性。

JDK 9+（2017）：引入 VarHandle（JEP 193），提供比 sun.misc.Unsafe 更标准化的内存访问 API，支持细粒度的内存屏障（plain/opaque/volatile/acquire/release），是对 JMM 操作能力的现代化封装。

未来趋势：Project Loom（Virtual Threads）不改变 JMM 语义但改变了线程调度模型；Valhalla 值类型与 LMAX Disruptor 风格的"无锁但有序"设计推动对内存序更精细控制的需求，VarHandle 的 acquire/release 语义日益重要。

JMM 抽象模型：每个线程有独立的工作内存（CPU 缓存抽象），共享变量存于主内存。线程对变量的操作必须经过 8 种原子操作：

8 种操作：lock/unlock（主内存加锁）、read/load（主→工作）、use/assign（工作→执行引擎）、store/write（工作→主）。JMM 要求它们按特定顺序执行，但允许某些重排。

happens-before 八条规则（JSL §17.4.5）：

本质：happens-before 是一个偏序关系（并非所有操作都可比较），它定义的是"前操作的结果对后操作可见"的保证，而非时间先后。编译器/CPU 只要不违反 happens-before 就可重排。

内存屏障实现（硬件层）：JVM 用 4 种屏障指令实现 happens-before：

• LoadLoad：Load1 → LoadLoad → Load2，保证 Load1 先于 Load2
• StoreStore：Store1 → StoreStore → Store2，保证 Store1 先于 Store2 且刷新
• LoadStore：Load1 → LoadStore → Store2，保证 Load1 先于 Store2
• StoreLoad：Store1 → StoreLoad → Load2，保证 Store1 对所有处理器可见后再 Load（开销最大，volatile 写后插入）

volatile 的实现：写 volatile 变量前插入 StoreStore 屏障（禁止与前面普通写重排），写后插入 StoreLoad 屏障（刷新到主内存并使其他 CPU 缓存失效）；读 volatile 变量后插入 LoadLoad 屏障（禁止与后面普通读重排）与 LoadStore 屏障（禁止与后面普通写重排）。底层依赖 CPU 的MESI 缓存一致性协议（Modified/Exclusive/Shared/Invalid）通过总线嗅探保证缓存一致。

高级开发 · 编码实战：

DCL 单例必须用 volatile，根因是"对象半初始化"问题违反 happens-before：

public class Singleton {
    // volatile 保证：构造完成对其他线程可见，禁止指令重排
    private static volatile Singleton instance;

    public static Singleton getInstance() {
        if (instance == null) {                // 第一次检查
            synchronized (Singleton.class) {
                if (instance == null) {            // 第二次检查
                    instance = new Singleton(); // 非原子：分配/初始化/赋值可能重排
                }
            }
        }
        return instance;
    }
}

无 volatile 时，new Singleton() 可能重排为"分配内存→赋值引用→初始化"，其他线程在第一次检查时看到非 null 但未初始化的对象。volatile 的 happens-before 保证"写 instance"对后续"读 instance"可见且有序。

架构师 · 设计决策：

• 无锁设计中的内存序选择：Disruptor 等高性能无锁队列用 volatile + happens-before 替代锁。架构师需理解 acquire/release（VarHandle）比 volatile 更轻量，可减少不必要的 StoreLoad 屏障。
• 跨线程可见性的架构保证：状态机、配置热更新等场景，用 volatile 或 AtomicReference 保证"写线程的修改对读线程立即可见"，避免读到过期配置。结合 Spring 的 @RefreshScope 时要理解其底层是重建 Bean，而非依赖 JMM。
• 避免过度同步：happens-before 的传递性意味着不必要的 synchronized 会引入 StoreLoad 屏障（性能最差）。架构上应区分"需要可见性"（用 volatile）与"需要互斥"（用 synchronized）。

追问 1：JSR-133 为何要修订 volatile 语义？

旧 JMM 下 volatile 只保证可见性不禁止重排，导致 volatile 变量的写可与前面的普通写重排。例如 DCL 中 instance = new Singleton() 的普通写（初始化字段）可与 volatile 写（赋值 instance）重排。JSR-133 增强 volatile 语义：volatile 写前插入 StoreStore 屏障禁止与前面普通写重排，彻底修复了 DCL 问题。

追问 2：happens-before 和时间先后是一回事吗？

不是。happens-before 是可见性偏序关系，不是时间顺序。一个操作 A 在时间上后于 B，但若不满足任何 happens-before 规则，A 对 B 不可见。例如两个无同步的普通变量写读，即使写先发生，读也可能读到旧值。happens-before 通过传递性构建可见性链，只有链上的操作才有可见性保证。

追问 3：MESI 协议与 JMM 是什么关系？

MESI 是硬件层缓存一致性协议，保证多核 CPU 的 L1/L2 缓存一致。JMM 是语言层抽象，定义跨线程可见性规范。JVM 通过插入内存屏障（触发 MESI 的 cache line invalidate/flush）来实现 JMM 的 happens-before。可以说：MESI 是 JMM 可见性保证的物理基础，但 JMM 屏蔽了不同 CPU 架构（x86/ARM）内存模型的差异，提供统一的跨平台保证。

考察对 OOM（内存不够，分配失败）与内存泄漏（对象无法回收，逐渐堆积）的概念区分，以及系统化的排查方法论。这是线上故障处理的高频实战题，要求能从现象定位到根因代码。核心是理解"泄漏是因，溢出是果"的因果关系与排查工具链。

JDK 1.4 时代：jmap -dump 导出堆 + jhat 离线分析，工具原始，分析效率低。

JDK 5-6：Eclipse MAT（Memory Analyzer Tool）登场，提供支配树（Dominator Tree）与 GC Root 引用链分析，成为堆 dump 分析的事实标准。

JDK 7-8：JProfiler/YourKit 商业工具普及，提供实时内存监控；-XX:+HeapDumpOnOutOfMemoryError 成为生产标配，OOM 时自动 dump。

JDK 9+：JFR（Java Flight Recorder）开源并免费，低开销持续采集内存/GC/分配事件，支持事后分析而非仅事后 dump。Arthas（阿里开源）提供线上 dashboard/heapdump/watch 等动态诊断。

云原生时代：容器环境下 dump 文件需持久化到 PV；eBPF 技术（如 Parca、Pixie）实现内核级无侵入内存 profiling；OpenTelemetry Memory Profiler 标准化内存指标采集。

未来趋势：从"事后 dump 分析"走向"实时持续 profiling + AIOps 预警"，JFR 与 OTel 结合实现内存增长的全链路可观测，在 OOM 前预警。

OOM 与内存泄漏的本质区别：

OOM 类型与触发位置（对应运行时数据区）：

• java.lang.OutOfMemoryError: Java heap space —— 堆，对象分配失败
• GC overhead limit exceeded —— 堆，GC 花费 98% 时间回收不足 2%（泄漏的典型征兆）
• OutOfMemoryError: Metaspace —— 元空间，类元数据过多（动态代理/ClassLoader 泄漏）
• OutOfMemoryError: Direct buffer memory —— 直接内存，NIO 堆外内存泄漏
• OutOfMemoryError: unable to create new native thread —— 线程数/内存不足
• StackOverflowError —— 栈深度超限（严格说是 Error 非 OOM）

内存泄漏的常见模式：

// 模式1: 静态集合持有对象引用，永不释放
public class CacheLeak {
    private static final Map<String, Object> CACHE = new HashMap<>();
    public void put(String k, Object v) { CACHE.put(k, v); } // 只进不出
}

// 模式2: ThreadLocal 未 remove，线程池线程复用导致泄漏
threadLocal.set(bigObject);
// 业务结束后忘记 threadLocal.remove();
// 线程池线程长期存活，ThreadLocalMap 的 value 无法回收

// 模式3: 监听器/回调未注销
eventBus.register(this);  // 注册后未 unregister

// 模式4: 资源未关闭（连接/流/文件句柄）
InputStream is = new FileInputStream(file); // 未 close

// 模式5: 内部类隐式持有外部类引用
public class Outer {
    class Inner {}  // Inner 隐式持有 Outer.this，若 Inner 被缓存则 Outer 泄漏
}

排查方法论（MAT 支配树 + GC Root 链）：

1. 现象确认：jstat 看 GC 频率与老年代增长趋势，确认是泄漏（持续增长）还是峰值溢出（瞬时）。
2. dump 堆：jmap -dump:format=b,file=heap.hprof <pid> 或 OOM 自动 dump。
3. MAT 支配树：按对象保留大小（Retained Size）排序，找出占内存最大的对象。
4. GC Root 引用链：右键 → Path To GC Roots → exclude weak/soft references，找到阻止回收的引用链。
5. 定位代码：根据引用链上的对象类型与字段，定位到具体代码的持有逻辑。

高级开发 · 编码实战：

• 生产必配自动 dump：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dump/，OOM 时自动保存现场。
• ThreadLocal 规范：try-finally 中 remove()，或用阿里 TransmittableThreadLocal 配合线程池自动清理。
• 用 WeakHashMap/Cache（Guava/Caffeine）替代手写静态 Map 缓存，设置 TTL 与最大容量，防泄漏。

// 正确的 ThreadLocal 使用模式
private static final ThreadLocal<UserContext> CTX = new ThreadLocal<>();

public void handle(Request req) {
    try {
        CTX.set(buildContext(req));
        doBusiness();
    } finally {
        CTX.remove();  // 必须 remove，防线程池复用泄漏
    }
}

架构师 · 设计决策：

• 分级容灾：内存告警阈值（如堆使用 80%）→ 自动触发 dump + 重启；OOM 时熔断降级而非崩溃，结合 K8s liveness/readiness 探针实现自动恢复。
• 可观测性建设：持续 JFR 采集 + Prometheus 暴露 JVM 内存指标 + Grafana 内存增长趋势图，在 OOM 前预警。关键指标：老年代增长率、GC 后存活率、Metaspace 增长。
• 容量规划：基于历史内存增长曲线预测 OOM 时间点，设定容量红线提前扩容。区分"稳态泄漏"（线性增长）与"突发峰值"（瞬时分配），分别治以修代码与调堆。

追问 1：如何区分是内存泄漏还是堆太小？

看 GC 后老年代存活率（jstat 的 OU 列）。若每次 Full GC 后老年代使用量持续上升且回收率低，是泄漏（对象无法回收）；若 GC 后能回收大部分但分配速率过高导致频繁 GC，是堆太小或分配过快。泄漏的特征是"GC 后内存不降"，堆太小的特征是"GC 后降了但很快又满"。

追问 2：GC overhead limit exceeded 和 Java heap space 有什么区别？

Java heap space 是分配时内存不足的直接报错；GC overhead limit exceeded 是 GC 自我保护机制——当 GC 花费超过 98% CPU 时间且回收不到 2% 堆内存时抛出，说明 GC 已"徒劳"。后者通常是内存泄漏的早期信号，可用 -XX:-UseGCOverheadLimit 关闭（不建议，会拖延到彻底 OOM）。

追问 3：SoftReference/WeakReference 也会泄漏吗？

会。虽然 SoftReference 在内存不足时、WeakReference 在下次 GC 时会被回收，但若强引用链持有的是 Reference 对象本身（如把 SoftReference 放入强引用的 List 且不清理），Reference 对象本身无法回收，其引用的对象也间接泄漏。典型如自建 SoftReference 缓存未用 ReferenceQueue 清理失效条目。

考察堆外内存（Direct Memory）的分配/回收机制与零拷贝原理，以及 NIO 为何引入 DirectByteBuffer。架构师视角需理解堆外内存的性能收益（避免堆内↔内核态拷贝）、回收机制（Cleaner + PhantomReference）、以及 Netty 等框架的池化设计。这是高并发 IO 场景的核心知识点。

传统 BIO（JDK 1.0-1.3）：IO 操作经堆内 byte[]，数据需从内核态 socket buffer → 用户态堆内 buffer，多次拷贝与用户态/内核态切换，高并发下性能瓶颈明显。

NIO 引入（JDK 1.4，2002）：JSR 51 引入 java.nio，提供 ByteBuffer.allocateDirect() 分配堆外内存，FileChannel.transferTo() 实现 sendfile 零拷贝，MappedByteBuffer 实现 mmap。DirectBuffer 让内核可直接操作用户态分配的堆外内存，避免一次堆内→堆外拷贝。

Netty 池化（2012+）：Netty 默认使用 PooledDirectByteBuf，基于 Jemalloc 算法的内存池化，避免频繁分配/释放堆外内存的开销（DirectByteBuffer 分配/释放成本高于堆内）。PoolArena/PoolChunk 分级管理，减少碎片。

JDK 9+ 改进：DirectByteBuffer 的回收仍依赖 Cleaner（PhantomReference），但内部实现优化；引入 jdk.internal.ref.Cleaner 替代旧的 sun.misc.Cleaner。

未来趋势：JEP 454（Foreign Function & Memory API，JDK 22 正式）提供 MemorySegment / Arena 替代 DirectByteBuffer，支持更安全、可显式释放的堆外内存管理，是 NIO 堆外内存的下一代方案。Netty 5 也计划适配。

为什么需要堆外内存？——避免堆内↔内核态的额外拷贝：

堆内 byte[] 在 GC 时可能被移动，地址变化导致内核无法稳定引用。因此传统 IO 通常需要先把堆内数据拷贝到堆外临时 buffer 再传给内核，多一次拷贝。DirectByteBuffer 通过 native 直接内存分配获得稳定地址，可减少这次堆内到堆外的 CPU 拷贝；但它本身不是文件页缓存，也不等价于 mmap，网络传输仍有内核协议栈路径和必要的设备传输环节。

零拷贝的三种实现：

• sendfile（FileChannel.transferTo）：数据全程在内核态从文件页缓存直达 socket buffer，零用户态拷贝。Kafka 的 fast replication 用此。
• mmap（MappedByteBuffer）：将文件区域映射到进程虚拟地址空间，访问时按缺页从文件页缓存填充；避免 read/write 调用中的一次用户缓冲拷贝，但不等于 DirectByteBuffer。Kafka 常用于索引文件访问，不应简单概括为所有消息消费路径。
• DirectByteBuffer：堆外内存，避免堆内→堆外拷贝，配合 gather（Scatter/Gather）减少 CPU 拷贝。

DirectByteBuffer 的分配与回收机制：

// DirectByteBuffer 构造（简化）
DirectByteBuffer(int cap) {
    // 通过 Unsafe.allocateDirect 分配堆外内存
    base = Unsafe.allocateMemory(size);
    // 注册 Cleaner，GC 时触发回收
    cleaner = Cleaner.create(this, new Deallocator(base));
}
// Deallocator.run() 通过 Unsafe.freeMemory 释放堆外内存

关键：DirectByteBuffer 对象本身在堆内（小），其指向的堆外内存（大）不归 GC 管理。回收依赖 Cleaner（PhantomReference 子类）：当 DirectByteBuffer 对象被 GC 回收时，JVM 的 Reference Handler 线程将 Cleaner 入队，触发 Deallocator 调用 Unsafe.freeMemory 释放堆外内存。

高级开发 · 编码实战：

• 高频 IO 场景（网络/文件）用 DirectByteBuffer，但注意用完显式释放或复用，避免堆外内存泄漏。
• 设置堆外内存上限：-XX:MaxDirectMemorySize=512m，防止无限分配拖垮容器。
• 排查堆外内存泄漏：用 jcmd <pid> VM.native_memory（需 -XX:NativeMemoryTracking=summary）或 Netty 的 ResourceLeakDetector。

架构师 · 设计决策：

• Netty 池化配置：高并发网关/IM 场景用 PooledDirectByteBuf（默认），-Dio.netty.allocator.type=unpooled 仅在低并发或调试时用。池化避免频繁 malloc/free，但需配合 ResourceLeakDetector（生产用 DISABLED/SIMPLE，测试用 ADVANCED/PARANOID）防泄漏。
• 零拷贝选型：大文件传输（如下载/日志聚合）优先评估 FileChannel.transferTo（sendfile，把用户态拷贝移出主路径，CPU 参与是否可消除取决于网卡、协议和内核路径）；随机映射读文件用 MappedByteBuffer；网络缓冲用 DirectByteBuffer + gather。Kafka 在不同路径分别使用 sendfile 和 mmap，属于按场景选型的例子。
• 容器内存规划：堆外内存不占 -Xmx 但占容器总内存。架构上要预留堆外内存空间：容器内存 = 堆 + 元空间 + 堆外（Direct + Native）+ 线程栈 + OS。Netty/Kafka 客户端场景堆外可能占 20-30% 容器内存。

追问 1：为什么 DirectByteBuffer 不靠 GC 直接回收堆外内存？

堆外内存不在 GC 管辖范围（GC 只管堆），GC 无法直接 free 堆外内存。因此用 Cleaner 机制：GC 回收堆内的 DirectByteBuffer 对象时，触发回调释放对应的堆外内存。这意味着堆外内存的释放时机滞后于堆内对象回收，若 Full GC 长期不触发，堆外内存可能积压。这也是 Netty 池化的动机——自己管理分配释放，不依赖 GC。

追问 2：堆外内存泄漏如何排查？

三步：① 开启 -XX:NativeMemoryTracking=summary，用 jcmd VM.native_memory summary 看 Internal/Other 增长；② Netty 用 -Dio.netty.leakDetection.level=PARANOID 打印分配栈；③ 若非 Netty，排查 DirectByteBuffer 持有链（堆 dump 中找 DirectByteBuffer 对象为何不被 GC）。

追问 3：mmap 和 sendfile 有什么区别？

mmap：文件映射到用户态虚拟地址，用户态直接读写页缓存，有 1 次用户态↔内核态拷贝（页缓存→用户态可见），适合随机读写与多次访问。sendfile：数据全程在内核态从文件页缓存到 socket buffer，零用户态拷贝，CPU 也较少参与（DMA），适合顺序大文件传输。Kafka 写入用 mmap（页缓存 + 顺序写），消费用 sendfile（零拷贝传输）。

考察 强/软/弱/虚四种引用的语义差异、GC 回收时机、以及 ReferenceQueue 机制。核心是理解"引用强度递减"如何让开发者精细控制对象生命周期，支撑缓存、资源清理（finalize 已废弃待移除，新代码优先 try-with-resources / Cleaner）、ThreadLocal 等场景。这也是理解 ThreadLocal 内存泄漏、DirectByteBuffer 回收的前置知识。

JDK 1.2（1998）：引入 java.lang.ref 包，定义强/软/弱/虚四种引用与 ReferenceQueue，Java 成为首个提供细粒度引用控制的主流语言。

JDK 1.2-1.8：Finalizer 机制（finalize()）依赖虚引用思想，但 Finalizer 线程优先级低、执行不确定、可能复活对象，成为长期痛点。SoftReference 被广泛用于内存敏感缓存（如 Guava 的 softKeys/softValues）。

JDK 9（2017）：finalize() 被标记 Deprecated，引入 java.lang.ref.Cleaner（JEP 282）作为替代，基于 PhantomReference + ReferenceQueue，更安全（不在 finalize 上下文中复活对象）、可控（可指定线程）。

JDK 18（2022，JEP 421）：finalize() 继续按 for-removal 语义废弃，JDK 18 起提供 --finalization=enabled|disabled；默认仍是 enabled，disabled 仅关闭终结器执行，不是删除 API。迁移 Cleaner 是架构建议，不是所有 JDK 18 运行时的强制行为。

未来趋势：Cleaner 成为资源释放标准；Valhalla 值类型引入"无引用"对象（inline type 不参与引用体系，生命周期完全栈式管理）；GraalVM Native Image 中 Reference 处理更简化。

四种引用对比：

ReferenceQueue 机制：

创建 Reference 时可关联一个 ReferenceQueue。当被引用对象被 GC 回收时，JVM 的 Reference Handler 线程将 Reference 对象本身入队（enqueue）。应用代码可轮询队列感知回收事件，执行清理逻辑。

SoftReference 的回收策略：由 -XX:SoftRefLRUPolicyMSPerMB（默认 1000ms/MB）控制。公式：软引用存活时间 = 堆剩余空间(MB) × 该参数(ms)。堆越满，软引用越快被回收。这使得 SoftReference 适合"内存够就留，不够就清"的自适应缓存。

WeakHashMap 原理：Entry 继承 WeakReference，Key 是弱引用。当 Key 对象无强引用被 GC 时，Entry 自动被清理（expungeStaleEntries）。适合"对象消失则缓存失效"的场景，如以 Class 为 Key 的反射缓存。

Finalizer 的问题与 Cleaner 的改进：

• Finalizer：GC 将待 finalize 对象加入 F-Queue，Finalizer 线程（低优先级）执行 finalize()。问题：执行时序不确定、finalize 中可复活对象（this 重新被引用）、可能抛异常吞没、对象需两轮 GC 才回收（finalize 前后各一次）。
• Cleaner：基于 PhantomReference，对象已确定被回收时才回调（无复活可能），可在独立线程执行清理，API 更安全。DirectByteBuffer 的堆外内存释放即用 Cleaner。

高级开发 · 编码实战：

• 内存敏感缓存用 Caffeine/Guava 的 softValues/weakKeys，而非手写 SoftReference Map（需自行清理 ReferenceQueue）。
• 资源释放用 try-with-resources（AutoCloseable），避免依赖 finalize/Cleaner（不确定时序）。
• ThreadLocal 的 Key 是弱引用（ThreadLocal 对象），但 Value 是强引用，必须 remove()，否则线程池场景泄漏。

// SoftReference 缓存：内存不足时自动回收
Map<String, SoftReference<byte[]>> cache = new ConcurrentHashMap<>();
public byte[] get(String key) {
    SoftReference<byte[]> ref = cache.get(key);
    return ref != null ? ref.get() : null;  // 可能返回 null（已被回收）
}

// 推荐：用 Caffeine 替代手写
Cache<String, byte[]> cache = Caffeine.newBuilder()
    .weakKeys()
    .softValues()
    .build();

架构师 · 设计决策：

• 缓存层次设计：Caffeine（堆内，weak/soft）+ Redis（分布式）+ DB。软引用层做 L1 突发流量缓冲，内存压力下自动降级，是自适应缓存架构的关键。
• 避免 Finalizer：新代码优先 try-with-resources；确需 GC 兜底清理时用 Cleaner，并指定明确生命周期。架构规范可禁止新增 finalize()；存量代码迁移时按 JDK 18+ 的 finalization 策略验证，不能假设默认已禁用。
• 堆外资源释放：DirectByteBuffer/Native 句柄用 Cleaner 释放，架构上要确保 Cleaner 关联的对象（DirectByteBuffer 本身）能被 GC 回收，否则堆外内存泄漏。

追问 1：ThreadLocal 为什么用弱引用 Key 仍会泄漏？

ThreadLocalMap 的 Entry 继承 WeakReference，Key（ThreadLocal 对象）是弱引用，但 Value 是强引用。当 ThreadLocal 对象被回收后，Key 变 null，但 Value 仍被 Entry 强引用，而 Entry 被 ThreadLocalMap（Thread 持有）强引用。线程池线程长期存活，Value 无法回收导致泄漏。解决：用完显式 remove()。

追问 2：虚引用 get() 为什么永远返回 null？

设计上虚引用不提供访问对象的能力，仅用于"对象被回收时通知"。若 get() 能返回对象，则该引用等同于强/弱引用，可能阻止回收或复活对象。虚引用的用途是资源清理（Cleaner），需在对象确定不可达后触发，get 返回 null 保证不会意外复活。

追问 3：Reference Handler 线程是什么？

JVM 启动时创建的 Reference Handler 线程（优先级 MAX_PRIORITY-1），负责处理 pending 链表中的 Reference 对象：将需入队的 Reference 加入对应 ReferenceQueue，对 Cleaner 触发 clean() 回调。它是 SoftReference/WeakReference/PhantomReference/Cleaner 机制能工作的后台引擎。

考察对 JPMS（Java Platform Module System，Project Jigsaw）如何根本性改变类加载、可见性与反射访问的深度理解。专家级要求理解模块层（ModuleLayer）与类加载器的两层模型、强封装对生态的冲击，以及为何 JPMS 没能取代 OSGi。这是理解现代 Java（JDK 9+，尤其是 17/21 LTS）运行时行为的关键。

OSGi 时代（2003+）：OSGi 最早实现 Java 模块化，基于 bundle（jar + MANIFEST）与网状类加载器，支持热部署、版本隔离。但 OSGi 复杂、侵入性强，未进入 JDK 标准。

JSR 277（2005，废弃）：早期模块化尝试，最终被 Jigsaw 替代。

Project Jigsaw（JDK 7 立项，2010）：目标是"让 Java 平台本身模块化"。JDK 8 内部开始封装内部 API（sun.misc.Unsafe 等标记 deprecated）。

JDK 9（2017，JEP 261）：JPMS 正式发布。JDK 自身拆分为约 90 个模块（java.base/java.sql/java.desktop 等），引入 module-info.java、模块路径、强封装。对类加载的影响：扩展加载器（ExtClassLoader）→ 平台加载器（PlatformClassLoader），模块层（ModuleLayer）引入新的可见性维度。

JDK 16-17（2021）：强封装默认生效（JEP 396/403），--illegal-access=deny 成为默认，反射访问 JDK 内部模块（如 java.base）被拒绝，导致大量旧库（Jackson、Lombok、ByteBuddy 早期版本）报 InaccessibleObjectException。

未来趋势：模块化是 GraalVM Native Image 的基础（构建期已知模块边界，利于闭世界分析）；Valhalla 值类型依赖模块的强封装；但应用级模块化（应用代码写 module-info）普及缓慢，多数项目仍在 classpath（未命名模块）模式。JPMS 与 OSGi 将长期共存。

模块定义：module-info.java 声明模块名、依赖（requires）、导出（exports）、服务（uses/provides）。

// module-info.java
module com.example.app {
    requires java.sql;           // 依赖 java.sql 模块
    requires transitive com.example.core; // 传递依赖
    exports com.example.api;     // 只导出 api 包，impl 包强封装
    opens com.example.dto to com.fasterxml.jackson.databind; // 反射开放给 jackson
    uses com.example.spi.Service; // 声明使用 SPI 服务
    provides com.example.spi.Service with com.example.impl.ServiceImpl;
}

类加载器的变化：

JDK 9 的关键变化：ExtClassLoader 被 PlatformClassLoader 替代；rt.jar 不复存在，JDK 拆为模块化 jmod 文件；模块路径（modulepath）与类路径（classpath）共存。

模块层（ModuleLayer）与类加载器的两层模型：

• 类加载器层：传统的 Bootstrap/Platform/App，负责字节码加载，双亲委派仍为基础。
• 模块层（ModuleLayer）：JPMS 新增的可见性维度。每个模块属于一个层，层有父子关系。类可见性 = 类加载器可见 + 模块导出可见（双重过滤）。
• 即便类加载器能加载某类，若该类所在模块未 exports 对应包，其他模块也无法访问（编译期与运行期均强制）。

强封装对反射的影响：

JDK 9 引入强封装（Strong Encapsulation）：模块未 exports 或 opens 的包，反射（setAccessible(true)）被拒绝。JDK 16+ 默认 --illegal-access=deny，对 JDK 内部模块（java.base 等）的反射彻底封死，需 --add-opens 显式开放。

高级开发 · 编码实战：

• JDK 17+ 旧库反射报错时，用 --add-opens java.base/java.lang=ALL-UNNAMED 临时开放（治标），或升级库版本（治本）。
• 判断类所属模块：clazz.getModule().getName()，未命名模块返回 null。
• SPI 服务加载在 JPMS 下用 ModuleLayer.findServices 或 ServiceLoader.load(ModuleLayer)，比传统 TCCL 更规范。

// JDK 17+ 反射访问受限的典型报错与解决
Field f = String.class.getDeclaredField("value");
f.setAccessible(true); // InaccessibleObjectException in JDK17+

// 临时解决（启动参数）:
// --add-opens java.base/java.lang=ALL-UNNAMED

// 治本：用 module-info 声明 opens，或升级框架版本

架构师 · 设计决策：

• 迁移策略：先 JDK 版本升级（classpath 模式，未命名模块兼容），再逐步模块化。优先底层共享库模块化，应用层最后。GraalVM Native Image 场景必须模块化或提供完整反射配置（reflect-config.json）。
• 强封装的架构收益：模块边界即架构边界，exports 显式声明 API，opens 控制反射，天然防止"内部实现被外部依赖"的架构腐化，是 DDD 限界上下文的代码级落地。
• JPMS vs OSGi 选型：JPMS 是平台标准、AOT 友好、简单，但不支持版本化（同一模块多版本）、不支持热部署、应用级采用低。OSGi 适合需要动态热部署与多版本共存的插件化平台（如 Eclipse IDE），JPMS 适合标准化的库与 GraalVM 场景。"微内核+插件"若需热部署仍可能选 OSGi。

追问 1：JPMS 为什么没能取代 OSGi？

JPMS 设计目标不同：它是"让 JDK 平台自身模块化"，不是"应用级动态模块系统"。关键缺失：① 不支持同一模块多版本共存（OSGi 支持），微服务依赖冲突无法靠 JPMS 解决；② 不支持运行时热部署/卸载（OSGi 的 bundle 可动态安装卸载）；③ 模块不可变性（模块一旦加载到层，不能动态改变依赖）。因此需要动态插件化的场景（IDE、网关插件）仍用 OSGi 或自定义 ClassLoader。

追问 2：模块层（ModuleLayer）如何实现模块化隔离？

ModuleLayer 是模块的运行时容器，有父子层关系。子层可 sees 父层的模块。可通过 ModuleLayer.defineModulesWithOneLoader 创建子层并指定类加载器，实现模块级隔离（类似自定义 ClassLoader）。这是 JPMS 下实现"插件层"的标准方式，但比 OSGi 简单，不支持同模块多版本。

追问 3：为什么 GraalVM Native Image 需要 JPMS？

Native Image 依赖闭世界分析（Closed-World Analysis）——构建时必须知道所有可达的类与模块。JPMS 的模块边界（exports/requires）为闭世界分析提供了静态可见性信息，比 classpath 的"全可见"更利于精确分析，减少 Native Image 体积。模块化应用做 Native Image 通常比非模块化效果更好。

JVM 的 JIT（Just-In-Time）编译器是"运行时将热点字节码编译为本地机器码"的核心机制，本质是用编译时间换执行时间、用内存（CodeCache）换 CPU。本题考察四个维度：① 分层编译（Tiered Compilation）如何用 C1/C2 两个编译器协同平衡启动速度与峰值吞吐；② C1 与 C2 优化器的能力差异（C1 求快、C2 求极致）；③ CodeCache 管理与编译产物回收；④ GraalVM 编译器作为 C2 的替代方案（JVMCI 接口）如何用 Java 重写 JIT。架构师必须理解"解释执行 → JIT 编译 → 激进优化 → 逆优化（Deoptimization）"的完整生命周期，以及 JIT 与 AOT（Native Image）的本质权衡。

JVM 编译技术的发展是一条"从纯解释到混合编译、再到多编译器协同、再到 AOT"的演进线：

• 纯解释器（Interpreter）：早期 JVM 全部解释执行，启动快但峰值慢，每次执行都要重新翻译字节码。
• C1 编译器（Client Compiler）：快速编译、轻量优化，追求低延迟启动，代表早期 Client 模式 VM。
• C2 编译器（Server Compiler）：慢编译、激进优化（循环展开/锁消除/向量化），追求峰值吞吐，代表 Server 模式 VM。早期 Client 与 Server 模式需用户手动选择。
• 分层编译（Tiered Compilation）：JDK 6 引入实验性，JDK 8 默认开启，让 C1 先编译热点、收集 Profile，再交给 C2 做激进优化，兼顾启动与峰值。分层编译默认开启，但仍可通过 -XX:-TieredCompilation 关闭；关闭后的行为还取决于 -XX:TieredStopAtLevel / C1、C2 选择。
• AOT 编译（JEP 295）：JDK 9 引入 jaotc 工具，将类预编译为本地代码缩短启动时间，但未能广泛使用，JDK 17 被移除。
• GraalVM JIT（JEP 317）：JDK 10 实验性引入，通过 JVMCI 接口用纯 Java 实现的 Graal 编译器替代 C2，支持更激进的优化（如部分逃逸分析）。
• GraalVM Native Image：基于闭世界分析的 AOT 方案，启动毫秒级、内存占用极低，适合 Serverless/微服务。
• Graal 与 JDK 内建 AOT 的边界：JDK 10 的 JEP 317 提供 JVMCI/Graal 编译器实验入口；Oracle GraalVM 后续独立发行，但其是否可用取决于 JDK、发行版和许可，不能说已在所有 JDK 中转正或成为默认。JDK 24 的 JEP 483 是 Ahead-of-Time Class Loading & Linking，通过构建期缓存类加载/链接工作改善启动，不等价于 Graal JIT 转正，也不等价于 Native Image。

1. 热点探测（Hot Spot Detection）：JIT 不会编译所有代码，只编译"热点"。HotSpot 用两种计数器——方法调用计数器（方法被调用次数）和回边计数器（循环回边次数）。当计数器超过阈值（-XX:CompileThreshold，分层编译下此参数作用被弱化），触发 JIT 编译。这是"把 90% 时间花在 10% 代码上"的工程体现。

2. C1 与 C2 的优化级别差异：

• C1（Client Compiler）：快速编译，编译耗时短，做简单优化——方法内联（Inlining）、逃逸分析（Escape Analysis）与标量替换、简单窥孔优化。不收集或只收集轻量 Profile。
• C2（Server Compiler）：慢编译，编译耗时长但生成代码质量高，做激进优化——循环展开（Loop Unrolling）、锁消除/锁粗化（Lock Elision/Coarsening）、向量化（Vectorization/SIMD）、分支频率预测、基于 Profile 的虚方法内联（CHA 分析）。C2 的 Sea-of-Nodes IR 支持更激进的优化。

3. 分层编译的 5 个编译层次（Tiered Compilation Levels）：

• Tier 0：解释器执行，同时采集 Profile（方法调用计数、回边计数、参数类型）。
• Tier 1：C1 编译，不采集 Profile，用于"快速但不需要再观察"的简单方法。
• Tier 2：C1 编译，采集轻量级 Profile（仅方法调用与回边计数）。
• Tier 3：C1 编译，采集完整 Profile（含分支频率、参数类型、虚方法目标），这是通往 C2 的过渡层。
• Tier 4：C2 编译，基于 Tier 3 采集的 Profile 做最激进优化，达到峰值性能。

典型路径：Tier 0 → Tier 3（C1 + 完整 Profile）→ Tier 4（C2）。当 C2 编译队列满或 CodeCache 紧张时，方法可能停留在 Tier 3 不再升级。

4. CodeCache（代码缓存）：JIT 编译产物（本地机器码）存放于 CodeCache，独立于 Java 堆。64 位分层编译（TieredCompilation）默认约 240MB（JDK 8 至今沿用），可通过 -XX:ReservedCodeCacheSize 调整。CodeCache 由 CodeHeap 分段管理（non-profiled / profiled / non-nmethod 段）。当 CodeCache 接近满时，JVM 会停止 C2 编译甚至逆优化（Deoptimization）已编译代码回退到解释执行，性能断崖式下降。

5. On-Stack Replacement（OSR）：方法正在执行中（通常在长循环里）被替换为编译后的版本，无需等方法退出重新进入。OSR 使长循环也能享受 JIT 优化，但 OSR 版本的入口质量通常比普通编译版本差（因为要从循环中间状态切入）。

6. 逃逸分析与标量替换：C1/C2 分析对象是否"逃逸"出方法/线程。若对象不逃逸，则标量替换——将对象拆解为标量字段直接用寄存器/栈存储，对象不在堆上分配，零 GC 压力。这是"new 了却没进堆"的根本原因。

// 查看方法被 JIT 编译的过程：分层层次、是否内联、是否逆优化
// 启动参数: java -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions
//          -XX:+PrintInlining YourApp
//
// PrintCompilation 输出格式示例（每列含义）：
//   134  4       b  com.demo.Foo::hotLoop (24 bytes)
//    ^  ^       ^  ^
//    |  |       |  方法签名
//    |  |       b=阻塞编译 s=OSR n=safepoint %=逆优化 !=有异常处理
//    |  Tier 层次（0~4，4=C2）
//    编译任务序号

// 逃逸分析示例：对象不逃逸，被标量替换，堆上零分配
public class EscapeAnalysisDemo {
    static class Point {
        int x, y;
        Point(int x, int y) { this.x = x; this.y = y; }
    }

    // Point 对象未逃逸出方法，C2 标量替换后等价于直接用 int x,y
    public int distance(int a, int b) {
        Point p = new Point(a, b);
        return p.x * p.x + p.y * p.y;  // 堆上 0 分配，零 GC
    }
}

高级开发层：

• 查看编译日志：-XX:+PrintCompilation 观察哪些方法被编译、编译到哪个 Tier、是否逆优化；-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining 查看内联决策（too big / hot / already compiled）。
• CodeCache 调优：默认 -XX:ReservedCodeCacheSize=240m，大型应用或大量动态生成代码（如反射/CGlib）可调到 256m~512m。监控 jstat -compiler <pid> 与 CodeCache 'non-profiled nmethods' 使用率。
• 关闭/开启分层编译：-XX:-TieredCompilation 关闭后只走 C2（启动慢、峰值略高，适合长时间运行且不在乎启动的服务）；现代应用默认开启分层编译即可。
• GraalVM JIT 启用：JDK 10+ 通过 -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler 启用 Graal 作为顶层编译器（替代 C2）。

架构师层：

• GraalVM Native Image 选型：Serverless/CLI/微服务启动敏感场景选 Native Image（毫秒级启动、低内存），但要接受无 JIT 运行时优化、反射需配置、动态代理受限、首次构建慢（几分钟）等代价。长跑型服务（> 几分钟预热）仍用传统 JIT 更优。
• JIT vs AOT 权衡：JIT 有运行时 Profile 加持、可激进优化与逆优化，峰值高；AOT 启动快、可预测、无预热，但无法利用运行时信息、优化保守。关键判断：服务生命周期短（< 预热时间）选 AOT，生命周期长选 JIT。
• CodeCache 溢出排查：症状为性能突降（C2 停止编译 + 批量 deopt）。排查：jcmd 查 CodeCache 段使用率，定位是否大量 Lambda/动态类产生编译产物，必要时扩容或排查反射滥用。

追问 1：为什么分层编译比纯 C2 更快启动？

纯 C2 模式下，方法必须积累足够热度才触发编译，而 C2 编译耗时长，启动阶段大量方法停留在解释执行，峰值来得慢。分层编译先用 C1（编译速度快 5~10 倍）快速把热点编译为质量"够用"的本地码，让应用尽早脱离解释执行；同时 C1 采集完整 Profile，等热度足够再交给 C2 做激进优化。这样启动期由 C1 主导（快出码），稳态期由 C2 主导（高质量码），两者衔接使启动时间和峰值吞吐都优于纯 C2。

追问 2：GraalVM JIT 能否完全替代 C2？

要分清三件事：JVMCI/Graal 编译器可通过受支持的 GraalVM/JDK 组合启用；GraalVM Native Image 是闭世界 AOT 发行形态；JDK 24 的 JEP 483 只缓存 AOT class loading/linking。Graal 可在部分发行版中生产使用，但 OpenJDK 主线默认顶层编译器仍是 C2；不要把 Graal JIT 说成所有 JDK 的默认或 JEP 483 的产物。

追问 3：CodeCache 满了会怎样？

CodeCache 接近满时触发分段降级：首先停止 Tier 4（C2）编译，只保留 C1 编译；继续紧张则停止所有 JIT 编译，新热点只能解释执行；最严重时触发批量逆优化（Sweep）——已编译的代码被标记为"not entrant"甚至"zombie"，方法回退到解释执行，性能断崖式下降（TPS 可能掉 50%+）。排查：jcmd <pid> Compiler.CodeCache 看各段使用率，-XX:+PrintCodeCache 看启动后占用。根因多为大量动态生成类（反射/CGlib/Lambda）产生海量编译产物，需扩容 CodeCache 或减少动态代码生成。

这道题考察对 JDK 17 → 21 → 25 三条 LTS 语言与 JVM 演进的掌握：Records / Sealed / Pattern Matching / 虚拟线程 / ScopedValue / 紧凑对象头等特性的设计动机与实现边界，以及生产升级真实代价。当前存量多在 17/21，新系统评估 21 或 25；虚拟线程在 21 可用，pinning 治理在 24+（JEP 491）显著改善。能否讲清三代差异与迁移坑是架构师基本功。

LTS 节奏：JDK 6/7（历史）→ 8（2014，长期主流）→ 11（2018）→ 17（2021）→ 21（2023）。Oracle 改为半年一个特性版、每三年一个 LTS；非 LTS 版仅支持 6 个月，生产应选 LTS。

语言特性演进：var（10）→ switch 表达式（14）→ Text Blocks（15）→ Records（16 正式）→ Pattern Matching for instanceof（16 正式）/ switch（21 正式）→ Sealed（17 正式）→ Record Patterns（21 正式）→ Virtual Threads（21 正式）。Structured Concurrency 与 ScopedValue 在 JDK 21 是预览；后者到 JDK 25 正式，前者在后续版本仍处于预览迭代。

JVM/类库演进：G1 成为默认 GC（9）；CMS 移除（14）；Generational ZGC 在 JDK 21 引入并需显式开启，JDK 23 起转为默认形态；内部 API 在 JDK 16/17 默认强封装；finalize 自 JDK 9 废弃，JEP 421 在 JDK 18 增加 finalization 开关；Security Manager 在 JDK 17 废弃、JDK 24 永久禁用（JEP 486）。JDK 25 LTS 侧重点：ScopedValue 正式；可选紧凑对象头（JEP 519，-XX:+UseCompactObjectHeaders）；分代 Shenandoah 等收集器继续演进；Structured Concurrency 仍处 Preview 迭代——升级 25 要单独评估预览 API 与对象头布局对 JOL/JNI 的影响。

Records：不可变数据载体，编译器自动生成私有 final 字段、全参构造、equals/hashCode/toString 与 accessor（非 getter）。JVM 层面是普通 final class，无特殊字节码，只是语法糖 + 约定。

Sealed Class：通过 permits 显式限定子类集合，JVM 用 PermittedSubclasses 属性存储。与 Pattern Matching 配合可做编译期穷尽性检查，替代 visitor 模式。

Pattern Matching：instanceof 模式匹配（16 正式）、switch 模式匹配（21 正式）、Record Pattern（21 正式）——把"类型判断 + 强转 + 解构"合并为一步，减少样板与 ClassCastException。还需说清：Structured Concurrency 和 ScopedValue 在 JDK 21 都需要 --enable-preview，不能作为 21 的稳定 API 介绍。

// Records：不可变数据载体，自动生成字段/构造/equals/hashCode/toString
record Point(int x, int y) {}

// Sealed：显式限定子类，配合模式匹配做穷尽分支
sealed interface Shape permits Circle, Rect, Square {}
final class Circle implements Shape { double r; }

// Pattern Matching for switch（JDK 21 正式）：类型 + 穷尽检查
String describe(Shape s) {
    return switch (s) {
        case Circle c -> "圆 r=" + c.r;
        case Rect  r -> "矩形";
        case Square s -> "正方形";
        default        -> "其他";  // 非 sealed 时仍需 default
    };
}

升级迁移实战：① 用 jdeprscan / jdeps 扫描废弃 API 与内部依赖；② 字节码版本：JDK 17 = 61，JDK 21 = 65，注意 Maven release 参数；③ Spring Boot 3 强制 JDK 17+ 且包名由 javax.* 改为 jakarta.*（Jakarta EE 9），这是最大的破坏性变更；④ 依赖库需同步升级（如 Hibernate 6、Tomcat 10）。

GC 调优变化：G1 是默认且大幅优化；低延迟候选是 ZGC/Shenandoah，但必须按 JDK 版本验证。Generational ZGC 在 JDK 21 通过 JEP 439 引入并需 -XX:+ZGenerational 显式开启，JDK 23 起按 JEP 474 成为默认形态；不能直接套用旧命令。

强封装影响：JDK 16 通过 JEP 396 默认强封装 JDK 内部 API，JDK 17 通过 JEP 403 继续收紧；旧库反射访问内部包通常需升级，或按最小范围显式 --add-opens。不要把废弃的 --illegal-access 当作长期方案。

追问 1：Records 为什么不可继承、不能有实例字段？ Records 的语义是"透明数据载体"，继承会破坏等值语义与解构稳定性，故设计为 final 且只能声明组件。需要可变/带行为时用普通类或 Builder。

追问 2：Sealed + Pattern Matching 如何替代 Visitor？ 对 sealed 类型做 switch 模式匹配，编译器能验证分支穷尽，新增子类时若漏处理会编译报错，比 Visitor 的双分派更轻量安全。

追问 3：JDK 21 的 String Templates 现状？ JEP 459/465 曾作为预览，后因设计争议在 JDK 23 被撤销，目前未定稿，不宜当作"已确定特性"大讲。

上线门禁：堆/Metaspace/CodeCache 阈值与 GC 日志采集；变更前后对比分配速率与停顿。表达提纲：现象→参数/日志证据→根因分层→回滚与容量。

这道题考察的是运行时内存的系统级本质：进程看到的是一段连续的虚拟地址空间，而磁盘/物理内存只是它背后的稀疏映射。JVM 的 -Xmx、直接内存、栈——最终都落在 OS 的虚拟内存 + 页表之上。能讲清 页表 → TLB → 缺页中断 这条链，才真正理解"堆为什么可以是逻辑大而物理小的"、GC 扫描为何怕 swap、以及透明大页对停顿的影响。

单一地址空间：早期进程直接使用物理地址，无隔离、无保护，一个程序崩溃整机受影响。

分段（Segmentation）：按逻辑段（代码/数据/栈）划分，段表映射 段号 + 偏移，保护语义好，但碎片化和难以共享。

分页（Paging）：把内存与地址空间切成固定大小页（常见 4KB），页表完成虚拟页 → 物理页帧的映射，是当代主流（x86-64、ARM 64 均采用），叠加"按需换页 + 写入时复制"。

现代多级页表 + TLB：为解决单级页表过大，演进为 4 级页表（PML4/PDPT/PD/PT） 稀疏结构，并用 TLB（页表高速缓存）加速地址翻译。

虚拟内存：每个进程有独立的虚拟地址空间（64 位下理论极大），通过一级级页表索引到物理页。虚拟 ≠ 物理常驻：访问的页可以尚不存在于物理内存，命中时通过 缺页中断（Page Fault） 才加载。

页表结构：x86-64 下 48 位线性地址 + 4 级页表（PML4→PDPT→PD→PT→Offset），每级页表只分配被实际使用的部分，从而稀疏；Linux 用 mmap 建立映射、文件映射页可 延迟加载（lazy load）。

TLB 与命中率：地址翻译每访问一次内存都查页表太慢，故用 TLB 缓存最近翻译；大页（Huge Pages / 2MB / 1GB） 让一个 TLB 项覆盖更多空间、显著提升命中率——这是 JVM 上大堆 GC 吞吐改善的底层原因。

换页（Paging/Swap）：物理内存不足时 OS 把冷页换出到磁盘。对 GC 而言，换页导致扫描时需要回读磁盘页，停顿呈数量级恶化，必须避免堆被换出。

// Java 侧观察虚拟内存 / 驻留集大小的常见命令
$ jcmd <pid> VM.flags | grep -i huge       // 查看是否用大页
$ pmap -x <pid> | tail -5                 // 进程地址空间分布
$ cat /proc/<pid>/smaps | grep -i rss      // 每段物理驻留大小
$ jcmd <pid> GC.heap_info                  // JVM 视角的堆视图

避免堆被 Swap：线上大堆服务应 vm.swappiness 调低（如 1~10），并监控 si/so（swap in/out）与 GC 停顿相关性；一旦出现频繁换页，优先收缩堆或扩容而非调 GC 参数。

透明大页 THP 的双刃剑：Linux THP 后台线程聚合页可能造成瞬时 CPU 尖峰与长停顿，大堆 JVM 常见做法是 echo never > /sys/kernel/mm/transparent_hugepage/enabled，G1 建议显式评估而非默认开启。

直接内存与页对齐：NIO 的 DirectByteBuffer 默认走 native direct allocation，不是 mmap；MappedByteBuffer 才基于文件映射。堆、映射区和大页池是否共享大页，取决于 JVM 参数、内核配置和平台，需分别验证。

容器内内存可见性：容器（cgroup）限制下 /proc 常显示宿主机内存，需结合 cgroup 统计判断真实 RSS，避免把"容器配额"误当"OS 物理内存"。

追问 1：为什么多级页表反而比单级省内存？ 单级页表需为整个地址空间预留，多级则只逐级分配"实际被占用"的页（Leaf 表才按需分配），索引结构开销摊到稀疏访问上。

追问 2：COW（写时复制）如何配合 fork/JVM？ 父进程 fork 后子进程共享同一组物理页（页表指向同一页并标记只读），任一写才复制新页。JVM 基于该机制做 -XX:+UseSerialGC 下的某些优化，也解释了进程数与内存的"假共享"现象。

追问 3：大页为什么能降低 GC 停顿方差？ 页更大 → TLB 命中率更高 → 堆遍历/对象搬运时地址翻译开销显著下降，尤其对 10GB+ 大堆在 G1/ZGC 下可降低扫描的 CPU 时间与波动。

这道题考察启动与预热成本的工程治理：类加载、JIT 编译、元数据解析在 Serverless/弹性扩容下被反复支付。CDS/AppCDS 缓存类元数据；Project Leyden 把「静态/半静态」优化产品化；AOT/Native 与 CRaC 是更强但更重的路径。要能讲清各自边界与组合拳。

HotSpot 默认每次冷启动解析类 → CDS（JDK 内置类归档）→ AppCDS（应用类归档，JDK 10+ 易用化）→ Leyden（凝聚 CDS/AOT 训练与约束，缩短 TTFB/TTFP）→ 与 Graal Native（C06）/ CRaC（检查点恢复）并列。驱动力：容器密度、缩扩容秒级、CI 反馈与 Serverless 计费。

启动时间 ≈ 类加载/链接 + 解释执行/JIT 升温 + I/O 初始化。CDS 解决「重复解析」；Leyden 进一步允许在受约束世界里预计算；Native Image 把运行时决策前移到构建期；CRaC 冻结已预热进程。约束越强（封闭世界），收益越大、灵活性越低。

1. AppCDS 落地：训练跑一遍生成 classlist → dump 归档 → 生产 -XX:SharedArchiveFile=；镜像构建把 jsa 打进层；注意 JDK 小版本与归档兼容。

2. Leyden：跟进 LTS 能力（静态/半静态特性以发行说明为准）；把「训练作业」纳入 CI，避免开发机手工产物。

3. 与 Spring：Boot 3 AOT 处理 Bean 定义；CDS 管类元数据——可叠加。Native 另见专卡，勿与 CDS 混为一谈。

4. 度量：分阶段看 time-to-first-request、CPU 升温曲线、RSS；扩容场景对比「无归档 / AppCDS / Native」。

# 简化示意：生成并使用 AppCDS（具体标志随 JDK 版本查阅 man）
java -XX:DumpLoadedClassList=app.classlist -jar app.jar
java -Xshare:dump -XX:SharedClassListFile=app.classlist -XX:SharedArchiveFile=app.jsa -jar app.jar
java -XX:SharedArchiveFile=app.jsa -jar app.jar

追问 1：有了 AppCDS 还要不要 Leyden？CDS 偏类元数据复用；Leyden 目标是更系统的静态化与训练流水线，覆盖预热而不只是加载。

追问 2：为何 Serverless 更敏感？冷启动频率高，每次支付全量类加载/JIT；归档与约束世界的 ROI 远高于长驻进程。

追问 3：CRaC 与 CDS 冲突吗？不冲突。CDS 利于每次启动；CRaC 利于从快照恢复。连接池/文件描述符必须有 restore 钩子。