深入 Spring Boot：排查 @Transactional 引起的 NullPointerException

（點選上方公眾號，可快速關註）

來源：hengyunabc，

blog.csdn.net/hengyunabc/article/details/78806296

寫在前面

這個demo來說明怎麼排查一個@Transactional引起的NullPointerException。

https://github.com/hengyunabc/spring-boot-inside/tree/master/demo-Transactional-NullPointerException

定位 NullPointerException 的程式碼

Demo是一個簡單的spring事務例子，提供了下麵一個StudentDao，並用@Transactional來宣告事務：

@Component

@Transactional

public class StudentDao {

 

    @Autowired

    private SqlSession sqlSession;

 

    public Student selectStudentById(long id) {

        return sqlSession.selectOne(“selectStudentById”, id);

    }

 

    public final Student finalSelectStudentById(long id) {

        return sqlSession.selectOne(“selectStudentById”, id);

    }

}

應用啟動後，會依次呼叫selectStudentById和finalSelectStudentById：

@PostConstruct

public void init() {

    studentDao.selectStudentById(1);

    studentDao.finalSelectStudentById(1);

}

用mvn spring-boot:run 或者把工程匯入IDE裡啟動，丟擲來的異常資訊是：

Caused by: java.lang.NullPointerException

    at sample.mybatis.dao.StudentDao.finalSelectStudentById(StudentDao.java:27)

    at com.example.demo.transactional.nullpointerexception.DemoNullPointerExceptionApplication.init(DemoNullPointerExceptionApplication.java:30)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

    at java.lang.reflect.Method.invoke(Method.java:498)

    at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleElement.invoke(InitDestroyAnnotationBeanPostProcessor.java:366)

    at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleMetadata.invokeInitMethods(InitDestroyAnnotationBeanPostProcessor.java:311)

為什麼應用程式碼裡執行selectStudentById沒有問題，而執行finalSelectStudentById就丟擲NullPointerException?

同一個bean裡，明明SqlSession sqlSession已經被註入了，在selectStudentById裡它是非null的。為什麼finalSelectStudentById函式裡是null？

獲取實際執行時的類名

當然，我們對比兩個函式，可以知道是因為finalSelectStudentById的修飾符是final。但是具體原因是什麼呢？

我們先在丟擲異常的地方打上斷點，除錯程式碼，獲取到具體執行時的class是什麼：

System.err.println(studentDao.getClass());

列印的結果是：

class sample.mybatis.dao.StudentDao$$EnhancerBySpringCGLIB$$210b005d

可以看出是一個被spring aop處理過的類，但是它的具體位元組碼內容是什麼呢？

dumpclass分析

我們使用dumpclass工具來把jvm裡的類dump出來：

https://github.com/hengyunabc/dumpclass

wget http://search.maven.org/remotecontent?filepath=io/github/hengyunabc/dumpclass/0.0.1/dumpclass-0.0.1.jar -O dumpclass.jar

找到java行程pid：

$ jps

5907 DemoNullPointerExceptionApplication

把相關的類都dump下來：

sudo java -jar dumpclass.jar 5907 ‘sample.mybatis.dao.StudentDao*’ /tmp/dumpresult

反彙編分析

用javap或者圖形化工具jd-gui來反編繹sample.mybatis.dao.StudentDao$$EnhancerBySpringCGLIB$$210b005d。

反編繹後的結果是：

1. class StudentDao$$EnhancerBySpringCGLIB$$210b005d extends StudentDao

2. StudentDao$$EnhancerBySpringCGLIB$$210b005d裡沒有finalSelectStudentById相關的內容

3. selectStudentById實際呼叫的是this.CGLIB$CALLBACK_0，即MethodInterceptor tmp4_1，等下我們實際debug，看具體的型別

public final Student selectStudentById(long paramLong)

{

  try

  {

    MethodInterceptor tmp4_1 = this.CGLIB$CALLBACK_0;

    if (tmp4_1 == null)

    {

      tmp4_1;

      CGLIB$BIND_CALLBACKS(this);

    }

    MethodInterceptor tmp17_14 = this.CGLIB$CALLBACK_0;

    if (tmp17_14 != null)

    {

      Object[] tmp29_26 = new Object[1];

      Long tmp35_32 = new java/lang/Long;

      Long tmp36_35 = tmp35_32;

      tmp36_35;

      tmp36_35.(paramLong);

      tmp29_26[0] = tmp35_32;

      return (Student)tmp17_14.intercept(this, CGLIB$selectStudentById$0$Method, tmp29_26, CGLIB$selectStudentById$0$Proxy);

    }

    return super.selectStudentById(paramLong);

  }

  catch (RuntimeException|Error localRuntimeException)

  {

    throw localRuntimeException;

  }

  catch (Throwable localThrowable)

  {

    throw new UndeclaredThrowableException(localThrowable);

  }

}

再來實際debug，儘管StudentDao$$EnhancerBySpringCGLIB$$210b005d的程式碼不能直接看到，但是還是可以單步執行的。

在debug時，可以看到

1. StudentDao$$EnhancerBySpringCGLIB$$210b005d裡的所有field都是null

2. this.CGLIB$CALLBACK_0的實際型別是CglibAopProxy$DynamicAdvisedInterceptor，在這個Interceptor裡實際儲存了原始的target物件

3. CglibAopProxy$DynamicAdvisedInterceptor在經過TransactionInterceptor處理之後，最終會用反射呼叫自己儲存的原始target物件

丟擲異常的原因

所以整理下整個分析：

1. 在使用了@Transactional之後，spring aop會生成一個cglib代理類，實際使用者程式碼裡@Autowired註入的StudentDao也是這個代理類的實體

2. cglib生成的代理類StudentDao$$EnhancerBySpringCGLIB$$210b005d繼承自StudentDao

3. StudentDao$$EnhancerBySpringCGLIB$$210b005d裡的所有field都是null

4. StudentDao$$EnhancerBySpringCGLIB$$210b005d在呼叫selectStudentById，實際上透過CglibAopProxy$DynamicAdvisedInterceptor，最終會用反射呼叫自己儲存的原始target物件

5. 所以selectStudentById函式的呼叫沒有問題

那麼為什麼finalSelectStudentById函式裡的SqlSession sqlSession會是null，然後丟擲NullPointerException？

1. StudentDao$$EnhancerBySpringCGLIB$$210b005d裡的所有field都是null

2. finalSelectStudentById函式的修飾符是final，cglib沒有辦法重寫這個函式

3. 當執行到finalSelectStudentById裡，實際執行的是原始的StudentDao裡的程式碼

4. 但是物件是StudentDao$$EnhancerBySpringCGLIB$$210b005d的實體，它裡面的所有field都是null，所以會丟擲NullPointerException

解決問題辦法

1. 最簡單的當然是把finalSelectStudentById函式的final修飾符去掉

2. 還有一種辦法，在StudentDao裡不要直接使用sqlSession，而透過getSqlSession()函式，這樣cglib也會處理getSqlSession()，傳回原始的target物件

總結

1. 排查問題多debug，看實際執行時的物件資訊

2. 對於cglib生成類的位元組碼，可以用dumpclass工具來dump，再反編繹分析

看完本文有收穫？請轉發分享給更多人

關註「ImportNew」，提升Java技能