从 JVM 分析 hibernate-validator NoClassDefFoundError

最近排查一个spring boot应用抛出hibernate.validator NoClassDefFoundError的问题,异常信息如下:

Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.hibernate.validator.internal.engine.ConfigurationImpl    at org.hibernate.validator.HibernateValidator.createGenericConfiguration(HibernateValidator.java:33) ~[hibernate-validator-5.3.5.Final.jar:5.3.5.Final]    at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:276) ~[validation-api-1.1.0.Final.jar:na]    at org.springframework.boot.validation.MessageInterpolatorFactory.getObject(MessageInterpolatorFactory.java:53) ~[spring-boot-1.5.3.RELEASE.jar:1.5.3.RELEASE]    at org.springframework.boot.autoconfigure.validation.DefaultValidatorConfiguration.defaultValidator(DefaultValidatorConfiguration.java:43) ~[spring-boot-autoconfigure-1.5.3.RELEASE.jar:1.5.3.RELEASE]    atsun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_112]    atsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_112]    atsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_112]    at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_112]    at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:162) ~[spring-beans-4.3.8.RELEASE.jar:4.3.8.RELEASE]    ...32common frames omitted

这个错误信息表面上是 NoClassDefFoundError ,但是实际上 ConfigurationImpl 这个类是在 hibernate-validator-5.3.5.Final.jar 里的,不应该出现找不到类的情况。

那为什么应用里抛出这个 NoClassDefFoundError ?

有经验的开发人员从 Could not initialize class 这个信息就可以知道,实际上是一个类在初始化时抛出的异常,比如static的静态代码块,或者static字段初始化的异常。

谁初始化了 org.hibernate.validator.internal.engine.ConfigurationImpl

但是当我们在 HibernateValidator 这个类,创建 ConfigurationImpl 的代码块里打断点时,发现有两个线程触发了断点:

