阅读目录
最近有个用户量 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。
延伸阅读
- ssh框架 2016-09-30
- 阿里移动安全 [无线安全]玩转无线电——不安全的蓝牙锁 2017-07-26
- 消息队列NetMQ 原理分析4-Socket、Session、Option和Pipe 2024-03-26
- Selective Search for Object Recognition 论文笔记【图片目标分割】 2017-07-26
- 词向量-LRWE模型-更好地识别反义词同义词 2017-07-26
- 从栈不平衡问题 理解 calling convention 2017-07-26
- php imagemagick 处理 图片剪切、压缩、合并、插入文本、背景色透明 2017-07-26
- Swift实现JSON转Model - HandyJSON使用讲解 2017-07-26
- 阿里移动安全 Android端恶意锁屏勒索应用分析 2017-07-26
- 集合结合数据结构来看看(二) 2017-07-26
学习是年轻人改变自己的最好方式