FileOutputStream close()方法瓶颈问题

现在要把收到的每个报文记录到单独的文件中，在做压力测试时发，FileOutputStream 中 close()方法执行需要的时间，随着系统持续压力测试时间的增长而增长，最后导致close()执行的时间在整个线程的执行时间占比越来越高，有没有什么方法改变一下这个情况。相关代码如下
[code="java"]
public static void write(byte[] msg, String fileName) {

    if (fileName.indexOf(File.separator) != -1) {
        String dirPath = fileName.substring(GatewayConstants.ZERO_INT, fileName.lastIndexOf(File.separatorChar));
        createDir(dirPath);
    }

    FileOutputStream os = null;
    try {
        os = new FileOutputStream(createFile(fileName));
        os.write(msg);
        os.flush() ;
    } catch (FileNotFoundException e) {
        logger.error("fileNotFoundException exception"+fileName, e);
    } catch (IOException e) {
        logger.error("fileOutputStream closed exception", e);
    }finally{
        try {
            if(os !=null)
                os.close() ;
        } catch (IOException e) {
            logger.error("fileOutputStream closed exception", e);
        }
    }
}

[/code]

刚才看了你的回复：
[quote]
1、根据JPROFILE监控的数据是close()执行的时间长。
2、将每个报文记录到单独的文件中，分开不同的文件。
3、关于磁盘响应，有什么比较好的方式监控，这个还请赐教。
4、不用取文件，每次文件都是新增。目录之前是按年月日小时，后来我也以为是文件太多，再加了一层分钟，但还是没什么效果。 2012-09-18 15:01
[/quote]

90%的可能是IO写的瓶颈问题，而不是程序：
测试办法：
1. 找一台有固态硬盘的电脑
2. 先使用普通硬盘的测试下
3. 再使用固态硬盘的测试下
4. 再对比两者差别。
分析：如果固态硬盘依然慢，就说明是程序瓶颈，否则就是硬盘IO瓶颈。

优化建议：
1. 使用一个线程写文件，而不是多个线程同时写（IO写基本上单线程最优）
2. 基于条件1，写一个文件而不是多个文件。

对比：java里面的日志记录，基本上都是多个线程同时在写日志，一般优化都是先缓冲，积累日志，再写入文件。

试试jdk7

你怎么知道是在close耗时还是write, flush耗时？
整个压力测试是在写文件，是写同一个文件还是不同的文件？
磁盘响应如何？压力大的情况下写不同文件肯定耗时增加啊！
写的都是在同一个目录下？同一目录下文件越多，你不去write，光取一个文件都要耗很大资源。

所有问题都理清了再说。

建议加上 BufferedOutputStream做缓冲

close时间比write时间还长？换NIO试试呢？

先确定真正原因
RandomAccessFile
这个类操作文件效率高。