String变量引起的Loadrunner资源泄漏

在压力测试中，通常碰到TPS平稳持续下降的现象，通常为负载机存在资源泄漏。一般有两种：1.连接数，2.JVM内存。本文就第2种类型进行测试和分析。

 

测试数据：

1.       String方式

public int action() throws Throwable {

lr.start_transaction("string");

 

String a = "The time is "+System.currentTimeMillis();

        String b = "The time is "+System.currentTimeMillis();

        String c = "The time is "+System.currentTimeMillis();

        String d = "The time is "+System.currentTimeMillis();

        String e = "The time is "+System.currentTimeMillis();

         lr.end_transaction("stringl", lr.AUTO);

 

写了个简单的给String变量赋值的代码，使用当前时间保证每次赋值都会变化。10个线程执行30分钟。

 

测试结果：

 

TPS持续下降：

 

YGC非常频繁：

同时CPU有走高的趋势

 

 

2.       StringBuilder方式一（New对象放在Action内）

 

//将new放在Action中，每次迭代都new一个对象

 

         public int action() throws Throwable {

         lr.start_transaction("StringBuilder");

         StringBuilder bf1=new StringBuilder();

         StringBuilder bf2=new StringBuilder();

         StringBuilder bf3=new StringBuilder();

         StringBuilder bf4=new StringBuilder();

         StringBuilder bf5=new StringBuilder();

         bf1.append("The time is ");

        bf2.append("The time is ");

         bf3.append("The time is ");

         bf4.append("The time is ");

         bf5.append("The time is ");

         bf1.append(System.currentTimeMillis());

        bf2.append(System.currentTimeMillis());

         bf3.append(System.currentTimeMillis());

         bf4.append(System.currentTimeMillis());

         bf5.append(System.currentTimeMillis());

        bf1.setLength(0);

         bf2.setLength(0);

        bf3.setLength(0);

         bf4.setLength(0);

         bf5.setLength(0);

         lr.end_transaction("StringBuilder", lr.AUTO);

 

TPS：

         

         TPS同样会下降

 

堆内存

 

 

 

3.       StringBuilder方式二（New对象放在Action外）

 

public class Actions

{

         StringBuilder bf1=new StringBuilder();

         StringBuilder bf2=new StringBuilder();

         StringBuilder bf3=new StringBuilder();

         StringBuilder bf4=new StringBuilder();

         StringBuilder bf5=new StringBuilder();

          

         public int init() throws Throwable {

 

                   return 0;

         }//end of init

 

 

         public int action() throws Throwable {

                  

         lr.start_transaction("StringBuilder");

 

         bf1.append("The time is ");

        bf2.append("The time is ");

         bf3.append("The time is ");

         bf4.append("The time is ");

         bf5.append("The time is ");

         bf1.append(System.currentTimeMillis());

        bf2.append(System.currentTimeMillis());

         bf3.append(System.currentTimeMillis());

         bf4.append(System.currentTimeMillis());

         bf5.append(System.currentTimeMillis());

        bf1.setLength(0);

         bf2.setLength(0);

        bf3.setLength(0);

         bf4.setLength(0);

         bf5.setLength(0);

         lr.end_transaction("StringBuilder", lr.AUTO);

 

                   return 0;

         }//end of action

 

 

TPS：

TPS有轻微下降，但下降幅度比前两种方式要改善很多。

 

堆内存

从内存Dump中看到StringBuilder 实例有50个 （10用户，每个用户new 5个对象），但仍然有其他对象占很大比重，不清楚是否是Loadrunner本身所占用。

 

 

测试结果：

1.       采用String类型给变量赋值，半小时看到TPS明显下降，并且负载机CPU有上升趋势，剩余内存有下降趋势；

2.       采用StringBuilder给变量赋值，new StringBuilder对象放在Action内（每次迭代均new一次），执行半小时，现象同String类型差不多；

3.       采用StringBuilder给变量赋值，new StringBuilder对象放在Action外，执行半小时，TPS有所下降，但下降趋势比前两个场景要小很多。

 

原因分析：

1.       String 类型和 StringBuffer/StringBuilder 类型的主要性能区别其实在于 String 是不可变的对象，因此在每次对 String 类型进行改变的时候其实都等同于生成了一个新的 String 对象，（脚本中变量取当前时间，保证每次取值不同） ，new 对象需要消耗资源，并且当内存中无引用对象多了以后， JVM 的 GC 就会开始工作，导致GC频繁；

2.       由于本次压力测试与MAM和BPS有一个共同特点，TPS比较高，因此可能是对象生成速度非常快，GC来不及回收，导致对象不断累积，并且GC越来越频繁导致了CPU上升和TPS逐渐下降，一般应用的TPS较低，因此有足够时间进行回收；

3.       另外，采用Loadrunner Java Vuser方式，LR本身也会生成一些对象，在高TPS下可能会出现对象来不及释放导致性能下降。