問題：

????js上傳文件時文件太大導(dǎo)致的上傳失敗，到底多大會上傳失敗沒測試過（因為我測試上傳了一個10G文件失敗了）。原因猜測很多，可能和post之類的網(wǎng)絡(luò)協(xié)議有關(guān)，可能和后臺某些設(shè)置有關(guān)。

思路：

????思路挺簡單的，因為前臺上傳使用的?Web Uploader,一個百度的插件，文檔里清清楚楚寫著有一個multiple屬性，設(shè)置成true開啟分片上傳，聽名字就知道可以用來上傳大文件，我想斷點續(xù)傳之類的應(yīng)該都是用這個做的吧。嘛，我的需求沒那么復(fù)雜，能上傳就行。然后重點是后臺。

? ? 分片上傳后臺的接收，網(wǎng)上很多帖子的做法是用RandomAccessFile獲取到文件，然后把文件下標(biāo)（不知道怎么形容好）移到文件最后，然后把分片上傳的數(shù)據(jù)寫入到后面。

? ? 然后我遇見的問題有兩個，一個一個遇見的。。1.分片上傳他是速度很快的發(fā)送數(shù)據(jù)，然后tomcat應(yīng)該會為每個請求分配不同的線程，所以有多線程問題（比如第一個請求正在寫數(shù)據(jù)還沒寫完第二個請求就把文件拿過去接著寫了）。2.分片上傳因為是請求，所以順序是不能保證的，每次都在文件最后開始寫入會出現(xiàn)文件損壞。（eg：一個文件叫做"123"，現(xiàn)在把文件拆分成"1","2","3"。分三次請求發(fā)送給服務(wù)器，服務(wù)器的接收順序可能是321,132。這樣會造成文件損壞）。

解決：

? ? 問題1：一開始在網(wǎng)上找資料發(fā)現(xiàn)有個叫文件鎖的東西可以用，可是報了一個錯，網(wǎng)上管管這個錯誤是因為線程一獲取了文件鎖，在線程一沒有釋放的時候線程二去獲取這個鎖就會拋出異常。囧。我理解的鎖難道不該是線程二沒獲取到鎖應(yīng)該就等著線程一釋放再去獲取嘛，直接拋出異常是什么鬼。嘛，不想這么多，直接給拼接方法那里加個 synchronized 關(guān)鍵字就好了。這樣大小起碼看起來是正常了（雖然這樣做并沒有什么卵用）。

? ? 問題2：這個是最蛋疼的，測試的時候發(fā)現(xiàn)壓縮包文件在這樣上傳后會出現(xiàn)文件損壞，想了很久還是經(jīng)過同事提醒才認(rèn)識到這個問題。知道問題，思路就可以有很多了，位置不對放對位置就好了嘛。我的思路是多看了下uploader這個插件，分片上傳時給把文件大小，分片總數(shù)，當(dāng)前分片數(shù)都傳給你。然后根據(jù)這個些參數(shù)在設(shè)置文件大小，根絕當(dāng)前分片數(shù)移動到對應(yīng)位置寫入數(shù)據(jù)就好了。這樣寫上邊問題1加上的?synchronized 關(guān)鍵字去掉也可以。

? ? 因為代碼直接復(fù)制過來都沒格式了。所以就簡單說下問題和思路?？匆院髸粫锌赵儋N代碼咯。