阅读目录
最近有个用户量 5W-10W 的 web 应用，频繁导致 weblogic 崩溃，让运维组很难受。
通过几天跟踪系统日志和 weblogic 运行状况，发现报错的姿势有很多，其中对定位问题比较关键的报错：
ExecuteThread: '496' for queue: 'weblogic.kernel.Default (self-tuning)' has beenbusy for "712" seconds working on the request "XXXX", which is more than the configured time (StuckThreadMaxTime) of "600" seconds.
weblogic 分配给 web 应用使用的线程响应返回周期最大为10分钟，线程迟迟无法返回结果导致阻塞，并且这样的刺头线程越来越多。
运行一段时间后达到 weblogic 阻塞线程的阀值，weblogic 自然就崩溃了。
刚开始也试着调大 weblogic 响应周期/阻塞线程的阀值，但是阻塞线程还是会存在并且很快达到阀值。
仔细比对奔溃前后日志，查看 weblogic 阻塞线程详情，导致阻塞开始罪魁祸首是数据库查询需要很长时间。
该系统与内外围很多厂商系统有进行数据交互，数据库里面旁根错杂的 db_link/synonyms/view/procedure。
