weblogic日常維護(hù)總結(jié)與故障診斷

1、中間件故障診斷總結(jié)一、 步驟：1、準(zhǔn)確描述現(xiàn)象：客戶說的和自己查看到的：平臺(tái)、版本、操作、信息等。特別是，故障前是否有做過什么操作：網(wǎng)絡(luò)調(diào)整、設(shè)備調(diào)整、主機(jī)參數(shù)調(diào)整、配置文件修改反正將這一切都列入排查的對(duì)象。2、使用工具收集數(shù)據(jù)，收集配置文件、日志、dump文件等等。3、 使用分析數(shù)據(jù)，根據(jù)問題或收集的數(shù)據(jù)，使用適當(dāng)?shù)墓ぞ叻治鰯?shù)據(jù)，當(dāng)然包括了在網(wǎng)上和在官方支持站點(diǎn)搜索類似的問題的解決辦法。 4、 嘗試解決問題，根據(jù)找到的問題點(diǎn)，嘗試解決。如修改錯(cuò)的，復(fù)原正確的；運(yùn)行有問題的，適當(dāng)調(diào)整運(yùn)行的環(huán)境和運(yùn)行的參數(shù)等等。5、 給出最佳解決方案，一般就是繼續(xù)觀察了。6、總結(jié)經(jīng)驗(yàn)并加以重用，知識(shí)積累。二、

2、通過前臺(tái)收集基本的信息：1、重點(diǎn)是故障前做過的操作2、比對(duì)運(yùn)行平臺(tái)是否在官方的兼容性列表中，一般就是關(guān)注各個(gè)版本，特別是一些比較怪異的問題3、檢查環(huán)境和參數(shù)，如能打開控制臺(tái)，就在控制臺(tái)中初步觀察，一般進(jìn)入控制臺(tái)的格式是http:/ip地址：端口/console 如：9:7001/console/。常用的留意點(diǎn)如下：A、 域運(yùn)行狀態(tài)（域-監(jiān)視-健康狀況）；一般為running狀態(tài)，如果不是running，那這些界面就沒有了。B、 服務(wù)器運(yùn)行狀態(tài)（域-環(huán)境-服務(wù)器），正常的為running。C、 各個(gè)server性能（JVM）狀態(tài)（域-環(huán)境-服務(wù)器，點(diǎn)擊具體的se

3、rve后進(jìn)入，監(jiān)視-健康狀況）;留意JVM 堆中當(dāng)前可用的內(nèi)存量。不同的JVM，所顯示的內(nèi)容可能不一樣，以下為sun的：D、 各個(gè)server線程狀態(tài)（域-環(huán)境-服務(wù)器，點(diǎn)擊具體的serve后進(jìn)入，監(jiān)視-線程）；一般來說，空閑線程要多；健康狀況為ok如下圖health狀態(tài)為：Warning，這個(gè)是有線程阻塞的。阻塞線程的內(nèi)容為：#<2011-8-13 上午02時(shí)42分35秒 .SocketOutputStream.socketWrite0(Native Method) .SocketOutputStream.socketWrite(SocketOutputStream.java:97)

4、.SocketOutputStream.write(SocketOutputStream.java:141) .ns.DataPacket.send(Unknown Source)E、 JDBC（域-環(huán)境-服務(wù)器，點(diǎn)擊具體的serve后進(jìn)入，監(jiān)視-JDBC）；活動(dòng)連接數(shù)合理。F、 程序EJB/Web Module（域-部署）；狀態(tài)為活動(dòng)，健康狀況為ok。其目標(biāo)關(guān)聯(lián)正確G、 JMS（域-服務(wù)-消息傳送-JMS服務(wù)器）；健康狀態(tài)為ok。4、在控制臺(tái)生成dump；生成Dump Thread Stacks內(nèi)容；查找queryList等關(guān)鍵字符，即可快速定位問題代碼。5、如果控制臺(tái)打不開或無法進(jìn)入，就要

