這個文章是在16年使用LitePal庫時遇到的一個問題，翻出來當做記錄，目前的LitePal貌似也改了這個實現。
當時的項目使用了LitePal庫作為數據庫存儲，當時User類存在數據庫中，初始化的時候會異步從數據庫讀取User信息，并且在主線程初始化一個默認的User類使用，但這過程出現死鎖的概率非常高，發現是庫的設計有問題，分析得到的過程結論如下：
日志：
"main" prio=5 tid=1 Blocked
| group="main" sCount=1 dsCount=0 obj=0x746f9a50 self=0xf4736a00
| sysTid=17043 nice=0 cgrp=bg_non_interactive sched=0/0 handle=0xf71b8de4
| state=S schedstat=( 1381247238 86682835 492 ) utm=127 stm=11 core=5 HZ=100
| stack=0xff657000-0xff659000 stackSize=8MB
| held mutexes=
at com.meizu.lifekit.entity.UserSingleton.(UserSingleton.java:22)
waiting to lock <0x0fd0e4f2> (a java.lang.Class<org.litepal.crud.DataSupport>) held by thread 16
at com.meizu.lifekit.entity.UserSingleton.(UserSingleton.java:21)
at com.meizu.lifekit.entity.UserSingleton$InstanceHolder.(UserSingleton.java:180)
at com.meizu.lifekit.entity.UserSingleton.getInstance(UserSingleton.java:30)
at com.meizu.lifekit.data.mainpage.NewHomeFragment.(NewHomeFragment.java:82)
at java.lang.Class.newInstance!(Native method)
TID16：
"LifeKitApplication" prio=5 tid=16 Blocked
| group="main" sCount=1 dsCount=0 obj=0x132db8e0 self=0xf395b900
| sysTid=17067 nice=0 cgrp=bg_non_interactive sched=0/0 handle=0xd9418930
| state=S schedstat=( 2762923 1967693 9 ) utm=0 stm=0 core=1 HZ=100
| stack=0xd9316000-0xd9318000 stackSize=1038KB
| held mutexes=
kernel: __switch_to+0x74/0x8c
kernel: futex_wait_queue_me+0xd8/0x168
kernel: futex_wait+0xe4/0x234
kernel: do_futex+0x184/0xa14
kernel: compat_SyS_futex+0x7c/0x168
kernel: el0_svc_naked+0x20/0x28
native: #00 pc 00017698 /system/lib/libc.so (syscall+28)
native: [#1](https://github.com/LitePalFramework/LitePal/issues/1) pc 000e8985 /system/lib/libart.so (_ZN3art17ConditionVariable4WaitEPNS_6ThreadE+80)
native: [#2](https://github.com/LitePalFramework/LitePal/issues/2) pc 0029fb2b /system/lib/libart.so (_ZN3art7Monitor4LockEPNS_6ThreadE+394)
native: [#3](https://github.com/LitePalFramework/LitePal/issues/3) pc 002a25cb /system/lib/libart.so (_ZN3art7Monitor12MonitorEnterEPNS_6ThreadEPNS_6mirror6ObjectE+270)
native: [#4](https://github.com/LitePalFramework/LitePal/issues/4) pc 002d775d /system/lib/libart.so (_ZN3art10ObjectLockINS_6mirror6ObjectEEC2EPNS_6ThreadENS_6HandleIS2_EE+24)
native: [#5](https://github.com/LitePalFramework/LitePal/issues/5) pc 0012bfdf /system/lib/libart.so (_ZN3art11ClassLinker15InitializeClassEPNS_6ThreadENS_6HandleINS_6mirror5ClassEEEbb.part.593+94)
native: [#6](https://github.com/LitePalFramework/LitePal/issues/6) pc 0012ce93 /system/lib/libart.so (_ZN3art11ClassLinker17EnsureInitializedEPNS_6ThreadENS_6HandleINS_6mirror5ClassEEEbb+82)
native: [#7](https://github.com/LitePalFramework/LitePal/issues/7) pc 002aea0d /system/lib/libart.so (_ZN3artL18Class_classForNameEP7_JNIEnvP7_jclassP8_jstringhP8_jobject+452)
native: [#8](https://github.com/LitePalFramework/LitePal/issues/8) pc 0025eb19 /data/dalvik-cache/arm/system@[framework@boot.oat](mailto:framework@boot.oat) (Java_java_lang_Class_classForName__Ljava_lang_String_2ZLjava_lang_ClassLoader_2+132)
at java.lang.Class.classForName!(Native method)
waiting to lock <0x081409ec> (a java.lang.Class<com.meizu.lifekit.entity.User>) held by thread 1
at java.lang.Class.forName(Class.java:324)
at java.lang.Class.forName(Class.java:285)
at org.litepal.LitePalBase.getSupportedFields(LitePalBase.java:170)
at org.litepal.crud.DataHandler.query(DataHandler.java:124)
at org.litepal.crud.QueryHandler.onFindLast(QueryHandler.java:96)
at org.litepal.crud.DataSupport.findLast(DataSupport.java:576)
locked <0x0fd0e4f2> (a java.lang.Class<org.litepal.crud.DataSupport>)
at org.litepal.crud.DataSupport.findLast(DataSupport.java:561)
locked <0x0fd0e4f2> (a java.lang.Class<org.litepal.crud.DataSupport>)
at com.meizu.lifekit.LifeKitApplication$ApplicationHandler.handleMessage(LifeKitApplication.java:117)
at android.os.Handler.dispatchMessage(Handler.java:111)
at android.os.Looper.loop(Looper.java:207)
at android.os.HandlerThread.run(HandlerThread.java:61)
原因：表User類實例化時，同時查詢數據庫，互相持有鎖造成死鎖
User實例化時持有User.class鎖申請父類DataSupport.class鎖，查詢User表時持有DataSupport.class鎖申請User.class鎖，互相持有對方資源不釋放死鎖了。
實例化User類的時候發生的事情，先初始化User類的過程中持有User.class鎖，發現DataSupport是父類，此時User.class處于being_initialized狀態，嘗試初始化DataSupport類（想進入being_initialized狀態），但是DataSupport.class已經被子線程的查詢操作訪問先進行初始化（已經進入了being_initialized狀態，但查詢線程需要等待User的being_initialized狀態完成），所以主線程實例化User的時候持有User.class鎖，等待DataSupport.class鎖；而子線程的查詢User操作的時候，先初始化DataSupport類，持有DataSupport.class鎖，等待訪問User.class鎖，順序相反地持鎖，死鎖BOOM！如果這個是程序邏輯死鎖的話，那我們使用LitePal時就不能查詢的時候同時在另一個線程實例化該類了。算是庫的設計缺陷吧
類初始化過程持鎖的原因 參考鏈接：https://yq.aliyun.com/articles/73595
