[[181411]]

問題描述

當我們一個系統既需要mysql驅動，也需要oracle驅動的時候，在并發加載初始化這些驅動類的過程中產生死鎖的可能性非常大，下面是一個模擬的例子，對于Thread2的實現其實是jdk里java.sql.DriverService的邏輯，也是我們第一次調用java.sql.DriverManager.registerDriver注冊一個驅動實例要走的邏輯(jdk1.6下)，不過這篇文章是使用我們生產環境的一個系統的線程dump和內存dump為基礎進行分析展開的。

如果以上代碼運行過程中發現有線程一直卡死在Class.forName的調用里，那么說明問題已經重現了。

先上兩張圖

內存態線程堆棧

線程堆棧

存疑點

仔細看看上面的線程dump分析和內存dump分析里的線程分析模塊，您可能會有如下兩個疑惑：

• 【為什么線程[Thread-0]一直卡在Class.forName的位置】：這有點出乎意料，做一個類加載要么找不到拋出ClassNotFoundException，要么找到直接返回，為什么會一直卡在這個位置呢?
• 【明明[Thread-0]注冊的是mysql驅動為什么會去加載Odbc的驅動類】：通過[Thread-0]在棧上看倒數第二幀展開看到傳入Class.forName的參數是com.mysql.jdbc.Driver，然后展開棧上順序第二幀，看到傳入的參數是sun.jdbc.odbc.JdbcOdbcDriver，這意味著在對mysql驅動類做加載初始化的過程中又觸發了JdbcOdbc驅動類的加載

疑惑點解釋

疑惑二：

第一個疑惑我們先留著，先解釋下第二個疑惑，大家可以對照堆棧通過反編譯rt.jar還有ojdbc6-11.2.0.3.0.jar看具體的代碼

驅動類加載過程簡要介紹:

當要注冊某個sql驅動的時候是通過調用java.sql.DriverManager.registerDriver來實現的(注意這個方法加了synchronized關鍵字，后面解釋第一個疑惑的時候是關鍵)，而這個方法在第一次執行過程中，會在當前線程classloader的classpath下尋找所有/META-INF/services/java.sql.Driver文件，這個文件在mysql和oracle驅動jar里都有，里面寫的是對應的驅動實現類名，這種機制是jdk提供的spi實現，找到這些文件之后，依次使用Class.forName(driverClassName, true, this.loader)來對這些驅動類進行加載，其中第二個參數是true，意味著不僅僅做一次loadClass的動作，還會初始化該類，即調用包含靜態塊的< clinit >方法，執行完之后才會返回，這樣就解釋了第二個疑惑，在mysql驅動注冊過程中還會對odbc驅動類進行加載并初始化

感想:

其實我覺得這種設計有點傻，為什么要干和自己不相關的事情呢，畫蛇添足的設計，首先類初始化的開銷是否放到一起做并沒有多大區別，其次正由于這種設計導致了今天這個死鎖的發生

疑惑一：

現在來說第一個疑惑，為什么會一直卡在Class.forName呢，到底卡在哪里，于是再通過jstack -m 命令將jvm里的堆棧也打印出來，如下所示

我們看到其實正在做類的初始化動作，并且線程正在調用ObjectSynchronizer::waitUninterruptibly一直沒返回，在看這方法的調用者instanceKlass1::initialize_impl，我們找到源碼位置如下：

類的初始化過程:

當某個線程獲得機會對某個類進行初始化的時候(請看上面的Step 6)，會設置這個類的init_state屬性為being_initialized(如果初始化好了會設置為fully_initialized，異常的話會設置為initialization_error)，還會設置init_thread屬性為當前線程，在這個設置過程中是有針對這個類提供了一把互斥鎖的，因此當有別的線程進來的時候會被攔截在外面，如果設置完了，這把互斥鎖也釋放了，但是因為這個類的狀態被設置了，因此并發問題也得到了解決，當另外一個線程也嘗試初始化這個類的時候會判斷這個類的狀態是不是being_initialized，并且其init_thread不是當前線程，那么就會一直卡在那里，也就是此次線程dump的線程所處的狀態，正在初始化類的線程會調用< clinit >方法，如果正常結束了，那么就設置其狀態為fully_initialized，并且通知之前卡在那里等待初始化完成的線程，然他們繼續往下走(下一個動作就是再判斷下狀態，發現完成了就直接return了)