5、先看進(jìn)程有沒有在跑，如果進(jìn)程有，但控制臺(tái)或程序無法進(jìn)入，一般就是有故障了，此時(shí)，可以通過相關(guān)日志進(jìn)行后臺(tái)分析分析。三、 后臺(tái)日志分析：一般來說，新建立的環(huán)境，配置的問題多一點(diǎn)；已經(jīng)運(yùn)行的生成系統(tǒng)錯(cuò)誤或bug的可能性大點(diǎn)。當(dāng)出現(xiàn)故障時(shí)，就可以調(diào)取系統(tǒng)日志、中間件的日志，根據(jù)相關(guān)關(guān)鍵字（BEA-）網(wǎng)上搜索，或到官方網(wǎng)站對(duì)相關(guān)問題的描述進(jìn)行查找。WebLogic在啟動(dòng)及運(yùn)行過程中會(huì)記錄各種LOG信息，以幫助系統(tǒng)治理員對(duì)整個(gè)應(yīng)用系統(tǒng)進(jìn)行治理及維護(hù)。1、log默認(rèn)位置.user_projectsdomainsyour_domainserversAdminServerlogs下面的AdminServer.

6、log;access.log;domain_name.log新版的如：C:OracleMiddlewareuser_projectsdomainsbase_domainserversAdminServerlogs如果是重定向輸出的，就看重定向輸出的文件。2、日志文件說明WebLogic SERVER運(yùn)行日志 假如WebLogic SERVER在啟動(dòng)或運(yùn)行過程中有錯(cuò)誤發(fā)生，錯(cuò)誤信息會(huì)顯示在屏幕上，并且會(huì)記錄在一個(gè)LOG文件中，該文件默認(rèn)名為AdminServer.log。該文件也記錄WebLogic的啟動(dòng)及關(guān)閉等其他運(yùn)行信息。可在Gernal屬性頁中設(shè)置該文件的路徑及名字，錯(cuò)誤的輸出的等級(jí)等。H

7、TTP訪問日志 在WebLogic中可以對(duì)用HTTP，HTTPS協(xié)議訪問的服務(wù)器上的文件都做記錄，該LOG文件默認(rèn)的名字為Access.log,內(nèi)容如下，該文件具體記錄在某個(gè)時(shí)間，某個(gè)IP地址的客戶端訪問了服務(wù)器上的那個(gè)文件。 - - 25/Feb/2002:11:35:58 +0800 "GET /weather HTTP/1.1" 302 0 - - 25/Feb/2002:11:35:58 +0800 "GET /weather/index.Html HTTP/1.1" 200 176 HTTP訪問日志的屬性

8、可在HTTP屬性頁中進(jìn)行設(shè)置。 DOMAIN運(yùn)行日志 記錄一個(gè)DOMIAN的運(yùn)行情況，一個(gè)DOMAIN中的各個(gè)WebLogic SERVER可以把它們的一些運(yùn)行信息（比如：很嚴(yán)重的錯(cuò)誤）發(fā)送給一個(gè)DOMAIN的ADMINISTRATOR SERVER上，ADMINISTRATOR SERVER把這些信息些到DOMAIN 日志中。默認(rèn)名為：domain_name.log 。一般就看這個(gè)最多。3、通過控制臺(tái)查看或修改系統(tǒng)日志路徑登錄weblogic后臺(tái)左側(cè)菜單：Environment->Servers右側(cè)菜單：AdminServer(admin)->logging只找到examples

9、Server.log、access.log配置 如圖: 4、其他如果日志太少，里面沒有記載相關(guān)信息，可參照日志文件的回滾設(shè)置。在“滾動(dòng)類型:”屬性頁中可以設(shè)置這些日志文件的回滾方式，當(dāng)日志文件到一定得大小或過了設(shè)定的時(shí)間后，把日志信息保存到一個(gè)新的文件中。WebLogic提供按文件大小和時(shí)間兩種方式。如下面的設(shè)置種，選擇Rotation Type 為BY SIZE。也就是當(dāng)日志文件的大小達(dá)到500K時(shí)，重新寫一個(gè)新的文件。假如Rotation Type 為BY TIME，那么是每隔一段時(shí)間重新寫一個(gè)新的文件。并且對(duì)這些文件編號(hào)設(shè)置日志文件名如：_%yyyy%_%MM%_%dd%_%h

10、h%_%mm%5、日志的處理：查看日志中輸出的具體內(nèi)容，再進(jìn)行處理。如：BEA-下面是一個(gè)線程阻塞的一個(gè)信息#<2011-8-13 上午03時(shí)51分46秒 GMT+08:00> <Error> <WebLogicServer> <dataweb1> <dc_admin1> <ACTIVE ExecuteThread: '11' for queue: 'we<BEA-000337> <STUCK ExecuteThread: '1' for queue: 'webl

