這個(gè)文章是在16年使用LitePal庫(kù)時(shí)遇到的一個(gè)問(wèn)題奄毡，翻出來(lái)當(dāng)做記錄兵志，目前的LitePal貌似也改了這個(gè)實(shí)現(xiàn)椎镣。
當(dāng)時(shí)的項(xiàng)目使用了LitePal庫(kù)作為數(shù)據(jù)庫(kù)存儲(chǔ)艺晴，當(dāng)時(shí)User類存在數(shù)據(jù)庫(kù)中冗美，初始化的時(shí)候會(huì)異步從數(shù)據(jù)庫(kù)讀取User信息魔种，并且在主線程初始化一個(gè)默認(rèn)的User類使用，但這過(guò)程出現(xiàn)死鎖的概率非常高粉洼，發(fā)現(xiàn)是庫(kù)的設(shè)計(jì)有問(wèn)題节预，分析得到的過(guò)程結(jié)論如下：
日志：
"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類實(shí)例化時(shí)叶摄，同時(shí)查詢數(shù)據(jù)庫(kù)，互相持有鎖造成死鎖
User實(shí)例化時(shí)持有User.class鎖申請(qǐng)父類DataSupport.class鎖安拟，查詢User表時(shí)持有DataSupport.class鎖申請(qǐng)User.class鎖蛤吓，互相持有對(duì)方資源不釋放死鎖了。
實(shí)例化User類的時(shí)候發(fā)生的事情糠赦，先初始化User類的過(guò)程中持有User.class鎖会傲，發(fā)現(xiàn)DataSupport是父類，此時(shí)User.class處于being_initialized狀態(tài)拙泽，嘗試初始化DataSupport類（想進(jìn)入being_initialized狀態(tài)）淌山，但是DataSupport.class已經(jīng)被子線程的查詢操作訪問(wèn)先進(jìn)行初始化（已經(jīng)進(jìn)入了being_initialized狀態(tài)，但查詢線程需要等待User的being_initialized狀態(tài)完成）顾瞻，所以主線程實(shí)例化User的時(shí)候持有User.class鎖泼疑，等待DataSupport.class鎖；而子線程的查詢User操作的時(shí)候荷荤，先初始化DataSupport類王浴，持有DataSupport.class鎖，等待訪問(wèn)User.class鎖梅猿，順序相反地持鎖氓辣，死鎖BOOM！如果這個(gè)是程序邏輯死鎖的話袱蚓，那我們使用LitePal時(shí)就不能查詢的時(shí)候同時(shí)在另一個(gè)線程實(shí)例化該類了钞啸。算是庫(kù)的設(shè)計(jì)缺陷吧
類初始化過(guò)程持鎖的原因 參考鏈接：https://yq.aliyun.com/articles/73595