猜想:

在了解了上面的過程之后，于是我們猜測兩種可能

• 第一，這個類的狀態還是being_intialized，還在while循環里沒有跳出來
• 第二，事件通知機制出現了問題，也就是pthread_cond_wait和pthread_cond_signal之間的通信過程出現了問題。

不過第二種可能性非常小，比較linux久經考驗了，那接下來我們驗證其實是第一個猜想

驗證：

我們通過GDB attach的方式連到了問題機器上(好在機器沒有掛)，首先我們要找到具體的問題線程，我們通過上面的jstack -m命令看到了線程ID是5738，然后通過info threads找到對應的線程，并得到它的序號14

然后通過thread 14切換到對應的線程，并通過bt看到了如下的堆棧，正如我們想象的那樣，正在做類的初始化，一直卡在那里

我們通過f 6選擇第7幀，在通過disassemble反匯編該幀，也就是對instanceKlass::initialize_impl ()這個方法反匯編

從上面的注釋我們其實得出了，我們要看當前類的初始化狀態，那就是看eax寄存器偏移0xe0的位置的值，而eax其實就是ebp寄存器偏移0xfffffff4位置的值，于是我們通過如下地址內存查到得到是4

而4其實代表的就是being_initialized這個狀態，代碼如下

從這于是我們驗證了第一個猜想，其實是狀態一直沒有變更，因此一直卡在那里，為了更進一步確認這個問題，要是我們能找到該類的init_thread線程id就更清楚了，拿到這個ID我們就能看到這個線程棧，就知道它在干什么了，但是很遺憾，這個很難獲取到，至少我一直沒有找到辦法，因為線程ID在線程對象里一直沒有存，都是調用的os函數來獲取的，得換個思路。

突然發現instanceKlass.hpp代碼中得知兩個屬性原來是相鄰的(init_state和init_thread)，于是斷定下一個地址的值就代表是這個線程對象了，但是其屬性何其多，找到想要的太不易了，最主要的是還擔心自己看的代碼和服務器上的jvm代碼不一致，這樣更蛋疼了，于是繼續查看Thread.hpp中的JavaThread類，找到個關鍵字0xDEAD-2=0xDEAB,這個有可能是volatile TerminatedTypes _terminated屬性的值，于是把線程對象打印出來，果然查到了關鍵字0xDEAB

因此順著這個屬性繼續往上找，找到了_thread_state表示線程狀態的值(向上偏移三個字)，0x0000000a，即10，然后查看代碼知道原來線程是出于block狀態

JavaThreadState

這樣一來查看下線程dump，發現Thread-1正好處于BLOCKED狀態，也就是說Thread-1就是那個正在對mysql驅動類做初始化的線程，這說明Thread-0和Thread-1成功互鎖了

于是我們展開Thread-1，看到- waiting to lock <0x71ae2ec0> (a java.lang.Class for java.sql.DriverManager)，該線程正在等待java.sql.DriverManager類型鎖，而blocked在那里，而這個類型鎖是被Thread-0線程持有的，從Thread-1這個線程堆棧來看它其實也是在做Class.forName動作，并且通過Thread-1,展開第四幀我們可以看到其正在對加載

sun.jdbc.odbc.JdbcOdbcDriver 

問題現場遐想:

于是我們大膽設想一個場景，Thread-1先獲取到初始化sun.jdbc.odbc.JdbcOdbcDriver的機會，然后在執行sun.jdbc.odbc.JdbcOdbcDriver這個類的靜態塊的時候調用DriverManager.registerDriver(new Driver());，而該方法之前已經提到了是會加同步鎖的，再想象一下，在這個這個靜態塊之前，并且設置了sun.jdbc.odbc.JdbcOdbcDriver類的初始化狀態為being_initialized之后，Thread-0這個線程執行到了卡在的那個位置，并且我們從其堆?？梢钥闯鏊呀洺钟辛薺ava.sql.DriverManager這個類型的鎖，因此這兩個線程陷入了互鎖狀態

【本文是51CTO專欄作者李嘉鵬的原創文章，轉載請通過微信公眾號(你假笨，id:lovestblog)聯系作者本人獲取授權】

戳這里，看該作者更多好文