最近刚刚完成了一个需要比以往更多的IO交互的项目,我觉得我想看看过去的常规库(特别是Commons IO),并解决更多的IO问题。
作为学术测试,我决定实施一个基本的多线程HTTP下载器。这个想法很简单:提供一个下载的URL,代码将下载该文件。为了提高下载速度,文件被分块,并且每个块同时下载(使用HTTP Range:bytes = x-xheader)尽可能多地使用带宽。
我有一个工作原型,但是你可能已经猜到了,这不完全是理想的。目前我手动启动3个“下载器”线程,每个线程都下载1/3的文件。这些线程使用一个通用的,同步的“文件写入器”实例来将文件实际写入磁盘。完成所有线程后,“文件写入程序”完成,任何打开的流都关闭。一些代码片段给你一个想法:
线程启动:
ExecutorService downloadExecutor = Executors.newFixedThreadPool(3);
...
downloadExecutor.execute(new Downloader(fileWriter, download, start1, end1));
downloadExecutor.execute(new Downloader(fileWriter, download, start2, end2));
downloadExecutor.execute(new Downloader(fileWriter, download, start3, end3));
每个“下载器”线程下载一个块(缓冲),并使用“文件写入器”写入磁盘:
int bytesRead = 0;
byte[] buffer = new byte[1024*1024];
InputStream inStream = entity.getContent();
long seekOffset = chunkStart;
while ((bytesRead = inStream.read(buffer)) != -1)
{
fileWriter.write(buffer, bytesRead, seekOffset);
seekOffset += bytesRead;
}
“文件写入程序”使用RandomAccessFile向磁盘写入()和write()块到磁盘:
public synchronized void write(byte[] bytes, int len, long start) throws IOException
{
output.seek(start);
output.write(bytes, 0, len);
}
所有考虑的事情,这种方法似乎都奏效。但是,它不能很好地工作。对以下几点我会感谢一些建议/帮助/意见。非常感激。
>这个代码的CPU使用率是通过屋顶。它使用一半的CPU(每个2核的50%)来做到这一点,这比可以下载的几乎没有任何CPU压力的下载工具多一点。我对这个CPU使用率来自哪里有点神秘,就像我没想到的那样。
>通常,3个线程中有1个明显落后。其他2个线程将完成,之后它需要第三个线程(这似乎主要是第一个线程的第一个线程)30秒或更多秒完成。我可以从任务管理器看到,javaw进程仍在进行小型IO写入,但是我不知道为什么会发生这种情况(我在猜测竞争条件?)。
>尽管我已经选择了相当大的缓冲区(1MB),但是我觉得InputStream几乎从来没有实际填满缓冲区,这会导致比我想要的更多的IO写入。我的印象是,在这种情况下,最好将IO访问限制在最低限度,但我不知道这是否是最佳方法。
>我认识到Java可能不是这样做的理想语言,但我相信有更多的性能要比我现在的实现。在这种情况下,NIO值得探索吗?
注意:我使用Apache HTTPClient执行HTTP交互,这是entity.getContent()来自哪里(万一有人想知道)。