候選項：
Jetty + Apache FileUpload
JDK自帶的HttpServer + 自行解析
Simple
Jetty + Jetty MultiPartFilter
備注：tomcat過于臃腫，不考慮。
測試情況：
兩臺機器，一臺使用httpclient模擬客戶端上傳文件，一臺作為http服務器。
兩臺機器均為8核、8G內存。
耗時：
以32..6M的文件測試
|
框架|性能|并發數
|
1
|
20
|
100
|
200
|
|
Jetty + Apache FileUpload
|
5.5s
|
13.7s
|
111s
|
207s
|
|
JDK自帶的HttpServer
|
5.8s
|
78s
|
390
|
--
|
|
Simple
|
5.2s
|
24s
|
130s
|
330s
|
|
Jetty+ Jetty MultiPartFilter
|
5.5s
|
26s
|
112s
|
203s
|
單線程情況下， 性能均差不多，在多線程情況下JDK自帶的HttpServer和Simple調度能力不足。
Cpu占用率
|
框架
|
200個并發時Cpu占用率
|
|
Jetty + Apache FileUpload
|
130%
|
|
JDKServer
|
350%
|
|
Simple
|
120%
|
|
Jetty+ Jetty MultiPartFilter
|
130%
|
客戶端：8核全負載，HttpClient太耗資源了。
服務器端：JDKServer比較耗資源，其他的都穩定在130%左右
功能拓展性：
拓展性主要考慮：
HttpServer接受到上傳請求時的一些處理。比如：當請求到Server時，如果合法則獲取輸入流進行上傳；如果不合法，則直接返回處理結果。
Simple ： 文件全部上傳到臨時文件夾后才能進行業務處理。極度不符合
MultiPartFilter： 使用過濾器處理缺點有二：一是業務邏輯不集中，部分在于Servlet中，部分在于過濾器中；二是改寫MultiPartFilter并進行封裝的難度稍大。
JDK自帶Server: 符合條件。但需要自己解析http輸入流，并進行封裝。難度較大。
Apache FileUpload：符合條件，對Http請求的封裝很棒。
Apache FileUpload > JDKServer > MultiPartFilter> Simple
最終選擇：Jetty + Apache FileUpload