今天在客户现场出现了weblogic down的事件，还是老规矩，陆续察看了几个相关日志，在server.log中发现error事件——stuckThreadMaxTime 600 

首先我们来说明一下stuckThreadMaxTime，如下：

Server 提供 stuckThreadMaxTime 及stuck Thread Timer Interval 兩個參數協助偵測 thread 

stuck 的狀況並發出警訊 , stuckThreadMaxTime 的 default 值為 600 秒 , 

stuckThreadTimerInterval 的 deault 值也是 600 秒 , 每 600 秒 WebLogic Server 會檢查 Queue 

中所有的 thread, 如果發現有持續工作 600 秒的狀況發生 ,Server 認定這個 thread 的狀態為 stuck, stuck 住的 

thread 在 Server log 中會有記錄提醒管理者 , 

如果情況持續的惡化 ,stuck thread 數量越來越多 , 造成 WEBLogic Server 的 Default Execute Queue 中的 

thread 全部 stuck,Server 就會變更自己的狀態為 CrITical, 如果是 Customer Execute Queue,Server 

變更自己的狀態為 Warning

在以前的项目中，也遇到过由于thread的异常造成了java processes的异常中断，看了一下相关程序，是用来发送邮件的，为了避免requestTimeout和页面友好度，采用异步发送（采用异步thread），在设计时忽略了一点，那就是异步线程同样受限于stuckThreadMaxTime，而且有多年java经验的人应该清楚，JVM 

Thread机制相比C/C++是非常不稳定和低效的

为了避免这样的问题，现在改成JNI C进行处理，当然如果有条件或者对应用要求过高的环境，可以使用JMS进行数据主推的分布式工作

以上就是这次事件的记录过程，有兴趣的朋友可以多讨论