11、ogic.kernel.Default (self-tuning)' has been busy for "2,503" seconds working on the request "weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpldeab5f", which is more than the configured time (StuckThreadMaxTime) of "2,400" seconds. Stack trace:四、 產(chǎn)生hread Dump來分

12、析問題hread Dump是非常有用的診斷Java應(yīng)用問題的工具，每一個(gè)Java虛擬機(jī)都有及時(shí)生成顯示所有線程在某一點(diǎn)狀態(tài)的thread-dump的能力。雖然各個(gè)Java虛擬機(jī)thread dump打印輸出格式上略微有一些不同，但是Thread dumps出來的信息包含線程；線程的運(yùn)行狀態(tài)、標(biāo)識(shí)和調(diào)用的堆棧；調(diào)用的堆棧包含完整的類名，所執(zhí)行的方法，如果可能的話還有源代碼的行數(shù)。Thread Dump特點(diǎn)：· 能在各種操作系統(tǒng)下使用 · 能在各種Java應(yīng)用服務(wù)器下使用 · 可以在生產(chǎn)環(huán)境下使用而不影響系統(tǒng)的性能 · 可以將問題直接定位到應(yīng)用程序的代碼行上

13、 Thread Dump能診斷的問題包括：· 查找內(nèi)存泄露，常見的是程序里load大量的數(shù)據(jù)到緩存 · 發(fā)現(xiàn)死鎖線程 · 收集 Thread Dump 進(jìn)行 Thread Dump 的方法取決于安裝掛起服務(wù)器實(shí)例的操作系統(tǒng)。有關(guān)在不同的操作系統(tǒng)上進(jìn)行 Thread Dump 的信息，Solaris OS<ctrl>- (Control-Backslash) kill -QUIT <pid>LinuxLinux 操作系統(tǒng)查看線程的方式不同于其它操作系統(tǒng)。該操作系統(tǒng)將每個(gè)線程視為一個(gè)進(jìn)程。若要在 Linux 上進(jìn)行 Thread Du

14、mp，查找通過其啟動(dòng)所有其它進(jìn)程的進(jìn)程 ID。使用命令： · 若要獲得根 PID，使用： ps -efHl | grep 'java' *. * 使用一個(gè)作為字符串的 grep 參數(shù)（可在與服務(wù)器啟動(dòng)命令匹配的進(jìn)程堆棧中找到該字符串）。如果 ps 命令還沒有管道傳送到另一個(gè)例程，則報(bào)告的第一個(gè) PID 將是根進(jìn)程。IBM AIX在AIX上用IBM的JVM，內(nèi)存溢出時(shí)默認(rèn)地會(huì)產(chǎn)生javacore文件（關(guān)于cpu的）和heapdump文件(關(guān)于內(nèi)存的)。執(zhí)行kill -3 <pid>命令可以生成javacore文件和heapdump文件（pid為was jav

15、a進(jìn)程的id號(hào)，可以用ps -ef|grep java 查到），可以多執(zhí)行幾次。有些Java應(yīng)用服務(wù)器是在控制臺(tái)上運(yùn)行，如Weblogic，為了方便獲取threaddump信息，在 weblogic啟動(dòng)的時(shí)候，最好將其標(biāo)準(zhǔn)輸出重定向到一個(gè)文件，用"nohup sh startWebLogic.sh > start.log &"命令，執(zhí)行"kill -3 <pid>"，Stack trace就會(huì)輸出到start.log里。為了反映線程狀態(tài)的動(dòng)態(tài)變化，需要接連多次做thread dump，每次間隔10-20s。Windows、XP、

16、NT 設(shè)置DOS 窗口的屬性：Layout -> Screen Buffer Size-> Height 9999。 同時(shí)按下CTRL-BREAK 找到Thread Dump的最開始的位置："Full thread dump. "每個(gè)服務(wù)器需要 <Ctrl>-<Break> 來創(chuàng)建診斷問題所需的 Thread Dump。確保在每個(gè)服務(wù)器上執(zhí)行幾次，每次間隔大約 5 到 10 秒，以幫助診斷死鎖問題。在 NT 上，在命令 shell 中輸入 CTRL-Break。 獲取失敗時(shí)刻的獲取失敗時(shí)刻的Thread Dump 啟動(dòng)JVM 時(shí)，加入?yún)?shù)

