粘滞线程(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
阅读(13421) | 评论(0) | 转发(0) |
