最近有版本特性要上線仗扬，但是在上線的過(guò)程中遇到了“阻礙”症概，使得上線過(guò)程不是很順利，想必你也曾經(jīng)遇到過(guò)吧厉颤！
1穴豫、問(wèn)題背景
說(shuō)說(shuō)大概的場(chǎng)景吧凡简。由于系統(tǒng)里面增加了權(quán)限的限制逼友，不同用戶擁有不同的數(shù)據(jù)權(quán)限。當(dāng)前的方案是查詢用戶uid和對(duì)應(yīng)的數(shù)據(jù)列表存放在本地內(nèi)存里秤涩，并且需要定時(shí)撈取對(duì)應(yīng)的關(guān)系數(shù)據(jù)存儲(chǔ)在本地緩存LocalCacheMap中帜乞，key為uid，value為L(zhǎng)ist筐眷。
接著其它接口則根據(jù)LocalCacheMap獲取對(duì)應(yīng)的數(shù)據(jù)權(quán)限進(jìn)行相關(guān)的判斷黎烈。
我們準(zhǔn)備上線時(shí)，發(fā)現(xiàn)功能不正常，本來(lái)應(yīng)該是能正常過(guò)濾權(quán)限數(shù)據(jù)的時(shí)候卻沒(méi)有生效照棋？
但是其它同學(xué)在測(cè)試環(huán)境驗(yàn)證基本沒(méi)問(wèn)題的资溃！所以就有很大的疑問(wèn)了。
我都不相信這功能真的在測(cè)試環(huán)境上OK烈炭？對(duì)測(cè)試結(jié)果表示懷疑溶锭，所以我跟組內(nèi)同學(xué)在測(cè)試環(huán)境驗(yàn)證一波，確實(shí)是沒(méi)問(wèn)題的符隙。那么繼續(xù)查看檢驗(yàn)代碼邏輯趴捅，查看是否有哪里不嚴(yán)謹(jǐn)，可能存在隱藏的bug霹疫。
在看代碼的過(guò)程中也發(fā)現(xiàn)了日志打的太少了拱绑，重點(diǎn)的地方都不打下，起碼還能知道從哪里跟蹤丽蝎，（對(duì)于代碼注釋等規(guī)范猎拨，可見(jiàn)原創(chuàng)《互聯(lián)網(wǎng)Code Review最佳實(shí)踐分享》），所以對(duì)于這點(diǎn)暫且不說(shuō)屠阻，我也不想說(shuō)重新補(bǔ)打日志迟几，然后重新打包，發(fā)版排查栏笆。
為了一探究竟类腮，此時(shí)必然還是需要使用強(qiáng)大的工具Arthas，之前就已經(jīng)解決過(guò)我的生產(chǎn)問(wèn)題蛉加。
可見(jiàn)于原創(chuàng)：《實(shí)戰(zhàn)使用Arthas排查生產(chǎn)問(wèn)題：實(shí)例方法接口調(diào)用》蚜枢，所以繼續(xù)使用阿爾薩斯Arthas來(lái)排查定位。
2针饥、排查解決問(wèn)題
1)排查一：
此時(shí)借助Arthas厂抽，嘗試調(diào)用獲取緩存數(shù)據(jù)：
調(diào)用實(shí)例方法，獲取到的結(jié)果為null丁眼，說(shuō)明緩存中沒(méi)有我要的數(shù)據(jù)筷凤，這就很奇怪了。然后我去驗(yàn)證拉去權(quán)限數(shù)據(jù)的接口苞七，手動(dòng)去調(diào)http接口藐守，此時(shí)在服務(wù)器上使用curl手動(dòng)調(diào)用接口，但是接口返回的443蹂风，所以我懷疑是不是調(diào)用的接口問(wèn)題造成緩存數(shù)據(jù)為空卢厂？此時(shí)找了運(yùn)維同學(xué)幫忙確認(rèn)下是不是網(wǎng)絡(luò)的問(wèn)題，最后排查結(jié)果確實(shí)是網(wǎng)絡(luò)沒(méi)有放行惠啄，于是等待網(wǎng)絡(luò)問(wèn)題解決之后繼續(xù)上線流程慎恒。
但是任内，網(wǎng)絡(luò)問(wèn)題雖然解決了，再次驗(yàn)證功能還是跟剛才一樣融柬，why死嗦？繼續(xù)排查...
2）排查二：
此時(shí)，再次借助Arthas粒氧，調(diào)用了refresh方法越走，來(lái)手動(dòng)觸發(fā)緩存刷新操作。
執(zhí)行刷新操作靠欢，返回null廊敌，這是正常的，因?yàn)閞efresh返回void门怪，此次刷新耗時(shí)在1132ms骡澈。
接著，再調(diào)前面獲取緩存數(shù)據(jù)的接口：
數(shù)據(jù)出來(lái)了Ｖ揽铡＠吲埂！說(shuō)明權(quán)限數(shù)據(jù)接口是正常的坦弟，拉取數(shù)據(jù)是正常护锤，接著我們就在功能上進(jìn)行驗(yàn)證，確實(shí)都正常了酿傍。
那么問(wèn)題就出在刷新方法的調(diào)用上烙懦，是否沒(méi)觸發(fā)或者調(diào)用者已經(jīng)沒(méi)調(diào)用等等情況。查看了代碼之后才發(fā)現(xiàn)發(fā)現(xiàn)是使用TimerTask來(lái)定時(shí)執(zhí)行任務(wù)赤炒，定時(shí)更新緩存數(shù)據(jù)氯析。
Timer?timer?=newTimer(false);
timer.schedule(newRefreshTask(),10*1000L,30*1000L);
privateclassRefreshTaskextendsTimerTask{
@Override
publicvoidrun(){
reflesh();
}
}
reflesh()?{
//?拉去權(quán)限數(shù)據(jù)
//?更新緩存數(shù)據(jù)
}
就是這樣來(lái)維護(hù)緩存數(shù)據(jù)。那么為什么它沒(méi)執(zhí)行莺褒？按道理啟動(dòng)之后都會(huì)每30秒執(zhí)行一次才對(duì)掩缓，但是為什么沒(méi)有呢？
3）罪魁禍?zhǔn)?/b>：
想必很多人知道TimerTask會(huì)存在一個(gè)問(wèn)題遵岩，就是定時(shí)調(diào)度執(zhí)行的方法如果沒(méi)有捕獲處理異常的話你辣，那么它就會(huì)終止，基本上不會(huì)再運(yùn)行了尘执。所以應(yīng)該是這個(gè)問(wèn)題造成的舍哄。
那么，應(yīng)該要找到它拋異常的地方才能驗(yàn)證我們這個(gè)問(wèn)題正卧。所以從日志里面找蠢熄，最終發(fā)現(xiàn)：
確實(shí)是在啟動(dòng)不久（10秒左右）的地方跪解，拋了NPE異常炉旷，所以這也驗(yàn)證了我們的問(wèn)題签孔，罪魁禍?zhǔn)拙褪撬恕?/p>
4）解決：
ScheduledExecutorService?executorService?=?
newScheduledThreadPoolExecutor(1,
newBasicThreadFactory.Builder().namingPattern(
"schedule-task-%d").build());;
executorService.scheduleWithFixedDelay(
newRefreshTask()?,10*1000L,30*1000L,?TimeUnit.MILLISECONDS);
使用ScheduledThreadPoolExecutor來(lái)定時(shí)調(diào)度刷新緩存。比TimerTask的好處就是出現(xiàn)異常也會(huì)繼續(xù)重新定時(shí)調(diào)度窘行。
3饥追、總結(jié)
這種問(wèn)題，雖說(shuō)不是特別難的問(wèn)題罐盔，但經(jīng)驗(yàn)不是很豐富的開(kāi)發(fā)人員卻在日常中常會(huì)犯的但绕，也會(huì)影響正常特性上線，造成發(fā)版阻礙惶看，影響功能上線捏顺。
針對(duì)此次“事件”，總結(jié)一下纬黎，以免下次再犯：
1）日志幅骄，日志，要打印本今，要打印好拆座。
2）盡量別用TimerTask，別踩坑冠息，如要用一定要捕獲處理好異常挪凑，一般建議使用ScheduledExecutorService代替。（阿里規(guī)約）
3）要學(xué)會(huì)使用Arthas逛艰，在緊急“救火”中非常有用躏碳！
此“事故”真實(shí)發(fā)生，若有雷同散怖，實(shí)屬巧合唐断。:)
推薦閱讀
互聯(lián)網(wǎng)Code Review最佳實(shí)踐分享
dubbo面試題！會(huì)這些杭抠，說(shuō)明你看懂了dubbo源碼
Kafka面試題脸甘！掌握它才說(shuō)明你真正懂Kafka
中臺(tái)之上——業(yè)務(wù)架構(gòu)系列【匯總】
加入：互聯(lián)網(wǎng)基礎(chǔ)/架構(gòu)交流 &群
-關(guān)注搬運(yùn)工來(lái)架構(gòu)丹诀，與優(yōu)秀的你一同進(jìn)步-