17、： Sun JVM: -XX:+ShowMessageBoxOnE JRockit JVM: -Djrockit.waitone 五、 常見的問題1、Out of Memory 當(dāng)JVM沒有足夠的內(nèi)存執(zhí)行任務(wù)時(shí)，會(huì)觸發(fā) java.lang.OutOfMemoryError 當(dāng)沒有更多內(nèi)存可以分配時(shí) 或空閑的內(nèi)存有太多碎片，無法利用時(shí) 可能不足的內(nèi)存類型有可能不足的內(nèi)存類型有： Native （物理內(nèi)存） Heap （堆內(nèi)存） 特定Java 內(nèi)存代（例如，permanet） 對(duì)Out of Memory的響應(yīng)的響應(yīng) JVM會(huì)發(fā)送error到標(biāo)準(zhǔn)輸出流和錯(cuò)誤輸出流 WLS會(huì)將應(yīng)用程序沒有處理的Ja

18、va異常和錯(cuò)誤都輸出 到服務(wù)器日志 Out-of-Memory和類似的系統(tǒng)錯(cuò)誤不應(yīng)該由應(yīng)用程序直 接處理接處理 如果應(yīng)用程序發(fā)生錯(cuò)誤，會(huì)給客戶端返回錯(cuò)誤信息（ 例如HTTP 500） 如果WLS子系統(tǒng)發(fā)生錯(cuò)誤，則服務(wù)器處于不穩(wěn)定狀態(tài) ，需要重啟 內(nèi)存泄漏內(nèi)存泄漏 內(nèi)存泄漏： 最常見的引發(fā)Out-of-Memory錯(cuò)誤的原因 在Java中，內(nèi)存泄漏并不常發(fā)生（相對(duì)傳統(tǒng)語言） 內(nèi)存泄漏的原因是當(dāng)對(duì)象不再被需要時(shí)，沒有顯式聲明，進(jìn)而 沒有被垃圾回收處理 常見的場景有： 太大的緩存造成內(nèi)存泄漏 太多使用HTTP會(huì)話，導(dǎo)致內(nèi)存泄漏 對(duì)數(shù)據(jù)庫操作結(jié)束時(shí)，沒有正常關(guān)閉數(shù)據(jù)集及數(shù)據(jù)連接 動(dòng)態(tài)類加載問題 錯(cuò)誤日

19、志錯(cuò)誤日志 該日志文件通常包括如下類型的信息： 操作系統(tǒng)錯(cuò)誤消息 JVM版本 硬件和操作系統(tǒng)參數(shù) 系統(tǒng)環(huán)境變量 堆和垃圾回收匯總 線程匯總Runtime data area 主要包括五個(gè)部分：Heap (堆), Method Area(方法區(qū)域), Java Stack(java的棧), Program Counter(程序計(jì)數(shù)器), Native method stack(本地方法棧)。Heap 和Method Area是被所有線程的共享使用的；而Java stack, Program counter 和Native method stack是以線程為粒度的，每個(gè)線程獨(dú)自擁有。 Heap J

20、ava程序在運(yùn)行時(shí)創(chuàng)建的所有類實(shí)或數(shù)組都放在同一個(gè)堆中。而一個(gè)Java虛擬實(shí)例中只存在一個(gè)堆空間，因此所有線程都將共享這個(gè)堆。每一個(gè)java程序獨(dú)占一個(gè)JVM實(shí)例，因而每個(gè)java程序都有它自己的堆空間，它們不會(huì)彼此干擾。但是同一java程序的多個(gè)線程都共享著同一個(gè)堆空間，就得考慮多線程訪問對(duì)象（堆數(shù)據(jù)）的同步問題。 （這里可能出現(xiàn)的異常java.lang.OutOfMemoryError: Java heap space） Method area 在Java虛擬機(jī)中，被裝載的class的信息存儲(chǔ)在Method area的內(nèi)存中。當(dāng)虛擬機(jī)裝載某個(gè)類型時(shí)，它使用類裝載器定位相應(yīng)的class文件，

21、然后讀入這個(gè)class文件內(nèi)容并把它傳輸?shù)教摂M機(jī)中。緊接著虛擬機(jī)提取其中的類型信息，并將這些信息存儲(chǔ)到方法區(qū)。該類型中的類（靜態(tài)）變量同樣也存儲(chǔ)在方法區(qū)中。與Heap 一樣，method area是多線程共享的，因此要考慮多線程訪問的同步問題。比如，假設(shè)同時(shí)兩個(gè)線程都企圖訪問一個(gè)名為Lava的類，而這個(gè)類還沒有內(nèi)裝載入虛擬機(jī)，那么，這時(shí)應(yīng)該只有一個(gè)線程去裝載它，而另一個(gè)線程則只能等待。 （這里可能出現(xiàn)的異常java.lang.OutOfMemoryError: PermGen full）Java stack        Java s

