Java 虚拟机默认的行为就已经足够满足大多数情况的需求了。不过如果遇到了需要与类加载器进行交互的情况，而对类加载器的机制又不是很了解的话，就很容易花大量的时间去调试 ClassNotFoundException 和 NoClassDefFoundError 等异常。本文将详细介绍 Java 的类加载器，帮助读者深刻理解 Java 语言中的这个重要概念。

下面我就介绍几种常见的简单错误，希望对于现场人员能有所帮助：

应用无法访问

下面是一张常见的由IBM HTTP SERVER（IHS）转发到后端AppCluster上的拓扑结构：

应用无法访问，问题可以出现在HTTP Server上，或者App Server上，更可能发生在数据库上，所以第一步需要缩小范围，确定问题发生的点。

我在这里假设IHS的应用地址为http://192.168.1.51/yingyong

DMGR的访问地址是http://192.168.1.51:9060/admin

APP SERVER的应用地址为http://192.168.2.50:9080/yingyong和 http://192.168.2.51:9080/yingyong

1. 找不到服务器或404错误

访问http://192.168.1.51，确定IHS是否正常，如果页面无法显示，那么去“服务”中尝试重启“IBM HTTP SERVER V6.x”。服务启动失败的话，“服务”只会提示你一句服务无法启动或者启动后又因为致命错误停止。所以你要到IBM\HTTPServer\bin目录下运行apache –k start或者httpd –k start，失败的话会有详细信息供参考。一般是端口被占用或者config目录下的httpd.conf格式出错（它会提示你出错的行数）。

如果IHS访问完好，那么尝试分别访问http://192.168.2.50（51）:9080/yingyong，如果访问正常，那么是IHS转发失败。

可以在管理控制台http://192.168.1.51:9060/admin中的“服务器”——“Web服务器”中勾选相应的webserver，“生成插件”并且“传播插件”。

很多IHS转发失败是因为应用发布过程中没有选则发布到webserver上，或在传播插件的过程中，由于目录访问控制等原因传播失败。你可以在“应用程序”中找到自己的应用，点击“管理模块”，确定是否正确的发布到app server上和webserver上了，注意首先在第一个框中选择要发布到集群和服务器，然后勾选模块前的勾，最后一定要点“应用”，而不是直接确定。

转发失败的原因很多，不过最快的解决方法是手动复制文件。生成插件后控制台会提示文件生成的位置，直接拿到然后复制到传播插件失败的位置就可以了。

不过我也遇到过很蹊跷的情况，明明部署正确，传播正确，确依旧无法访问。这时候你要看一下生成的plugin-cfg.xml文件

       是否有你的应用url那行存在，不存在的话手动添加一下即可，不过记得下次生成插件后注意再修改。

       最后要确定app server是否已经启动，是否遇到错误退出了，这点在下面一部分细说。

2. 505 Internal Error

505内部错误有三种情况，一是程序出错，不是本文讨论的重点。二是AppServer或应用程序没有正常启动，三是数据库连接失败。

AppServer是否运行可以通过访问管理控制台，查看JAVA进程确定。在profiles\AppSrv01\logs\server1目录下会有一个pid文件，此文件记录的PID号即为进程号。Windows下在“任务管理器”点击“查看”—“选择列”，勾选PID-进程标识符即可显示。Unix/linux下运行ps –ef | grep PID或者ps –ef | grep java，查看该app的进程和所有的JAVA进程。注意：在安装DM profile的节点上，一般至少有DM、Node agent、app server三个java进程，注意区分。

确定服务器没有运行或者想重启时，在profiles\AppSrv01\bin下运行startServer.sh(bat）即可启动服务器，观察启动状况，直到出现“为电子商务开放服务器 server1”，即为启动成功。如果失败，那就要打开logs下的SystemOut.log，查看最新的日志，查找error信息。

一般启动失败无外乎端口冲突、权限不够。

端口冲突

端口出错在SystemOut.log中的信息如下：

这时你可以用netstat –an 命令查看监听端口信息，然后用tcpview或者icesword等工具查看占用端口的进程，linux/unix下可以用netstat –an | grep LISTEN（或端口号）直接查看，然后使用lsof -i :端口号或者rmsock来查看占用端口的进程。

这时候你也许才恍然想起某个不经意的操作将websphere的端口占用了，怎么办？如果要WebSphere作出让步，那么可以修改profile_path\config\cells\cell_name\nodes\node_name目录中serverindex.xml文件：

看到端口号了么？不过要注意WC_adminhost、WC_defaulthost、WC_adminhost_secure、WC_defaulthost_secure，也就是常用的管理端口、应用访问端口和它们各自的SSL端口，被修改后需要到profile_path\config\cells\cell_name再修改virtualhosts.xml文件中的相应端口（添加亦可），否则出现虚拟主机未定义的错误可别怪我没提醒。（我遇到过很多说用IHS可以访问，但是直接访问端口出错的情况，原因就是没有添加相应的虚拟主机，在管理控制台——虚拟主机——default host里添加改动后的端口就可以了）。

权限不足

权限不足一般发生在Unix/Linux下，比较常见的是安装websphere时新建了一个单独的用户和组，但是开发阶段权限管理不严导致开发人员也有root权限，启停没有su到was用户，等到权限回收之后发现无法启动服务了。这时候只要用root权限chown username/groupname 整个安装 目录即可。

还有一种情况是修改的端口<1024，在Unix/Linux下只能用root来起了。

其它情况

还要注意文件系统的情况，见过几次access.log和dump文件把文件系统撑满的。

应用更新失败

应用更新了，修改的文件直接上传到目录，重启应用程序，测试正常。等等！为何重启app server或者集群下重启dm后又变回修改前了呢？

这应该是dm的同步机制在捣鬼，你有没有注意到profiles\AppSrv01\config\cells\cell_name\applications目录下也有你的程序，打开可以看到并不是程序所有的内容都在此，而是web.xml和WEB-INF等重要内容。所以如果你更新的文件在config目录下也存在，那么你需要这里也更新一份。集群环境下还要注意profiles\Dmgr的config目录下还有一份等着你呢。

3. 确定数据库无故障

这个很简单，只要用sqlplus连接数据库正常且能查询即可。

4. 日志文件很重要

日志文件是排查的依赖。我见过不少项目，因为处于试运行修改阶段，log4j中输出日志信息极多，每条sql语句都丝毫不差的打出来，导致1m大小的SystemOut.log文件十几分钟就写满，10个SystemOut.log存档也顶不过几小时的日志量（单个文件1～2M，总共10～20个存档是一般设置），等我赶到时案发现场已经荡然无存。（这种情况一般是重启能暂时解决问题，但是故障原因没有找到）

所以即时保存当时日志是很重要的，logs\server1下的SystemOut.log、SystemErr.log一定要保存一份，并记下故障发生的时间。

WebSphere不像Weblogic，可以在console窗口后一直看到运行的日志，在unix/linux下，你可以用tail –f SystemOut.log来达到这个效果，windows下也有一个tail工具，后跟文件名运行就可以了。

结束语

暂时能想到的简单排错就这些，这些都比较容易被开发人员遇到，所以还是很有必要了解一下的。

现象描述：

Weblogic启动后，10到30分钟就会hang住，应用和管理控制台都无法访问。强制kill -9 pid后端口无法释放，使用rmsock 命令查看端口显示Wait for exiting processes to be cleaned up before removing the socket。

分析及处理过程

1. 用ps –ef | grep java找到weblogic进程，每隔三分种执行kill -3 pid，在domain目录下生成javacore文件

2. 分析weblogic日志，发现如下内容

<Aug 21, 2009 4:33:37 AM CDT> <Error> <WebLogicServer> <BEA-000337> <[STUCK] ExecuteThread: ‘1′ for queue: ‘weblogic.kernel.Default (self-tuning)’ has been busy for “620″ seconds working on the request

“weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl@20de20de”, which is more than the configured time (StuckThreadMaxTime) of “600″ seconds. Stack trace:

java.net.SocketOutputStream.socketWrite0(Native Method)

java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:103)

……

<Aug 21, 2009 4:34:37 AM CDT> <Error> <WebLogicServer> <BEA-000337> <[STUCK] ExecuteThread: ‘1′ for queue: ‘weblogic.kernel.Default (self-tuning)’ has been busy for “680″ seconds working on the request

“weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl@20de20de”, which is more than the configured time (StuckThreadMaxTime) of “600″ seconds. Stack trace:

java.net.SocketOutputStream.socketWrite0(Native Method)

java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:103)

……

3. 用IBM Thread and Monitor Dump Analyzer for java分析刚才生成的thread dump，找到如下两个线程信息：

3XMTHREADINFO “[ACTIVE] ExecuteThread: ‘5′ for queue: ‘weblogic.kernel.Default (self-tuning)’” TID:0×39CBED00, j9thread_t:0×3751C83C, state:R, prio=5

3XMTHREADINFO1 (native thread ID:0xCE1DB, native priority:0×5, native policy:UNKNOWN)

4XESTACKTRACE at java/net/PlainSocketImpl.socketClose0(Native Method)

4XESTACKTRACE at java/net/PlainSocketImpl.socketPreClose(PlainSocketImpl.java:706)

4XESTACKTRACE at java/net/PlainSocketImpl.close(PlainSocketImpl.java:540)

4XESTACKTRACE at java/net/SocksSocketImpl.close(SocksSocketImpl.java:1041)

4XESTACKTRACE at java/net/Socket.close(Socket.java:1343)

4XESTACKTRACE at weblogic/socket/SocketMuxer.closeSocket(SocketMuxer.java:475)

4XESTACKTRACE at weblogic/socket/SocketMuxer.cancelIo(SocketMuxer.java:813)

4XESTACKTRACE at weblogic/socket/SocketMuxer$TimerListenerImpl.timerExpired(SocketMuxer.java:1021(Compiled Code))

4XESTACKTRACE at weblogic/timers/internal/TimerImpl.run(TimerImpl.java:273(Compiled Code))

4XESTACKTRACE at weblogic/work/SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516(Compiled Code))

4XESTACKTRACE at weblogic/work/ExecuteThread.execute(ExecuteThread.java:201(Compiled Code))

4XESTACKTRACE at weblogic/work/ExecuteThread.run(ExecuteThread.java:173)

3XMTHREADINFO “ExecuteThread: ‘7′ for queue: ‘weblogic.socket.Muxer’” TID:0×35381D00, j9thread_t:0×35385864, state:R, prio=5

3XMTHREADINFO1 (native thread ID:0xB916F, native priority:0×5, native policy:UNKNOWN)

4XESTACKTRACE at weblogic/socket/PosixSocketMuxer.poll(Native Method)

4XESTACKTRACE at weblogic/socket/PosixSocketMuxer.processSockets(PosixSocketMuxer.java:102(Compiled Code))

