独占线程数过多-weblogic报警

生产项目发生告警短信,提示:独占线程数过多,703个。

搜索资料并记录如下:http://tekkamanninja.blog.chinaunix.net/uid-17176286-id-5180127.html

-------

问题分析与处理:

独占线程(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内部的运算机制可能并非是严格按照上面的公式和数值来判断的,这个例子只是为了讲解它的原理。
### WebLogic独占线程的使用场景与解决方案 #### 使用场景分析 在WebLogic环境中,某些操作可能需要确保特定任务在一个单独的线程上执行而不受其他请求干扰。这种需求通常出现在高并发环境下,当某个处理过程涉及到敏感资源的操作或是为了防止数据竞争条件的发生。 对于长时间运行的任务或对性能要求极高的服务调用来说,分配专门的工作线程可以有效提高系统的稳定性和响应速度[^2]。此外,在涉及复杂业务逻辑的情况下,比如分布式事务管理中的两阶段提交协议[TCC模式][^1],也需要利用到独占线程来保障事务的一致性。 #### 存在的问题及风险 然而,创建过多独占线程可能会带来一些潜在的风险: - **资源浪费**:每个Java虚拟机(JVM)实例能够支持的最大线程数有限制,过度占用会消耗大量内存和其他计算资源; - **饥饿现象**:如果某些类型的请求总是被指派给固定的几个线程,则可能导致这些线程过载而使其他正常请求得不到及时处理; - **死锁隐患**:不当的设计还容易引发死锁问题,特别是在多线程之间存在依赖关系的时候。 #### 解决策略建议 针对上述挑战,可采取如下措施优化独占线程的应用方式: - **合理配置参数**:调整`weblogic.server.BlockingQueueLength`等属性控制等待队列长度以及最大允许阻塞时间(默认为600秒),以平衡效率和安全性之间的矛盾; - **采用连接池技术**:通过引入数据库或其他外部组件的连接池机制减少频繁建立新连接所带来的开销,并实现资源共享最大化; - **实施细粒度锁定策略**:尽可能缩小临界区范围并缩短持有锁的时间间隔,以此降低发生冲突的概率同时加快程序整体执行进度; - **定期监控健康状态**:借助内置工具如JMX接口获取实时统计信息,一旦发现异常情况立即触发报警通知运维人员介入排查原因。 ```java // 设置合理的超时时间和重试次数 server.setBlockingDispatchPolicy(new DefaultContext.RequestClass( "blocking", new Integer(30), // 超时时间为30秒 null, // 不设置优先级 false)); // 是否启用公平调度算法 ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值