EAS性能问题解决跟踪-java内存泄漏相关

近期X为客户反馈EAS系统出现实例宕机现象，经总部研发专家的跟踪发现是byte[]存放在LinkedList没有及时释放（附件批量下载时），该问题应引起开发人员的高度重视，同时从网上查超找了一些java内存泄漏注意事项。

问题描述：

1、从实例的崩溃时产生的dump文件可以看到，大量的byte[]对象占用了大量的堆内存，高达3.3GB

2、查看这些byte[] 对象的根引用，发现这些对象的根引用在栈上，并且存放在LinkedList集合里面。

 

转到javacore日志，发现好几个线程有附件上传的调用：

 CommonAttamentController这个类在sp_ecc_waf_web.jar中。反编译查看相关的方法调用，发现有将文件字节存储在内存中的行为，在批量下载大量文件的时候会造成内存不足从而引起 OutOfMemoryError：

解决方法：在存储byte[]的LinkedList使用之后 释放缓存

 

追加描述：

在以上方式处理后还是会发现内存溢出的问题，最终解决方式时痛定思痛将整个代码梳理改造，不可以再linkedList缓存中方byte字节数组。（因这些代码是之前的开发人员写的，原本只是想以最小的改动解决问题，最后不得不静下心来将整个代码逻辑读懂并修改优化）

以下java代码内存泄漏注意事项摘自网络：

1、尽早释放无用对象的引用。特别是大对象和集合对象，通过置为NULL，暗示垃圾收集器来收集该对象，防止发生内存泄露。

2、程序中如果出现大量使用字符串处理，避免使用 String ，应使用 StringBuffer。
   for(Int i=0;i<100;i++)
   {
 String s1="";
 s1=s1+"abc";//不要这样写
   }
3、尽量少用静态变量，因为静态变量是全局的， GC 不会回收的；
4、避免集中创建对象尤其是大对象， JVM 会突然需要大量内存，这时必然会触发 GC 优化系统内存环境；显示的声明数组空间，而且申请数量还极大。
5、尽量运用对象池技术以提高系统性能；生命周期长的对象拥有生命周期短的对象时容易引发内存泄漏，例如大集合对象拥有大数据量的业务对象的时候，可以考虑分块进行处理，然后解决一块释放一块的策略。
5、不要在经常调用的方法中创建对象，尤其是忌讳在循环中创建对象。可以适当的使用 hashtable ， vector 创建一组对象容器，然后从容器中去取那些对象，而不用每次 new 之后又丢弃。
6、一般都是发生在开启大型文件或跟数据库一次拿了太多的数据，造成 Out Of Memory Error 的状况，这时就大概要计算一下数据量的最大值是多少，并且设定所需最小及最大的内存空间值。
7、注意集合数据类型，包括数组、树、图、链表等数据结构，这些数据结构对GC来说，回收更为复杂。
8、尽量避免在类的默认构造器中创建、初始化大量的对象，防止在调用其自类的构造器时造成不必要的内存资源浪费。

9、尽量避免强制系统做垃圾内存的回收，增长系统做垃圾回收的最终时间。

10、代码中是否有死循环或递归调用 
11、是否有大循环重复产生新对象实体。
12、检查List、MAP等集合对象是否有使用完后，未清除的问题。List、MAP等集合对象会始终存有对对象的引用，使得这些对象不能被GC回收。

下面给出了一个简单的内存泄露的例子。在这个例子中，我们循环申请Object对象，并将所申请的对象放入一个Vector中，如果我们仅仅释放引用本身，那么Vector仍然引用该对象，所以这个对象对GC来说是不可回收的。

Vector v=new Vector(10);
for (int i=1;i<100; i++)
{
 Object o=new Object();
 v.add(o);
 o=null; 
}

 

函数内，如果可以清除的，清除集合中对象

Map<Object,Object> v=new Map<Object,Object>();
for (int i=1;i<100; i++)
{
 Object o=new Object();
 v.put(i,o); 
}

v.clear();

摘自：JAVA内存泄漏