Vulcan Spring

Vulcan Spring 公司是家專業(yè)制造精密特種彈簧的美國企業(yè),成立于1967年，現坐落于紐約西南部的賓州泰爾夫德市，生產的彈簧被用于外太空探測領域，人造衛(wèi)星和火星上的漫游者號等.

Vulcan Spring公司生產的彈簧以精巧,精確和壽命長而聞名，美國通用汽車GM公司、GE公司、摩托羅拉、波音公司、3M、埃默森Emerson公司等世界著名公司都是Vulcan公司的客戶。Vulcan 為客戶定制不同的彈簧。同時，在英國,德國,法國,意大利,中國臺灣、中國香港等國家和地區(qū)也有Vulcan公司的產品，Vulcan的產品 （PullBox等）在沃爾瑪等大型超市應用廣泛.

Vulcan Spring工廠占地面積5600平方米,那里涵蓋了生產彈簧產品所有的生產工序.同時，公司內部還擁有一支設計經驗豐富、專業(yè)技術和制造能力過硬的彈簧設計專家隊伍,能快速提供客戶所需彈簧樣品,為客戶提供新產品設計并改善其現有產品的性能。客戶如有特殊要求，彈簧專家將協(xié)同客戶一起開發(fā)新產品.

Vulcan Spring 產品應用范圍廣，可用于家電產品、動力工具、電動馬達、玩具、工業(yè)設備、辦公設備、“彈出式”陳列架、機械工具、電動設備、電子、外科儀器、X射線和核磁共振設備等諸多領域.

主要產品包括：

Contorque(恒扭力彈簧) ，該產品采用獨到的設計，Contorque彈簧在勢能不變的情況下可旋轉數圈，適于電纜延伸并可替代電池電機或配重。

電機電刷彈簧，為電機換向器電刷受力穩(wěn)固提供了理想手段，可減小電刷磨損，從而提高電機的作業(yè)性能。

Conpower動力彈簧，這種彈簧在比力矩不高的情況下可旋轉很多圈。彈簧由心軸或盒提供旋轉能或借助滑輪或纜線來提供線性運動。Vulcan還制造非預應力動力彈簧。

機械卷筒，該產品能為需要平衡、回收或返回的應用提供動力。在需要長偏轉的應用中，機械卷筒供力穩(wěn)定且壽命期長。

其他定制彈簧，從沖壓片和封槽到線材成形、扭力彈簧、十字扣帶和定制的板簧設計。

來源：hengyunabc ，

hengyunabc.github.io/depth-analysis-hibernate-validar-noclassdefounderror/

問題

可重現的Demo代碼：demo.zip

http://hengyunabc.github.io/img/demo.zip

最近排查一個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]

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里的，不應該出現找不到類的情況。

那為什么應用里拋出這個NoClassDefFoundError ？

有經驗的開發(fā)人員從Could not initialize class 這個信息就可以知道，實際上是一個類在初始化時拋出的異常，比如static的靜態(tài)代碼塊，或者static字段初始化的異常。

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

但是當我們在HibernateValidator 這個類，創(chuàng)建ConfigurationImpl的代碼塊里打斷點時，發(fā)現有兩個線程觸發(fā)了斷點：

public class HibernateValidator implements ValidationProvider<HibernateValidatorConfiguration> {

@Override

public Configuration<?> createGenericConfiguration(BootstrapState state) {

return new ConfigurationImpl( state );

}

其中一個線程的調用棧是：

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

另外一個線程調用棧是：

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的初始化過程。

BackgroundPreinitializer 做了什么

那么重點來看下 BackgroundPreinitializer 線程做了哪些事情：

@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 線程會吞掉所有的異常。

顯然ConfigurationImpl 初始化的異常也被吞掉了，那么如何才能獲取到最原始的信息？

獲取到最原始的異常信息

在BackgroundPreinitializer的 run() 函數里打一個斷點（注意是Suspend thread類型, 不是Suspend VM），讓它先不要觸發(fā)ConfigurationImpl的加載，讓spring boot的正常流程去觸發(fā)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 這個函數。

那么檢查下應用的依賴，可以發(fā)現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 這個依賴過時了，需要排除掉。

總結異常的發(fā)生流程

應用依賴了jboss-common-1.2.1.GA.jar，它里面的org.jboss.logging.Logger太老 spring boot啟動時，BackgroundPreinitializer里的線程去嘗試加載ConfigurationImpl，然后觸發(fā)了org.jboss.logging.Logger的函數執(zhí)行問題 BackgroundPreinitializer 吃掉了異常信息，jvm把ConfigurationImpl標記為不可用的 spring boot正常的流程去加載ConfigurationImpl，jvm發(fā)現ConfigurationImpl類是不可用，直接拋出NoClassDefFoundError

Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.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來確定類的狀態(tài)

當拋出第一個異常時，嘗試用HSDB來看下這個類的狀態(tài)。

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查找到這個地址，發(fā)現_init_state是5。

再看下hotspot代碼，可以發(fā)現5對應的定義是initialization_error：

// /hotspot/src/share/vm/oops/instanceKlass.hpp

// See "The Java Virtual Machine Specification" section 2.16.2-5 for a detailed deion

// 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

};

JVM規(guī)范里關于Initialization的內容

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

從規(guī)范里可以看到初始一個類/接口有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 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);

}

第二次嘗試加載Version類時

當第二次嘗試加載時，檢查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);

}

}

總結