深入JVM分析spring-boot應用hibernate-validator

阿新 • • 發佈：2017-07-30

using virtual orf replace vid share create sun abs

問題

可重現的Demo代碼：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 ？

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

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

但是當我們在HibernateValidator 這個類，創建ConfigurationImpl的代碼塊裏打斷點時，發現有兩個線程觸發了斷點：

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），讓它先不要觸發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
““

深入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來看下這個類的狀態。

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
};

JVM規範裏關於Initialization的內容

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

從規範裏可以看到初始一個類/接口有12步，比較重要的兩步都用黑體標記出來了：

1. If the Class object for C is in an erroneous state, then initialization is not possible. Release LC and throw a NoClassDefFoundError.
1. 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);
      }
    }

總結

spring boot在BackgroundPreinitializer類裏用一個獨立的線程來加載validator，並吃掉了原始異常
第一次加載失敗的類，在jvm裏會被標記為initialization_error，再次加載時會直接拋出NoClassDefFoundError: Could not initialize class
當在代碼裏吞掉異常時要謹慎，否則排查問題帶來很大的困難
http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-5.html#jvms-5.5

http://blog.csdn.net/hengyunabc/article/details/71513509

深入JVM分析spring-boot應用hibernate-validator

using virtual orf replace vid share create sun abs 問題可重現的Demo代碼：demo.zip 最近排查一個spring boot應用拋出hibernate.validator NoClassDefFoundE

深入JVM分析spring-boot應用hibernate-validator

問題

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

BackgroundPreinitializer 做了什麽

獲取到最原始的異常信息

總結異常的發生流程

深入JVM

使用HSDB來確定類的狀態

JVM規範裏關於Initialization的內容

第一次嘗試加載Version類時

第二次嘗試加載Version類時

總結

深入JVM分析spring-boot應用hibernate-validator

spring boot 使用 hibernate validator驗證框架

Spring Boot 使用hibernate validator進行引數校驗

讓你的spring-boot應用日誌隨心所欲--spring boot日誌深入分析

spring boot應用啟動原理分析

深入Spring Boot--使用Arthas排查Spring Boot應用404/401問題

Spring Boot應用的啟動和停止（Spring Boot應用通過start命令啟動）

Docker 容器整合 Spring Boot 應用

Spring Boot + JPA(hibernate 5) 開發時，數據庫表名大小寫問題

構建Spring Boot應用鏡像

將Spring Boot應用程序遷移到Java9：兼容性

spring MVC 使用 hibernate validator驗證框架,國際化配置

Spring Boot 應用AOP

spring boot 自定義Validator註解

開發者測試-采用精準測試工具對Spring Boot應用進行測試

Spring Boot應用監控的實戰教程

用 Docker、Gradle 來構建、運行、發布一個 Spring Boot 應用

Spring Boot應用總結更新

Spring Boot + Jpa(Hibernate) 架構基本配置

SpringBoot學習_使用嚮導快速建立Spring Boot應用

深入JVM分析spring-boot應用hibernate-validator

問題

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

BackgroundPreinitializer 做了什麽

獲取到最原始的異常信息

總結異常的發生流程

深入JVM

使用HSDB來確定類的狀態

JVM規範裏關於Initialization的內容

第一次嘗試加載Version類時

第二次嘗試加載Version類時

總結

相關推薦