堵塞線程(Stuck Thread)，相對比較容易理解，就是那些執行時間超過“粘滯線程最長時間”（默認是600秒）的線程。聯機文檔是這樣說的：
如果執行線程處理某個請求的粘滯時間超過了配置的粘滯線程最大時間，則爲“真”。
True if the execute thread is stuck working on a request for more than the configured stuck thread maximum time.
可以通過控制檯的設置來增大或減小這個值（雖然絕大部分情況下修改這個值沒有什麼意義）：
控制檯 >> 環境 >> 服務器 >> MedRecSvr1 >> 配置 >> 優化 >> 粘滯線程最長時間
WebLogic把某些線程標記爲Stuck Thread，是爲了提醒我們那些線程執行的時間太長了。我們應該去分析線程爲什麼需要那麼長時間才能執行完（甚至永遠執行不完）。不去做根本原因的分析，而單純的依靠增加“粘滯線程最長時間”這個值的設置來減少Stuck Thread線程的出現，是掩耳盜鈴的做法。
獨佔線程(Hogging Thread)，很多資料上都沒有講清楚。先來看看聯機文檔是怎麼說的：
【獨佔】
如果根據調度程序的自動觀察，某個請求獨佔執行線程的時間超過了正常執行時間，則爲“真”。
True if the execute thread is being hogged by a request for much more than the normal execution time, as automatically observed by the scheduler.
【獨佔線程計數】
請求現在所保留的線程。這些線程將在配置的超時過後被聲明爲粘滯或在超時結束前返回給池。自優化機制將在必要時進行回填。
The threads that are being held by a request right now. These threads will either be declared as stuck after the configured timeout or will return to the pool before that. The self-tuning mechanism will backfill if necessary.
通過聯機文檔的解釋可以看出，WebLogic要把一個線程標記爲Hogging Thread需要滿足兩個條件：
（1）線程執行時間超過了“正常執行時間”。
（2）線程執行時間還沒有超過“粘滯線程最長時間”。
隨着時間的推移，Hogging Thread會出現兩種不同的狀態變化：
（1）在超過“粘滯線程最長時間”之前，請求執行完畢，Hogging Thread被釋放，重新回到線程池，等待下一個請求的到來。
（2）超過“粘滯線程最長時間”之後請求還沒有執行完畢，Hogging Thread被標記爲Stuck Thread，直到最後執行完畢（雖然有可能永遠執行不完）。
那麼，問題就來了，什麼叫做“正常執行時間”呢？它的工作原理是這樣：
WebLogic實例在啓動時候會同時啓動一個計時器，這個計時器每兩秒鐘掃描一次所有線程，然後根據公式來判斷是不是要把某個線程標記爲Hogging Thread。
（1）對於那些在剛剛過去的兩秒鐘內執行完畢的線程，計算出它們的平均完成時間。假設有2個線程執行完了，Thread_A花了1秒，Thread_B花了5秒，那麼平均時間Average_Time=(1+5)/2=3
（2）如果7*Average_Time大於4，那麼把Hog_Duration設置爲7*Average_Time，否則把Hog_Duration設置爲4。這個Hog_Duration就是聯機文檔裏面提到的“正常執行時間”。在我們的例子中 7*3=21 > 4 所以Hog_Duration設置爲21
（3）逐個掃描其它正在執行的線程，如果某個線程的執行時間已經超過了21秒(Hog_Duration)，那麼就把該線程標記爲Hogging Thread
友情提示，每個不同版本的WebLogic內部的運算機制可能並非是嚴格按照上面的公式和數值來判斷的，這個例子只是爲了講解它的原理。
參考資料：
https://support.oracle.com/epmos/faces/DocumentDisplay?id=1643449.1