22、tack以幀為單位保存線程的運(yùn)行狀態(tài)。虛擬機(jī)只會(huì)直接對(duì)Java stack執(zhí)行兩種操作：以幀為單位的壓?；虺鰲！Ｃ慨?dāng)線程調(diào)用一個(gè)方法的時(shí)候，就對(duì)當(dāng)前狀態(tài)作為一個(gè)幀保存到j(luò)ava stack中(壓棧)；當(dāng)一個(gè)方法調(diào)用返回時(shí)，從java stack彈出一個(gè)幀(出棧)。棧的大小是有一定的限制，這個(gè)可能出現(xiàn)StackOverFlow問題。 下面的程序可以說明這個(gè)問題。public class TestStackOverFlow public static void main(String args) Recursive r = new Recursive();r.doit(10000);class R

23、ecursive public int doit(int t) if (t <= 1) return 1;return t + doit(t - 1); Program counter 每個(gè)運(yùn)行中的Java程序，每一個(gè)線程都有它自己的PC寄存器，也是該線程啟動(dòng)時(shí)創(chuàng)建的。PC寄存器的內(nèi)容總是指向下一條將被執(zhí)行指令的餓&ldquo;地址&rdquo;，這里的&ldquo;地址&rdquo;可以是一個(gè)本地指針，也可以是在方法區(qū)中相對(duì)應(yīng)于該方法起始指令的偏移量。 Native method stack 對(duì)于一個(gè)運(yùn)行中的Java程序而言，它還能會(huì)用到一些跟

24、本地方法相關(guān)的數(shù)據(jù)區(qū)。當(dāng)某個(gè)線程調(diào)用一個(gè)本地方法時(shí)，它就進(jìn)入了一個(gè)全新的并且不再受虛擬機(jī)限制的世界。本地方法可以通過本地方法接口來訪問虛擬機(jī)的運(yùn)行時(shí)數(shù)據(jù)區(qū)，不止與此，它還可以做任何它想做的事情。比如，可以調(diào)用寄存器，或在操作系統(tǒng)中分配內(nèi)存等?？傊镜胤椒ň哂泻蚃VM相同的能力和權(quán)限。 (這里出現(xiàn)JVM無法控制的內(nèi)存溢出問題native heap OutOfMemory )舊系統(tǒng)2、服務(wù)器掛起問題描述在出現(xiàn)以下情況時(shí)懷疑服務(wù)器掛起：服務(wù)器不響應(yīng)新的請(qǐng)求。 請(qǐng)求超時(shí)。 請(qǐng)求處理的時(shí)間越來越長（其最終結(jié)果可能是掛起）。 通常，服務(wù)器掛起不會(huì)表現(xiàn)為服務(wù)器崩潰，但服務(wù)器掛起之后可能會(huì)崩潰。 資源瀕臨枯

25、竭：內(nèi)存、工作線程、數(shù)據(jù)庫連接池 故障排除請(qǐng)注意，并非下面所有任務(wù)都需要完成。有些問題僅通過執(zhí)行幾項(xiàng)任務(wù)就可以解決。 快速鏈接： l為什么發(fā)生此問題？ l服務(wù)器掛起的可能原因 l基本步驟 l已知的 WebLogic Server 問題 l收集 Thread Dump lThread Dump 分析 為什么發(fā)生此問題？服務(wù)器掛起有多種原因。一般而言，服務(wù)器掛起是因?yàn)槿鄙倌撤N資源。缺少資源會(huì)阻止服務(wù)器響應(yīng)服務(wù)請(qǐng)求。例如，由于故障（死鎖）或者大量請(qǐng)求的緣故，可能沒有任何可用的執(zhí)行線程來完成工作，所有執(zhí)行線程都被占用或忙于處理以前的請(qǐng)求。 引起引起Server Hang的原因的原因 工作線程太少 垃圾