4XESTACKTRACE at weblogic/socket/SocketReaderRequest.run(SocketReaderRequest.java:29)

4XESTACKTRACE at weblogic/socket/SocketReaderRequest.execute(SocketReaderRequest.java:42)

4XESTACKTRACE at weblogic/kernel/ExecuteThread.execute(ExecuteThread.java:145)

4XESTACKTRACE at weblogic/kernel/ExecuteThread.run(ExecuteThread.java:117)

4. 执行线程只有这两个是running状态，一个做CLOSE()，一个做POLL()。别的都是blocked或者wait状态。

5. 经过metalink查询以及和800支持人员确认，这是Weblogic在AIX的JVM上由来已久的bug，从8.1.4就开始在不同版本间出现。原因是IBM的JVM底层socket实现和weblogic配合问题，需要打patch CR370915_1030GA.jar解决。

操作过程

1．在weblogic的启动脚本中，找到CLASSPATH一行

2．在CLASSPATH变量的第一位添加补丁jar包
Eg: CLASSPATH=”${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}”
—>
CLASSPATH=/路径/CR370915_1030GA.jar:”${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}”

3．以上操作仅对这个domain起作用，为了对所有domain起作用，可以添加到common/bin/的目录中的commEnv.sh文件中WEBLOGIC_CLASSPATH=最前面

总结

这个bug在weblgoic和IBM的JVM相组合的平台上出现较为普遍，如果出现相关日志信息，基本可以断定需要打CR370915补丁。

更新：我这里的补丁仅仅 for weblogic 10.3.0.0，其它版本的可以自行用Smart Update下载

Patches for WLS 8.x can be found in My Oracle Support. Open the Patches & Updates tab. Search for patch ID 8173442 for the patches for WLS 8.1mp3, 8.1mp4, and 8.1mp5. Search for patch ID 8179792 for the patch for WLS 8.1mp6.

Patches for WLS 9.x and higher can be downloaded from Smart Update using these patch IDs and passcodes:

——————————————
PATCH REPOSITORY INFORMATION
——————————————
WLS Version | Patch ID |  Passcode
————+———-+—————-
9.2      |  T4DV    |  7C7PYV9B
9.2mp1   |  HZHQ    |  PTUYCCSI
9.2mp2   |  WJD2    |  GU1CW2AB
9.2mp3   |  GNLT    |  8J9L6Q4Y
10.0     |  PMAJ    |  9UQ69LLT
10.0mp1  |  ITVL    |  K8RBHQQ2
10.3     |  9YT5    |  I1DB5QSV

如果生产机无法联网，可以

1. You can apply the patch to the offline system manually by extracting the actual patch and adding it to the classpath on the offline system:Extract the actual patch jar file. If you downloaded the patch using SmartUpdate, it will be in the form <patch_id>.jar (for example: E5W8.jar). Inside this jar file is the actual patch jar file, which will be of the form CR326566_92mp3.jar. Extract the latter file for the following steps.
2. Add the extracted jar file as the first element of the classpath of the Admin server as well as the managed servers in the domain.
3. If you are starting servers using the WebLogic startup script, update the classpath in the startup script like this:set CLASSPATH=<PATCH_DIR>\jars\CR326566_92mp3.jar;%CLASSPATH% (Windows)CLASSPATH=<PATCH_DIR>/jars/CR326566_92mp3.jar:$CLASSPATH (UNIX)where PATCH_DIR is the directory on your local machine where you extracted/saved the patch file.
4. Similarly, if you are starting servers using Node Manager, add the patch jar to the beginning of the Class Path argument in the Server Start tab for the server(s).

我一般用第二种，对于单个补丁快捷方便，SmartUpdate可以单独安装，但是会让你选择应用到哪个BEA的主目录，不同的版本和平台能下的补丁不一样。在Windows平台上当然没有AIX的BEA版本，不过只要自己建个目录，然后拷贝一份register.xml进去就可以了。

赶到现场后，查看平台版本为Webshpere6.0.2.29，操作系统为Windows 2003企业版sp2，于是首先分析systemout.log，发现有如下报错：

= com.ibm.websphere.ce.j2c.ConnectionWaitTimeoutException Max connections reached 869

Exception = com.ibm.websphere.ce.j2c.ConnectionWaitTimeoutException

Source = Max connections reached

probeid = 869

同时也发现有“Caused by: java.io.IOException: Async IO operation failed, reason: RC: 10053 您的主机中的软件放弃了一个已建立的连接。”

很明显是连接池无法分配一个新连接给请求，wait时间过长达到WaitTimeout时间，第一反应是数据库连接池大小开的不够，于是设成初始50，最大150，120S空闲则自动释放连接。

但是调整参数后没有改善，过了不到10分钟应用依旧变慢。再次查看System.out和FFDC里的错误信息，发现有许多关于IO的报错：

com.ibm.ws.webcontainer.channel.WCCByteBufferInputStream 102

Exception = java.net.SocketTimeoutException

Source = com.ibm.ws.webcontainer.channel.WCCByteBufferInputStream

probeid = 102

stack Dump = java.net.SocketTimeoutException: Async operation timed out

java.io.IOException com.ibm.ws.webcontainer.servlet.RequestUtils.parsePostData 398

Exception = java.io.IOException

Source = com.ibm.ws.webcontainer.servlet.RequestUtils.parsePostData

probeid = 398

Stack Dump = java.io.IOException: Async IO operation failed, reason: RC: 55 指定的网络资源或设备不再可用。probeid = 1184

事后才知道其实数据库和中间件之间的问题，但是一来没有报连接池大小不够的错，二来此时管理控制台也几乎无法使用，又结合此应用在操作中会上传许多文件并进行校验，怀疑是服务器的I/O瓶颈导致应用变慢。

        于是在服务器上开启性能工具，添加%Disk time、%Disk Write、%Disk Read、Disk Queue Length、Fage Fault等计数器。发现%Disk Time平均维持在20~70之间，瞬时的Disk Time会达到90多，而且Disk Read值很小，基本是Disk Write。

继续观察了一段时间，发现当磁盘读写下来后，应用还是很慢，于是分析内存回收情况，查看是否有内存泄漏发生。

用IBM Monitoring and Diagnostic Tools for Java™ – Garbage Collection and Memory Visualizer分析发现 Mean interval between collections只有0.46分钟，且内存使用量才250多M就开始GC，而内存参数设置为760~1260M，于是分析内存中的碎片太多，导致GC频繁，使服务的响应速度变慢。同时分析软件得出The mean heap unusable due to fragmentation is estimated at 34.685%，问了应用他们申请内存对象一般是短期的，于是更改GC Policy为Gencon（分代并发），再观察GC日志发现每次回收间隔都较长，而且是young区的回收，Global collections间隔为23分钟。

可惜做了如此的性能优化，情况一点都未改善，在控制台的性能实时检测中可以看到JDBC连接有40~60个繁忙状态，当时无法确定这是否正常，是否是确实需要用到如此多连接。后来应用开发的检测数据库，发现很多active的连接时间长达5到10分钟，内容为一查询语句。原来应用是在Hibernat下开发的，查询语句被它加了自己的函数，导致原先建的索引无法起作用（应用建立索引的时候犯了低级错误），后来重新建立索引后，查询很快完成，连接池繁忙数量降低到0~5，应用恢复正常。原来是数据库的查询时间过长，导致线程都在等待数据库的返回信息，100个线程很快被用完，无法响应新的服务，因为数据库连接池资源已经开大，所以没有这方面的报错。

回顾这一周的排错过程，走了很大的弯路，当时因为经验欠缺没有想到做thread dump，如果做了thread dump的话，应该很容易看到大量的线程在等待数据库的返回，从而定位到数据库问题。

从中我们也看到，最终的问题也许很低级，但是排查的过程会很复杂，因为中间件问题牵扯到主机、网络、数据库、应用等各方面。不过得到的经验就是，在应用响应慢的时候，应该做个thread dump观察线程运行情况，而并非要等到hang住，cpu 100%，OutOfMemory的时候才想起分析javacore。

Related posts:

• Java 类加载器的又一篇文章
• Java性能优化参考资料
• 软硬兼施 优化 WebSphere Application Server
• Linux 性能监控
• Websphere系列介绍

Problem Description

An inadvertent deadlock in the application code can cause a server to hang. For example, a situation in which thread1 is waiting for resource1 and is holding a lock on resource2, while thread2 needs resource2 and is holding the lock on resource1. Neither thread can progress.

Problem Troubleshooting

This Application Deadlock pattern should be used only after doing all the steps in the Generic Server Hang pattern. One indicator that this is an application deadlock problem is that thread dumps will show the threads are in the application methods. Several thread dumps taken a few seconds apart will show that the threads are not progressing. Troubleshooting this problem will involve reviewing the application code. There exists a thread analyzer tool at BEA dev2dev which has proven useful in analysis of the thread dumps.

Quick Links

• Why does the problem occur?
• Known WebLogic Server Issues
• External Resources

Why does the problem occur?

Fundamentaly, this problem happens because the design and implementation of the application has introduced the possibility of deadlocks. These types of problems may only show up under heavy load. Therefore, these applications often pass through QA testing and become problems in production.

Coding problems to look for:

