set JAVA_VM=-client
set MEM_ARGS=-Xms768m -Xmx1024m -XX:MaxPermSize=256m
set JAVA_OPTIONS=%JAVA_OPTIONS% -Xverify:none
goto continue
:sun_prod_mode
set JAVA_VM=-server
set MEM_ARGS=-Xms768m -Xmx1024m -XX:MaxPermSize=256m
goto continue
一般在文件中,有二處這樣的代碼存在,一個是使用weblogic自帶的jrockit JDK,二是使用sun的JDK.這里是以sun JDK為例.
通過修過二處的=-Xms768m -Xmx1024m 可以達到修改JVM目的所在.修改后保存重啟即可.
MaxPermSize=256m的介紹:
一般情況下，在分析服務器掛起問題、原因不明的超時或其它引起混亂的不明行為過程中會發現丟失線程問題。在缺省的 WebLogic Server 配置中，Default 隊列應當有 15 個執行線程（0 到 14）。下面是一個 Thread Dump 摘錄，顯示Default隊列的 ExecuteThread 13、8、6、5 和 3 丟失。在指示線程已經終結的服務器日志記錄中沒有任何異常、堆棧跟蹤或通知。
線程在拋出未捕獲的異?；蝈e誤時可能會消失。這種情況會導致服務器掛起，因為其它線程可能在永遠不會調用 notify() 的監視器上等待（即，要調用 notify() 的線程已經消失了）。
如果設置 MaxPermSize 能夠糾正此問題，有一種可能的解釋是 OutOfMemoryException 在某些時候因為沒有足夠的 MaxPermSize 設置而被拋出。如果線程正在記錄此異常，同時又發生另一個異常（例如，另一個 OutOfMemoryException），則線程將不發出任何通知就結束。一直等待該線程調用 notify() 的其它線程將掛起。
排除丟失執行線程故障的檢查清單
進行 Thread Dump 并判斷是否有任何線程丟失。您應當參考 config.xml 文件以確定在 Thread Dump 中可以看到多少執行線程。如果沒有丟失任何 WebLogic 線程，那么您需要判斷應用程序創建的線程是否丟失。
在一些情況下，此問題通過在服務器啟動時設置 -XX:MaxPermSize JVM 選項得到了解決。MaxPermSize 可以設置為最大堆分配 (mx) 的一半。嘗試設置 .XX:MaxPermSize=128m，并不斷增大其值直至問題得到解決。
如果這種方法沒有起到幫助作用，那么問題可能是應用程序的異常處理功能故障引起的，需要利用調試器進行代碼審核或分析才能發現問題根源。有關詳細信息，請參閱下列外部資源。