为何Java 8/SpringBoot应用中Unsafe.defineClass出现高CPU占用异常

根因分析 #

你遇到的是Java 8反射优化+字节码增强工具叠加导致的锁竞争卡顿问题，触发逻辑如下：

• Java 8默认对反射调用做了优化：同一个方法反射调用次数达到sun.reflect.inflationThreshold默认值15次后，JVM会通过MethodAccessorGenerator动态生成字节码，调用Unsafe.defineClass生成对应的MethodAccessor实现类，替代原先的Native方法调用，提升反射性能。
• 你业务代码中使用的org.springframework.beans.BeanUtils.copyProperties底层基于反射实现Bean属性拷贝，如果业务中存在大量不同类的Bean拷贝场景，会触发大量动态类生成逻辑。
• 从pstack调用栈可以看到，你的JVM加载了instrument的字节码增强组件（大概率是APM探针、链路追踪工具、Arthas这类调试工具、热部署组件），这类组件会注册ClassFileLoadHook钩子，每次类加载都会触发字节码转换逻辑，该逻辑内部存在全局锁，大量动态类并发生成时会出现严重的锁竞争，CPU打满100%，运行时间越长累积的待生成动态类越多，卡顿时长越高，等批量类生成完成后CPU就会自动回落。

解决方案 #

• 优先替换Bean拷贝实现：改用编译期生成拷贝代码的工具MapStruct，完全避免运行期反射调用，从根源上消除动态类生成逻辑，性能也会提升数倍。
• 临时应急调整：如果暂时不能修改业务代码，可以添加JVM启动参数抬高反射优化阈值，避免大量动态类生成：

  -Dsun.reflect.inflationThreshold=2147483647
  

  该配置会让反射几乎一直走Native调用，不会生成动态类，代价是单反射调用性能下降约30%，适合临时恢复业务使用。
• 优化字节码增强配置：排查你使用的APM/链路追踪/调试探针，升级到最新稳定版，同时在探针配置中排除sun.reflect包下的类增强，这类动态生成的临时类不需要做埋点、链路追踪等逻辑，排除后可以大幅降低类加载钩子的开销。
• 业务逻辑优化：检查DisputeSubmit.insertDisputeInfo方法及上层调用逻辑，避免在循环中反复调用BeanUtils拷贝不同类的属性，尽量复用拷贝逻辑或者提前缓存反射元数据。

内容的提问来源于stack exchange，提问作者xumenger