• Unnecessary use of synchronized java classes, e.g., using Hashtable (synchronized) versus the use of HashMap(unsynchronized)
• Application has a synchronized method that contains synchronized object method calls. See example below.

  import java.util.Vector;   <– Vector is a synchronized java class
  Public class Employee {
             Vector names = new Vector();
              Employees () {
                     Object object = new Object();
                      synchronized (object) {
                              names.add("al");
                              names.add("Saganich");
                       }
              }
              synchronized String getName (int index) {
                        String name = (String) names.elementAt(index);
                         return name;
              }

• Using synchronization around long running complex code.
• Threads are waiting on resources that will never become available.

Application Design

• The application uses up all of the configured number of threads. This can happen when an executing thread reaches a point where it must wait for work done by another thread to complete. The timing may be that the waited for method which this thread is trying to enter is long running. Eventually, all the threads must reach this long running method. After running awhile, the application will find that the threads will be lined up waiting for this long running method. No new work can be introduced because the allocated number of threads is all used up. See example below.

  import java…..;
  import java…..;
  public class myAppMethods {
            public String getName(String name) {
                       String lastname =  getLastName(name);
                       return lastname;
            }
            public synchronized String getLastName (String name) {
                       do a DB Lookup    <———— takes mucho time to get a last name
                        return lastname;
           }

  If the database if very slow, the server can appear to be hung because the threads will line up trying to get access to the database and all the available threads could eventually be used up.

• The application running inside a WebLogic Server invokes a service on another WebLogic instance on a remote machine. The remote service invoked on the remote machine makes a call back to the first server. This sets up the opportunity for a deadlock on the first server especially under heavy load. The first server has an execution thread that is tied up waiting for an inbound response. This inbound response will require a thread from the same execute pool as the thread that is waiting to receive the response.

  If the first server is faster than the remote server, eventually all the threads in the execute pool will be exhausted by the server making outbound requests with fewer threads available for processing inbound responses. As the load grows, the number of outgoing requests that cannot complete their work grows while they wait for an inbound response to complete. Below is an example of a thread in the waitForDataResponseImpl.java method of.

  "ExecuteThread: ‘52′ for queue: ‘default’" daemon prio=5 tid=0×4b3e40b0 nid=0×1170 waiting on monitor [0x4c74f000..0x4c74fdbc] 
  at java.lang.Object.wait(Native Method)
  at 
  weblogic.rjvm.ResponseImpl.waitForData(ResponseImpl.java:72)

Top of Page

Known WebLogic Server Issues

WebLogic Server cannot detect deadlocked threads. Some JVM’s are able to do so. See External Resources. There is a tool available for thread analysis as well as good information about thread dumps on BEA dev2dev.

Top of Page

External Resources

If you suspect a deadlock, it is helpful to go to the site of the JVM vendor to learn if there are clues provided for you in their thread dumps. If you are using JDK 1.3.1 you can add - XX:+JavaMonitorInStack Trace to show locking more explicitly/builtin. Here is an example of an HP JVM thread dump in which it is clearly marked that the threads’ state are waiting on monitor, and the monitor is identified. See example below.

"msg 0-941667944865" (TID:0×7b1a5ba0, sys_thread_t:0×2a4290,
  state:Waiting on Monitor,
  thread_t: t@108, stack_base:0×7a76e000, stack_size:0×20000,
pc: 0xc01ea178, monitor = 0×25334) prio=8
  MsgThread.rest(Compiled Code)
  MsgThread.run(Compiled Code)
"msg 3-941667944865" (TID:0×7b1a5a80, sys_thread_t:0×263278,
  state:Waiting on Monitor,
  thread_t: t@105, stack_base:0×7a95d000, stack_size:0×20000,
pc: 0xc01ea178, monitor = 0×25334) prio=8
  MsgThread.rest(Compiled Code)
  MsgThread.run(Compiled Code)
"msg 5-941667944864" (TID:0×7b1a5f08, sys_thread_t:0×2c42d8,
  state:Waiting on Monitor,
  thread_t: t@106, stack_base:0×7aa65000, stack_size:0×20000,
pc: 0xc01ea178, monitor = 0×25334) prio=8
  MsgThread.rest(Compiled Code)
  MsgThread.run(Compiled Code)

JDBC Causes Server Hang

Problem Description A JDBC connection which is used by an application or by WebLogic Server itself will block one WebLogic Server execute thread for the complete duration of the calls that are made via this connection. The JVM will ensure that the CPU is given to runnable threads by its thread scheduling mechanism, while the thread that blocks on a SQL query needs to wait. However, the thread occupied by the JDBC call will be reserved and used for the application until the call returns from the SQL query. Even a transaction timeout will not kill or timeout any action that is done by the resources that are enlisted in this transaction. The actions will run as long as they take, without interruption. A transaction timeout will set a flag on the transaction that will mark it as rollback only, so that any subsequent request to commit this transaction will fail with a TimedOutException or RollbackException. However, as mentioned above, the long running JDBC calls can lead to blocked WebLogic Server execute threads, which can finally lead to a hanging instance, if all threads are blocked and no execute thread remains available for handling incoming requests. More recent WebLogic Server versions have a health check functionality that regularly checks if a thread does not react for a certain period of time (the default is 600 seconds). If this happens, an error message is printed to your log file similar to following:

####<Nov 6, 2004 1:42:30 PM EST> <Warning> <WebLogicServer> <mydomain> <myserver> <CoreHealthMonitor> <kernel identity> <> <000337> <ExecuteThread: ‘64′ for queue: ‘default’ has been busy for “740″ seconds working on the request “Scheduled Trigger”, which is more than the configured time (StuckThreadMaxTime) of “600″ seconds.>

This does not interrupt the thread, as this is just a notification for the administrator. The only way a stuck thread becomes unstuck again is when the request it is handling finishes. In this case, you will find a message similar to following in your WebLogic Server’s log file:

####<Nov 7, 2004 4:17:34 PM EST> <Info> <WebLogicServer><mydomain> <myserver> <ExecuteThread: ‘66′ for queue: ‘default’> <kernel identity> <> <000339> <ExecuteThread: ‘66′ for queue: ‘default’ has become “unstuck”.>

The time interval for the health check functionality is configurable. Please check StuckThreadMaxTime property in the <Server> tag of your config.xml file: http://e-docs.bea.com/wls/docs81/config_xml/Server.html#StuckThreadMaxTime or the “Detecting stuck threads” section in the WebLogic Server administration console help: http://e-docs.bea.com/wls/docs81/perform/WLSTuning.html#stuckthread. Top of Page Problem Troubleshooting Different programming techniques or JDBC connection pool configurations can lead to deadlocks or long running JDBC calls that lead to hanging WebLogic Server instances. General information about how to troubleshoot and analyze a hanging WebLogic Server instance is provided in Generic Server Hang Pattern. This pattern addresses JDBC calls causing a server hang and other well known JDBC-related causes for common problems leading to hanging WebLogic Server instance.  Other Support Patterns referenced in this pattern are at the WebLogic Server Support Patterns Site. Quick Links Why does the problem occur? Analysis of a hanging WebLogic Server instance Tips and Tricks to optimize your JDBC code and JDBC connection pool configuration Why does the problem occur? The following are some different possible reasons that can cause JDBC calls to lead to a hanging WebLogic Server instance: Use of DriverManager.getConnection() in your JDBC code. SQL Queries issued to the database take unexpectedly long time to return. Database for which the JDBC connection pool is configured hangs and does not return from calls in a timely manner. A slow or overloaded network causes database calls to slow down or hang. A deadlock causes all execute threads to hang and wait forever. RefreshMinutes or TestFrequencySeconds property in the JDBC connection pool causes hang periods in WebLogic Server. JDBC connection pool shrinking and re-creation of database connections causes long response times. Top of Page Synchronized DriverManager.getConnection() Older JDBC application code sometimes uses DriverManager.getConnection() calls to retrieve a database connection using a certain driver. This technique is not recommended as it can cause deadlocks or at least relatively low performance for your connection requests. The reason behind this is, that all DriverManager calls are class-synchronized, meaning that one DriverManager call in one thread will block all other DriverManager calls in any other thread inside one WebLogic Server instance. In addition to that, the constructor for a SQLException makes a DriverManager call, and most drivers have DriverManager.println() calls for logging, so any of these can block all other threads that issue a DriverManager call. DriverManager.getConnection() can take a relatively long time until it returns with the physical connection created to the database. Even if no deadlock occurs, all other calls need to wait until that one thread gets its connection. This is not a best practice in a multi-threaded system like WebLogic Server.

This information is taken from http://forums.bea.com/bea//thread.jspa?forumID=2022&threadID=200063365&messageID=202311284&start=-1#202311284.

Also our documentation clearly states that DriverManager.getConnection() should not be used: http://e-docs.bea.com/wls/docs81/faq/jdbc.html#501044. If you prefer to use JDBC connections in your JDBC code, you should use a WebLogic Server JDBC connection pool, define a DataSource for it, and get the connection from the DataSource. This will give you all advantages from a pool (resource sharing, connection reuse, connection refresh if a database was down, etc). It also will help you avoid the deadlocks that may happen with DriverManager calls. See detailed information on how to use JDBC connection pools, DataSources, and other JDBC objects in WebLogic Server at: http://e-docs.bea.com/wls/docs81/jdbc/intro.html#1036718 and http://e-docs.bea.com/wls/docs81/jdbc/programming.html#1054307. A typical thread blocked in a DriverManager.getConnection() call looks like:

“ExecuteThread-39″ daemon prio=5 tid=0×401660 nid=0×33 waiting for monitor entry [0xd247f000..0xd247fc68]   at java.sql.DriverManager.getConnection(DriverManager.java:188)   at com.bla.updateDataInDatabase(MyClass.java:296)   at javax.servlet.http.HttpServlet.service(HttpServlet.java:865)   at weblogic.servlet.internal.ServletStubImpl.invokeServlet (ServletStubImpl.java:120)   at weblogic.servlet.internal.ServletContextImpl.invokeServlet (ServletContextImpl.java:945)   at weblogic.servlet.internal.ServletContextImpl.invokeServlet (ServletContextImpl.java:909)   at weblogic.servlet.internal.ServletContextManager.invokeServlet (ServletContextManager.java:269)   at weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:392)   at weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:274)   at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:130)

Top of Page

“ExecuteThread: ‘4′ for queue: ‘weblogic.kernel.Default’” daemon prio=5 tid=0×8e93c8 nid=0×19 runnable [e137f000..e13819bc]   at java.net.SocketInputStream.socketRead0(Native Method)   at java.net.SocketInputStream.read(SocketInputStream.java:129)   at oracle.net.ns.Packet.receive(Unknown Source)   at oracle.net.ns.DataPacket.receive(Unknown Source)   at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)   at oracle.net.ns.NetInputStream.read(Unknown Source)   at oracle.net.ns.NetInputStream.read(Unknown Source)   at oracle.net.ns.NetInputStream.read(Unknown Source)   at oracle.jdbc.ttc7.MAREngine.unmarshalUB1(MAREngine.java:931)   at oracle.jdbc.ttc7.MAREngine.unmarshalSB1(MAREngine.java:893)   at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:375)   at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1983)   at oracle.jdbc.ttc7.TTC7Protocol.fetch(TTC7Protocol.java:1250)   – locked <e8c68f00> (a oracle.jdbc.ttc7.TTC7Protocol)   at oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:2529)   at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout (OracleStatement.java:2857)   at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:608)   – locked <e5cc44d0> (a oracle.jdbc.driver.OraclePreparedStatement)   – locked <e8c544c8> (a oracle.jdbc.driver.OracleConnection)   at oracle.jdbc.driver.OraclePreparedStatement.executeQuery (OraclePreparedStatement.java:536)   – locked <e5cc44d0> (a oracle.jdbc.driver.OraclePreparedStatement)   – locked <e8c544c8> (a oracle.jdbc.driver.OracleConnection)   at weblogic.jdbc.wrapper.PreparedStatement.executeQuery(PreparedStatement.java:80)   at myPackage.query.getAnalysis(MyClass.java:94)   at jsp_servlet._jsp._jspService(__jspService.java:242)   at weblogic.servlet.jsp.JspBase.service(JspBase.java:33)   at weblogic.servlet.internal.ServletStubImpl$ ServletInvocationAction.run(ServletStubImpl.java:971)   at weblogic.servlet.internal.ServletStubImpl.invokeServlet (ServletStubImpl.java:402)   at weblogic.servlet.internal.ServletStubImpl.invokeServlet (ServletStubImpl.java:305)   at weblogic.servlet.internal.RequestDispatcherImpl.include (RequestDispatcherImpl.java:607)   at weblogic.servlet.internal.RequestDispatcherImpl.include (RequestDispatcherImpl.java:400)   at weblogic.servlet.jsp.PageContextImpl.include(PageContextImpl.java:154)   at jsp_servlet._jsp.__mf1924jq._jspService(__mf1924jq.java:563)   at weblogic.servlet.jsp.JspBase.service(JspBase.java:33)   at weblogic.servlet.internal.ServletStubImpl$ ServletInvocationAction.run(ServletStubImpl.java:971)   at weblogic.servlet.internal.ServletStubImpl.invokeServlet (ServletStubImpl.java:402)   at weblogic.servlet.internal.ServletStubImpl.invokeServlet (ServletStubImpl.java:305)   at weblogic.servlet.internal.WebAppServletContext$ ServletInvocationAction.run(WebAppServletContext.java:6350)   at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)   at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)   at weblogic.servlet.internal.WebAppServletContext.invokeServlet (WebAppServletContext.java:3635)   at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2585)   at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)   at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)

