记录处理那次系统性能故障的过程

那次为了下载jprofiler7来测试系统的内存泄露点，还主动去开通了迅雷三个月的会员，虽然钱不多。因为那时候下载这个软件速度非常慢，才几K的速度，而这个软件却有70多兆，一冲动就花钱开了个会员，心想离线下载也许会快点，结果也没快多少，估计是国外服务器的问题吧。

后来终于下载完了，把软件传到现网的服务器上去又花了一部分时间，因为使用VPN来连接的，速度也不快。

传上去后，一开始以为能够直接不用重启weblogic，jprofiler能够直接attach到那个weblogic的进程，结果试了好久也不行，无奈只有在weblogic的启动参数中加了启动参数：

-agentpath:/home/xxxuser/xxxme/jprofiler7/bin/hpux-ia64w/libjprofilerti.so

直到那台服务器因没有足够的内存跑不动了，才叫pso来重启weblogic，8G的内存都用完了，这是什么内存泄露啊。后来发现系统一开始处理任务的速度越快，服务器也就会死的越快。

加上上面的启动命令后，就可以直接使用jprofiler连上weblogic的进程查看heap的使用情况，包括每个对象的数量及占用内存空间的大小。

观察了几次，就发现有几个关于Hibernate的对象数量特别多，而且是一直增长的。因我没用使用过Hibernate，对它的初始化产生的对象及日志没有足够的重视，当时还没有立即发现问题的所在。问了下身边有用过这个框架的同事，说可能是多次初始化了Hibernate的SessionFactory。

于是查找jpa使用Hibernate的地方，的确发现有一个地方工厂方法每被调用一次，就产生一个SessionFactory对象，原始的代码如下：

public static EntityManagerFactory getPlatformEntityManagerFactory() {
  EntityManagerFactory factory = Persistence.createEntityManagerFactory("xxxDS");
  return factory;
}

不知道当初那些人是怎么写的代码，也不考虑一下是否合适，就写上去了，结果排查这个问题实在是太费劲了，起初还以为是自己模块的问题。

结果因为这个问题导致了一系列的问题，管理有点混乱啊。

而我除了要处理本身模块的问题外，还要处理各种各样的问题，包括性能，功能以及接口调试，而我也只是一个普通的开发。

那时的我感觉真的好累，我是否有必要做这么多啊？