Java文件上传组件，Fastupload 0.31 功能完备速度飙升

   <p><a href="/misc/goto?guid=4958347258558211177" target="_blank">fastupload </a>0.31版本上周已经发布，因为工作的关系，只到今天才有点时间来写一些0.31版本中深层次的东西。fastupload以前的版本，尽管在性能上取得 了不小的进步，但只支持解析文件，不支持解析非文件的内容，因为HttpFileUploadParser这个类来解析ServletRequest的输 入流的过程中，忽略非文件的请求数据。举个列子来说，假如表单中有两个input标签，一个是文本输入控件，一个是文件输入控件，经过 HttpFileUploadParser解析后，只会把文件类型请求的数据保存在指定的目录下。</p>    <p>在fastupload项目编写之初，考虑的是如何把文件类型请求的数据保存到文件中去，在这种目标下，如何处理非文件类型请求数据？自然的”选择“了忽略这种方式。</p>    <p>在fastupload 0.23发布后 ，原计划是在下一个版本中提供对struts2、spring mvc3的注解(annotation)一些高级特性的支持，有些网友对fastupload提出了批评和建议，其中，网友<strong>silence1214</strong> 提出了对于非文件类型请求数据的处理问题。经过仔细考虑后，决定先实现非文件类型请求数据的处理。于是，0.31版本中，类HttpMemoryUploadParser能处理非文件类型的请求数据了，具体的示例代码如下，</p>    <pre class="brush:java; toolbar: true; auto-links: false;">MultiPartDataFactory mpdf = new MemoryMultiPartDataFactory("utf-8");    HttpMemoryUploadParser uploadParser = new HttpMemoryUploadParser(request, mpdf);    long s = System.currentTimeMillis();    List<MultiPartData> list = uploadParser.parseList();      File dir = new File(System.getProperty("user.home") + "/memoryupload/dump");    dir.mkdirs();      for (MultiPartData e : list) {     String target = String.format("%s/%s", dir.getAbsolutePath(), e.getFileName());     if (e.isFile()) {     e.toFile(target);     }     else {      System.out.println(new String(e.getContentBuffer()));     }    }      System.out.format("memoryupload cost: %d %n", System.currentTimeMillis() - s);</pre>    <p> </p>    <p>当新建一个HttpMemoryUploadParser类的实例时，首先读取ServletRequest输入流中所有的字节，写入内存缓冲中，parseList()函数从这片大的缓冲中解析上传表单中的内容，返回一个包含MultiPartData类型的数组。</p>    <p> </p>    <p>这里的MultiPartData是multipart/form-data中两个边界(boundary)中数据的一个抽象。上传请求数据中的头 部信息表明这部分数据是一个文件中的内容，还是输入控件中“输入”的内容，MultiPartData.isFile()函数则实现了这个判断功能，此 外，MultiPartData.getContentHeaderMap()函数把这些“头部信息”以Map的形式暴露出来，供外部代码使用。</p>    <p>在成功解析上传表单后，每个MultiPartData都有一个自己的一片内存缓冲，用于保存解析后所得出的数据，如果需要把这些数据保存到文件中 去，则调用toFile()函数，如果想直接获得数据，则调用getContentBuffer()函数。需要提醒的是，创建 MemoryMultiPartDataFactory时，指定了字符集，MemoryMultiPartDataFactory在创建 MemoryMultiPartData对象时，对把name属性转换成所指定的字符集字符串，对于所解析出的内容，并不做字符集的转换，因为数据已经读 入到内存中，开发人员可以对其转换成所期望的字符集，不象MultiPartTextFile写入时，需要强制进行字符集转换。</p>    <p>对于支持非文件类型请求后，fastupload和Apache Commons FileUpload的性能相比，是一个什么样的结果呢？继续做一个实际的测试对比，分别用fastupload的 HttpMemoryUploadParser和Apache Commons FileUpload的相类似的API接受1.7M、1.7M和1.2M的图像文件。得到下面的测试结果，单位毫秒。</p>    <pre class="java">memoryupload cost: 10   memoryupload cost: 8   memoryupload cost: 11   memoryupload cost: 8   memoryupload cost: 12   memoryupload cost: 8   memoryupload cost: 48   memoryupload cost: 14   memoryupload cost: 346   memoryupload cost: 11   memoryupload cost: 8   memoryupload cost: 9   memoryupload cost: 14   memoryupload cost: 8   memoryupload cost: 14   memoryupload cost: 9   memoryupload cost: 10   memoryupload cost: 14   memoryupload cost: 10   memoryupload cost: 12   Apache Common File Upload costs: 379   Apache Common File Upload costs: 29   Apache Common File Upload costs: 66   Apache Common File Upload costs: 87   Apache Common File Upload costs: 92   Apache Common File Upload costs: 24   Apache Common File Upload costs: 195   Apache Common File Upload costs: 286   Apache Common File Upload costs: 25   Apache Common File Upload costs: 314   Apache Common File Upload costs: 50   Apache Common File Upload costs: 84   Apache Common File Upload costs: 217   Apache Common File Upload costs: 86   Apache Common File Upload costs: 314   Apache Common File Upload costs: 120 </pre>    <p>可以看出，两组数据中，最快的单次时间比是8:24，如果比较两组数据中前10个的平均值，这个比是8.8:51，如果比较最慢的10个数据的平均值，是49.6:229, 最慢的单次比值是 346:379，相差不大，平均时间比是29.2:140。</p>    <p>总的说来，得益于改进的BM查找算法，HttpMemoryUploadParser解析速度比Apache Commons FileUpload的要快好很多，速度上占据了绝对的优势，从最慢那个对比来看，fastupload仍然有提高的空间，比如说尽可能的优化内存的使 用。</p>    <p>开源fastupload项目纯粹我当时的一个想法，没想到引起了广大网友的注意，不屑、质疑、建议、批评的都有，不管怎么说，你们的声音是fastupload项目前进中动力的重要部分，这里特别感谢广大网友。</p>