文章目录服务器挂起是什么情况？ 有症状吗？ Weblogic线程的作用和责任？ 什么是执行队列？ 服务器挂起的原因是什么？ 如果服务器挂起或响应缓慢，服务器端日志会怎么样？ 服务器端出现上述日志，是否意味着Weblogic挂起了？ 收集调试数据所需的紧急步骤是什么？ 作者简介
线程dump分析是确定服务器响应缓慢、服务器挂起、线程导致服务器崩溃等问题原因的最重要的手段之一。 本文介绍了Weblogic线程模型以及这些线程执行的功能和任务的基本重要特性。 本文介绍了用于分析场景(如线程dump和服务器挂起)的常用术语。
服务器挂起了是什么情况？ 有症状吗？ 如果一台服务器的响应速度远远低于预期的响应时间，则整个服务器可能已挂起。 如果一台服务器也不响应客户端请求，则这是服务器完全锁定的场景。 如果服务器被完全阻止，服务器可能会崩溃。 Weblogic线程的作用和责任？
Weblogic线程大致分为两个类别。
Weblogic Execute 线程:此线程处理客户/用户的请求。 确定一台服务器可以同时执行的任务数。 在开发模式下，WLS服务器缺省有15个执行线程；在生产模式下，缺省有25个线程。 但是，增加Execute线程的数量并不能提高性能……相反，在某些情况下，性能会下降。Weblogic Socket Reader 线程:这样的线程将接收输入的客户端请求。 这意味着这些线程基本上负责处理网络通信部分的工作。 这些是Execute线程的一部分，缺省情况下使用33%的Execute线程。 这意味着，缺省情况下33%的Execute线程是Socket Reader线程，并且可以根据实际需要进行调整。 例如，如果处于开发模式的WLS服务器有15个执行线程，则5个线程是Socket Reader线程，其他10个线程负责处理实际的客户请求。
什么是执行队列？ Execute队列是负责指定servlet/RMI对象/EJB/JSP请求的一组Execute线程。 在WLS8.1之前，我们发现这些Execute队列信息是“config.xml”的一部分。 但是，从WLS9.x开始，Weblogic线程模型随着WorkManager的引入而发生了更改，因此在WLS9.x以后的WLS中，缺省情况下无法看到Execute队列详细信息。 但是，如果要在WLS9.x或更高版本的Weblogic上使用WLS8.1样式的线程模型，请单击此JAVA_OPTION: -Dweblogic.Use81StyleExecuteQueues=true
服务器挂起的原因是什么？ 服务器响应缓慢或锁定的背后可能有很多原因…
原因一如果可用堆内存很小，线程将无法创建Java堆内存所需的对象。
原因二线程数量不足。 通常，如果服务器负载(用户请求数)急剧增加，且MaxThreadCount未设置为正确的值，服务器将无法处理这些请求。
原因三如果垃圾回收需要更多的时间，则清理垃圾数据所需的时间将比平时更长，所有线程都将用于垃圾回收工作，而不是处理客户端请求。 或者线程们在等待垃圾收集变干净，形成新的空间，制作新的对象。
原因四Java (编译器)的代码优化可能会导致临时挂起。 这是因为代码优化是一个有点沉重的过程，但它有助于获得更好的性能。
原因五某些远程JDBC搜索可能会导致服务器挂起。
原因六不正确的JSP编译设置。 为了避免经常编译JSP，建议在将JSP部署到生产环境之前预编译并正确设置PageCheckSeconds
原因七应用代码死锁或JDBC驱动死锁或第三方API错误：当线程正在等待以无限循环获取对象锁时……例如：
线程Thread_A获取了对象Obj_A的锁定。 线程Thread_B获取了对象Obj_B的锁定。 线程Thread_A现在在处理了Obj_A的一些逻辑后请求锁定对象Obj_B。 对象Obj_B正在由线程Thread_B锁定。 同样，线程Thread_B在处理了Obj_B的一些逻辑后，开始请求锁定对象Obj_A。 对象Obj_A仍被线程Thread_A锁定。 在这种情况下，两个线程都在等待对方释放锁定的对象……但实际上没有人能释放自己锁定的对象。
r> 原因八。分配给进程的系统文件描述符的数量非常小 (资源不足)，在这种情况下我们也可能会面临服务器响应慢或者挂起的情形。 如果出现服务器挂起或响应缓慢的情形，服务端的日志是什么样子的？Weblogic 将一个线程标记为 STUCK 线程的默认时间间隔是 600 秒 (也就是 10 分钟)。当出现 STUCK 线程时服务端日志会对此进行详细记录，所以你可以在服务端日志中找到如下日志：
<Warning> <WebLogicServer> <BEA-000337> <ExecuteThread: '7' for queue: 'weblogic.kernel.Default' has been busy for "630" seconds working on the request "weblogic.ejb20.internal.JMSMessagePoller@d64412", which is more than the configured time (StuckThreadMaxTime) of "600" seconds.> 服务器端出现上述这种日志是不是就意味着 Weblogic 已经挂起？上述日志信息只是指示出有些线程在处理一些请求时占用了过多的时间，这当然会导致 Weblogic 服务器响应缓慢，同时这有可能会导致服务器挂起。但这并不 100% 意味着 Weblogic 无法从这些线程中恢复正常。
Weblogic 有能力将一个 STUCK 线程标记为 UNSTUCK。Weblogic 会根据 “Stuck Thread Max Time” 和 “Stuck Thread Timer Interval” 的设置对 STUCK 线程进行定期检查，请参考官方文档 http://e-docs.bea.com/wls/docs103/ConsoleHelp/taskhelp/tuning/TuningExecuteThreads.html。
Weblogic 只是对线程标记为 STUCK 进行报告，随着线程的处理结束 (可能看起来是卡住了，实际上是在运行一个很长的事务)，Weblogic 还会将其标记为 UNSTUCK。很多时候应用需求确实需要线程花费很多时间来处理客户端请求 (多余 600 秒)，在这种情况下屋面可以改变 “StuckThreadMaxTime” 的时间间隔。比方说我们的应用有一些需要长时间运行的 JDBC 查询可能会占用 900 多秒，这时候我们就可以增大 StuckThreadMaxTime 了。
调试一。使用 “weblogic.Admin PING” 工具 ping Weblogic 服务器五到六次来看看我们需要多久才能得到响应返回？
java weblogic.Admin -url t3://StuckThreadHostName:9001 -username weblogic -password weblogic PING
调试二。立刻检查详细的 GC 日志 (前提是你已经通过以下 JAVA_OPTIONS 启用了 GC 日志)。
调试三。在九到十秒之间收集至少四到五次线程 DUMP 来查看线程的活跃度。遵循各种线程 DUMP 的收集方法：http://middlewaremagic.com/weblogic/?p=823。
调试四。检查服务器负载 (客户端请求数) 是不是异常高？
调试五。检查 JMS 子系统连接或数据库连接是否在某个地方丢失了…你可能会在服务器日志中发现一些奇怪的条目，比如说 DataSource is Disables/ Network Adapter could not Establish Connection to the Database/ JMS Messaging System “PeerGoneException”…Tuxedo/Jolt Connectivity Errors…等等。
Jay SenSharma
Apache Ambari Committer、Staff Software Engineer
原文链接：What Is Server Hang And What Need To Be Done ?