如何通过分析 Class.forName 产生的锁竞争解决应用启动时的性能缓慢问题

一分耕耘，一分收获！既然都打开这篇《如何通过分析 Class.forName 产生的锁竞争解决应用启动时的性能缓慢问题》，就坚持看下去，学下去吧！本文主要会给大家讲到等等知识点，如果大家对本文有好的建议或者看到有不足之处，非常欢迎大家积极提出！在后续文章我会继续更新文章相关的内容，希望对大家都有所帮助！

Class.forName会触发ClassLoader.loadClass的同步锁竞争，导致高并发下线程阻塞；可通过ConcurrentHashMap缓存+computeIfAbsent避免重复加载，配合启动预热和统一ClassLoader复用缓解。

Class.forName 会触发类加载器锁竞争

Class.forName 默认会触发类加载器的 loadClass 流程，而 JVM 的双亲委派机制在 ClassLoader.loadClass(String, boolean) 中对类名做了同步保护——尤其是当多个线程并发调用 Class.forName("com.example.Foo") 时，若该类尚未加载，它们会争抢同一个 ClassLoader 实例上的 monitor 锁。

这种锁不是你代码里写的 synchronized，而是 JVM 内部实现的重量级锁；一旦发生锁膨胀（比如高并发 + 频繁未命中缓存），就会出现大量线程卡在 Object.wait() 或 Unsafe.park()，表现为启动阶段 CPU 不高但耗时飙升。

• 典型现象：应用启动日志中看到多条“Loading class X”几乎同时开始，但结束时间错开几十到几百毫秒
• 堆栈里频繁出现 java.lang.ClassLoader.loadClass 调用链，且线程状态为 WAITING 或 BLOCKED
• 使用 jstack -l 可观察到多个线程在等待同一 sun.misc.Launcher$AppClassLoader 实例

ConcurrentHashMap 缓存 Class.forName 结果能绕过锁

核心思路是：不让多个线程重复走到 JVM 的 loadClass 同步入口。自己用 ConcurrentHashMap 缓存已加载的 Class，后续直接返回，跳过锁检查。

注意必须用 computeIfAbsent，它内部基于 CAS + volatile 写入，不依赖外部锁；且传入的 lambda 只会在 key 不存在时执行一次，天然避免并发重复加载：

private static final Map> CLASS_CACHE = new ConcurrentHashMap<>();

public static Class safeLoadClass(String className) throws ClassNotFoundException {
    return CLASS_CACHE.computeIfAbsent(className, name -> {
        try {
            return Class.forName(name, true, Thread.currentThread().getContextClassLoader());
        } catch (ClassNotFoundException e) {
            throw e;
        }
    });
}

• 不要用 get + putIfAbsent 组合，存在竞态窗口：两次调用可能都查不到、都触发 Class.forName
• 缓存 key 必须包含 classloader，否则不同 classloader 加载同名类会冲突（不过多数启动场景用的是 AppClassLoader，可暂不考虑）
• 如果类加载失败，computeIfAbsent 会把异常包装成 RuntimeException 抛出，需在外层捕获处理

预热关键类可摊薄锁竞争压力

启动初期集中触发类加载，比分散在运行时更可控。与其让 50 个线程在 1 秒内随机调用 Class.forName，不如在 main 方法开头或 Spring ApplicationContext 初始化前，用单线程批量加载。

例如 JDBC 驱动预热：

// 在应用真正初始化前执行
List driverClasses = Arrays.asList(
    "com.mysql.cj.jdbc.Driver",
    "com.zaxxer.hikari.HikariDataSource",
    "org.springframework.jdbc.core.JdbcTemplate"
);
driverClasses.forEach(Classes::safeLoadClass); // 复用上面的缓存方法

• 避免在静态块里直接 Class.forName，因为静态块执行顺序不可控，可能被其他类间接触发，反而加剧竞争
• 预热应避开高并发路径（如 Servlet 初始化、BeanPostProcessor 回调），选在主线程空闲期做
• 预热后仍要保留缓存逻辑——运行时反射调用（如 JSON 反序列化）仍可能触发新类加载

锁竞争最隐蔽的点：锁对象不稳定

如果你封装了 Class.forName 工具类，但每次调用都 new 一个临时 ClassLoader 实例，或者用字符串字面量作锁标识（如 synchronized("key")），那缓存和预热都白做——JVM 无法复用偏向锁，每次都是重量级锁。

真正有效的做法是：

• 确保所有 Class.forName 调用走同一个上下文 ClassLoader（通常是 Thread.currentThread().getContextClassLoader()）
• 缓存 Map 声明为 static final，避免被 GC 或重置
• 不要在循环里反复调用 Class.forName 加载同一类，哪怕加了缓存，也浪费哈希查找开销

锁竞争问题从来不在“有没有锁”，而在“锁是不是打在了不该打的地方”。Class.forName 的锁藏得深，但只要盯住类加载器实例的生命周期和复用性，就能把它从性能瓶颈变成透明通道。

今天关于《如何通过分析 Class.forName 产生的锁竞争解决应用启动时的性能缓慢问题》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！