The thread will be in running state. You should compare the threads in your different thread dumps in order to see if they receive the return from the SQL call in a timely manner or if they hang in this same call for a longer period of time. If the thread dumps seem to imply long response times from SQL calls, the corresponding database logs should be checked to see if problems in the database cause this slow performance or hang situation. Top of Page Slow Network Communication between WebLogic Server and the database relies on a well-performing and reliable network in order to serve the requests in a timely manner. Slow network performance can therefore lead to hanging or blocking execute threads waiting for results of SQL queries. The related stack traces will look similar to example above in Hanging Database section. It is not possible to find the root cause of the hanging or slow SQL queries by solely analyzing the WebLogic Server thread dumps. These give the first hint that something is wrong with the performance of the SQL calls. The next step is to check if there is a database or network problem that causes poorly performing SQL calls. Deadlock Both an application level deadlock as well as a deadlock on the database level can lead to hanging threads. You should check your thread dumps to see if there is an application level deadlock. Information on how to do this is provided in Server Hang – Application Deadlock Pattern. A database deadlock can be detected either in the database log or by the SQL Exception that can be found in the WebLogic Server log file. An example for a related SQL Exception is:

java.sql.SQLException: ORA-00060: deadlock detected while waiting for resource   at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:170)   at oracle.jdbc.oci8.OCIDBAccess.check_error(OCIDBAccess.java:1614)   at oracle.jdbc.oci8.OCIDBAccess.executeFetch(OCIDBAccess.java:1225)   at oracle.jdbc.oci8.OCIDBAccess.parseExecuteFetch(OCIDBAccess.java:1338)   at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:1722)   at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1647)   at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2167)   at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate (OraclePreparedStatement.java:404)

As it generally can take some time until a database detects a deadlock and resolves it by rolling back one or more transactions that cause the deadlock, one or more execute threads will be blocked until the rollback has finished. RefreshMinutes or TestFrequencySeconds If you see recurring periods of low database performance, slow SQL calls, or connection peaks, the setting of the RefreshMinutes or TestFrequencySeconds configuration property in your JDBC connection pools could be the reason. This is described in detail in Investigating JDBC Problems Pattern. Unless you do not have a firewall between your WebLogic Server instance and your database, you should disable this functionality. Pool Shrinking Physical connections to a database are resources that should be opened once and kept open as long as possible, as a new connection request is a considerable resource overhead for the database, the operating system kernel, and the WebLogic Server. Consequently, pool shrinking should be disabled on production systems in order to keep this overhead at a minimum. If pool shrinking is enabled, idle pool connections will be closed and reopened once connection requests to the pool cannot be satisfied. As these activities can take some time, the related application requests may take an unexpectedly long time which can lead users to assume that the system hangs. Information on how to optimize JDBC connection pool configurations is provided in Investigating JDBC Problems Pattern. Top of Page Analysis of a hanging WebLogic Server instance General information on how to analyze a hanging WebLogic Server instance is provided in Generic Server Hang Pattern. Most times it will be helpful to start with taking thread dumps from the hanging system in order to find out what is going on, e.g., what the different threads are doing and why they hang. Generally, thread dumps can be taken on production systems, however caution is necessary for very old versions of the JVM (<1.3.1_09), as they may crash during thread dumps. Also if the WebLogic Server instance has a huge number of threads, it will mean that the thread dump will take awhile to complete, while the rest of the threads are blocked. Please take more than one thread dump (5 to 10) with a delay of some seconds in between. This gives you the possibility to check the progress of the different threads. Also it will show if the system actually hangs (no progress at all) or if the throughput is extremely slow, which can seem to be a hanging system. Information on how to take thread dumps is provided in “Generic Server Hang” support pattern or in our documentation: http://e-docs.bea.com/wls/docs81/cluster/trouble.html. Also please check if the complete WebLogic Server instance hangs or if it is the application that hangs. “Generic Server Hang” support pattern also includes this information. Analyzing the thread dumps can show if one of the reasons mentioned in the previous section Why does the problem occur? actually is responsible for your hanging instance. If for example all your threads are in a DriverManager method like getConnection() then you have identified the root cause and need to change your application to use a DataSource or Driver.connect() instead of DriverManager.getConnection(). A very useful tool, Samurai, can be used to analyze thread dumps and to monitor the progress of threads between different thread dumps. This can be downloaded from dev2dev at:  http://dev2dev.bea.com/resourcelibrary/utilitiestools/adminmgmt.jsp. A whitepaper on analyzing thread dumps on dev2dev: http://dev2dev.bea.com/products/wlplatform81/articles/thread_dumps.jsp will also be helpful in going deeper into the thread dumps to find out more about the server hang. Top of Page Tips and Tricks to optimize your JDBC code and JDBC connection pool configuration There are some best practices both in the development of JDBC code and also in the configuration practice of JDBC connection pools that can help to avoid common problems and optimize resource usage so that hanging server instances should not happen. JDBC Programming In order to optimize resource usage in WebLogic Server and conserve database resources, you should use JDBC connection pools for your application’s JDBC calls. Connections created and destroyed in your application code generate an unnecessary overhead which should be avoided. For generic documentation on JDBC programming, see: http://e-docs.bea.com/wls/docs81/jdbc/rmidriver.html#1028977. Also details on JDBC performance tuning are at: http://e-docs.bea.com/wls/docs81/jdbc/performance.html#1027791. You can view comprehensive information on JDBC that will help to optimize your JDBC code and the utilization of your JDBC resources on dev2dev Java Database Connectivity page at: http://dev2dev.bea.com/technologies/jdbc/index.jsp. JDBC Connection Pool Configuration The Investigating JDBC Problems Pattern has recommendations on how to configure a connection pool for production environments. In order to avoid hangs or bad performance, these configuration tips should be considered.

Top of Page

Need Further Help? If you have followed the pattern, but still require additional help, you can: Query AskBEA at http://support.bea.com/ using “jdbc server hang”, as an example, to discover other published solutions.  Contract Support Customers: Ensure you are logged to access available CR-related information. Ask a more detailed question on one of BEA’s newsgroups at http://forums.bea.com If this does not resolve your issue and you have a valid Support Contract, you can open a Support Case by logging in at: http://support.bea.com/ .

FEEDBACK Please provide us input on whether or not this Support Diagnostic Pattern “JDBC Causes Server Hang” helped, any clarifications you needed, and any requests for new topics to Support Diagnostic Patterns.

DISCLAIMER NOTICE: BEA Systems, Inc. provides the technical tips and patches on this Website for your use under the terms of BEA’s maintenance and support agreement with you. While you may use this information and code in connection with software you have licensed from BEA, BEA makes no warranty of any kind, express or implied, regarding the technical tips and patches. Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.

其实这是BEA官网上的一篇文档，是在weblogic8.1的时候推出的。在BEA被Oracle收购后，所有的support文章也就被重定向到Oracle的官网首页= =，而且google的快照也没有了。这篇来自无意间google到的一个外国论坛，虽然是写在8.1时，但是解决问题的方法和思路现在依旧有效。本想理解之后结合案例来写一篇，但是最近一直没有遇到相关的问题，而且觉得那样也许会破坏文章的完整性，所以放出原文，既在网上留个副本，也能让大家各取所需，见仁见智。

从内容看，你会发现除了这篇，还有EJB_RMI Server Hang、Application Dead Lock、JDBC Causes Server Hang，但是那个论坛里还能找到的仅有JDBC Causes Server Hang一篇。所以如果你接触weblogic比较早，保存过另两篇文章，或者在网上看到了，那请留言说明，万分感谢。

Generic Hang

内存泄漏是比较常见的一种应用程序性能问题，一旦发生，则系统的可用内存和性能持续下降；最终将导致内存不足(OutOfMemory)，系统彻底宕掉，不能响应任何请求，其危害相当严重。同时，Java堆(Heap)中大量的对象以及对象间之复杂关系，导致内存泄漏问题的探测和分析均比较困难，采用相应的辅助工具是很必要的。

我使用的比较多的是Memory Dump Diagnostic for Java (MDD4J)和IBM HeapAnalyzer，这两个工具都能支持几乎所有JDK版本所生成的堆转储文件，使用前可以在两者的帮助文件中查看一下支持列表。

先说一下IBM HeapAnalyzer，下载之后首先阅读一下readme，这上面详细写了HeapAnalyzer的使用方法。对于我用的2.6版本（最新为3.8），可以在命令行中输入<Java path>java –Xmx[heapsize] –jar ha26.jar <heapdump file>来启动工具并加载heapdump文件。对于比较大的heapdump，将-Xmx设置一个较大的值（大于heapdump的大小），来避免加载过程中的OOM。对于64位机器上产生的超大heapdump，个人机器上分析就不大可能了。

打开heapdump文件后，我一般点击“Analysis”里的“Tree View”，以树的形式从根节点展示内存对象分配的信息

第一行java.lang.ref.Refenrence这个class及它的76个children占用了67%的已用堆大小（31M/46M），它本身仅占用了76bits。双击java.lang.ref.Refenrence，我们可以看到它所引用的两个子节点。其中一个子节点java.lang.ref.Finalizer后的67%指引我们内存泄漏的问题应该在它的引用上。

