Java FileChannel 的使用體會

今天看到一篇文章，說用NIO複製比較快。

原文是[url]http://www.iteye.com/topic/667457[/url]

我就寫一篇關於FileChannel的文章吧，大家可以一起討論。

首先來看

public abstract long transferTo(long position,
long count,
WritableByteChannel target)
throws IOException
[color=red]An attempt [/color]is made to read up to count bytes starting at the given position in this channel's file and write them to the target channel. An invocation of this method may or may not transfer all of the requested bytes; whether or not it does so depends upon the natures and states of the channels.[color=green]Fewer than the requested number of bytes are transferred if this channel's file contains fewer than count bytes starting at the given position, or if the target channel is non-blocking and it has fewer than count bytes free in its output buffer. [/color]

[color=blue]This method is potentially much more efficient than a simple loop that reads from this channel and writes to the target channel.[/color] Many operating systems can transfer bytes directly from the filesystem cache to the target channel without actually copying them.

首先這個方法是一個attempt，意味著你可能得不到所有的byte。

綠色部分解釋了這個原因，首先這是個non-blocking的方法，遇到網絡或者其他方法，很容易得不到所有的byte而返回，此外，到底是阻塞還是非阻塞，還與文件的句柄本身有關，有文件設置為阻塞的，有些是非阻塞的，比如unix。

最下面的藍色部分，闡述了這個原理上更快的原因。

其實，transferTo method 實際上會先從 source channel 取得 MappedByteBuffer，然後在把 MappedByteBuffer 的內容傳輸到 destination channel上面。但是值得注意的是，[color=red]這個操作不總是能夠成功[/color]，我在一台配置有 4G 內存的 Win7 上，沒有辦法去Map一個長度為2G的文件。會有exception:
java.io.IOException: Map failed
的異常，這點我目前是無法解釋的。

相反來說，BufferedReader可能原理上面沒有FileChannle快，但是非常穩定，並且速度上面並不遜於FileChnanel，主要是SUN對BufferedReader已經優化了無數次吧。

實際經驗而言，如果一次性COPY的數據大於MEM的1/4，我覺得還是使用BufferedReader，如果小一些的話，用FileChannel無疑最快，畢竟它還有一把FileLock，這是你多執行緒最佳選擇。