java各种上传技术 分析报告

工程下载：

http://woshiyinbin.iteye.com/admin/blogs/1859968

Jsp下测试数据（单位ms）

 

1.6 mb

	第一次	第二次	第三次	第四次	第五次
smartupload	40	40	55	45	40
fileupload	120	180	110	110	110
cos	60	60	55	50	50
javazoom	246	266	312	300	296

 

 

10 mb

	第一次	第二次	第三次	第四次	第五次
smartupload	385	335	370	355	325
fileupload	665	696	650	631	630
cos	330	340	305	330	315
javazoom	705	675	695	685	675

 

28 mb

	第一次	第二次	第三次	第四次
smartupload	1375	1000	982	1045
fileupload	1695	1785	1535	2470
cos	813	790	655	765
javazoom	1670	1781	1826	1771

 

74 mb （smartupload溢出）

	第一次	第二次	第三次
fileupload	3952	8515	9792
cos	2175	2069	2060
javazoom	4578	5007	9491

 

200+  mb （smartupload溢出）

	第一次
fileupload	17000
cos	8327
javazoom	33651

 

结论：

1.小文件，如10M以下的，cos和smartupload比较优越，超过10M，cos要优于smartupload

2.大文件估计超过50M，smartupload就会出现内存溢出这样的情况

3.fileupload， javazoom 性能上面相差不大

缺点：

1.不方便调试

Servlet下测试数据（单位 ms）

 

1.6 mb

	第一次	第二次
smartupload	98	101
fileupload	95	100
cos	53	57
javazoom	361	280

 

10 mb

	第一次	第二次
smartupload	365	500
fileupload	747	816
cos	351	336
javazoom	912	742

 

28 mb

	第一次	第二次
smartupload	1339	1179
fileupload	1389	1902
cos	908	840
javazoom	6918	6981

 

74 mb （smartupload溢出）

	第一次	第二次
fileupload	10822	14689
cos	2406	2492
javazoom	10490	5264

 

结论：

       1.和上面jsp对比，性能上面稍微有点缺损，这种缺损的价值还是值得，现在代码可以在servlet里面处理，方便调试

Struts 下测试数据（单位ms）

1.6 mb

	第一次	第二次	第三次
fileupload	52	58	38
javazoom	39	44	49

 

10 mb

	第一次	第二次	第三次
fileupload	220	242	229
javazoom	219	226	248

 

28 mb

	第一次	第二次	第三次
fileupload	630	617	611
javazoom	595	605	628

 

74 mb

	第一次	第二次	第三次
fileupload	1682	1797	1790
javazoom	1821	1622	1627

 

结论：

1.       性能上更加优化，比前两者的性能更好

2.       而且代码是在struts里面写的，和其他的框架方便整合

3.       如果需要换底层，比如fileupload 2.0或者javazoom，只需要修改配置文件

4.       底层使用 fileupload和javazoom性能上差不多，但javazoom要略优一些

5.       强调fileupload 2.0，是因为struts默认用的1.0，而且部分方法已经过时了

 

缺点：

1.       复杂度高，其他框架在struts里面不能使用，因为在经过action之前，request的流对象会被拦截，MultipartRequestHandler 会把里面流取出来，所以在action中再取出流会取不到，会抛异常，所以必须要自己实现MultipartRequestHandler接口。

2.       javazoom底层是把cos集成进来了，但速度上还是没有集成cos的优点，他和fileupload一样属于比较成熟的组件，API比较多，使用起来比较方便。

3.       如果底层换用cos，会遇到很多问题，必须对cos更深入的研究

 

改进：

1.       对比jsp和servlet，会发现cos的性能要优于fileupload，javazoom，如果struts底层换cos，性能可能比这要快。

前面的例子在包里面都有，而且使用简便，看下例子就明白了

 

介绍 MultipartRequestHandler实现这部分的结构

 

这代码主要在handler包里面，base包下的BaseMultipartRequestHandler实现了MultipartRequestHandler所有接口(除了handleRequest方法),JavaZoomHandler和CommonsFileUploadHandler继承BaseMultipartRequestHandler类，实现自己的handleRequest方法。

 

类里面有三个成员

elementsAll：存放所有从流中获取到得对象,包括elementsFile，elementsText

elementsFile：获取流中的FileItem

elementsText：获取流中普通字段

 

handleRequest(HttpServletRequest request)：

主要将拦截到的request中的流取出来,然后调用对应的addFileParameter，addTextParameter。

 

addFileParameter(FileItem item)

       主要将流中的FileItem取出来，将值塞入elementsAll，elementsFile

 

addTextParameter(HttpServletRequest request,Object)

       主要将流中的普通字段取出来，将值塞入elementsAll，elementsText

 

class CommonsFormFile implements FormFile, Serializable

       将底层的File取出的对象，封装成FormFile

 

注意：

1.  当使用Commsfileupload时

Jsp:

<input type="file" name="files" />

<input type="file" name="files" />

<input type="file" name="files1" />

<input type="file" name="files1" />

 

ActionForm:

    声明：

    List<FormFile> files，

    List<FormFile> files1，

 

一定要用List,不能用数组或者set,底层就是这样封装的。

 

2．当时用javazoom时

Jsp:

<input type="file" name="files" />

<input type="file" name="files1" />

<input type="file" name="files3" />

<input type="file" name="files1" />

 

ActionForm:

    声明：

    List<FormFile> files，

 

    Jsp上面的name可以随便取名字，但一定要有name这个属性，而且在ActionForm里面，只能用files，不能用其他的比如files1，files3，因为底层把所有的FormFile放在这个list里面