高频面试题三连击

Q1：请描述JVM类加载的全过程？哪些行为会触发类加载？

当面试官抛出这个问题时，他期待的是一个有层次感的回答。类加载绝非简单的"读取.class文件"，而是包含着精妙的生命周期设计：

1. 加载阶段（Loading）
   通过全限定名获取二进制字节流 → 转化为方法区运行时数据结构 → 生成堆中的Class对象。这里有个隐藏考点：数组类的加载由JVM直接创建，不通过类加载器。

2. 验证阶段（Verification）
   文件格式验证（魔数0xCAFEBABE）→ 元数据验证（继承final类检查）→ 字节码验证（栈帧类型一致性）→ 符号引用验证。阿里等大厂特别关注验证阶段对性能的影响。

3. 准备阶段（Preparation）
   为类变量分配内存并设置初始值（零值）。注意与初始化阶段的区别：public static int value = 123; 在准备阶段value=0，初始化阶段才会变为123。

4. 解析阶段（Resolution）
   将符号引用转换为直接引用，这里可能触发其他类的加载。美团面试曾考过解析阶段与动态绑定的关系。

5. 初始化阶段（Initialization）
   执行clinit方法（静态变量赋值+静态代码块）。触发条件包括：new指令、反射调用、主类加载等。

触发时机的完整清单：
- 遇到new、getstatic等字节码指令
- Class.forName()反射调用
- 子类加载触发父类加载
- JDK7+的MethodHandle解析
- 接口default方法实现类初始化

Q2：双亲委派模型是如何破坏的？有什么实际应用案例？

双亲委派不是铁律，而是可被打破的约定。掌握这个知识点，能体现你对框架底层原理的理解深度：

常规流程：
自定义类加载器 → AppClassLoader → ExtClassLoader → BootstrapClassLoader 自底向上检查，自顶向下尝试加载。

破坏方式：
1. SPI机制（JDBC经典案例）
BootstrapClassLoader加载DriverManager（在rt.jar），但需要加载厂商实现的Driver接口实现类（在classpath）。通过线程上下文类加载器（TCCL）实现反向委托。

1. OSGi模块化
   每个Bundle有自己的类加载器，采用网状结构而非树状结构。平级Bundle间可能直接交互，形成类加载的"微服务化"。

2. 热部署场景
   Tomcat为每个Web应用配置独立的WebappClassLoader，修改类后直接创建新加载器，避免重复加载冲突。

大厂实战：
- 阿里HSF框架自定义类加载器实现服务隔离
- 美团Leaf雪花算法实现动态加载不同业务ID生成器
- 动态代码加密场景中（如某金融公司保护业务逻辑）需要重写findClass方法

Q3：如何自定义类加载器？哪些核心方法必须重写？

面试官要考察你的动手能力和对类加载本质的理解。以下是实现要点：

java
public class CustomClassLoader extends ClassLoader {
private String classPath;

@Override // 关键方法1：获取字节码
protected Class<?> findClass(String name) {
    byte[] classData = loadClassData(name);
    if(classData == null){
        throw new ClassNotFoundException();
    }
    return defineClass(name, classData, 0, classData.length);
}

// 关键方法2：打破双亲委派
@Override 
protected Class<?> loadClass(String name, boolean resolve) {
    synchronized (getClassLoadingLock(name)) {
        // 1. 特殊处理核心类（如java.lang包）
        if(name.startsWith("java.")){
            return super.loadClass(name, resolve);
        }
        // 2. 先检查是否已加载
        Class<?> c = findLoadedClass(name);
        if(c == null){
            c = findClass(name);
        }
        if(resolve){
            resolveClass(c);
        }
        return c;
    }
}

private byte[] loadClassData(String className) {
    // 实现从文件/网络等自定义位置加载字节码
}

}

注意事项：
1. 重写findClass而非loadClass是更安全的方式（除非明确要破坏双亲委派）
2. defineClass方法需要保护性拷贝字节数组（防止外部修改）
3. 考虑并行加载时需要getClassLoadingLock保证线程安全
4. 实现FQCN到文件路径的转换逻辑（如org.Test → org/Test.class）

大厂进阶考法：
- 如何实现不同版本类库的并行加载？（如同时加载Hibernate 3和4）
- 类卸载的条件和监控手段（PermGen vs MetaSpace差异）
- 如何避免内存泄漏？（特别注意JVM对类加载器的可达性判定）

深度扩展知识

类加载器与命名空间

每个类加载器实例维护独立的命名空间，相同类被不同加载器加载会被JVM视为不同的类。这也是实现模块化隔离的基础原理。

预验证优化

Android的DEX文件在编译时进行大部分验证工作，牺牲少量灵活性换取运行时性能。这种设计思想在服务端JVM也有体现（AOT编译趋势）。

现代JVM的变化

JDK9模块化系统对类加载机制的改造：
- 引入Layer概念实现模块版本隔离
- 不再严格区分BootstrapClassLoader和ExtensionClassLoader
- 新增jrt协议访问运行时镜像中的类

明日预告：《JVM内存模型的攻防战——从硬件缓存到逃逸分析》，我们将深入剖析：
- 对象内存布局对synchronized的影响
- 伪共享问题的定位与解决
- 美团面试真题：volatile与内存屏障的底层实现