26、回收占用時(shí)間太多 JVM代碼優(yōu)化問題 應(yīng)用程序死鎖 JDBC 死鎖 Remote JNDI lookups JSP 編譯 JSP 不正確的設(shè)置：PageCheckSeconds JVM bug 服務(wù)器掛起的可能原因 主題模式名稱鏈接RMI、RJVM 響應(yīng) 所有綁定線程等待 RJVM、RMI 響應(yīng)。EJB_RMI 服務(wù)器掛起EJB_RMI 服務(wù)器掛起應(yīng)用程序死鎖 線程鎖定資源 1，然后等待鎖定資源 2。另一個(gè)線程鎖定資源 2，然后等待鎖定資源 1。應(yīng)用程序死鎖導(dǎo)致服務(wù)器掛起待定線程全部被占用，沒有線程可用于新工作。線程占用導(dǎo)致服務(wù)器掛起待定垃圾回收花費(fèi)太多時(shí)間。垃圾回收導(dǎo)致服務(wù)器掛起待定serv

27、let 時(shí)間的 JSP 錯(cuò)誤設(shè)置，比如 PageCheckSeconds。JSP 導(dǎo)致服務(wù)器掛起待定死鎖造成 JDBC 掛起。JDBC 中的服務(wù)器掛起待定（代碼優(yōu)化）過程中的 JVM 掛起類似于服務(wù)器掛起。代碼優(yōu)化中服務(wù)器掛起待定在大量負(fù)載情況下 JSP 編譯造成服務(wù)器掛起。JSP 編譯導(dǎo)致服務(wù)器掛起待定SUN JVM 錯(cuò)誤，比如輕量型線程庫。Sun JVM 錯(cuò)誤導(dǎo)致服務(wù)器掛起待定返回頁首 基本步驟當(dāng)服務(wù)器掛起時(shí)，首先使用 java weblogic.Admin t3:/server:port PING 來 ping 該服務(wù)器。如果服務(wù)器能夠響應(yīng)此 ping，則可能是應(yīng)用程序正在掛起而不是服務(wù)

28、器自身。 確保服務(wù)器確實(shí)正在掛起，而不是在做垃圾回收。若要驗(yàn)證掛起，啟用 -verbosegc 重新啟動(dòng)服務(wù)器，然后將 stdout 和 stderr 重定向到一個(gè)文件中。當(dāng)服務(wù)器停止響應(yīng)時(shí)，可以判斷它是正在收集無用信息還是確實(shí)掛起。 WebLogic Server 使用“Default”線程隊(duì)列響應(yīng)客戶端服務(wù)請(qǐng)求。這些是在發(fā)生服務(wù)器掛起時(shí)應(yīng)當(dāng)檢查的線程。下面是其中一個(gè)線程在 Thread Dump 中的形式示例。Execute Thread 14 正在等待任務(wù)。該線程調(diào)用的最后方法是 Object.wait()。 "ExecuteThread: '14' for q

29、ueue: 'default'" daemon prio=5 tid=0x8b0ab30 nid=0x1f4 waiting on monitor 0x96af000.0x96afdc4atjava.lang.Object.wait(Native Method)atjava.lang.Object.wait(Object.java:420)atweblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:94)atweblogic.kernel.ExecuteThread.run(ExecuteThre

30、ad.java:118)確定“Default”ExecuteThread 隊(duì)列是否超載。利用控制臺(tái)確定“Default”隊(duì)列中的所有 ExecuteThreads 是否空閑。如果沒有一個(gè)空閑，則應(yīng)用程序可能需要一個(gè)更大的 ExecuteThread 數(shù)來配置。可以通過控制臺(tái)更改該值，并將其保存在 config.xml 文件中。 如果執(zhí)行隊(duì)列有空閑線程，則可能沒有分配足夠的 Socket Reader 線程。缺省情況下，WebLogic Server 實(shí)例在啟動(dòng)時(shí)創(chuàng)建三個(gè) Socket Reader 線程。如果群集系統(tǒng)在高峰期使用的 Socket Reader 線程超過三個(gè)，則增加 Socket

31、 Reader 線程的數(shù)量。 通常，Socket Reader 線程的數(shù)量應(yīng)當(dāng)較小。但是，如果 Weblogic Serve 充當(dāng)正在掛起的服務(wù)器實(shí)例的客戶端，則應(yīng)當(dāng)為每個(gè) Weblogic Serve 配置一個(gè)線程。 如果使用 JDBC 連接池，確保池中已經(jīng)配置的 JDBC 連接數(shù)量與同時(shí)請(qǐng)求（即執(zhí)行線程）的數(shù)量相等。 已知的 WebLogic 問題JDBC 產(chǎn)生死鎖問題的可能性存在。檢查在 weblogic.log 開頭找到的服務(wù)器的版本和 Service Pack 級(jí)別。然后對(duì)已經(jīng)應(yīng)用于服務(wù)器類路徑的所有臨時(shí)修補(bǔ)程序檢查以上版本和 Service Pack 行。修補(bǔ)程序?qū)⒅该饕呀?jīng)解決了什

