WebLogic執行線程耗盡的解決方法

本篇文章給大家分享的是有關 WebLogic執行線程耗盡的解決方法，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

WebLogic執行線程耗盡解決方法

WebLogic執行線程耗盡

1.1、概述 

更多WebLogic相關知識·：

WebLogic集群管理 生活中常用腳本及運維技巧 WebLogic圖形化安裝及靜默安裝

WebLogic服務器執行線程耗盡后就不再響應后續請求，WebLogic即出現掛起現象。

WebLogic線程耗盡產生的原因有多種，一般而言線程耗盡是由于線程在爭奪某種資源。當一種資源處于缺少狀態，比如數據庫JDBC連接池的達到最大連接數，就會導致后續的業務線程都卡在等待獲取JDBC的連接上，最終導致服務器無法響應后續的服務請求。

1.2、常見線程耗盡原因

WebLogic服務器線程耗盡，最常見的幾種原因如下：

WebLogic、JDK自身的Bug

業務系統中采用的開源軟件的Bug

主機硬件到達上限瓶頸，無法承擔更多的負載

數據庫JDBC連接池耗光，后續業務線程無法獲取到可用JDBC連接而一直處于等待狀態

應用程序同步調用。比如業務線程A執行的過程中鎖定了資源1，而由于同步調用的原因導致其他業務線程不得不一直無限等待資源1的鎖被釋放。

業務系統沒有使用WebLogic線程池，而使用自定義的線程池。當自定義線程池全部被占用，就會導致沒有線程可用于新工作。

線程都處于等待RJVM、RMI響應

應用配置不合理，比如設置了錯誤JSP PageCheckSeconds參數等

1.3、判斷條件

在出現以下情況時懷疑WebLogic服務器線程耗盡：

服務器不響應新的請求

請求超時

請求處理的時間越來越長（其最終結果可能是掛起）

通常，服務器掛起不會表現為服務器崩潰，但服務器掛起之后可能會崩潰。

1.4、收集信息

當服務器掛起時，首先使用 java weblogic.Admin t3://server:port PING 來 ping 該服務器。如果服務器能夠響應此 ping，則可能是應用程序所使用的線程池耗盡而不是服務器自身。

WebLogic Server 在8.1版本之前使用“Default”線程池響應客戶端服務請求，在9.0版本以后使用Default (self-tuning)線程池響應客戶端服務請求。這些是在發生線程耗盡時應當檢查的線程池。通常情況下，用收集JVM的Thread Dump的辦法來分析線程池運行信息。 加粗樣式

Linux / Unix系統

任何WebLogic版本均可使用 kill -3 創建診斷問題所需的 Thread Dump。確保在每個服務器上執行幾次，每次間隔大約 3 到 5秒，以幫助診斷死鎖問題。

在WebLogic 9.2版本或者是更高的版本中，可以直接通過使用JDK的jstack命令來收集Thread Dump信息。

Windows操作系統

任何WebLogic版本均可使用 - 來創建診斷問題所需的 Thread Dump。確保在每個服務器上執行幾次，每次間隔大約 3 到 5 秒，以幫助診斷死鎖問題。

在WebLogic 9.2版本或者是更高的版本中，可以直接通過使用JDK的jstack命令來收集Thread Dump信息。

1.5、實施步驟

收集操作系統、WebLogic運行相關基本信息

收集出現線程耗盡時間段WebLogic運行日志

采集Thread Dump

在服務器上快速分析Thread Dump，初步定位線程耗盡問題

重啟線程耗盡WebLogic服務器，使其盡快對外提供服務

將采集到的Thread Dump下載到本地，進行詳細的離線分析

1.6、分析Thread Dump

WebLogic除了包含業務系統所使用的執行線程池以外，還包括ListenThread線程池、Socket Reader線程池以及自定義線程池等等。由于WebLogic軟件是非常復雜的企業軟件，所以在分析的時候，我們不但需要關注業務執行線程池，同時也需要關注其他線程池。WebLogic線程池簡易圖示如下：

Thread Dump線程轉儲是將當前JVM包含的所有的線程的運行狀態的一個映像，包含了：

各個線程的棧 (stacktrace)

線程當前的狀態

線程名字

線程號(tid)以及對應的native thread id (nid) 等信息

分析WebLogic服務器線程耗盡的最有用的辦法是分析一系列 的Thread Dump。一系列 Thread Dump（一般每隔3 到 5 秒進行三個或更多 Thread Dump）可以幫助分析每個線程從一個 Thread Dump 到另一個 Thread Dump 過程中的狀態變化或所缺少的變化。WebLogic服務器線程耗盡導致服務器掛起后，服務器的 Thread Dump 一般顯示線程狀態從第一個 Thread Dump 到最后一個 Thread Dump 中變化很小。

在 Thread Dump 中查看的內容

所有請求都通過 ListenThread 進入 WebLogic Server。如果 ListenThread 丟失，就無法接收任何工作，因此也無法完成任何工作。確認在 Thread Dump 中存在 ListenThread。ListenThread 應當在 socketAccept 方法中。下面示例說明監聽線程 (Listen Thread) 的形式。

Socket Reader 線程接受來自監聽線程隊列的傳入請求，并將該請求放入執行線程隊列。如果 Thread Dump 中沒有 Socket Reader 線程，則在某個地方存在導致 Socket Reader 線程消失的錯誤。應當始終保持至少有三個 Socket Reader 線程。一個 Socket Reader 線程一般用于輪詢功能，另外兩個用于處理請求。下面是一個 Thread Dump 示例中的 Socket Reader 線程。

通常，業務代碼使用的是WebLogic默認的執行線程池，在WebLogic 8.1之前以“Default”命名，在9.x以后以“weblogic.kernel.Default(self-tuning)”命名。查看執行線程的狀態，主要看thread dump里面的state的值。同時，為了更快的定位問題，WebLogic服務器會將運行時間超過600秒的執行線程標記為“STUCK”狀態，如下所示：

java中線程的狀態

Thread Dump中，Java線程的各種狀態如下：

狀態

說明

NEW

初始狀態。線程剛剛被創建，并且start()方法還未被調用

RUNNABLE

運行狀態。表示線程正在java虛擬機中執行，但是可能正在等待操作系統的其他資源，比如CPU

BLOCKED

阻塞狀態。表示線程正在等待監視器鎖。表示線程正在等待獲取監視器鎖，以便進入同步方法或者同步代碼快，也有可能是從wait（）方法被喚醒而等待再次進入同步方法或者同步代碼塊

WAITING

等待狀態。表示當前線程需要等待其他線程執行一些特殊操作，比如當前線程調用了a.wait()方法，它正在等待其他線程調用a.notify或a.notifyAll方法;如果當前線程調用了threada.join(),那么它在等待threada執行完成

TIMED_WAITING

超時等待。與WAITING的不同在于，該狀態有超時時間

TERMINATED

終止狀態，表示當前線程已經執行完畢

線程狀態的詳細介紹請參考Java源代碼的Thread內部類：State。

其中線程狀態中WAITING與TIMED_WAITING區別如下：

調用以下三個方法會進入WAITING狀態：

Object.wait() 不設置超時時間

Thread.join() 不設置超時時間

LockSupport.park() 不設置超時時間

調用下面的方法會進入TIMED_WAITING狀態：

Object.wait(time)

Thread.join(time)

Thread.sleep(time)

LockSupport.parkNanos(time)

LockSupport.parkUntil(time)

1.6、相關腳本

收集thread dump的示例腳本如下：

以上就是 WebLogic執行線程耗盡的解決方法，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。