我有一個功能，其目的是創建一個目錄并將 csv 檔案復制到該目錄。同一個函式被多次運行，每次都由不同執行緒中的一個物件運行。它在物件的建構式中被呼叫，但我在那里有邏輯只在檔案不存在時復制檔案（意思是，它檢查以確保并行的其他實體之一尚未創建它）。
現在，我知道我可以簡單地重新排列代碼，以便在并行運行物件之前創建此目錄并復制檔案，但這對我的用例來說并不理想。
我想知道，以下代碼會失敗嗎？也就是說，由于其中一個實體正在復制檔案，而另一個實體試圖開始將同一檔案復制到同一位置？
private void prepareGroupDirectory() {
new File(outputGroupFolderPath).mkdirs();
String map = "/path/map.csv"
File source = new File(map);
String myFile = "/path/test_map.csv";
File dest = new File(myFile);
// copy file
if (!dest.exists()) {
try{
Files.copy(source, dest);
}catch(Exception e){
// do nothing
}
}
}
總結一下。這個函式是否是執行緒安全的，因為不同的執行緒都可以并行運行這個函式而不會中斷？我想是的，但任何想法都會有所幫助！
需要明確的是，我已經對此進行了多次測驗，并且每次都有效。我問這個問題是為了確保理論上它永遠不會失敗。
編輯：此外，這是高度簡化的，以便我可以以易于理解的格式提出問題。
這是我在遵循評論后現在所擁有的（我仍然需要使用nio），但目前正在作業：
private void prepareGroupDirectory() {
new File(outputGroupFolderPath).mkdirs();
logger.info("created group directory");
String map = instance.getUploadedMapPath().toString();
File source = new File(map);
String myFile = FilenameUtils.getBaseName(map) "." FilenameUtils.getExtension(map);
File dest = new File(outputGroupFolderPath File.separator "results_" myFile);
instance.setWritableMapForGroup(dest.getAbsolutePath());
logger.info("instance details at time of preparing group folder: {} ", instance);
final ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
// copy file
if (!dest.exists()) {
String pathToWritableMap = createCopyOfMap(source, dest);
logger.info(pathToWritableMap);
}
} catch (Exception e) {
// do nothing
// thread-safe
} finally {
lock.unlock();
}
}
uj5u.com熱心網友回復：
不是。
您正在尋找的是旋轉到位的概念。檔案操作的問題在于幾乎沒有一個是原子的。
大概您不只是希望“只有一個”執行緒贏得制作此檔案的競賽，您還希望該檔案是完美的，或者根本不存在：您不希望任何人能夠觀察該 CSV 檔案處于半生不熟的狀態，您肯定不希望在生成 CSV 檔案的程序中發生崩潰，這意味著該檔案在那里，半生不熟，但它的存在意味著它阻止了任何嘗試正確寫出它。您不能使用finally塊或例外捕獲來解決此問題；有人可能會被電源線絆倒。
那么，您如何解決所有這些問題？
你不寫foo.csv。相反，您寫入foo.csv.23498124908.tmp該數字隨機生成的位置。因為這不是任何人正在尋找的實際 CSV 檔案，所以您可以花所有的時間來正確地完成它。完成后，您就可以使用魔術：
您重命名foo.csv.23498124908.tmp為foo.csv，并以原子方式進行- 一個瞬間foo.csv不存在，下一個瞬間存在，并且具有完整的內容。此外，只有在檔案之前不存在時，重命名才會成功：兩個單獨的執行緒不可能同時將它們的foo.csv.23481498.tmp檔案重命名為foo.csv。如果您要嘗試并獲得完美的時機，其中一個（任意哪個）“獲勝”，另一個會收到 IOException 并且不會重命名任何內容。
這樣做的方法是使用Files.move(from, to, StandardCopyOptions.ATOMIC_MOVE). 如果作業系統/檔案系統組合以某種方式根本不支持 ATOMIC_MOVE（盡管它們幾乎都支持），ATOMIC_MOVE 甚至可以完全拒絕執行。
第二個優點是，即使您有多個完全不同的應用程式在運行，這種鎖定機制也能正常作業。如果他們都ATOMIC_MOVE在該語言的 API 中使用或等效，那么只有一個可以獲勝，無論我們是在談論“JVM 中的執行緒”還是“系統上的應用程式”。
如果您想避免多個執行緒同時進行作業以制作此 CSV 檔案的概念，即使只有一個應該這樣做，其余的應該“等待”直到第一個執行緒完成，檔案系統鎖不是答案- 你可以嘗試（創建一個空檔案，它的存在表明其他執行緒正在處理它） - 在 java 的java.nio.fileAPI 中甚至有一個原語。這CREATE_NEW標志可以在創建檔案時使用，這意味著：以原子方式創建它，如果檔案已經存在并保證并發（如果多個行程/執行緒都同時運行，一個成功，其他所有失敗，保證），則失敗。但是， CREATE_NEW 只能以原子方式創建。它不能以原子方式寫入，沒有任何東西可以（因此上面的整個“將其重命名到位”技巧）。
這種鎖的問題有兩個：
- 如果 JVM 崩潰，該檔案不會消失。曾經啟動過一個linux守護行程，比如postgresd，它告訴你'pid檔案還在那里，如果沒有postgres運行，請洗掉它'？是的，那個問題。
- 沒有辦法知道它何時完成，只能每隔幾毫秒重新檢查該檔案是否存在。如果您等待很少幾毫秒，您可能會破壞磁盤（希望您的作業系統和磁盤快取演算法做得不錯）。如果你等了很久，你可能會無緣無故地等很長時間。
因此，為什么你不應該做這些事情，而只是在行程中使用鎖。使用synchronized或制作新的java.util.concurrent.ReentrantLock或諸如此類的東西。
具體回答您的代碼段，沒有被打破：這是可能的2個執行緒同時運行，并都得到false，當它運行dest.exists()，從而既進入副本塊，然后將它們復制時摔倒各地相互-根據檔案系統，通常一個執行緒最終“獲勝”，他們的復制操作成功，而另一個執行緒似乎丟失了以太（大多數檔案系統是基于參考/節點的，這意味著檔案被寫入磁盤但它的“指標”被立即覆寫，并且檔案系統或多或少認為它是垃圾）。
大概您認為這是一個失敗的場景，并且您的代碼并不能保證它不會發生。
NB: What API are you using? Files.copy(instanceOfJavaIoFile, anotherInstanceOfJavaIoFile) isn't java. There is java.nio.file.Files.copy(instanceOfjnfPath, anotherInstanceOfjnfPath) - that's the one you want. Perhaps this Files you have is from apache commons? I strongly suggest you don't use that stuff; those APIs are usually obsolete (java itself has better APIs to do the same thing), and badly designed. Ditch java.io.File, it's outdated API. Use java.nio.file instead. The old API doesn't have ATOMIC_MOVE or CREATE_NEW, and doesn't throw exceptions when things go wrong - it just returns false which is easily ignored and has no room to explain what went wrong. Hence why you should not use it. One of the major issues with the apache libraries is that it uses the anti-pattern of piling a ton of static utility methods into a giant container. Unfortunately, the second take on file stuff in java itself (java.nio.file) is similarly boneheaded API design. I guess in the java world, third time will be the charm. At any rate, a bad core java API with advanced capabilities is still a better than a bad apache utility API that wraps around the older API which simply does not expose the kinds of capabilities you need here.
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/344600.html
標籤：爪哇 多线程 异步 thread-safety