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 <pid>可观察到多个线程在等待同一sun.misc.Launcher$AppClassLoader实例
ConcurrentHashMap 缓存 Class.forName 结果能绕过锁
核心思路是：不让多个线程重复走到 JVM 的 loadClass 同步入口。自己用 ConcurrentHashMap 缓存已加载的 Class<?>，后续直接返回，跳过锁检查。
注意必须用 computeIfAbsent，它内部基于 CAS + volatile 写入，不依赖外部锁；且传入的 lambda 只会在 key 不存在时执行一次，天然避免并发重复加载：
private static final Map<String, Class<?>> 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<String> 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 的锁藏得深，但只要盯住类加载器实例的生命周期和复用性，就能把它从性能瓶颈变成透明通道。