publicclassHibernateValidatorimplementsValidationProvider{    @OverridepublicConfiguration createGenericConfiguration(BootstrapState state) {returnnewConfigurationImpl( state );    }

其中一个线程的调用栈是:

Thread [background-preinit] (Classload:ConfigurationImpl)    HibernateValidator.createGenericConfiguration(BootstrapState)line:33Validation$GenericBootstrapImpl.configure()line:276BackgroundPreinitializer$ValidationInitializer.run()line:107BackgroundPreinitializer$1.runSafely(Runnable)line:59BackgroundPreinitializer$1.run()line:52Thread.run()line:745

另外一个线程调用栈是:

Thread [main] (Suspended (breakpoint at line33inHibernateValidator))    owns: ConcurrentHashMap  (id=52)    owns:Object(id=53)    HibernateValidator.createGenericConfiguration(BootstrapState) line:33Validation$GenericBootstrapImpl.configure() line:276MessageInterpolatorFactory.getObject() line:53DefaultValidatorConfiguration.defaultValidator() line:43NativeMethodAccessorImpl.invoke0(Method,Object,Object[]) line:notavailable [native method]    NativeMethodAccessorImpl.invoke(Object,Object[]) line:62DelegatingMethodAccessorImpl.invoke(Object,Object[]) line:43Method.invoke(Object,Object...) line:498CglibSubclassingInstantiationStrategy(SimpleInstantiationStrategy).instantiate(RootBeanDefinition,String, BeanFactory,Object, Method,Object...) line:162ConstructorResolver.instantiateUsingFactoryMethod(String, RootBeanDefinition,Object[]) line:588DefaultListableBeanFactory(AbstractAutowireCapableBeanFactory).instantiateUsingFactoryMethod(String, RootBeanDefinition,Object[]) line:1173

显然,这个线程的调用栈是常见的spring的初始化过程。

BackgroundPreinitializer 做了什么

那么重点来看下 BackgroundPreinitializer 线程做了哪些事情:

@Order(LoggingApplicationListener.DEFAULT_ORDER +1)publicclassBackgroundPreinitializerimplementsApplicationListener{@OverridepublicvoidonApplicationEvent(ApplicationEnvironmentPreparedEvent event){try{            Thread thread =newThread(newRunnable() {@Overridepublicvoidrun(){                    runSafely(newMessageConverterInitializer());                    runSafely(newMBeanFactoryInitializer());                    runSafely(newValidationInitializer());                    runSafely(newJacksonInitializer());                    runSafely(newConversionServiceInitializer());                }publicvoidrunSafely(Runnable runnable){try{                        runnable.run();                    }catch(Throwable ex) {// Ignore}                }            },"background-preinit");            thread.start();        }

可以看到 BackgroundPreinitializer 类是spring boot为了加速应用的初始化,以一个独立的线程来加载hibernate validator这些组件。

这个 background-preinit 线程会吞掉所有的异常。

显然 ConfigurationImpl 初始化的异常也被吞掉了,那么如何才能获取到最原始的信息?

获取到最原始的异常信息

在 BackgroundPreinitializer 的 run() 函数里打一个断点(注意是 Suspend thread 类型, 不是 Suspend VM ),让它先不要触发 ConfigurationImpl 的加载,让spring boot的正常流程去触发 ConfigurationImpl 的加载,就可以知道具体的信息了。

那么打出来的异常信息是:

Causedby:java.lang.NoSuchMethodError:org.jboss.logging.Logger.getMessageLogger(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Object;    at org.hibernate.validator.internal.util.logging.LoggerFactory.make(LoggerFactory.java:19) ~[hibernate-validator-5.3.5.Final.jar:5.3.5.Final]    at org.hibernate.validator.internal.util.Version.(Version.java:22) ~[hibernate-validator-5.3.5.Final.jar:5.3.5.Final]    at org.hibernate.validator.internal.engine.ConfigurationImpl.(ConfigurationImpl.java:71) ~[hibernate-validator-5.3.5.Final.jar:5.3.5.Final]    at org.hibernate.validator.HibernateValidator.createGenericConfiguration(HibernateValidator.java:33) ~[hibernate-validator-5.3.5.Final.jar:5.3.5.Final]    at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:276) ~[validation-api-1.1.0.Final.jar:na]    at org.springframework.boot.validation.MessageInterpolatorFactory.getObject(MessageInterpolatorFactory.java:53) ~[spring-boot-1.5.3.RELEASE.jar:1.5.3.RELEASE]

那么可以看出是 org.jboss.logging.Logger 这个类不兼容,少了 getMessageLogger(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Object 这个函数。

那么检查下应用的依赖,可以发现 org.jboss.logging.Logger 在 jboss-common-1.2.1.GA.jar和 jboss-logging-3.3.1.Final.jar 里都有。

显然是 jboss-common-1.2.1.GA.jar 这个依赖过时了,需要排除掉。

总结异常的发生流程

应用依赖了 jboss-common-1.2.1.GA.jar ,它里面的 org.jboss.logging.Logger 太老

spring boot启动时, BackgroundPreinitializer 里的线程去尝试加载 ConfigurationImpl ,然后触发了 org.jboss.logging.Logger 的函数执行问题

BackgroundPreinitializer 吃掉了异常信息,jvm把 ConfigurationImpl 标记为不可用的

spring boot正常的流程去加载 ConfigurationImpl ,jvm发现 ConfigurationImpl 类是不可用,直接抛出 NoClassDefFoundError

Causedby:java.lang.NoClassDefFoundError:Couldnotinitializeclassorg.hibernate.validator.internal.engine.ConfigurationImpl

深入JVM

为什么第二次尝试加载 ConfigurationImpl 时,会直接抛出 java.lang.NoClassDefFoundError: Could not initialize class ?

下面用一段简单的代码来重现这个问题:

try{  org.hibernate.validator.internal.util.Version.touch();}catch(Throwable e) {  e.printStackTrace();}System.in.read();try{  org.hibernate.validator.internal.util.Version.touch();}catch(Throwable e) {  e.printStackTrace();}

使用HSDB来确定类的状态

当抛出第一个异常时,尝试用HSDB来看下这个类的状态。

sudojava -classpath"$JAVA_HOME/lib/sa-jdi.jar"sun.jvm.hotspot.HSDB

然后在HSDB console里查找到 Version 的地址信息

hsdb>classorg.hibernate.validator.internal.util.Versionorg/hibernate/validator/internal/util/Version @0x00000007c0060218

然后在 Inspector 查找到这个地址,发现 _init_state 是5。

再看下hotspot代码,可以发现5对应的定义是 initialization_error :

// /hotspot/src/share/vm/oops/instanceKlass.hpp// See "The Java Virtual Machine Specification" section 2.16.2-5 for a detailed description// of the class loading & initialization procedure, and the use of the states.enumClassState{  allocated,// allocated (but not yet linked)loaded,// loaded and inserted in class hierarchy (but not linked yet)linked,// successfully linked/verified (but not initialized yet)being_initialized,// currently running class initializerfully_initialized,// initialized (successfull final state)initialization_error// error happened during initialization};

JVM规范里关于Initialization的内容

http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-5.html#jvms-5.5

从规范里可以看到初始一个类/接口有12步,比较重要的两步都用黑体标记出来了:

5: If the Class object for C is in an erroneous state, then initialization is not possible. Release LC and throw a NoClassDefFoundError.

11: Otherwise, the class or interface initialization method must have completed abruptly by throwing some exception E. If the class of E is not Error or one of its subclasses, then create a new instance of the class ExceptionInInitializerError with E as the argument, and use this object in place of E in the following step.

第一次尝试加载Version类时

当第一次尝试加载时,hotspot InterpreterRuntime在解析 invokestatic 指令时,尝试加载 org.hibernate.validator.internal.util.Version 类, InstanceKlass 的 _init_state 先是标记为 being_initialized ,然后当加载失败时,被标记为 initialization_error 。

对应 Initialization 的11步。

// hotspot/src/share/vm/oops/instanceKlass.cpp// Step 10 and 11Handlee(THREAD, PENDING_EXCEPTION);CLEAR_PENDING_EXCEPTION;// JVMTI has already reported the pending exception// JVMTI internal flag reset is needed in order to report ExceptionInInitializerErrorJvmtiExport::clear_detected_exception((JavaThread*)THREAD);{EXCEPTION_MARK;this_oop->set_initialization_state_and_notify(initialization_error, THREAD);CLEAR_PENDING_EXCEPTION;// ignore any exception thrown, class initialization error is thrown below// JVMTI has already reported the pending exception// JVMTI internal flag reset is needed in order to report ExceptionInInitializerErrorJvmtiExport::clear_detected_exception((JavaThread*)THREAD);}DTRACE_CLASSINIT_PROBE_WAIT(error,InstanceKlass::cast(this_oop()), -1,wait);if(e->is_a(SystemDictionary::Error_klass())) {THROW_OOP(e());}else{JavaCallArgumentsargs(e);THROW_ARG(vmSymbols::java_lang_ExceptionInInitializerError(),vmSymbols::throwable_void_signature(),            &args);}

第二次尝试加载Version类时

当第二次尝试加载时,检查 InstanceKlass 的 _init_state 是 initialization_error ,则直接抛出 NoClassDefFoundError: Could not initialize class .

对应 Initialization 的5步。

// hotspot/src/share/vm/oops/instanceKlass.cppvoidInstanceKlass::initialize_impl(instanceKlassHandle this_oop, TRAPS) {// ...// Step 5if(this_oop->is_in_error_state()) {      DTRACE_CLASSINIT_PROBE_WAIT(erroneous, InstanceKlass::cast(this_oop()),-1,wait);ResourceMarkrm(THREAD);constchar* desc ="Could not initialize class ";constchar* className = this_oop->external_name();size_tmsglen =strlen(desc) +strlen(className) +1;char* message = NEW_RESOURCE_ARRAY(char, msglen);if(NULL== message) {// Out of memory: can't create detailed error messageTHROW_MSG(vmSymbols::java_lang_NoClassDefFoundError(), className);      }else{        jio_snprintf(message, msglen,"%s%s", desc, className);        THROW_MSG(vmSymbols::java_lang_NoClassDefFoundError(), message);      }    }

总结

spring boot在 BackgroundPreinitializer 类里用一个独立的线程来加载validator,并吃掉了原始异常

第一次加载失败的类,在jvm里会被标记为 initialization_error ,再次加载时会直接抛出 NoClassDefFoundError: Could not initialize class

当在代码里吞掉异常时要谨慎,否则排查问题带来很大的困难

欢迎工作一到五年的Java工程师朋友们加入Java程序员开发: 854393687

群内提供免费的Java架构学习资料(里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码,MyBatis,Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料)合理利用自己每一分每一秒的时间来学习提升自己,不要再用"没有时间“来掩饰自己思想上的懒惰!趁年轻,使劲拼,给未来的自己一个交代!

你可能感兴趣的:(从 JVM 分析 hibernate-validator NoClassDefFoundError)