背景
在測驗環境上遇到一個詭異的問題，部分業務邏輯會記錄用戶ID到資料庫，但記錄的資料會串，比如當前用戶的操作記錄會被其他用戶覆寫， 而且這個現象是每次重啟后一小段時間內就正常
問題
在執行緒池內部使用了InheritableThreadLocal獲取用戶資訊由于沒有及時remove，執行緒復用后，拿到的是舊的用戶資料
排查程序
1.通過臨時列印日志,確認整個鏈路中用戶ID是否一致
2.確認寫日志方法是否有被修改，最后確認是寫日志這塊開了執行緒池后導致問題
思考
1.為什么在之前測驗程序沒有復現
之前依賴的日志記錄二方jar包進行過一次升級，原先的版本在記錄日志沒有執行緒池去異步記錄，后面升級版本后，引入了執行緒池，而執行緒池是一直復用core 數量的執行緒的，處理完任務之后并不會回收，而InheritableThreadLocal是和執行緒綁在一起的，所以下一個任務復用執行緒池的時候用 threadLocal.get() 方法拿到的是還是老的變數
2.分析為什么用了InheritableThreadLocal還會導致這個資料錯亂（覆寫）
ThreadLocal 在 ThreadLocalMap 中是以一個弱參考身份被Entry中的Key參考的，因此如果ThreadLocal沒有外部強參考來參考它，那么ThreadLocal會在下次JVM垃圾收集時被回收，這個時候就會出現Entry中Key已經被回收，出現一個null Key的情況，外部讀取ThreadLocalMap中的元素是無法通過null Key來找到Value的，因此如果當前執行緒的生命周期很長（在本篇案例中,由于執行緒池的核心執行緒沒有被回收，一直存在），那么其內部的ThreadLocalMap物件也一直生存下來，這些null key就存在一條強參考鏈的關系一直存在：Thread --> ThreadLocalMap-->Entry-->Value，這條強參考鏈會導致Entry不會回收，Value也不會回收
3.本地求證
為此我寫了一個demo在本地去復現這個問題，為了能模擬測驗環境，我設定了2個核心執行緒，并且呼叫4次
根據上面的運行日志結果，可以發現第二次的設值并沒有真正改變，所以本地模擬問題成功，接下來就是分析為什么會出現這個原因，以及如何解決方案
分析執行緒池的核心執行緒是如何不被回收的，原始碼分析如下（主要分析重點在于核心執行緒創建后是如何保證不被回收）
1.跟進execute主入口分析
public void execute(Runnable command) {
if (command == null)
throw new NullPointerException();
int c = ctl.get();
if (workerCountOf(c) < corePoolSize) {
if (addWorker(command, true)) //未超過核心執行緒數，則新增 Worker 物件，true表示核心執行緒
return;
c = ctl.get();
}
if (isRunning(c) && workQueue.offer(command)) {
int recheck = ctl.get();
if (! isRunning(recheck) && remove(command))
reject(command);
else if (workerCountOf(recheck) == 0)
addWorker(null, false);
}
else if (!addWorker(command, false))
reject(command);
}
由上可知核心執行緒通過addWorker方法創建
2.跟進addWorker方法
private boolean addWorker(Runnable firstTask, boolean core) {
retry:
for (;;) {
int c = ctl.get();
int rs = runStateOf(c);
// Check if queue empty only if necessary.
if (rs >= SHUTDOWN &&
! (rs == SHUTDOWN &&
firstTask == null &&
! workQueue.isEmpty()))
return false;
for (;;) {
int wc = workerCountOf(c);
if (wc >= CAPACITY ||
wc >= (core ? corePoolSize : maximumPoolSize))
return false;
if (compareAndIncrementWorkerCount(c))
break retry;
c = ctl.get(); // Re-read ctl
if (runStateOf(c) != rs)
continue retry;
// else CAS failed due to workerCount change; retry inner loop
}
}
boolean workerStarted = false;
boolean workerAdded = false;
Worker w = null;
try {
w = new Worker(firstTask);
final Thread t = w.thread;
if (t != null) {
final ReentrantLock mainLock = this.mainLock;
mainLock.lock();
try {
// Recheck while holding lock.
// Back out on ThreadFactory failure or if
// shut down before lock acquired.
int rs = runStateOf(ctl.get());
if (rs < SHUTDOWN ||
(rs == SHUTDOWN && firstTask == null)) {
if (t.isAlive()) // precheck that t is startable
throw new IllegalThreadStateException();
workers.add(w);
int s = workers.size();
if (s > largestPoolSize)
largestPoolSize = s;
workerAdded = true;
}
} finally {
mainLock.unlock();
}
if (workerAdded) {
t.start(); //執行核心執行緒
workerStarted = true;
}
}
} finally {
if (! workerStarted)
addWorkerFailed(w);
}
return workerStarted;
}
由上可知核心執行緒通過 t.start()執行，接下來繼續查看原始碼看一下創建好后或者執行后是如何保證不被回收
3.跟進Work類里面的run方法
由上可知通過While去不斷輪詢getTask方法來保證核心執行緒被創建后不被回收，至此也搞明白了為什么InheritableThreadLocal設定的value不會被remove
總結
1.每次用完后ThreadLocal后及時remove
2.盡量不要在執行緒池里使用 ThreadLocal,很多時候開發關注的點比較多，疏忽的程序也在所難免，例如本次解決方案是我先把用戶ID在執行緒池呼叫前查詢出來,在傳進去
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/473402.html
標籤：Java