调优须谨慎数据说话.doc

调优须谨慎 数据说话 吴战胜080723 调优（optimize）须谨慎，数据说话。前半句说的是调优时所应该持有的态度，后半句说的是对调优成果的确认。说到“调优”很自然会想起许多大师前辈们对我们的告诫（附录摘录了一则），这些告诫以箴言的形式被许多人引用传诵，尽管表达的内容不尽相同，但是“谨慎”的基调是一致的。不成熟或者草率的调优，不仅不能给系统带来任何好处，反而会让系统变得更复杂，性能更加让人担忧。 底下是一次关于从传统IO到NIO一次调优的实践，从这次的实践中出现的问题上，我们再次强调调优时“谨慎”的态度，以及调优后通过数据反复确认的重要性。 问题描述 我们都知道JDK1.4引入的NIO是为了提高JAVA IO的效率，而且伴随着NIO的引入，传统的基于流的IO底层的实现也引入了NIO的特征，做了相应的改动。不过，即便是做了整改，据Thinking in java里面比较描述，传统的IO在效率上还是比不上NIO的效率。因为 我们现在的系统中涉及到大量的文件读写操作，所以考虑将传统IO读写文件的操作更改为NIO的方式，尽管NIO的方式会复杂一点，但是只要做一次封装加入开发工具箱，就一劳永逸了，性能的好处也就伴随着整个或者以后的开发进程了。 基于此，将如下传统的IO文件读取方式： Public static String readFileToString(String filename,String charset)throws IOException { File f = new File(filename); BufferedReader br = null; StringBuffer sb = new StringBuffer(); Try { br = new BufferedReader(new InputStreamReader(new FileInputStream(f),charset); String line = null; While((line=br.readLine()) != null) { sb . append(line+”\r\n”); } }finally { If(br != null) Br.close(); } Return sb.toString(); } 改为NIO的方式： Public static String readFileToString(String filename,Charset cs) { File f = new File(fileName); StringBuffer buffer = new StringBuffer(); If(f.exists()) { FileChannel fc = new FileInputStream(f).getChannel(); ByteBuffer buff = ByteBuffer.allocate(1024*1000); While(fc.read(buff)!=-1) { Buff.flip(); Buffer.append(cs.decode(buff)); Buffer.clear(); } Fc.close(); } Return buffer.toString(); } 看看NIO的实现版本，很经典的做法，似乎没什么不妥。心理暗自较好，觉得这样一来，文件读取已经获得了些额外性能上的好处了。 后来又想想，尽管TIJ里面做过NIO与StandardIO的比较，而且结论是NIO快，但是这个效率的提升从来都没有感受自己切身感受过。现在手头恰好就有两个版本的读写函数，何不来个比较，NIO想来应该快，但是到底会快多少？ 于是写如下代码进行比较测试： Long begin = System.currentTimeMillis(); For(int i=0;iloopCount;i++) { readFileToString(fileName); } Long end = System.currentTimeMillis(); System.out.println(end-begin); 这不测则已，一测着实吓了一跳。如下是测试结果： Io type\loopCount 100 1000 10000 Standard io 32 110 756 New io 297 3156 29437 不禁冷汗涔涔… …调优后的方式尽然比原来的要慢那么多，如果当时想当然地放过这个问题，那么就意味着，这个频繁读文件的地方