接下去你可以逐级展开，或者右键点击“Locate a leak suspect”，让HeapAnalyzer帮你找到泄漏可能发生的地方。泄漏一般发生在那些拥有“超乎寻常多”的引用（子节点）的class上，正是这些创建后没有释放、累积了成千上百的对象，造成了OutOfMemory。右键中的“Go to the largest drop subtrees”也是以此为原理而设的，它的解释为：

“Search for total size drop” will find a size drop between the total size of a parent and the biggest total size of child of the parent.

因为出现泄漏的点，每个子节点占用的内存空间不大，但是巨大的数量会导致父节点占用的total size很大。不过反过来寻找到的点都是泄漏发生的地方这种说法是不成立的，否则也不需要我们来分析了。

更多细节的内容，可以看这篇PPT

Memory Dump Diagnostic for Java (MDD4J)则是IBM Support Assistant（ISA）里的一个工具，可以在ISA里加载。它的使用方法和HeapAnalyzer类似，不过它会自动列出“可疑泄漏点”供分析。所依据的，是“分析算法查找父对象与子对象之间对象大小的显著变化。这些发生显著变化的父对象可能是基于数组的容器对象，它们包含大量不断增大的子对象。”

具体的使用方法可以参考《WebSphere Application Server 中的内存泄漏检测与分析:第 2 部分：用于泄漏检测与分析的工具和功能》一文中的实际案例。（不过文中的版本应该比较低，现在能下到的2和3版本有些不同，不过不妨碍使用）.

Heapdump工具的使用很简单，难点在于找到“内存泄漏的真正原因”，一般需要通过多个heapdump文件的对比才能找到。

比较分析用于对运行内存泄漏应用程序期间（即可用 Java 堆内存流失时）获取的两个内存转储进行分析。在运行泄漏应用程序的早期触发的内存转储被称为基线内存转储，发生泄漏的应用程序运行一段时间（以允许泄漏程度加大）后触发的内存转储被称为主内存转储。在发生了内存泄漏的情况下，主内存转储可能包含大量对象，而这些对象占用的 Java 堆空间量会比基线内存转储大很多。

为了获得更好的分析结果，建议使主内存转储的触发点与基线内存转储的触发点在时间上拉开一定距离，从而使总耗用堆大小在两个触发点之间大幅增长。

如果发现“主内存转储”中的某个对象数量大大大于“基线内存转储”，那么这个对象一般就是发生泄漏的点。但是要避免在appserver刚启动时就做heapdump，否则会把正常需要分配的对象当作泄漏嫌疑点。比如原先运行3天会发生OOM，那么可以：缩小堆大小，让OOM提早发生；在运行4个小时后每隔4小时手动做一次Heapdump直到OOM发生。这些动作也许不适合在生产环境下进行，可以另建测试环境进行。

之前几篇文章中介绍的分析gc log，和本文讲到的分析heapdump，都是脱机分析法。它们的缺陷就是无法找到代码引起的“性能低下”的原因，正如《用HPjtune分析GC日志》里所看到的那样，系统性能很差，但是没有OOM发生，可用堆在每次full gc后还不断减少的现象不能简单怪罪为内存泄漏，毕竟最后都回收下来了，如果手动做heapdump，可能有问题的对象已被回收，无法得到正确的结果。这种情况下要使用诸如Jprofile这样直接附加到JVM上的工具来监测了。

最后附一下手动生成heapdump的方法，免得事到临头在google。

在Linux/AIX环境下

使用Kill -3 pid命令来调用堆转储.

Windows环境下

1． 找到JVM对象名字。

<wsadmin> set objectName [$AdminControl queryNames
WebSphere:type=JVM,process=<servername>,node=<nodename>,*]

2． 对JVM MBean调用generateHeapDump操作。

<wsadmin> $AdminControl invoke $objectName generateHeapDump

如果上述方法是没有生成，那么进行下面的设置。

访问管理控制台

转到“服务器”>“应用程序服务器”> Server1（或者要获取其堆转储的服务器的名称）>“进程定义”>“环境条目”。

单击“新建”。

在“名称”字段中，输入 IBM_HEAPDUMP（默认是开启的）。在“值”字段中，输入 true。

单击“确定”。

重复步骤 3 至 5，但将 IBM_HEAPDUMP_OUTOFMEMORY 设置为 true。

缺省情况下，将在 ~/WebSphere/AppServer/ 目录中创建内存转储（对于 WebSphere Application Server V6.x 而言，缺省目录是：~/WebSphere/AppServer/profiles/default）。要将堆转储目标定向到另一个目录，请转至“环境条目”，单击“新建”，将 IBM_HEAPDUMPDIR 设置为适当的目录（例如 /heapdumps），然后单击“确定”。

单击“保存”，然后在下一个屏幕中再次单击“保存”。

转到“服务器”>“应用程序服务器”> server1（或者要获取其堆转储的服务器的名称）>“进程定义”>“Java 虚拟机”。

选择“详细垃圾回收”。

单击“保存”，然后在下一个屏幕中再次单击“保存”。

重新启动服务器。

打开命令提示符并转至 /WebSphere/AppServer/bin 目录。

通过发出 kill -3 XXXXX 命令来调用堆转储，其中 XXXXX 是进程标识。

如果WebSphere运行在HP-UX上，那么需要

• 访问管理控制台
• 转到“服务器”>“应用程序服务器”> Server1（或者要获取其堆转储的服务器的名称）>“进程定义”>“环境条目”。
• 在“常规参数”中，输入：-Xrunhprof:depth=0,heap=dump,format=a,thread=n,doe=n
• 缺省情况下，将在 ~/Websphere/AppServer/ 目录中创建内存转储。要将堆转储目标定向到另一个目录，请添加 HProf 参数 file=/heapdumpdir/hprof.txt，其中 heapdumpdir 是适当的目录，而 hprof.txt 是适当的文件名。如果创建了多个内存转储，那么将把每个内存转储追加到同一个 hprof.txt 文件中。
• 选中“启用详细垃圾回收方式”。
• 重新启动服务器。
• 通过发出 kill -3 XXXXX 命令创建堆转储，其中 XXXXX 是进程标识。
• 除非另有指定，否则将在 ~/WebSphere/AppServer/ 目录中创建 hprof 转储，并且文件名看起来类似于 java.hprof.txt。
• 关闭应用程序服务器，然后移动 hprof 转储文件。直到正确关闭应用程序服务器之后，hprof 转储文件才完整。
• 注意：请检查是否每个 hprof 转储都包含 HEAP DUMP BEGIN 和 HEAP DUMP END 这两组标记。如果 hprof 转储的这两组标记不齐全，那么表明该转储不完整且不能用于分析。

Related posts:

• Linux 性能监控
• IBM WebSphere Recent Supports

接下来我将分析一个实际生产环境下的日志文件，这个生产系统在启用新的功能后应用访问速度变慢，每个操作都要耗时10s左右，通过对比前后不同的gc信息，希望能从JVM的层面来优化当前的性能。

HP小机（Pa-Risc和安腾平台）使用HP的JDK后，使用-Xloggc:filename或者-Xverbosegc:file=filename参数会生成形如

的日志，这种格式人肉分析就别想了，它可以在PMAT中以Xverbosegc/hpux文件格式打开，但是图象功能我这里没法使用，只好求助于HP自家的工具——HPjmeter了。

分析过程

用HPjmeter加载日志文件后，会自动打开HPjtune的窗口。首先会看到Heap Usage After GC标签页，这是四月份正常的情况（请先忽略systemgc，这点留待后面分析）

下面是六月份速度慢的情况：

明显能看到Old full（with perm）代表的黄点增多了，从之前的日志文件头我们了解到这个系统所用的JDK为1.4.2 32位版本（64位版本会写明Java VM name = Java HotSpot(TM) 64-Bit Server VM），默认的回收策略是串行收集器，在Old区发生垃圾回收时是Stop the world的full gc，每次full gc耗时基本在10s～12s

切换到”Summary”标签页

4月花在gc上的时间占整个JVM运行时间的3.036%，Full GC占整个JVM运行时间的0.993%，应该说是情况良好。

到了6月份，情况却变化很大，时间分别为10.791%和8.417%，因为超过了5%的警戒线而显示为红色，而且79%的GC时间花在full gc上。

这还是一周的情况，包括了周末和晚间空闲时刻，让我们看看在上班高峰期间的运行情况。

乖乖，有61%的时间花在gc上，速度不慢才怪了。我们查看当前对应的Heap Usage After GC

除了开始的少数年轻代中发生的快速Scavenge，大部分都是慢速的Full GC，而且可以看到每次回收后使用的堆空间并没有减小，反而越来越大，有内存泄漏的征兆。不过堆空间并没有一路增长下去直到OutOfMemory，而是像下图般那样反复。

早上和下午两个业务繁忙期全是full gc，性能表现很差，而4月正常的情况应是如此

Eden区满了后，经过Scavenge动作一部分对象被转移到了Old区，所以堆中占用空间上升，直到Old区也无法分配了，那么发生full gc，内存又重新回到一个较低的位置，这是正常的情况。现在6月份出现一直Full GC也无法回收，但又没有发生OutOfMemory，可以判断为原来设置的参数无法满足新内容投产后的需求

例如没有使用并行回收，没有发挥8个CPU的效果，没有采用低响应时间的CMS回收模式。

同时新系统产生的对象数量也大大增加，从四月一天的500000个增加到900000个（左边四月，右边六月）。

导致每次回收后，从新生代转移到年老区的对象数量也变多，其实它们并非是长存对象，只是新生代暂时无法容纳下它们了。

而且full gc会导致Survivor区里的所有对象都被转移到old区，这造成了恶性循环。（黄色的Full GC后，Survivor里的对象为零）

优化操作

调整目标：尽可能的将短时间存活的对象在年轻代就能被丢弃掉，而不要转移到年老代中；采用并行回收方式增加效率；避免产生不必要的Full GC；或者采用响应时间短的垃圾回收方式。

调整方法：增大年轻代大小，减小SurvivorRatio加大Survivor区（也就是From or To）；设置并行回收参数;设置初始堆和最大堆为同样值、设置初始PermSize为一个合理值，避免运行过程中增长；设置回收策略为CMS。

参数设置一：-Xms1500m -Xmx1500m -Xmn800m -XX:SurvivorRatio=4 -XX:PermSize=160m  -XX:+UseParallelGC（-XX:ParallelGCThreads=8我觉得可以不用显示的声明，可以再上述参数设置后分析新的gc log，看一下System Details页面中ParallelGCThreads的数目再做定夺，1.4.2的JDK不能再Old区做并行回收，也是一个遗憾）

参数设置二：-Xms1500m -Xmx1500m -Xmn800m -XX:PermSize=160m  -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSFullGCsBeforeCompaction=5（或者最后一个参数设置为-XX:+UseCMSCompactAtFullCollection）

