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

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

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

3、rve后進入，監(jiān)視-健康狀況）;留意JVM 堆中當前可用的內(nèi)存量。不同的JVM，所顯示的內(nèi)容可能不一樣，以下為sun的：D、 各個server線程狀態(tài)（域-環(huán)境-服務(wù)器，點擊具體的serve后進入，監(jiān)視-線程）；一般來說，空閑線程要多；健康狀況為ok如下圖health狀態(tài)為：Warning，這個是有線程阻塞的。阻塞線程的內(nèi)容為：#<2011-8-13 上午02時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ù)器，點擊具體的serve后進入，監(jiān)視-JDBC）；活動連接數(shù)合理。F、 程序EJB/Web Module（域-部署）；狀態(tài)為活動，健康狀況為ok。其目標關(guān)聯(lián)正確G、 JMS（域-服務(wù)-消息傳送-JMS服務(wù)器）；健康狀態(tài)為ok。4、在控制臺生成dump；生成Dump Thread Stacks內(nèi)容；查找queryList等關(guān)鍵字符，即可快速定位問題代碼。5、如果控制臺打不開或無法進入，就要

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

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

7、TTP訪問日志 在WebLogic中可以對用HTTP，HTTPS協(xié)議訪問的服務(wù)器上的文件都做記錄，該LOG文件默認的名字為Access.log,內(nèi)容如下，該文件具體記錄在某個時間，某個IP地址的客戶端訪問了服務(wù)器上的那個文件。 - - 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屬性頁中進行設(shè)置。 DOMAIN運行日志 記錄一個DOMIAN的運行情況，一個DOMAIN中的各個WebLogic SERVER可以把它們的一些運行信息（比如：很嚴重的錯誤）發(fā)送給一個DOMAIN的ADMINISTRATOR SERVER上，ADMINISTRATOR SERVER把這些信息些到DOMAIN 日志中。默認名為：domain_name.log 。一般就看這個最多。3、通過控制臺查看或修改系統(tǒng)日志路徑登錄weblogic后臺左側(cè)菜單：Environment->Servers右側(cè)菜單：AdminServer(admin)->logging只找到examples

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

10、h%_%mm%5、日志的處理：查看日志中輸出的具體內(nèi)容，再進行處理。如：BEA-下面是一個線程阻塞的一個信息#<2011-8-13 上午03時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)用問題的工具，每一個Java虛擬機都有及時生成顯示所有線程在某一點狀態(tài)的thread-dump的能力。雖然各個Java虛擬機thread dump打印輸出格式上略微有一些不同，但是Thread dumps出來的信息包含線程；線程的運行狀態(tài)、標識和調(diào)用的堆棧；調(diào)用的堆棧包含完整的類名，所執(zhí)行的方法，如果可能的話還有源代碼的行數(shù)。Thread Dump特點：· 能在各種操作系統(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 進行 Thread Dump 的方法取決于安裝掛起服務(wù)器實例的操作系統(tǒng)。有關(guān)在不同的操作系統(tǒng)上進行 Thread Dump 的信息，Solaris OS<ctrl>- (Control-Backslash) kill -QUIT <pid>LinuxLinux 操作系統(tǒng)查看線程的方式不同于其它操作系統(tǒng)。該操作系統(tǒng)將每個線程視為一個進程。若要在 Linux 上進行 Thread Du

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

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

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

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

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

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

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

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

22、tack以幀為單位保存線程的運行狀態(tài)。虛擬機只會直接對Java stack執(zhí)行兩種操作：以幀為單位的壓?；虺鰲！Ｃ慨斁€程調(diào)用一個方法的時候，就對當前狀態(tài)作為一個幀保存到j(luò)ava stack中(壓棧)；當一個方法調(diào)用返回時，從java stack彈出一個幀(出棧)。棧的大小是有一定的限制，這個可能出現(xiàn)StackOverFlow問題。 下面的程序可以說明這個問題。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 每個運行中的Java程序，每一個線程都有它自己的PC寄存器，也是該線程啟動時創(chuàng)建的。PC寄存器的內(nèi)容總是指向下一條將被執(zhí)行指令的餓&ldquo;地址&rdquo;，這里的&ldquo;地址&rdquo;可以是一個本地指針，也可以是在方法區(qū)中相對應(yīng)于該方法起始指令的偏移量。 Native method stack 對于一個運行中的Java程序而言，它還能會用到一些跟

24、本地方法相關(guān)的數(shù)據(jù)區(qū)。當某個線程調(diào)用一個本地方法時，它就進入了一個全新的并且不再受虛擬機限制的世界。本地方法可以通過本地方法接口來訪問虛擬機的運行時數(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)以下情況時懷疑服務(wù)器掛起：服務(wù)器不響應(yīng)新的請求。 請求超時。 請求處理的時間越來越長（其最終結(jié)果可能是掛起）。 通常，服務(wù)器掛起不會表現(xiàn)為服務(wù)器崩潰，但服務(wù)器掛起之后可能會崩潰。 資源瀕臨枯

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

26、回收占用時間太多 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。另一個線程鎖定資源 2，然后等待鎖定資源 1。應(yīng)用程序死鎖導(dǎo)致服務(wù)器掛起待定線程全部被占用，沒有線程可用于新工作。線程占用導(dǎo)致服務(wù)器掛起待定垃圾回收花費太多時間。垃圾回收導(dǎo)致服務(wù)器掛起待定serv

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

28、器自身。 確保服務(wù)器確實正在掛起，而不是在做垃圾回收。若要驗證掛起，啟用 -verbosegc 重新啟動服務(wù)器，然后將 stdout 和 stderr 重定向到一個文件中。當服務(wù)器停止響應(yīng)時，可以判斷它是正在收集無用信息還是確實掛起。 WebLogic Server 使用“Default”線程隊列響應(yīng)客戶端服務(wù)請求。這些是在發(fā)生服務(wù)器掛起時應(yīng)當檢查的線程。下面是其中一個線程在 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 隊列是否超載。利用控制臺確定“Default”隊列中的所有 ExecuteThreads 是否空閑。如果沒有一個空閑，則應(yīng)用程序可能需要一個更大的 ExecuteThread 數(shù)來配置?？梢酝ㄟ^控制臺更改該值，并將其保存在 config.xml 文件中。 如果執(zhí)行隊列有空閑線程，則可能沒有分配足夠的 Socket Reader 線程。缺省情況下，WebLogic Server 實例在啟動時創(chuàng)建三個 Socket Reader 線程。如果群集系統(tǒng)在高峰期使用的 Socket Reader 線程超過三個，則增加 Socket

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

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

33、hread 進入 WebLogic Server。如果 ListenThread 丟失，就無法接收任何工作，因此也無法完成任何工作。確認在 Thread Dump 中存在 ListenThread。ListenThread 應(yī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)聽線程隊列的傳入請求，并將該請求放入執(zhí)行線程隊列。如果 Thread Dump 中沒有 Socket Reader 線程，則在某個地方存在導(dǎo)致 Socket Reader 線程消失的錯誤。應(yīng)當始終保持至少有三個 Socket Reader 線程。一個 Socket Reader 線程一般用于輪詢功能，另外兩個用于處理請求。下面是一個 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.