Webloic JDBC连接泄漏

执行线程篇  

说实话，执行线程的设置没有什么准确的计算公式，一切都得依赖测试和实际的运行情况。设置少了，会有等待队列；设置多了，性能也未必高。但是，对于调优，我还是建议先不足再增加，即先少后多。通常情况下，如果一开始就把各种资源设置的很高，那么很可能问题就被掩盖了。如果设置的少，当出现故障时会有比较明显的表征。

虽然没有计算公式，但是根据经验值，一颗CPU可以配置25-30之间的执行线程，当然，也有人说可以按照50线程/CPU计算。这个经验值的前提是，主机上没有其他的大型的占用资源较多的应用在运行。也就是说，一台主机上WebLogic Server实例，无论是一个，还是多个，他们的执行线程的总和大概是25*CPU数量到30*CPU数量之间。我经历过一个应用的压力测试，4CPU的 HP主机，同样的测试脚本，在不同的执行线程配置下进行测试和比较。结果是配置50和120的时候，TPS在300左右，当配置70的时候，能够达到 400左右。有可能70也不是最好的，但是至少说明执行线程的配置不是越多越好。

说到这里，想起来另外一个比较常见的问题，就是设置的执行线程的数量还算合适，没有过高也没有过低，但是就是在压力测试的时候，发现TPS值很低，CPU的利用率也上不去。我遇到的有两种情况：

1. 操作系统的补丁问题

在HP-UX上执行大型Java应用，需要打上很多的补丁，在HP的官方站点可以查到

http://www.hp.com/products1/unix/java/patches/index.html

其中有一个补丁包就是和线程调度相关的，如果不打上这些补丁，那么对于Java的线程调度存在问题，导致CPU利用率也不高，但是执行效率较低，甚至可能导致进程Crash。所以在安装软件之前去官方网站查看所需要的补丁以及经过认证的相关产品是一个好习惯。

2. 同步代码

如果代码中存在同步方法，并且是调用率比较高的，那么可能会出现CPU利用率低并且TPS也低的情况。通常Java应用自身的同步代码并不是很多，但是所用到的一些扩展的包，就有可能用到了同步代码。最典型的一个例子是Log4j. 给出一个示例的Thread Dump

“ExecuteThread: ‘152′ for queue: ‘weblogic.kernel.Default’” daemon prio=1 tid=0×08d9fef8 nid=0×1f28 waiting for monitor entry [5a1fd000..5a1fe24c]
at org.apache.log4j.Category.callAppenders(Category.java:185)
- waiting to lock <0×838664b0> (a org.apache.log4j.spi.RootCategory)
at org.apache.log4j.Category.forcedLog(Category.java:372)
at org.apache.log4j.Category.info(Category.java:674)

…

152号执行线程在等待<0×838664b0> (a org.apache.log4j.spi.RootCategory) 对象被其他线程释放同步锁。在完整的Thread dump中可以看出，有大量的线程都在等待同一个对象。这个对象被158号线程使用：

“ExecuteThread: ‘158′ for queue: ‘weblogic.kernel.Default’” daemon prio=1 tid=0×08da4d28 nid=0×1f28 waiting for monitor entry [59efd000..59efe24c]
at java.lang.StackTraceElement.toString(StackTraceElement.java:130)
at java.lang.String.valueOf(String.java:2131)
at java.lang.StringBuffer.append(StringBuffer.java:370)
- locked <0xa32e5370> (a java.lang.StringBuffer)
at java.lang.Throwable.printStackTrace(Throwable.java:512)
- locked <0xa326af28> (a org.apache.log4j.spi.VectorWriter)
at org.apache.log4j.spi.ThrowableInformation.getThrowableStrRep(ThrowableInformation.java:50)
at org.apache.log4j.spi.LoggingEvent.getThrowableStrRep(LoggingEvent.java:333)
at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:295)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:150)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:221)
- locked <0×83866430> (a org.apache.log4j.ConsoleAppender)
at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:57)
at org.apache.log4j.Category.callAppenders(Category.java:187)
- locked <0×838664b0> (a org.apache.log4j.spi.RootCategory)
at org.apache.log4j.Category.forcedLog(Category.java:372)

由于Log4j的同步代码导致出现上述的问题。所以，如果不是为了跟踪问题，尽量将Log4j的日志级别设置的高一些。减少同步代码的调用，能够极大的利用硬件资源。

如果一个应用中有部分页面执行时间较长，并且使用频率较低，可以为这些JSP/Servlet或者EJB配置独立的执行线程（当然了，尽量优化应用才是治本之道），将执行效率低下的放到一个执行线程队列，将效率高的放到一个执行线程队列，这样就避免因为一个执行效率低的页面影响整个应用了。

下面是简单的步骤说明：

1. 配置整个Web应用到单独的执行队列

