一个性能瓶颈分析的过程（一个牛人的性能测试分析思路、拜读）

本文主要是介绍一个性能瓶颈分析的过程（一个牛人的性能测试分析思路、拜读），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

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

18000个TPS左右。

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

jvisulevm监视查看到其中的加密方法占用了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策略，利用率将打更大的折扣。

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

DeflaterOutputSream dos = new DeflaterOutputSream(byteArrayOutputStream,new Deflater(Deflater.BSET_ 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);
.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();

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

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

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

end()。

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

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

DeflaterOutputSream dos = new DeflaterOutputSream(byteArrayOutputStream,def);

ObjectOutputStream out = new ObjectOutputStream (dos);

out.write(加密数据);

byte[] data = byteArrayOutputStream.toByteArray();