只要connection没有被close就一定会发生connection leak。先前我对此也是笃信不疑。直到有一次我在作系统压力测试时碰巧发现没有close掉的connection居然没发生leak,这让我很吃惊。于是专门做了一个实验来验证没有close的connection是否可以被GC回收。下面就把这个简单的试验说一下:
先写一个很简单的jsp,从pool中申请connection,把申请出的connection存放在jsp的局部变量中,用完后不关它。然后用类似LR压力测试工具录制一段简单脚本,制造若干并发去访问这个页面,或者干脆就使劲刷新这个jsp,然后观察WLS connection pool的状态,看看connection是不是一会就分配不出来了?答案是,connection pool没发生leak,connection一直可以从pool中申请出来。
让我们分析一下,为什么connection没有发生leak。
当GC发现connection对象已经没有被别的对象引用时,就把它当“垃圾”回收了。在connection被destroy掉的时候,应该是connection的finalize方法对connection是否close做了判断,如果没有close,那就close这个connection,于是pool回收了这个Connection。
由于不清楚WebLogic关于Connection pool的实现机制,上述connection回收过程的具体流程实属臆测,但有一点可以肯定,connection确实是被pool回收了。
做完这个实验很惭愧,惭愧的是把SUN和BEA想的太简单了,其实BEA聪明的利用了看似很傻的GC实现了资源的回收,呵呵。
先写一个很简单的jsp,从pool中申请connection,把申请出的connection存放在jsp的局部变量中,用完后不关它。然后用类似LR压力测试工具录制一段简单脚本,制造若干并发去访问这个页面,或者干脆就使劲刷新这个jsp,然后观察WLS connection pool的状态,看看connection是不是一会就分配不出来了?答案是,connection pool没发生leak,connection一直可以从pool中申请出来。
让我们分析一下,为什么connection没有发生leak。
当GC发现connection对象已经没有被别的对象引用时,就把它当“垃圾”回收了。在connection被destroy掉的时候,应该是connection的finalize方法对connection是否close做了判断,如果没有close,那就close这个connection,于是pool回收了这个Connection。
由于不清楚WebLogic关于Connection pool的实现机制,上述connection回收过程的具体流程实属臆测,但有一点可以肯定,connection确实是被pool回收了。
做完这个实验很惭愧,惭愧的是把SUN和BEA想的太简单了,其实BEA聪明的利用了看似很傻的GC实现了资源的回收,呵呵。