前段时间公司打造了自己的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 ut = 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[] utput = 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 utputString = 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 ut = new ObjectOutputStream (dos);
out.write(加密数据);
byte[] data = byteArrayOutputStream.toByteArray();
在finally语句中执行{
def.end();
close();
}
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/axman/archive/2010/05/14/5591301.aspx
