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] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_112] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_112] at sun.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] ... 32 common frames omitted
這個錯誤信息表面上是 NoClassDefFoundError
,可是實際上 ConfigurationImpl
這個類是在 hibernate-validator-5.3.5.Final.jar
裏的,不該該出現找不到類的狀況。html
那爲何應用裏拋出這個 NoClassDefFoundError
?java
有經驗的開發人員從 Could not initialize class
這個信息就能夠知道,其實是一個類在初始化時拋出的異常,好比static的靜態代碼塊,或者static字段初始化的異常。spring
可是當咱們在 HibernateValidator
這個類,建立 ConfigurationImpl
的代碼塊裏打斷點時,發現有兩個線程觸發了斷點:api
public class HibernateValidator implements ValidationProvider<HibernateValidatorConfiguration> { @Override public Configuration<?> createGenericConfiguration(BootstrapState state) { return new ConfigurationImpl( state ); }
其中一個線程的調用棧是:oracle
Thread [background-preinit] (Class load: ConfigurationImpl) HibernateValidator.createGenericConfiguration(BootstrapState) line: 33 Validation$GenericBootstrapImpl.configure() line: 276 BackgroundPreinitializer$ValidationInitializer.run() line: 107 BackgroundPreinitializer$1.runSafely(Runnable) line: 59 BackgroundPreinitializer$1.run() line: 52 Thread.run() line: 745
另一個線程調用棧是:app
Thread [main] (Suspended (breakpoint at line 33 in HibernateValidator)) owns: ConcurrentHashMap<K,V> (id=52) owns: Object (id=53) HibernateValidator.createGenericConfiguration(BootstrapState) line: 33 Validation$GenericBootstrapImpl.configure() line: 276 MessageInterpolatorFactory.getObject() line: 53 DefaultValidatorConfiguration.defaultValidator() line: 43 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 498 CglibSubclassingInstantiationStrategy(SimpleInstantiationStrategy).instantiate(RootBeanDefinition, String, BeanFactory, Object, Method, Object...) line: 162 ConstructorResolver.instantiateUsingFactoryMethod(String, RootBeanDefinition, Object[]) line: 588 DefaultListableBeanFactory(AbstractAutowireCapableBeanFactory).instantiateUsingFactoryMethod(String, RootBeanDefinition, Object[]) line: 1173
顯然,這個線程的調用棧是常見的spring的初始化過程。jvm
那麼重點來看下 BackgroundPreinitializer
線程作了哪些事情:ide
@Order(LoggingApplicationListener.DEFAULT_ORDER + 1) public class BackgroundPreinitializer implements ApplicationListener<ApplicationEnvironmentPreparedEvent> { @Override public void onApplicationEvent(ApplicationEnvironmentPreparedEvent event) { try { Thread thread = new Thread(new Runnable() { @Override public void run() { runSafely(new MessageConverterInitializer()); runSafely(new MBeanFactoryInitializer()); runSafely(new ValidationInitializer()); runSafely(new JacksonInitializer()); runSafely(new ConversionServiceInitializer()); } public void runSafely(Runnable runnable) { try { runnable.run(); } catch (Throwable ex) { // Ignore } } }, "background-preinit"); thread.start(); }
能夠看到 BackgroundPreinitializer
類是spring boot爲了加速應用的初始化,以一個獨立的線程來加載hibernate validator這些組件。函數
這個 background-preinit
線程會吞掉全部的異常。spring-boot
顯然 ConfigurationImpl
初始化的異常也被吞掉了,那麼如何才能獲取到最原始的信息?
在 BackgroundPreinitializer
的 run()
函數裏打一個斷點(注意是 Suspend thread
類型, 不是 Suspend VM
),讓它先不要觸發 ConfigurationImpl
的加載,讓spring boot的正常流程去觸發 ConfigurationImpl
的加載,就能夠知道具體的信息了。
那麼打出來的異常信息是:
Caused by: 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.<clinit>(Version.java:22) ~[hibernate-validator-5.3.5.Final.jar:5.3.5.Final] at org.hibernate.validator.internal.engine.ConfigurationImpl.<clinit>(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
Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.hibernate.validator.internal.engine.ConfigurationImpl
爲何第二次嘗試加載 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來看下這個類的狀態。
sudo java -classpath "$JAVA_HOME/lib/sa-jdi.jar" sun.jvm.hotspot.HSDB
而後在HSDB console裏查找到 Version
的地址信息
hsdb> class org.hibernate.validator.internal.util.Version org/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. enum ClassState { 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 initializer fully_initialized, // initialized (successfull final state) initialization_error // error happened during 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.
當第一次嘗試加載時,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 11 Handle e(THREAD, PENDING_EXCEPTION); CLEAR_PENDING_EXCEPTION; // JVMTI has already reported the pending exception // JVMTI internal flag reset is needed in order to report ExceptionInInitializerError JvmtiExport::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 ExceptionInInitializerError JvmtiExport::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 { JavaCallArguments args(e); THROW_ARG(vmSymbols::java_lang_ExceptionInInitializerError(), vmSymbols::throwable_void_signature(), &args); }
當第二次嘗試加載時,檢查 InstanceKlass
的 _init_state
是 initialization_error
,則直接拋出 NoClassDefFoundError: Could not initialize class
.
對應 Initialization
的5步。
// hotspot/src/share/vm/oops/instanceKlass.cpp void InstanceKlass::initialize_impl(instanceKlassHandle this_oop, TRAPS) { // ... // Step 5 if (this_oop->is_in_error_state()) { DTRACE_CLASSINIT_PROBE_WAIT(erroneous, InstanceKlass::cast(this_oop()), -1,wait); ResourceMark rm(THREAD); const char* desc = "Could not initialize class "; const char* className = this_oop->external_name(); size_t msglen = strlen(desc) + strlen(className) + 1; char* message = NEW_RESOURCE_ARRAY(char, msglen); if (NULL == message) { // Out of memory: can't create detailed error message THROW_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
當在代碼裏吞掉異常時要謹慎,不然排查問題帶來很大的困難