java内存泄漏原因、判定及解决方法——再提5_Weblogic8.1SP1+Spring1.1.5+Hibernate2.1.8+Struts1.1会导致内存泄漏

Linux版本：
# uname -a
Linux ykcuss1 2.4.21-20.ELsmp #1 SMP Wed Aug 18 20:46:40 EDT 2004 i686 i686 i386 GNU/Linux
# cat /proc/version
Linux version 2.4.21-20.ELsmp (bhcompi

全部加入SessionFactory.evict和session.clear后，实践证明。此方法是无效的，不能避免内存泄露。但我的程序中仍然会保留它。

再次本着怀疑一切的态度来一次大升级：
1。升级JDK到1.4的最新版本：j2sdk1.4.2_16
2。spring 已经是此版本中最新的了1.1.5，hibernate 已经是此版本中最新的了2.1.8不用动了。
3。重新配置ssh
4。修改JDK的参数：-Xms256m -Xmx1024m -XX:MaxPermSize=512m
把以

版本信息：
WebLogic Server 8.1 SP1迁移到apache-tomcat-4.1.37-LE-jdk1.4（使用JDK1.4的最新版本）
j2sdk1.4.2_16
Spring-Version: 1.1.5
Hibernate-Version: 2.1.7（通过hibernate.jar大小实际是2.1.8，MANIFEST.MF上写的2.1.7，并且下载官方2.1.8MANIFEST.MF上写的也是2.1.7）
Struts:1.1

迁移步骤和遇到的问题：
首先当然是下jdk和Tomcat了。然后在Linux上解压(Linux下常用压缩格式的压缩与解压方法)

根据java内存泄露原因、判定及解决方法——再提2的计划，先研究Struts+Spring+Hibernate的正确配置：

网上的常用配置方式
从网上下了个ssh的demo，发现这个例子中使用的了HibernateTransactionManager事务管理器+TransactionProxyFactoryBean代理类，实现自动管理事务的功能。但每个DAO肯定都要手工配置一个代理类。

目前程序使用的配置方式与其区别

年前2月3日做的关于Introspector的改动，过完年后，13日去看了一下，生产环境下运行的2个服务器F，和Y，内存都在增长。并且基本没有减缓。实践证明并不是这个问题导致内存泄漏。

详细分析日志发现问题：
1。F服务器晚上12点的内存突然增长月20M左右，然后缓慢下降到接近原来的水平，但还是要高一点。
2。F服务器早8点左右的内存增长，比较突出约20M左右，这个是可以理解的，早上用户

前几篇篇文章里由于
1。资料的阅读不够详细
2。资料的阅读不够广泛
3，对许多一条线索追踪的不够彻底。
所以有一些错误。

最近在老黄的帮助下有了一些新的进展。

思路1：使用新的内存泄露监控工具，JProfiler。可以实现远程监控虚拟机。(其实JProbe也可以，只不过我没有查到，或者说了解的不彻底)效率比HROF高很多。应用程序能够起来，但非常不稳定。负载比较小的情况下，挺1天就不行了。
JProfiler使用方法：在服务器安装JProfiler，或拷贝JProf

更新程序发现的同时查看其他服务器堆占用情况，个别很高：

把增加了详细日志信息信息（每个请求，每个定时触发）的程序更新到了一个服务器上。这个服务器就是昨天因为heap满非常慢，而被kill掉weblogic的服务器。
通过weblogic 控制台，查看了所有运行本项目的服务器。发现有的服务器堆占用很高4,5百兆(我最大设置的是1G)，但通过weblogic的强制垃圾回收就能收回来，将为100M左右，有的甚至更少也就80M左右。
从日志上看一般执行的都是GC，强制垃圾回收执行的是Full GC，有事也会自动触发Full G

从profiler生产环境虚拟机这条路基本已经断了。那么，换了一个角度来思考问题。

从可能引起问题的原因来思考。检查程序代码。项目使用了Struts+Spring+Hibernate。

检查代码：

首要的应该是去掉全局变量。搜索了项目中的所有static类型的成员变量。主要是一些日志类，都被我去掉了。使用了static的，如果不是基本类型，都被我加入了输出长度的日志。然后更新，