java处理大文本方案

转载自：http://langgufu.iteye.com/blog/2107023

java处理大文件，一般用BufferedReader,BufferedInputStream这类带缓冲的Io类，不过如果文件超大的话，更快的方式是采用MappedByteBuffer。

MappedByteBuffer是java nio引入的文件内存映射方案，读写性能极高。NIO最主要的就是实现了对异步操作的支持。其中一种通过把一个套接字通道(SocketChannel)注册到一个选择器(Selector)中,不时调用后者的选择(select)方法就能返回满足的选择键(SelectionKey),键中包含了SOCKET事件信息。这就是select模型。

SocketChannel的读写是通过一个类叫ByteBuffer(java.nio.ByteBuffer)来操作的.这个类本身的设计是不错的,比直接操作byte[]方便多了.
ByteBuffer有两种模式:直接/间接.间接模式最典型(也只有这么一种)的就是HeapByteBuffer,即操作堆内存
(byte[]).但是内存毕竟有限,如果我要发送一个1G的文件怎么办?不可能真的去分配1G的内存.这时就必须使用"直接"模式,即
MappedByteBuffer,文件映射.
    
先中断一下,谈谈操作系统的内存管理.一般操作系统的内存分两部分:物理内存;虚拟内存.虚拟内存一般使用的是页面映像文件,即硬盘中的某个(某些)特殊的文件.操作系统负责页面文件内容的读写,这个过程叫"页面中断/切换".
MappedByteBuffer也是类似的,你可以把整个文件(不管文件有多大)看成是一个ByteBuffer.MappedByteBuffer
只是一种特殊的 ByteBuffer ，即是ByteBuffer的子类。 MappedByteBuffer
将文件直接映射到内存（这里的内存指的是虚拟内存，并不是物理内存）。通常，可以映射整个文件，如果文件比较大的话可以分段进行映射，只要指定文件的那个部分就可以。

三种方式：
             
FileChannel提供了map方法来把文件影射为内存映像文件： MappedByteBuffer map(int mode,long
position,long size); 可以把文件的从position开始的size大小的区域映射为内存映像文件，mode指出了
可访问该内存映像文件的方式：READ_ONLY,READ_WRITE,PRIVATE.                    
a. READ_ONLY,（只读）： 试图修改得到的缓冲区将导致抛出 ReadOnlyBufferException.(MapMode.READ_ONLY)
 b. READ_WRITE（读/写）： 对得到的缓冲区的更改最终将传播到文件；该更改对映射到同一文件的其他程序不一定是可见的。 (MapMode.READ_WRITE)
c. PRIVATE（专用）： 对得到的缓冲区的更改不会传播到文件，并且该更改对映射到同一文件的其他程序也不是可见的；相反，会创建缓冲区已修改部分的专用副本。 (MapMode.PRIVATE)

三个方法：

a. fore();缓冲区是READ_WRITE模式下，此方法对缓冲区内容的修改强行写入文件
b. load()将缓冲区的内容载入内存，并返回该缓冲区的引用
c. isLoaded()如果缓冲区的内容在物理内存中，则返回真，否则返回假

三个特性：

调用信道的map()方法后，即可将文件的某一部分或全部映射到内存中，映射内存缓冲区是个直接缓冲区，继承自ByteBuffer,但相对于ByteBuffer,它有更多的优点：

a. 读取快
b. 写入快
c. 随时随地写入

下面来看代码：