32、么問題。 Thread Dump 分析 分析服務(wù)器掛起的最有用的工具是一系列 Thread Dump。Thread Dump 提供關(guān)于每個(gè)線程在特定時(shí)刻正在執(zhí)行什么操作的信息。一系列 Thread Dump（一般每隔 5 到 10 秒進(jìn)行三個(gè)或更多 Thread Dump）可以幫助分析每個(gè)線程從一個(gè) Thread Dump 到另一個(gè) Thread Dump 過程中的狀態(tài)變化或所缺少的變化。掛起服務(wù)器 Thread Dump 一般顯示線程狀態(tài)從第一個(gè) Thread Dump 到最后一個(gè) Thread Dump 中變化很小。 在 Thread Dump 中查看的內(nèi)容 所有請(qǐng)求都通過 ListenT

33、hread 進(jìn)入 WebLogic Server。如果 ListenThread 丟失，就無法接收任何工作，因此也無法完成任何工作。確認(rèn)在 Thread Dump 中存在 ListenThread。ListenThread 應(yīng)當(dāng)在 socketAccept 方法中。下面示例說明監(jiān)聽線程 (Listen Thread) 的形式。 "ListenThread.Default" prio=10 tid=0x00037888 nid=93 lwp_id=6888343 runnable 0x 1a81b000.0x1a81b530at .PlainSocketImpl.socket

34、Accept(Native Method)at.PlainSocketImpl.accept(PlainSocketImpl.java:353)- locked <0x26d9d490> (a .PlainSocketImpl)at.ServerSocket.implAccept(ServerSocket.java:439)at.ServerSocket.accept(ServerSocket.java:410)atweblogic.socket.WeblogicServerSocket.accept(WeblogicServerSocket.java:24)atweblogic.

35、t3.srvr.ListenThread.accept(ListenThread.java:713)atweblogic.t3.srvr.ListenThread.run(ListenThread.java:290) Socket Reader 線程接受來自監(jiān)聽線程隊(duì)列的傳入請(qǐng)求，并將該請(qǐng)求放入執(zhí)行線程隊(duì)列。如果 Thread Dump 中沒有 Socket Reader 線程，則在某個(gè)地方存在導(dǎo)致 Socket Reader 線程消失的錯(cuò)誤。應(yīng)當(dāng)始終保持至少有三個(gè) Socket Reader 線程。一個(gè) Socket Reader 線程一般用于輪詢功能，另外兩個(gè)用于處理請(qǐng)求。下面是一個(gè) Th

36、read Dump 示例中的 Socket Reader 線程。"ExecuteThread: '2' for queue: 'weblogic.socket.Muxer'" daemon prio=10 tid=0x00036128 nid=75 lwp_id=6888070 waiting for monitor entry 0x1b12f000.0x1b12f530atweblogic.socket.PosixSocketMcessSockets(PosixSocketMuxer.java:92)- waiting to

37、 lock <0x25c01198> (a java.lang.String)atweblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:32)atweblogic.kernel.ExecuteThread.execute(ExecuteThread.java:178)atweblogic.kernel.ExecuteThread.run(ExecuteThread.java:151) "ExecuteThread: '1' for queue: 'weblogic.

38、socket.Muxer'" daemon prio=10 tid=0x00035fc8 nid=74 lwp_id=6888067 runnable 0x1b1b0000.0x1b1b0530at weblogic.socket.PosixSocketMuxer.poll(Native Method)atweblogic.socket.PosixSocketMcessSockets(PosixSocketMuxer.java:99) - locked <0x25c01198> (a java.lang.String)atweblogic.sock

39、et.SocketReaderRequest.execute(SocketReaderRequest.java:32)atweblogic.kernel.ExecuteThread.execute(ExecuteThread.java:178)atweblogic.kernel.ExecuteThread.run(ExecuteThread.java:151) "ExecuteThread: '0' for queue: 'weblogic.socket.Muxer'" daemon prio=10 tid=0x00035e68 nid=73 lwp_id=6888066 waiting for monitor entry 0x1b231000.