最近工作用到windows 訪問共享目錄，進行文件操作。途中遇到很多問題，在當初開始寫代碼的時候覺得沒什麼問題，
一旦線上大規模測試，問題就暴露出來；把遇到的問題總結下：
1、同一個文件的讀寫同時問題：
相信很多人都遇到過，在去讀取一個文件的時候發現讀取出錯或者讀取的並不是一個全文件，
而只是一部分； 特別是在分佈式的情況下，當A線程往這個文件裏面寫內容，另一個B線程從
這個文件讀取內容，文件被A佔用後，其他線程就只能讀， 在windows共享訪問
（非商用下載工具，沒測試過）的情況下，讀取出來的就是部分內容。如果這時還有
C線程想往文件中寫入，就會出錯。
而判斷一個文件是否讀寫完成 就通過file.renameTo 來判斷，爲true或者false 代表是否被佔用與否；
2、共享文件夾的訪問量問題：
在我們的程序中，對共享文件夾的訪問是大數據量頻繁訪問，偶爾就會出現 “網絡名不再可用”，
相信很多人在百度裏面搜索一下都能看到很多， 這裏所說的和網站上看到的還是有點關聯；
首先，出現這個問題，說明網絡共享文件夾的網絡名稱對外不可用，舉一個最簡單的例子就是（公司用
內網大部分都是局域網通過寬帶接入，路由分配ip 然後pc獲得ip連接上網，如果帶寬爲4M，
但是公司內容有幾個同事開了p2p 把帶寬佔完了，其他人能連接上本地，但是也訪問不了外網）；
這裏網絡名不可用在我分析就是一個道理。由於線程訪問數過多，加上內部網絡的各種因數，
很可能出現這種情況。
採取措施：A、做好異常處理機制： 所有與網絡共享文件夾訪問有關的地方都加上異常處理，如果出錯，
想好下步action（既然是不可避免的問題，那就去解決吧）
B、網絡上有設置“客戶端和服務器的併發命令的數量上限限制”，這個能解決一些小併發量得問題；
但是大併發量頻繁操作的話，還是要出現網絡名不可用 的情況；
C、增加共享文件夾的數量：比如之前是從一個文件夾下面讀取數據， 限制設置爲兩個分別在
不同的ip下，降低每個共享文件夾的訪問流量壓力；但是爲了 防止大文件比較集中的情況，
導致訪問線程數一個時間段內過高，共享文件夾訪問壓力大，還是要對共享文件夾訪問加上
異常處理機制。
個人小體會，歡迎大家噴墨