net域名做企业网站怎么样,上海最大的外贸公司,做网站在手机端预览乱码了,品牌买购网java线程死锁本文将描述从在IBM JVM 1.6上运行的Weblogic 11g生产系统中观察到的最新Java死锁问题的完整根本原因分析。 此案例研究还将证明掌握线程转储分析技能的重要性#xff1b; 包括用于IBM JVM Thread Dump格式。 环境规格 – Java EE服务器#xff1a;Oracle Weblo… java线程死锁 本文将描述从在IBM JVM 1.6上运行的Weblogic 11g生产系统中观察到的最新Java死锁问题的完整根本原因分析。 此案例研究还将证明掌握线程转储分析技能的重要性 包括用于IBM JVM Thread Dump格式。 环境规格 – Java EE服务器Oracle Weblogic Server 11g和Spring 2.0.5 –操作系统AIX 5.3 – Java VMIBM JRE 1.6.0 –平台类型门户和订购应用程序 监控和故障排除工具 – JVM线程转储IBM JVM格式– Compuware Server VantageWeblogic JMX监视和警报 问题概述 从Compuware Server Vantage观察到并报告了一个严重的线程阻塞问题该问题影响了我们的2台Weblogic 11g生产托管服务器从而导致了最终用户的应用程序影响和超时情况。 事实的收集和验证 像往常一样Java EE问题调查需要收集技术和非技术事实因此我们可以得出其他事实和/或就根本原因进行结论。 在采取纠正措施之前要对以下事实进行验证以便得出根本原因 ·对客户有什么影响 中在16个中只有2个受管服务器/ JVM受影响·受影响平台的最新更改 是新的与JMS相关的异步组件·最近到受影响平台的流量增加了吗 否·这个问题如何表现出来 观察到线程突然增加导致线程快速耗尽。·Weblogic托管服务器重新启动是否解决了问题 是的但是几个小时后问题又回来了不可预测的间歇性模式 – 结论1 该问题与间歇性卡住的线程行为有关该行为当时仅影响少数Weblogic托管服务器 – 结论2 由于问题是断断续续的因此不太可能出现全局根本原因例如下游系统无响应 线程转储分析–第一遍 处理滞留的线程问题时要做的第一件事是生成JVM线程转储。 无论您的环境规格和问题背景如何这都是一条黄金法则。 JVM线程转储快照为您提供了有关活动线程及其当时正在执行的处理/任务类型的重要信息。 现在回到我们的案例研究生成了一个IBM JVM线程转储javacore.xyz格式它确实揭示了以下Java线程死锁情况 1LKDEADLOCK Deadlock detected !!!NULL ---------------------NULL 2LKDEADLOCKTHR Thread [STUCK] ExecuteThread: 8 for queue: weblogic.kernel.Default (self-tuning) (0x000000012CC08B00)3LKDEADLOCKWTR is waiting for:4LKDEADLOCKMON sys_mon_t:0x0000000126171DF8 infl_mon_t: 0x0000000126171E38:4LKDEADLOCKOBJ weblogic/jms/frontend/FESession0x07000000198048C0/0x07000000198048D8: 3LKDEADLOCKOWN which is owned by:2LKDEADLOCKTHR Thread [STUCK] ExecuteThread: 10 for queue: weblogic.kernel.Default (self-tuning) (0x000000012E560500)3LKDEADLOCKWTR which is waiting for:4LKDEADLOCKMON sys_mon_t:0x000000012884CD60 infl_mon_t: 0x000000012884CDA0:4LKDEADLOCKOBJ weblogic/jms/frontend/FEConnection0x0700000019822F08/0x0700000019822F20: 3LKDEADLOCKOWN which is owned by:2LKDEADLOCKTHR Thread [STUCK] ExecuteThread: 8 for queue: weblogic.kernel.Default (self-tuning) (0x000000012CC08B00) 死锁情况可以按照以下方式进行翻译 – Weblogic线程8正在等待获取Weblogic线程10拥有的对象监视器锁 – Weblogic线程10正在等待获取Weblogic线程8拥有的对象监视器锁 结论 Weblogic线程8和10都在等待。 永远 现在在深入分析根本原因之前让我为您提供有关Java Thread死锁的高级概述。 Java线程死锁概述 你们大多数人可能都熟悉Java Thread死锁原理但是您真的遇到了真正的死锁问题吗 根据我的经验真正的Java死锁很少见并且在过去的10年中我仅见过约5次此类事件。 原因是大多数与线程卡住有关的问题是由于线程挂起情况正在等待远程IO调用等引起的而不是与其他线程发生真正的死锁情况。 Java线程死锁是一种情况例如线程A正在等待获取线程B持有的对象监视器锁定而线程B本身正在等待获取线程A持有的对象监视器锁定。这两个线程将永远彼此等待。 这种情况可以如下图所示 线程死锁已确认……现在该怎么办 一旦确认了死锁 大多数JVM Thread Dump实现将为您突出显示 下一步就是通过检查死锁情况下涉及的每个线程及其当前任务和等待条件来进行更深入的分析。 在我们的问题案例中对于涉及死锁条件的每个线程在部分线程堆栈跟踪下面找到 **请注意出于保密目的真实应用程序Java包名称已重命名** Weblogic线程8 [STUCK] ExecuteThread: 8 for queue: weblogic.kernel.Default (self-tuning) J9VMThread:0x000000012CC08B00, j9thread_t:0x00000001299E5100, java/lang/Thread:0x070000001D72EE00, state:B, prio1(native thread ID:0x111200F, native priority:0x1, native policy:UNKNOWN)Java callstack:at weblogic/jms/frontend/FEConnection.stop(FEConnection.java:671(Compiled Code))at weblogic/jms/frontend/FEConnection.invoke(FEConnection.java:1685(Compiled Code))at weblogic/messaging/dispatcher/Request.wrappedFiniteStateMachine(Request.java:961(Compiled Code))at weblogic/messaging/dispatcher/DispatcherImpl.syncRequest(DispatcherImpl.java:184(Compiled Code))at weblogic/messaging/dispatcher/DispatcherImpl.dispatchSync(DispatcherImpl.java:212(Compiled Code))at weblogic/jms/dispatcher/DispatcherAdapter.dispatchSync(DispatcherAdapter.java:43(Compiled Code))at weblogic/jms/client/JMSConnection.stop(JMSConnection.java:863(Compiled Code))at weblogic/jms/client/WLConnectionImpl.stop(WLConnectionImpl.java:843)at org/springframework/jms/connection/SingleConnectionFactory.closeConnection(SingleConnectionFactory.java:342)at org/springframework/jms/connection/SingleConnectionFactory.resetConnection (SingleConnectionFactory.java:296)at org/app/JMSReceiver.receive()…………………………………………………………………… Weblogic线程10 [STUCK] ExecuteThread: 10 for queue: weblogic.kernel.Default (self-tuning) J9VMThread:0x000000012E560500, j9thread_t:0x000000012E35BCE0, java/lang/Thread:0x070000001ECA9200, state:B, prio1(native thread ID:0x4FA027, native priority:0x1, native policy:UNKNOWN)Java callstack:at weblogic/jms/frontend/FEConnection .getPeerVersion(FEConnection.java:1381(Compiled Code))at weblogic/jms/frontend/FESession.setUpBackEndSession(FESession.java:755(Compiled Code))at weblogic/jms/frontend/FESession.consumerCreate(FESession.java:1025(Compiled Code))at weblogic/jms/frontend/FESession.invoke(FESession.java:2995(Compiled Code))at weblogic/messaging/dispatcher/Request.wrappedFiniteStateMachine(Request.java:961(Compiled Code))at weblogic/messaging/dispatcher/DispatcherImpl.syncRequest(DispatcherImpl.java:184(Compiled Code))at weblogic/messaging/dispatcher/DispatcherImpl.dispatchSync(DispatcherImpl.java:212(Compiled Code))at weblogic/jms/dispatcher/DispatcherAdapter.dispatchSync(DispatcherAdapter.java:43(Compiled Code))at weblogic/jms/client/JMSSession.consumerCreate(JMSSession.java:2982(Compiled Code))at weblogic/jms/client/JMSSession.setupConsumer(JMSSession.java:2749(Compiled Code))at weblogic/jms/client/JMSSession.createConsumer(JMSSession.java:2691(Compiled Code))at weblogic/jms/client/JMSSession.createReceiver(JMSSession.java:2596(Compiled Code))at weblogic/jms/client/WLSessionImpl.createReceiver(WLSessionImpl.java:991(Compiled Code))at org/springframework/jms/core/JmsTemplate102.createConsumer(JmsTemplate102.java:204(Compiled Code))at org/springframework/jms/core/JmsTemplate.doReceive(JmsTemplate.java:676(Compiled Code))at org/springframework/jms/core/JmsTemplate$10.doInJms(JmsTemplate.java:652(Compiled Code))at org/springframework/jms/core/JmsTemplate.execute(JmsTemplate.java:412(Compiled Code))at org/springframework/jms/core/JmsTemplate.receiveSelected(JmsTemplate.java:650(Compiled Code))at org/springframework/jms/core/JmsTemplate.receiveSelected(JmsTemplate.java:641(Compiled Code))at org/app/JMSReceiver.receive()…………………………………………………………… 正如您在上面的Thread Strack跟踪中看到的那样这种死锁确实来自我们的应用程序代码该应用程序代码使用Spring框架API进行JMS使用者实现在不使用MDB的情况下非常有用。 堆栈跟踪非常有趣它揭示了两个线程都在同一个 Weblogic JMS使用者会话/连接的竞争状态下并导致死锁情况 – Weblogic线程8试图重置并关闭当前的JMS连接– Weblogic线程10试图使用相同的JMS连接/会话以创建新的JMS使用者–触发了线程死锁 根本原因非线程安全的Spring JMS SingleConnectionFactory实现 Spring JIRA错误数据库的代码回顾和快速研究确实揭示了以下与以下分析完美相关的以下线程安全缺陷 SingleConnectionFactory的resetConnection导致与基础OracleAQ的JMS连接的死锁https://jira.springsource.org/browse/SPR-5987 Spring SingleConnectionFactory的补丁发布于2009年确实涉及添加适当的sync {}块以防止在发生JMS Connection重置操作时线程死锁 synchronized (connectionMonitor) {//if condition added to avoid possible deadlocks when trying to reset the target connection if (!started) {this.target.start(); started true; }} 解 我们的团队目前正计划将该Spring补丁不久后集成到我们的生产环境中。 在我们的测试环境中执行的初始测试是肯定的。 结论 我希望这个案例研究能够帮助您理解现实中的Java Thread死锁问题以及适当的Thread Dump分析技能如何使您能够在代码级快速查明与线程相关的问题。 请不要犹豫发表任何评论或问题。 参考 Java线程死锁– Java EE支持模式和Java教程博客上的JCG合作伙伴 Pierre-Hugues Charbonneau的案例研究 。 翻译自: https://www.javacodegeeks.com/2012/06/java-thread-deadlock-case-study.htmljava线程死锁
