WebLogic Server Hang產生的原因一般為：

系統內存不足

系統cpu忙

系統文件描述符數目不足

線程死鎖

JVM有GC方面的bug

對于一些特定的情況可以使用truss命令跟蹤系統調用來進行分析

系統內存不足

出現OutOfMemoryError或是觀察到內存吃緊

操作系統本身的剩余內存

通過top或是vmstat觀察

操作系統的swap區

Swap區太小可能導致編譯jsp時報“Not enough space”的錯

操作系統kernel參數中maxdsiz的大小

如果觀測到數據庫連接池里的連接泄漏，極可能是內存泄漏的先兆

系統內存不足

JVM的heap區大小

通過java命令行中的-Xms,-Xmx指定，建議最小值和最大值設成一樣

可以通過weblogic console上server/monitor/performance來觀察其使用情況

建議生產系統最少256M，一般情況下可以設置為系統剩余物理內存的80％

Heap size太大在一些jvm上會有問題

對于sun和hp的jvm，permanent size太小也會出OutOfMemoryError

在java命令行上加-XX:MaxPermSize=128m

系統內存不足

盡量減少內存消耗

Session中不要放大的數據，并盡量在不再需要的時候remove掉；如果可以調整session timeout到較小的值

避免在J2EE server端應用里邊調用awt/swing作圖

調整ejb的cache/pool設置

系統內存不足

內存泄漏

可以通過weblogic console來觀察jvm的heap memory使用情況來獲知是否有內存泄漏情況

采用第三方輔助工具來獲取更詳細信息

Jprobe/OptimizeIt

有可能是weblogic的bug，但絕大部分情況是由用戶的應用引起的

最常見的代碼問題是數據庫連接沒正常關閉

比較好的寫法是：

Connection conn = null;

Statement stmt = null;

ResultSet rset= null;

try

{

conn = getConnection()…

}

catch(SQLException sqle)

{

}

finally

{

try{rset.close();}catch(Exception e){}

try{stmt.close();}catch(Exception e){}

try{conn.close();}catch(Exception e){}

}

系統cpu忙

如果用戶訪問量很大，cpu占用很高(user態)并不是異常

如果是kernel態很多，需要OS廠商調整操作系統

采用top找到占用cpu很多的進程

如果是非weblogic進程，應該考慮將其移到另外的server上運行

如果是運行weblogic的java進程，通過做thread dump(詳細信息后邊會介紹到)來確認是那段代碼導致了這么高的cpu使用(也有可能是os/jvm本身不正常)

系統文件描述符數目不足

Log中有“too many open files”的錯誤

表示達到了系統對一個進程能同時打開的文件數的限制

ulimit ？Ca ？CH 可以查看當前限制

ulimit ？Cn number可以來更改當前環境的設置，建議至少設到4096

Solaris上可以通過/usr/proc/bin/pfiles pid來查看指定進程的限制和當前使用的file descriptor數目

Solaris上root用戶可以通過/usr/proc/bin/plimit -n soft,hard pid 來動態更改進程的文件描述符的限制

線程死鎖

對于原因不明的hang或是響應慢，最根本的方法就是獲取thread dump信息

對于windows系統，在運行java的窗口按Ctrl＋Break

對于unix系統，首先用ps找到運行weblogic的java進程的pid，然后執行kill ？C3 pid

JVM將負責將所有java進程的狀態、執行堆棧dump到其標準輸出

為了方便獲取thread dump信息，在weblogic啟動的時候，最好將其標準輸出重定向到一個文件

為了反映線程狀態的動態變化，需要接連多次做thread dump，每次間隔10-20s

線程死鎖

對于thread dump信息，主要關注的是線程的狀態和其執行堆棧

線程的狀態一般為三類

Runnable(R)：當前可以運行的線程

Waiting on monitor(CW)：線程主動wait

Waiting for monitor entry(MW)：線程等鎖

一般關注的都是第一和第三種狀態的線程

Cpu很忙則關注runnable的線程

Cpu閑則關注waiting for monitor entry的線程

一種典型的死鎖是由于在server端應用(比如servlet)中請求由同一weblogic實例serve的資源

解決辦法就是將該servlet放到另外的執行隊列里去執行

JVM有GC方面的bug

打開jvm的gc log

在java命令行上加上-verbose:gc

GC的log輸出在java進程的標準輸出里

在hp的jvm上，可以通過在java命令行上加

-Xverbosegc:file=gcfilename來將gc log寫到指定的文件

其輸出類似：

[GC 15639K->13700K(65280K), 0.0068439 secs]

調整jvm的內存設置和gc算法

升級jvm或是os patch

mit ？Cn number可以來更改當前環境的設置，建議至少設到4096

Solaris上可以通過/usr/proc/bin/pfiles pid來查看指定進程的限制和當前使用的file descriptor數目

Solaris上root用戶可以通過/usr/proc/bin/plimit -n soft,hard pid 來動態更改進程的文件描述符的限制

線程死鎖

對于原因不明的hang或是響應慢，最根本的方法就是獲取thread dump信息

對于windows系統，在運行java的窗口按Ctrl＋Break

對于unix系統，首先用ps找到運行weblogic的java進程的pid，然后執行kill ？C3 pid

JVM將負責將所有java進程的

總結

以上是生活随笔為你收集整理的weblogic占用java_weblogic内存占用过大调优的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。