log4j 多线程死锁问题_Log4j线程死锁–案例研究

本文详细探讨了一次生产环境中由Log4j引起的多线程死锁问题,涉及Log4j 1.2.15版本的代码审查及线程转储分析。在一次部署变更后,发现大量线程因尝试获取同一Log4j对象锁而卡住,导致性能下降。通过回滚部署和代码审查,确定问题源于Log4j Category.callAppenders()方法的同步块设计,以及类加载器级别的Log4j库重构。解决方案包括回滚重构和调整日志级别。
摘要由CSDN通过智能技术生成

log4j 多线程死锁问题

此案例研究描述了影响Weblogic Portal 10.0生产环境的Apache Log4j线程争用问题的完整根本原因分析和解决方案。 它还将展示在开发和支持Java EE应用程序时适当的Java类加载器知识的重要性。

本文也是您提高线程转储分析技能和了解线程竞争条件的另一个机会。

环境规格

  • Java EE服务器:Oracle Weblogic Portal 10.0
  • 操作系统:Solaris 10
  • JDK:Oracle / Sun HotSpot JVM 1.5
  • 记录API:Apache Log4j 1.2.15
  • RDBMS:Oracle 10g
  • 平台类型:Web门户

故障排除工具

  • Quest Foglight for Java(监视和警报)
  • Java VM线程转储(线程竞争分析)

问题概述

从我们的一个Weblogic Portal生产环境中观察到主要性能下降。 还从Foglight代理发送了警报,表明Weblogic线程利用率显着上升,达到默认上限400。

事实的收集和验证

通常,Java EE问题调查需要收集技术事实和非技术事实,因此我们可以得出其他事实和/或就根本原因进行结论。 在采取纠正措施之前,要对以下事实进行验证,以便得出根本原因:

  • 对客户有什么影响?
  • 受影响平台的最近更改? 是的,最近进行的部署涉及少量内容更改以及一些Java库更改和重构。
  • 受影响平台最近的流量增加了吗? 没有
  • 从多久以来观察到此问题? 部署后发现新问题
  • 重新启动Weblogic服务器是否可以解决问题? 否,任何重新启动尝试均会立即导致线程激增
  • 回滚部署更改是否解决了问题? 是

结论1:问题似乎与最近的变化有关。 但是,团队最初无法查明根本原因。 现在,我们将在本文的其余部分进行讨论。

Weblogic占用线程报告

Foglight报告了初始线程激增问题。 如下所示,线程利用率很高(最多400个),从而导致大量待处理的客户端请求,最终导致严重的性能下降。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值