上述参数的意义可以看《JAVA性能优化—Sun Hotspot JDK JVM参数设置》

后续进展

参数设置后还有一个观察过程，如果效果不佳，那从系统集成的角度，一是更换64位JDK，这样可以设置更大的堆空间（不过WebSphere更换JDK不像Weblogic那么简单，如果没有买过64位WebSphere的话只好作罢）；二是启用WebSphere的集群，但这需要ND版本的WAS。

从应用的角度，可以在早上8点做一次heapdump，9点半做一次heapdump，分析一下full gc内存回收不下来的原因，确定不是程序的错误造成的。或者启用-agentlib:hprof参数，用HPjmeter来trace应用的表现、用HPjmeter来直接监控应用的运行情况。不过这两个方法对性能影响较大，要在测试环境下进行。

其它的一些碎碎念

现在我们来说说日志中那么多的systemgc，刚开始看到我大吃一惊，但放大图像后发现这些自行调用的full gc都是下班后做的，应该是另一个应用触发的，对白天的性能影响应该不大。

不过这里还是要再申明一句：自行调用System.gc（）函数会损害到JVM的性能，因为这时候是Stop the World的回收，消耗的时间长，但效果并非最佳。你也许会认为你对程序很熟悉，可以在空闲的时间执行system.gc，不会影响到客户访问，但是正如之前所说，full gc后survivor里的所有内容都被转移到了old区长久保存，所以在某个将来，JVM就不得不因为这个原因再做一次不必要的full gc。

IBM JDK下避免主动回收的参数是“-Xdisableexplicitgc”，Sun JDK下的参数是“-XX:+DisableExplicitGC”，注意区别。

Related posts:

• 预告
• 什么是真正的思考？
• WebSphere troubshooting-用工具分析GC Log
• 用IBM HeapAnalyzer和MOD4J分析Java内存泄漏
• 应用程序死锁导致服务器挂起的介绍

这是由于was服务启动用户一般是“本地系统”或者“Administraotr”，而这两个用户都是非认证（unauthenticated）的。如果没有被添加为服务，或者在Unix/Linux环境下，停止服务器时就会提示你输入用户名和密码，或者运行命令时添加“-username 用户名 -password 密码”参数。

所以解决的方法很简单，只要更新一下WAS服务属性即可。在wasHome下的bin目录中，运行

启动服务时不需要用户名密码，所以不需要添加-startArgs参数。得到提示：

PS：to 香我宁的几个问题：

Q：在控制台的应用程序服务器–>serverxxx–>进程定义–>Java虚拟机页面勾选“详细类装入”（与-verbose:class作用一样），为何在SystemOut.log里没有类加载的日志输出？应该怎么看？

A：出现在了native_stderr.log里。

Q：没有更改日志级别详细信息，也没有类装入器查看器 = =跟踪规范是 *=all=disabled 这是啥意思？

A：在“故障诊断”中有“类装入器查看器”，在“日志和跟踪”里有“更改日志详细信息级别”，默认为“*=info”。其它级别为

WebSphere Application Server 缺省配置在缺省情况下支持 Level.INFO 和更高的 JUL 级别。应用服务器将从 Level.CONFIG 到 Level.SEVERE 的所有 JUL 级别作为日志事件级别对待，旨在供管理员使用。

表 3. 日志记录级别

日志记录级别

Level.SEVERE

Level.WARNING

Level.INFO

Level.CONFIG

应用服务器将从 Level.FINE 到 Level.FINEST 的级别作为跟踪级别对待（这些级别用于旨在帮助代码的作者进行调试的事件）。

权威支持: WebSphere Application Server 日志记录开发人员指南

“*=all=disabled ”说明对所有的记录器关闭跟踪，不过具体的要视WAS版本而定。

在 WebSphere Application Server V6 和更高版本中，使用了一种日志记录基础结构，即，扩展 Java 日志记录。这导致 WebSphere Application Server 中记录基础结构配置的以下更改：

• Java 日志记录中定义的记录器等同于先前版本的 WebSphere Application Server 中引入的跟踪组件，并且是使用同一种方式配置的。两者都称为“组件”。
• Java 日志记录级别和 WebSphere Application Server 级别都可以使用。以下是有效级别的完整列表，按严重性以升序排列：
• 将组件的记录和跟踪级别设置为 all 将启用该组件的所有记录。将组件的记录和跟踪级别设置为 off 将禁用该组件的所有记录。
• 只可以将一个组件配置为一个级别。但是，将组件配置为某种级别将使它可以在配置的级别和任何更高严重性级别执行记录。
• 几个级别有同等名称：finest 等同于 debug；finer 等同于 entryExit；fine 等同于 event；severe 等同于error。

COMPONENT_NAME 是用跟踪服务记录基础结构注册的组件或组的名称。通常，WebSphere Application Server 组件使用标准 Java 类名（例如 com.ibm.servlet.engine.ServletEngine）注册。另外，您可以使用星号（*）通配符终止组件名称和表明多个类或包。例如，使用组件名 com.ibm.servlet.* 指定所有名称以 com.ibm.servlet 开头的组件。在组件名或组名末尾使用星号（*）作为通配符，以使记录字符串可应用于其名称以指定字符串开头的所有组件或组。例如，将“com.ibm.servlet.*”指定为组件名的记录字符串将应用到名称以 com.ibm.servlet 开头的所有组件。当使用星号（*）本身来代替组件名时，字符串指定的级别将应用到所有组件。

以下是在记录字符串中使用星号（*）的一些示例。注意，记录字符串中的星号（*）不需要在它前面具有句点（.）。句点（.）可用于记录字符串中的任何位置。

• com.ibm.ejs.ras.*=all － 对于名称以“com.ibm.ejs.ras.”开头的所有记录器启用跟踪。如果有一个记录器名为“com.ibm.ejs.ras”，那么它将不会启用跟踪。
• com.ibm.ejs.ras*=all － 对于名称以“com.ibm.ejs.ras”开头的所有记录器（例如，com.ibm.ejs.ras、com.ibm.ejs.raslogger 和 com.ibm.ejs.ras.ManagerAdmin）启用跟踪

注：

• 在 WebSphere Application Server V5.1.1 和更低版本中，可以将 LEVEL 设置为“all=disabled”以禁用跟踪。从 V6.0 开始，此语法将导致 LEVEL=info；将禁用跟踪，但是将启用日志记录。
• 在 WebSphere Application Server V6 和更高版本中，“info”是缺省级别。如果指定的组件不存在（未找到 *=xxx），那么始终意味着 *=info。跟踪字符串不匹配的任何组件会将其级别设置为 info。
• 如果记录字符串不以指定所有组件级别的组件记录字符串（使用“*”代替组件名）开始，那么将添加一个设置所有组件为缺省级别的组件记录字符串。
• 在 V6 和更高版本中，不需要使 STATE = enabled | disabled。但如果使用的话，它具有下列效果：
  • “enabled”将指定组件的记录设置为指定的级别
  • “disabled”将指定组件的记录设置为上述指定级别的上一个级别。下列示例说明禁用记录级别的影响：

更详细的看跟踪和日志记录配置

最后，如果可以的话，改下你的名字。

Related posts:

• 应用程序死锁导致服务器挂起的介绍
• IBM JDK的Java堆空间的碎片问题
• 什么是真正的思考？
• IBM WebSphere最新技术支持信息
• WebSphere troubshooting-用工具分析GC Log

上次在WebSphere的类加载机制和故障排查一文中整理了一下Classloader的一些概念和加载原理，但是概念的应用不是很明确，故障排查也没有具体的方法。所以今天再次整理了IBM developerworks里有参考价值的文章，希望在遇到ClassCastException、ClassNotFoundException、NoClassDefFoundException、UnsatisfiedLinkError的错误时提供解决思路。

《IBM WebSphere 开发者技术期刊: 类路径冲突的鉴别》一文描述了应用迁移过程中所发生的“故障”，打引号那是因为WAS并没有发出ClassNotFoundException、NoClassDefFoundException等的错误信息，而是“并非预期中的表现”。最终排查的结果是：

其结果是 C:/Program Files/IBM/WebSphere Studio/Application Developer/v5.1.1/runtimes/base_v51/lib/jython.jar ，而不是我们期望的 WEB-INF/lib/jakarta-oro-2.0.7.jar 。

这是一个很典型的类加载错误例子，默认的PARENT_FIRST加载模式让类加载器从应用程序 类装入器中先加载了jython.jar（正好有需要的同名类），而不是Web 模块类装入器里正确的jakarta-oro-2.0.7.jar。解决的方法可以启用PARENT_LAST 加载模式即可。文章中检测类加载路径的Servelet可以作为参考，不过我觉得一般会用-verbose 命令行选项打开 IBM JVM 的详细输出、trace某个确定类的情况或者dump的方法找到类加载路径。

调试方法

《类装入问题解密，第 1 部分: 类装入和调试工具介绍》 介绍了这三种方法

可以用 -verbose 命令行选项打开 IBM JVM 的详细输出。当某些事件发生的时候（例如，类装入时），详细输出会在控制台上显示信息。要想得到额外的类装入信息，可以用详细类输出。可以用 -verbose:class 选项启动这个模式。

解释详细输出
详细输出列出已经打开的所有 JAR 文件，包括到这些 JAR 的完整路径。下面是一个示例：

...
[Opened D:\jre\lib\core.jar in 10 ms]
[Opened D:\jre\lib\graphics.jar in 10 ms]
...

所有装入的类都已经列出，同时还指出它们是从哪个 JAR 文件或目录装入的。例如：

...
[Loaded java.lang.NoClassDefFoundError from D:\jre\lib\core.jar]
[Loaded java.lang.Class from D:\jre\lib\core.jar]
[Loaded java.lang.Object from D:\jre\lib\core.jar]
...

可以仅输出某个特定的类加载情况，剔除无关紧要的类：

-Dibm.cl.verbose=<class name>。可以用正则表达式声明类的名称，例如 Hello* 会跟踪所有以 Hello 开头的名称。

更准确的就是用trace工具来跟踪java代码

IBM JVM 有一个内置的方法跟踪工具。这样，不需要修改 Java 代码，就可以跟踪任何 Java 代码（包括核心系统）中的方法。因为这个工具可以提供大量数据，所以可以控制跟踪的级别，只获取需要的信息。

比较常用的步骤是

1. 在控制台导航树中单击故障诊断 > 记录和跟踪，然后单击服务器 > 诊断跟踪。
2. 单击配置。
3. 选中启用记录复选框启用跟踪，清除此复选框禁用跟踪。

…………

