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