一个性能瓶颈分析的过程

引自http://blog.csdn.net/axman/article/details/5591301

前段时间公司打造了自己的WEB开发框架新版，性能比以前的两个版有很大提高。在性能基准测试时，某个测试的业务场景为

18000个TPS左右。

但是后来增加了session序列化模块后，一下子下降低到6000个TPS左右，就是因为这个模块性能一下子降低三倍。

 

jvisualvm监视查看到其中的加密方法占用了47%的CPU处理时间，于是重点测试这个方法。

 

这个方法做了三件事。

1.加密，

2.压缩，

3.base64编码成可见字符

 

加密过程虽然消耗了一定的系统资源，但经百万次循环测试性能是可以接受的。

BASE64这个可以放心，测试过N次了。

于是测试压缩算法，单线程1万次循环时耗时在秒级，我想1百万次也就应该是两三分钟吧。

结果一跑以后，系统差点死掉，响应非常慢，看看后台非JAVA线程在十几秒内竟然一下子吃掉10G的内存，大量的磁盘交换产生。

不用说，肯定是有内存泄漏，生产系统中是因为采用CMS策略来进行GC的。因为不断进行回收，所以不会出现瞬间内存都被吃光的

情况。但是对于依赖finalize来做回收的情况，虽然对象最终会被回收，但利用率大大地打了下降了。

 

这是最简单的道理，就比如一个连接，在finalize中调用了close()方法，你即使不手工调用 close()方法它最后也被回收了，但它

利用率却下降低了好多倍，假设系统只允许1个连接，从产生到JVM回收它的过程是1秒，那么在1秒内如果你每次只使用100ms,然后手工close()，那么其它线程有9次机会重新产生连接，而如果利用finalize在1秒内只有一次使用机会，这还是因为CMS策略的GC，如果是

暂停式GC策略，利用率将打更大的折扣。

 

所以最终关注压缩的代码，其实只有三行：

 

DeflaterOutputStream dos = new DeflaterOutputStream(byteArrayOutputStream,new Deflater(Deflater.BEST_ COMPRESSION,false));

ObjectOutputStream out = new ObjectOutputStream (dos);

out.write(加密数据);

byte[] data = byteArrayOutputStream.toByteArray();

//close等收尾工作。

对于输出流这种常规操作，打造平台的大牛们不可能犯低级错误，而大量的内存泄漏应该和压缩参数无关，于是直接分析

Deflater类(因为之前大多数是直接使用GZipOutputStream,对Deflater类本身并不是很熟悉)。发现文档中有对于end方法的说明是：

end

public void end()

    关闭解压缩器并放弃所有未处理的输入。此方法应该在不再使用该压缩器时调用，但是也可以由 finalize() 方法自动调用。调用此方法后，Deflater 对象的行为将是不确定的。

 

其实jdk自己的例子就给人一个误导：

 

 

// Encode a String into bytes
 String inputString = "blahblahblah??";
 byte[] input = inputString.getBytes("UTF-8");
 // Compress the bytes
 byte[] output = new byte[100];
 Deflater compresser = new Deflater();
 compresser.setInput(input);
 compresser.finish();
 int compressedDataLength = compresser.deflate(output);
 // Decompress the bytes
 Inflater decompresser = new Inflater();
 decompresser.setInput(output, 0, compressedDataLength);
 byte[] result = new byte[100];
 int resultLength = decompresser.inflate(result);
 decompresser.end();
 // Decode the bytes into a String
 String outputString = new String(result, 0, resultLength, "UTF-8");

  

 

在这个例子中，压缩的代码并没有调用compresser.end,因为仅调用一次，最后肯定会在对象被回收时调用finalize来调用end();

这在偶尔调用一两次的情况下也没有大问题。

 

另外，对于DeflaterOutputStream构造方法中，如果你没有传入Deflater,它自己new了一个Deflater,并使用useDefaultDeflater标记来

在close()中调用Deflater的end(),但如果是你自己传入的Deflater,因为可能在外部会多次复用，本着谁生产谁负责的原则，它没有为你调用

end()。

 

凡是在finalize中调用方法说明一定要保证被回收，而在密集调情况下一定不能依赖finalize，上面已经说过道理。所以一定要在用完后立即调用它以“尽早地立即回收”。所以这里应该有一个手工调用的参与，于是修改为：

 

Deflater def = new Deflater(Deflater.BEST_ COMPRESSION,false);

DeflaterOutputStream dos = new DeflaterOutputStream(byteArrayOutputStream,def);

 

ObjectOutputStream out = new ObjectOutputStream (dos);

out.write(加密数据);

byte[] data = byteArrayOutputStream.toByteArray();

在finally语句中执行{

def.end();

close();

}

 

结果，呵呵，不用多说了..................................