1. 1. 在控制台导航树中单击故障诊断 > 记录和跟踪。
   2. 选择服务器名。
   3. 单击更改日志级别详细信息。
   4. 如果已启用所有组件，那么可能要关闭它，然后启用特定组件。
   5. 单击组件或组名。要获取更多详细信息，请参阅日志级别设置 。 如果所选服务器未在运行，您将无法以图形方式查看个人组件。
   6. 在跟踪字符串框中输入跟踪字符串。
   7. 选择应用，然后选择确定。

要输入跟踪字符串以将跟踪规范设置为需要的状态：

亦可以在故障诊断 > 类装入器查看器 以访问企业应用程序拓扑页。

在“类装入器查看器”页中，单击搜索以访问搜索页，在该页面上，可以在类装入器中搜索下列内容：

• 特定字符串
• 特定 .jar 文件
• 特定目录中的文件名
• 特定类装入器装入的文件名

搜索区分大小写

用Trace来跟踪应用程序情况其实是很有技术含量的活，能自成一章。我接触的项目基本到了这一层都是由开发人员去找BUG，所以实践比较少，没有分享的心得。有机会的话我以后学习学习再写。

如果你觉得用trace来跟踪调试比较复杂，那么可以直接生成一个javacore文件，里面会记录类装入器信息。推荐用wsadmin命令来生成core文件，因为kill -3带出个heapdump可就不好玩了。

键入wsadmin.bat命令，进入wsadmin管理命令行，键入如下代码：

set jvm [$AdminControl completeObjectName type=JVM,process=server1,*]
$AdminControl invoke $jvm dumpThreads

javacore.TIMESTAMP.NUMBER.txt  文件会自动在C:\WebSphere\AppServer或C:\WebSphere\AppServer\default\或您指定的目录中产生。

解决问题

了解了查找的方法，那么就可以开始解决问题：《类装入问题解密，第 2 部分: 基本的类装入异常》

ClassNotFoundException 是最常见的类装入异常类型。它发生在装入阶段。Java 规范对 ClassNotFoundException 的描述是这样的：

当应用程序试图通过类的字符串名称，使用以下三种方法装入类，但却找不到指定名称的类定义时抛出该异常。

• 类 Class 中的 forName() 方法。
• 类 ClassLoader 中的 findSystemClass() 方法。
• 类 ClassLoader 中的 loadClass() 方法。

所以，如果显式地装入类的尝试失败，那么就抛出 ClassNotFoundException。

通过抛出 ClassNotFoundException，类装入器提示，定义类时所需要的字节码在类装入器所查找的位置上不存在。这些异常修复起来通常比较简单。可以用 IBM 的 verbose 选项检查类路径，确保使用的类路径设置正确。如果类路径设置正确，但是仍然看到这个错误，那么就是需要的类在类路径中不存在。要修复这个问题，可以把类移动到类路径中指定的目录或 JAR 文件中，或者把类所在的位置添加到类路径中。

更多的解决方法请看原文，第三第四部分的《类装入问题解密，第 3 部分: 处理更少见的类装入问题》、

《类装入问题解密，第 4 部分: 死锁和约束》就当扩展阅读好了。

个人感想

类加载问题是一个不难解决却又令人头疼的问题，特别当多个应用部署在一起的时候。问题状况相似，其实出错的原因并不相同，往往单独成功的例子——例如jar包换个目录，对于另一个环境却束手无策。网上有不少的“解决案例”就是这种情况，所以我把“渔”的方法整理在这里，并非个人原创，都是照搬IBM developerworks已有的内容。惭愧之余，也感叹一下IBM的强大。其它的大型厂商，Oracle是需要Metelink帐号才能看到最有用的资料；SAP也需要购买产品后才能查看详细文档，否则就是简陋两字；Microsoft的KB和webcasting做的很好，但是本地化和有价值的文章却逊一筹。在都想依靠服务赚钱的现在，IBM没有把这些资料敝帚自珍，让我们有个学习交流的环境，这也许是它数十年它经久不衰的奥秘之一吧。

Related posts:

• Java 类加载器的又一篇文章
• JAVA性能优化—编写符合GC胃口的程序
• 应用程序死锁导致服务器挂起的介绍
• IBM WebSphere最新技术支持信息
• IBM WebSphere Recent Supports

首先需要下载IBM Support Assistant，下载之后就可以从Update-Tools add on中下载我们需要的工具了，ISA使用方法。ISA把所有的工具集成在一个界面内，省去了设置启动参数的麻烦，同时能保持最及时的更新。分析垃圾回收日志，我主要用“The IBM Monitoring and Diagnostic Tools for Java™ – Garbage Collection and Memory Visualizer”和“IBM Pattern Modeling and Analysis Tool for Java Garbage Collector (PMAT)”这两个工具。我会用实际例子来说明如何使用这个工具。

用Garbage Collection and Memory Visualizer载入native_stderr.log，首先你会看到

点击展开大图

这是一个500分钟的垃圾回收曲线图，可以观察到一天以内的大致情况。总的来说，蓝色的Used heap（after collection）运行在“平行通道”内，没有走“上升通道”（炒股的朋友应该知道上升通道的图形是咋样的）。所以在Report这个标签内，可以看到“The memory usage of the application does not indicate any obvious leaks.”。

Report中的Summary是需要关注的，它向我们显示了GC发生的次数，所用的policy（optthruput），平均停顿时间248ms，平均间隔时间3.37分钟，还有垃圾回收的速率（垃圾产生多并非不好，反而是吞吐率高的一种表现）。

让我们再切回Line plot视图，现在可以框选某一个时间段进行放大，同时在右边Axes中选择X轴的坐标系，默认的是相对时间，以分钟为单位，适用于你的应用程序总在启动N个小时后出现问题。如果是每天固定时间发生性能问题，那么应该选用绝对时间。

默认的曲线开启了Heap size和Used heap（after collection），你可以根据需要，在VGC Pause Date和VGC Date、VGC Heap Data中勾选你需要查看的曲线。比如你觉得程序响应时间很长，那么可以勾选上Intervals between garbage collection triggers和Pause time，看看上一条曲线是否和下面一条靠的“太近”。

通过在Tabbed data查看表格模式的回收信息（同样可以勾选上节提到的内容来增加列），我们看到GC reason都是af。通过查看Free heap before collection，我们发觉有些af发生的时候，堆中剩余空间其实还很多

我覆盖上Compact times曲线，发现十分吻合，原来这时候是堆中的碎片太多，所以导致即使剩余空间很大，但是没有连续空间分配给新的请求，这时候就发生了压缩（Compact）。加了Unuseable heap due to fragmentatiion的第二副图可以更明显的看到这一点。进一步的，可以根据第一列的collection id去查看引起压缩的requested_bytes，是否是需要比较大的空间（比如大于64K），然后结合一下所有requested_bytes中大对象的数量，确定是否需要调整LOA大小。

你会发现还有些曲线是灰色不能选择状态，那是因为根据我现在的gc policy，关于gencon模式下的nursery和tenured曲线在这个模式下是没有的。

总的来说，运用不同的曲线组合，合适的缩放比例，不同的日志显示方法对照，我们可以验证gc是否符合我之前说过的一些“最优原则”——回收的间隔是否大大大于持续时间，整个回收时间是否在整个运行时间的5%以下，压缩的次数是否仅占一小部分（太多的话要考虑设置-Xk -Xp和调整LOA）……Report标签中的Tuning recommendation是你需要参考的内容，但不要一上来就根据它的提示去优化。

下一个例子就是一个有问题的垃圾回收日志。

整个垃圾回收曲线，当中有一个Excessive GC引发的OutOfMemory

The concurrent collector will throw an OutOfMemoryError if too much time is being spent in garbage collection: if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, an OutOfMemoryError will be thrown. This feature is designed to prevent applications from running for an extended period of time while making little or no progress because the heap is too small.

放大出问题的地方的曲线

根据ID查看原始文件

<af type=”tenured” id=”1030″ timestamp=”Tue Nov 04 14:57:26 2008″ intervalms=”11.440″>
<minimum requested_bytes=”216″ />
<time exclusiveaccessms=”0.322″ />
<tenured freebytes=”0″ totalbytes=”1342177280″ percent=”0″ >
<soa freebytes=”0″ totalbytes=”1342177280″ percent=”0″ />
<loa freebytes=”0″ totalbytes=”0″ percent=”0″ />
</tenured>
<gc type=”global” id=”1031″ totalid=”1031″ intervalms=”11.837″>
<compaction movecount=”3301258″ movebytes=”196674784″ reason=”low free space (less than 4%)” />
<refs_cleared soft=”0″ weak=”15″ phantom=”7″ />
<finalization objectsqueued=”40″ />
<timesms mark=”1753.108″ sweep=”10.302″ compact=”1858.390″ total=”3622.032″ />
<tenured freebytes=”519040″ totalbytes=”1342177280″ percent=”0″ >
<soa freebytes=”519040″ totalbytes=”1342177280″ percent=”0″ />
<loa freebytes=”0″ totalbytes=”0″ percent=”0″ />
</tenured>
</gc>
<warning details=”excessive gc activity detected” />
<tenured freebytes=”518352″ totalbytes=”1342177280″ percent=”0″ >
<soa freebytes=”518352″ totalbytes=”1342177280″ percent=”0″ />
<loa freebytes=”0″ totalbytes=”0″ percent=”0″ />
</tenured>
<time totalms=”3623.033″ />
</af>

<af type=”tenured” id=”1031″ timestamp=”Tue Nov 04 14:57:30 2008″ intervalms=”3.715″>
<minimum requested_bytes=”120″ />
<time exclusiveaccessms=”0.232″ />
<tenured freebytes=”0″ totalbytes=”1342177280″ percent=”0″ >
<soa freebytes=”0″ totalbytes=”1342177280″ percent=”0″ />
<loa freebytes=”0″ totalbytes=”0″ percent=”0″ />
</tenured>
<gc type=”global” id=”1032″ totalid=”1032″ intervalms=”4.385″>
<compaction movecount=”3170275″ movebytes=”192337800″ reason=”compact to aid heap contraction” />
<contraction type=”tenured” amount=”67108352″ newsize=”1275068928″ timetaken=”0.001″ reason=”excess free space following gc” />
<refs_cleared soft=”0″ weak=”0″ phantom=”0″ />
<finalization objectsqueued=”9″ />
<timesms mark=”245.373″ sweep=”12.272″ compact=”482.748″ total=”745.486″ />
<tenured freebytes=”1022923992″ totalbytes=”1275068928″ percent=”80″ >
<soa freebytes=”1022923992″ totalbytes=”1275068928″ percent=”80″ />
<loa freebytes=”0″ totalbytes=”0″ percent=”0″ />
</tenured>
</gc>

考虑到垃圾回收频率也较高，每次请求的空间都不大，所以我讲垃圾回收模式改为了gencon，之后没有OutOfMemory发生。不过我那份回收日志没有留下来，否则应该在文件Compare file中导入修改后生成的日志，进行比较，确定修改的结果。