1 package study;
2 import java.io.FileInputStream;
3 import java.io.FileOutputStream;
4 import java.nio.ByteBuffer;
5 import java.nio.MappedByteBuffer;
6 import java.nio.channels.FileChannel;
7
8 public class MapMemeryBuffer {
9
10 public static void main(String[] args) throws Exception {
11 ByteBuffer byteBuf = ByteBuffer.allocate(1024 * 14 * 1024);
12 byte[] bbb = new byte[14 * 1024 * 1024];
13 FileInputStream fis = new FileInputStream("e://data/other/UltraEdit_17.00.0.1035_SC.exe");
14 FileOutputStream fos = new FileOutputStream("e://data/other/outFile.txt");
15 FileChannel fc = fis.getChannel();
16 long timeStar = System.currentTimeMillis();// 得到当前的时间
17 fc.read(byteBuf);// 1 读取
18 //MappedByteBuffer mbb = fc.map(FileChannel.MapMode.READ_ONLY, 0, fc.size());
19 System.out.println(fc.size()/1024);
20 long timeEnd = System.currentTimeMillis();// 得到当前的时间
21 System.out.println("Read time :" + (timeEnd - timeStar) + "ms");
22 timeStar = System.currentTimeMillis();
23 fos.write(bbb);//2.写入
24 //mbb.flip();
25 timeEnd = System.currentTimeMillis();
26 System.out.println("Write time :" + (timeEnd - timeStar) + "ms");
27 fos.flush();
28 fc.close();
29 fis.close();
30 }
31
32 }
33 运行结果：
34 14235
35 Read time :24ms
36 Write time :21ms
37 我们把标注1和2语句注释掉，换成它们下面的被注释的那条语句，再来看运行效果。14235
38 Read time :2ms
39 Write time :0ms

可以看出速度有了很大的提升。MappedByteBuffer的确快，但也存在一些问题，主要就是内存占用和文件关闭等不确定问题。被MappedByteBuffer打开的文件只有在垃圾收集时才会被关闭，而这个点是不确定的。在javadoc里是这么说的：A mapped byte buffer and the file mapping that it represents remain valid until the buffer itself  is garbage-collected.
这里提供一种解决方案：

AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
try {
Method getCleanerMethod = buffer.getClass().getMethod("cleaner", new Class[0]);
getCleanerMethod.setAccessible(true);
sun.misc.Cleaner cleaner = (sun.misc.Cleaner)
getCleanerMethod.invoke(byteBuffer, new Object[0]);
cleaner.clean();
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
});

关于MappedByteBuffer资源释放问题

1 //文件复制
2 public void copyFile(String filename,String srcpath,String destpath)throws IOException {
3 File source = new File(srcpath+"/"+filename);
4 File dest = new File(destpath+"/"+filename);
5 FileChannel in = null, out = null;
6 try {
7 in = new FileInputStream(source).getChannel();
8 out = new FileOutputStream(dest).getChannel();
9 long size = in.size();
10 MappedByteBuffer buf = in.map(FileChannel.MapMode.READ_ONLY, 0, size);
11 out.write(buf);
12 in.close();
13 out.close();
14 source.delete();//文件复制完成后，删除源文件
15 }catch(Exception e){
16 e.printStackTrace();
17 } finally {
18 in.close();
19 out.close();
20 }
21 }

但是如果要实现文件文件复制完成后，删除源文件，以上方法就有问题。因为在source.delete()时，会返回false，删除失败，主 要原因是变量buf仍然有源文件的句柄，文件处于不可删除状态。既然MappedByteBuffer是从FileChannel中map()出来的，为 什么它又不提供unmap()呢？SUN自己也没有讲清楚为什么。O'Reilly的<<Java NIO>>中说是因为"安全"的原因，但是到底unmap()会怎么不安全，作者也没有讲清楚。

在sun网站也有相应的BUG报告：bug id:4724038链接为http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4724038，但是sun自己不认为是BUG，而只是一个RFE(Request For Enhancement)，有待改进。

好在有个叫bellomi的网友提出了一个解决方法，我也测试过，可以实现期望的功能。具体实现代码如下：

1 public static void clean(final Object buffer) throws Exception {
2 AccessController.doPrivileged(new PrivilegedAction() {
3 public Object run() {
4 try {
5 Method getCleanerMethod = buffer.getClass().getMethod("cleaner",new Class[0]);
6 getCleanerMethod.setAccessible(true);
7 sun.misc.Cleaner cleaner =(sun.misc.Cleaner)getCleanerMethod.invoke(buffer,new Object[0]);
8 cleaner.clean();
9 } catch(Exception e) {
10 e.printStackTrace();
11 }
12 return null;}});
13
14 }

不知道为什么SUN不提供ByteBuffer的派生。毕竟这是一个很实用的类，如果允许派生，那么我就可以操作的就不仅仅限于堆内存和文件了，我可以扩展到任何存储设备。