一个性能瓶颈分析的过程

引自http://blog.youkuaiyun.com/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自己的例子就给人一个误导：

 

 

[java]  view plain copy

 

1. // Encode a String into bytes  
2.  String inputString = "blahblahblah??";  
3.  byte[] input = inputString.getBytes("UTF-8");  
4.  // Compress the bytes  
5.  byte[] output = new byte[100];  
6.  Deflater compresser = new Deflater();  
7.  compresser.setInput(input);  
8.  compresser.finish();  
9.  int compressedDataLength = compresser.deflate(output);  
10.  // Decompress the bytes  
11.  Inflater decompresser = new Inflater();  
12.  decompresser.setInput(output, 0, compressedDataLength);  
13.  byte[] result = new byte[100];  
14.  int resultLength = decompresser.inflate(result);  
15.  decompresser.end();  
16.  // Decode the bytes into a String  
17.  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();

}

 

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