编辑web应用的weblogic.xml，加入<wl-dispatch-policy>节点： <wl-dispatch-policy>yourexecutequeue</wl-dispatch-policy>

2. 配置JSP/Servlet到单独的执行队列

如果是JSP，编辑web应用的web.xml，加入一个<servlet>节点

<servlet>
<servlet-name>myServlet</servlet-name>
<jsp-file>/context/package/file.jsp</jsp-file>
</servlet>

然后在weblogic.xml中对这些Servlet进行配置

<servlet-descriptor>
<servlet-name>the servlet name or the servlet for the jsp file</servlet-name>
<dispatch-policy>your customized queue name</dispatch-policy>
</servlet-descriptor>

3. 配置EJB到单独的执行队列

编辑weblogic-ejb-jar.xml，例如：

<weblogic-enterprise-bean>
<ejb-name>Hello</ejb-name>
<jndi-name>lab.ejb.Hello</jndi-name>
<dispatch-policy>your customized queue name</dispatch-policy>
</weblogic-enterprise-bean>

详细可以参考：

Developing Web Applications for WebLogic Server http://edocs.bea.com/wls/docs81/webapp/index.html

Programming WebLogic Enterprise JavaBeans http://edocs.bea.com/wls/docs81/ejb/index.html

JDBC连接池篇  

JDBC连接池是J2EE应用最常用的一个服务，JDBC连接池的设置相对比较简单一些。JDBC连接池的设置最主要的是Intial Capcity和Maximum Capacity两个属性。下面对于JDBC连接池的几个属性及优化配置方案进行描述：

Initial Capacity: 初始容量，即WebLogic Server在建立连接池的时候创建的连接数量

Maximum Capacity: 最大容量，即WebLogic Server允许的在这个连接池中的连接的最大数量。

通常，初始容量和最大容量设置为相等，并且不小于执行线程的数量。如果你的应用中配置了自定义执行线程队列，那么就要计算全部的用来给应用工作的线程的数量。如此设置才能够起到Pool的作用，避免在应用运行过程中出现创建JDBC连接的请求。因为创建JDBC连接对于WebLogic Server和数据库服务器来说，都是开销比较大的动作。如果应用中存在在一个线程中获取多个连接的情况，那么初始容量和最大容量应该大于执行线程的数量，甚至需要成倍增加。比如下面的JSP代码就会导致一个线程工作占用2个连接：

ctx = new InitialContext();
ds = (DataSource)ctx.lookup(”lab.ds.pbjade”);
conn = ds.getConnection();
// do some query operations

conn2 = ds.getConnection();
// do some query operations

以上这段代码，在执行过程中，第一个连接conn关闭之前，又获取了第二个连接conn2，这样一来，这个JSP页面在执行的时候（由一个线程来执行），会同时获取2个连接，连接池容量的最优化设置是执行线程的数量的2倍。因为在极端情况下，如果在同一时刻，所有的请求都指向这个页面，那么就需要执行线程数量2倍的连接才不会出现连接等待。

Capcity Increment: 增长步长。如果初始容量和最大容量不相等，并且需要更多的连接时，WebLogic Server一次建立新连接的数量。

Allow Shrinking: 允许自动收缩。如果连接池的初始容量和最大容量不相等，那么当池中的连接大于初始容量时，经过Shrink Frequency时间，如果连接池中的活动连接不高于初始容量个，那么连接池中连接的数量会减少到初始容量大。

上面这几个参数是配置相关的，通常Initial Capacity=Maximum Capacity 并且>=执行线程的数量，并且不选择Allow Shrinking选项，避免不必要的周期检查。

如 果WebLogic Server和数据库服务器之间的网络连接不稳定，或者两个服务器之间存在防火墙，导致JDBC连接不稳定，WebLogic Server还提供了一些测试策略以尽量保证应用难道的连接是有效的。主要有3个选项：Test Reserved Connections、Test Created Connections、Test Released Connections。测试的时机分别是应用获取连接、WebLogic Server创建连接、应用释放连接。通常这3个选项只需选择Test Reserved Connections即可，无需全部选择。根据测试数据，可能会有3%左右的性能下降。所以如果不是必要，也不必使用这些选项。

在使用JDBC连接池的过程中，最常见的一个问题就是连接池泄漏问题。一个池里面的资源是有限的，应用用完之后应该还回到池中，否则池中的资源会被耗尽。 WebLogic Server提供了一个Inactive Connection Timeout选项，默认是60秒，如果一个连接被应用拿走之后，超过这个时间还没有还回来，WebLogic Server会强制将这个连接回收。如果应用中不存在连接泄漏的问题，则不需要这个选项。设置为0即可禁用。

总结一下，连接池的设置相对比较简单，主要是初始容量及最大容量两个参数。其他的选项不需要的可以去掉，避免不必要的性能开销。