WebLogicServerHang产生的原因一般为：
系统内存不足
系统cpu忙
系统文件描述符数目不足
线程死锁
JVM有GC方面的bug
对于一些特定的情况可以使用truss命令跟踪系统调用来进行分析
系统内存不足
出现OutOfMemoryError或是观察到内存吃紧
操作系统本身的剩余内存
通过top或是vmstat观察
操作系统的swap区
Swap区太小可能导致编译jsp时报“Notenoughspace”的错
操作系统kernel参数中maxdsiz的大小
如果观测到数据库连接池里的连接泄漏，极可能是内存泄漏的先兆
系统内存不足
JVM的heap区大小
通过java命令行中的-Xms,-Xmx指定，建议最小值和最大值设成一样
可以通过weblogicconsole上server/monitor/performance来观察其使用情况
建议生产系统最少256M，一般情况下可以设置为系统剩余物理内存的80％
Heapsize太大在一些jvm上会有问题
对于sun和hp的jvm，permanentsize太小也会出OutOfMemoryError
在java命令行上加-XX:MaxPermSize=128m
系统内存不足
尽量减少内存消耗
Session中不要放大的数据，并尽量在不再需要的时候remove掉；如果可以调整sessiontimeout到较小的值
避免在J2EEserver端应用里边调用awt/swing作图
调整ejb的cache/pool设置
系统文件描述符数目不足
Log中有“toomanyopenfiles”的错误
表示达到了系统对一个进程能同时打开的文件数的限制
ulimit？a？H可以查看当前限制
ulimit？nnumber可以来更改当前环境的设置，建议至少设到4096
Solaris上可以通过/usr/proc/bin/pfilespid来查看指定进程的限制和当前使用的filedescriptor数目
Solaris上root用户可以通过/usr/proc/bin/plimit-nsoft,hardpid来动态更改进程的文件描述符的限制
线程死锁
对于原因不明的hang或是响应慢，最根本的方法就是获取threaddump信息
对于windows系统，在运行java的窗口按Ctrl＋Break
对于unix系统，首先用ps找到运行weblogic的java进程的pid，然后执行kill？3pid
JVM将负责将所有java进程的状态、执行堆栈dump到其标准输出
为了方便获取threaddump信息，在weblogic启动的时候，最好将其标准输出重定向到一个文件
为了反映线程状态的动态变化，需要接连多次做threaddump，每次间隔10-20s
线程死锁
对于threaddump信息，主要关注的是线程的状态和其执行堆栈
线程的状态一般为三类
Runnable（R）：当前可以运行的线程
Waitingonmonitor（CW）：线程主动wait
Waitingformonitorentry（MW）：线程等锁
一般关注的都是第一和第三种状态的线程
Cpu很忙则关注runnable的线程
Cpu闲则关注waitingformonitorentry的线程
一种典型的死锁是由于在server端应用（比如servlet）中请求由同一weblogic实例serve的资源
解决办法就是将该servlet放到另外的执行队列里去执行
JVM有GC方面的bug
打开jvm的gclog
在java命令行上加上-verbose:gc
GC的log输出在java进程的标准输出里
在hp的jvm上，可以通过在java命令行上加
-Xverbosegc:file=gcfilename来将gclog写到指定的文件
其输出类似：
[GC15639K->13700K(65280K),0.0068439secs]
调整jvm的内存设置和gc算法
升级jvm或是ospatch
mit？nnumber可以来更改当前环境的设置，建议至少设到4096
Solaris上可以通过/usr/proc/bin/pfilespid来查看指定进程的限制和当前使用的filedescriptor数目
Solaris上root用户可以通过/usr/proc/bin/plimit-nsoft,hardpid来动态更改进程的文件描述符的限制
线程死锁
对于原因不明的hang或是响应慢，最根本的方法就是获取threaddump信息
对于windows系统，在运行java的窗口按Ctrl＋Break
对于unix系统，首先用ps找到运行weblogic的java进程的pid，然后执行kill？3pid
JVM将负责将所有java进程的