注意事项：对于IBM JDK，直接勾选“详细垃圾回收”即可，但是对于HP 或者Sun JDK，最好使用-Xverbosegclog:file_name（生成能解析的XML格式）来指定一下，否则默认文件中会包含其它信息，工具讲无法以图像显示，还要自己修改文件，比较麻烦的。

IBM Pattern Modeling and Analysis Tool for Java Garbage Collector (PMAT)这个工具大同小异，个人使用它只是觉得提供的优化建议可以和上述工具互补，比如它会计算一个适合的-Xk -Xp值出来。

对于HP-UX上生成的垃圾回收日志，我们还可以用HPjmeter下的HPjtune来分析。

Related posts:

• Java性能优化参考资料
• Linux 性能监控
• 你需要多大的池？— WebSphere性能优化（一）
• 两个关于JAVA性能优化的PPT
• JAVA性能优化—编写符合GC胃口的程序

下文主要内容来自http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/welcome_nd.html 和IBM developworks中的《如何在WebSphere中解决jar包冲突》一文，我把个人觉得最容易理解的部分总结在一起，方便学习和快速的解决问题。

使用的类装入器以及使用顺序

WebSphere Application Server 的运行时环境按以下顺序使用下列类装入器来查找和装入应用程序的新类：

1. Java 虚拟机创建的引导程序、扩展和 CLASSPATH 类装入器引导程序类装入器使用引导类路径（通常是 jre/lib 中的类）找到并装入类。扩展类装入器使用系统属性 java.ext.dirs（通常是 jre/lib/ext）找到并装入类。CLASSPATH 类装入器使用 CLASSPATH 环境变量查找和装入类。CLASSPATH 类装入器装入 WebSphere Application Server 产品在 j2ee.jar 文件中提供的 Java 2 Platform, Enterprise Edition（J2EE）应用程序编程接口（API）。由于这个类装入器装入 J2EE API，所以，可以将依赖于 J2EE API 的库添加到类路径系统属性中以扩展服务器类路径。但是，扩展服务器的类路径的首选方法是添加共享库。
2. WebSphere 扩展类装入器WebSphere 扩展类装入器装入在运行时需要的 WebSphere Application Server 类。扩展类装入器使用 ws.ext.dirs 系统属性来确定装入类时所使用的路径。ws.ext.dirs 类路径中的每个目录和这些目录中的每个 Java 归档（JAR）文件或 ZIP 文件都添加到此类装入器使用的类路径中。如果安装在服务器上的应用程序模块引用了与资源提供程序相关联的资源，并且该提供程序指定了资源驱动程序的目录名称，那么 WebSphere 扩展类装入器还将资源提供程序类装入到服务器中。
3. 一个或多个应用程序模块类装入器，它们负责装入在服务器中运行的企业应用程序的元素应用程序元素可以是 Web 模块、企业 bean（EJB）模块、资源适配器归档（RAR 文件）和依赖项 JAR 文件。应用程序类装入器按照 J2EE 类装入规则从企业应用程序装入类和 JAR 文件。WebSphere Application Server 允许使共享库与应用程序相关联。
4. 零个或多个 Web 模块类装入器缺省情况下，Web 模块类装入器装入 WEB-INF/classes 和 WEB-INF/lib 目录的内容。Web 模块类装入器是应用程序类装入器的子代。可以指定使用应用程序类装入器来装入 Web 模块的内容，而不是使用 Web 模块类装入器来装入这些内容。

关于WebSphere的类加载器的层次结构，以下的几点说明可能更有助于进一步的理解类的查找和加载过程：

• 每个类加载器负责在自身定义的类路径上进行查找和加载类。
• 一个子类加载器能够委托它的父类加载器查找和加载类，一个加载类的请求会从子类加载器发送到父类加载器，但是从来不会从父类加载器发送到子类加载器。
• 一旦一个类被成功加载，JVM 会缓存这个类直至其生命周期结束，并把它和相应的类加载器关联在一起，这意味着不同的类加载器可以加载相同名字的类。
• 如果一个加载的类依赖于另一个或一些类，那么这些被依赖的类必须存在于这个类的类加载器查找路径上，或者父类加载器查找路径上。
• 如果一个类加载器以及它所有的父类加载器都无法找到所需的类，系统就会抛出ClassNotFoundExecption异常或者NoClassDefFoundError的错误。

类装入器隔离策略

WebSphere中对类加载器有一些相关的配置，称为类加载器策略（class loader policy）。类加载器策略指类加载器的独立策略（class loader isolation policy）,通过类加载器策略设置，我们可以为WAS和应用程序的类加载器进行独立定义。

每个WAS可以配置自己的应用程序类加载器策略，WAS中的每个应用程序也可以配置自己的Web模块类加载器策略，下面我们对这两种策略分别介绍。

1．应用服务器（WAS）配置：应用程序类加载器策略

应用服务器对应用程序类加载器策略有两种配置：

• Single：整个应用服务器上的所有应用程序使用同一个类加载器。在这种配置下，每个应用程序不再有自己的类加载器。
• Multiple：应用服务器上的每个应用程序使用自己的类加载器。

2．应用程序配置：Web模块类加载器策略

应用程序中对Web模块类加载器有两种配置：

• Application：整个应用程序内的所有的实用程序jar包和Web模块使用同一个类加载器。
• Module：应用程序内的每个Web模块使用自己的类加载器。应用程序的类加载器仍然存在，负责加载应用程序中Web模块以外的其它类，包括所有的实用程序jar包。

从上面的定义可以看出，不同的类加载器策略的配置下，类加载器的层次结构上的某些类加载器可能不存在。比如在应用程序服务器的应用程序类加载器策略定义为single的情况下，应用程序的类加载器将不存在，同一个应用服务器上的所有应用程序将共用同一个类加载器，这也就意味着不同的应用程序之间的类是共享的，应用程序间不能存在同名的类。

类装入器方式

类加载器有一个重要的属性：委托模式（Delegation Mode，有时也称为加载方式：Classloader mode）。委托模式决定了类加载器在查找一个类的时候， 是先查找类加载器自身指定的类路径还是先查找父类加载器上的类路径。

类加载器的委托模式有两个取值：

• Parent_First：在加载类的时候，在从类加载器自身的类路径上查找加载类之前，首先尝试在父类加载器的类路径上查找和加载类。
• Parent_Last：在加载类的时候，首先尝试从自己的类路径上查找加载类，在找不到的情况下，再尝试父类加载器类路径。

有了委托模式的概念，我们可以更加灵活的配置在类加载器的层次结构中类的加载和查找方式。表1中给出了在WebSphere的类加载器层次结构中各个类加载器的委托模式的定义，并给出了不同的类加载器内类的生命周期。

问题解答

具体分析引起jar包冲突的情况，主要有三种：

• 多个应用程序间jar包冲突：多个应用程序间由于使用了共享jar包的不同版本而造成jar包版本冲突。
• 应用程序中多个Web模块间jar包冲突：同一个应用程序内部，不同的Web模块间同时使用一个jar包的不同版本而造成jar包版本冲突。
• 应用程序中同一个Web模块内jar包冲突：同一个应用程序内部，同一个Web模块内，由于需要同时使用同一个jar包的两个版本而造成的jar包冲突

本部分根据这三种jar包冲突的情况，讨论三种解决jar包冲突的办法，并具体讨论三种解决办法的实现步骤和适用情况：

• 共享库方式解决jar包冲突：主要解决应用程序间的jar包冲突问题
• 打包到Web模块中解决jar包冲突：主要解决应用程序中多个Web模块间jar包冲突问题
• 命令行运行方式解决jar包冲突：主要解决应用程序中同一个Web模块内jar包冲突问题

详细操作过程参考《如何在WebSphere中解决jar包冲突》一文

扩展阅读

类装入器

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/crun_classload.html

类装入异常

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/rtrb_classload_viewer.html

类装入器查看器设置（排查重要工具）

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/utrb_classload_viewer.html

Related posts:

• Java 类加载器的又一篇文章
• 再谈WebSphere的类加载和故障排查
• 软硬兼施 优化 WebSphere Application Server
• Websphere系列介绍
• 一次WebSphere性能问题诊断过程

下面是我的排错经过：

查看无法提供服务的app2的systemout.log日志，发现从昨天晚上5点09分后，没有新的日志输出。最后的日志为

查看system.err文件，没有发现有价值的内容

于是查看ffdc目录下的17：09生成的日志，在APP2_7b2c7b2c_09.04.15_17.09.27_0.txt中发现有Stack Dump = javax.imageio.IIOException: Can’t create output stream!信息。

于是使用ulimit –a命令查看AIX的limit参数

发现一个进程可以打开的最大文件数为2000.

用ps –ef | grep java命令找到app2的sid，然后用procfiles sid命令查看app2的进程现在打开了多少文件

APP2:/was/IBM/WebSphere/AppServer/profiles/AppSrv01/bin#procfiles 815304

815304 : /was/IBM/WebSphere/AppServer/java/bin/java -Declipse.security -Dwas.status.sock

Current rlimit: 2000 file descriptors

………………

1993: S_IFREG mode:0444 dev:10,15 ino:160745 uid:0 gid:0 rdev:0,0

O_RDONLY size:15694

1994: S_IFREG mode:0444 dev:10,15 ino:160745 uid:0 gid:0 rdev:0,0

O_RDONLY size:15694

1995: S_IFREG mode:0444 dev:10,15 ino:160745 uid:0 gid:0 rdev:0,0

O_RDONLY size:15694

1999: S_IFREG mode:0444 dev:10,15 ino:164300 uid:0 gid:0 rdev:0,0

O_RDONLY size:1042

打开文件数已经到达2000，于是app2无法创建新的systemout.log日志文件，也就无法再提供服务。

由此分析得AIX的nofiles参数对于websphere来说不够大（对于Hp-ux，安装前调整系统参数时就需要把maxfiles调整为8192，但是AIX内核是自调整，所以IBM安装要求上没有提到需要手动修改什么参数）特别是在压力测试时候，短时间内的积累可能会达到2000的限制，实际生产环境中也可能会遇到如此情况，当然集群中另外一台APP跑的好好的也挺让人奇怪。

接下来就是调整ulimit中的nofiles限制到4096，然后重启nodeagent，再由控制台重启app即可。当然也可以直接用命令重启app，但是因为nodeagent没有重启过，环境变量没有生效，下次在控制台中重启app后nofiles依旧会被限制在2000。

Related posts:

• Google Docs不能打开问题
• Weblogic10.3.0在AIX6.1、JDK1.6下挂起解决方法
• 各司其职-WebSphere的动静分离
• Server Node Cell Cluster—Websphere拓扑结构及术语介绍上
• 士别三日