進程間文件交換：效率和競爭條件

Question

故事：
幾天前，我在考慮基於文件交換的進程間通信。 假設進程A在其工作期間創建了幾個文件，然后進程B讀取這些文件。 為確保正確寫入所有文件，創建一個特殊文件會很方便，該文件的存在將表明所有操作都已完成。

工作簡單：
進程A創建文件“file1.txt”
進程A創建文件“file2.txt”
進程A創建文件“processA.ready”

進程B正在等待文件“processA.ready”出現，然后讀取file1和file2。

釋疑：
文件操作由操作系統執行，特別是由文件子系統執行。 由於Unix，Windows或MacOS的實現可能不同，我不確定文件交換進程間通信的可靠性。 即使操作系統能夠保證這種一致性，Java中的JIT編譯器也可以重新排序程序指令。

問題：
1.操作系統中的文件操作是否有任何實際規范？
2. JIT是否真的允許為單個程序線程重新排序文件操作程序指令？
3.文件交換現在仍然是進程間通信的相關選項，還是無條件地更好地選擇TCP / HTTP /等？

Answer 1

1. 在這種情況下，您無需了解操作系統詳細信息。 記錄Java IO API以猜測文件是否已保存。
2. JVM無法重新排序本機調用。 它不是明確地用JMM編寫的，但暗示它不能這樣做。 JVM無法猜測本機調用的影響是什么，並且那些調用的重新排序可能相當慷慨。
3. 使用文件作為溝通方式有一些缺點：
   1. 它使用緩慢的IO
   2. 如果您需要它，很難在不同機器之間分離進程（例如，有使用samba的方法，但是非常依賴於平台）

Answer 2

1. 您可以在Java中使用File watcher（WatchService）在.ready文件出現時接收信號。

2. 重新排序可能適用但在這種情況下不應該損害您的應用程序邏輯 - 請參閱以下鏈接： https ： //assylias.wordpress.com/2013/02/01/java-memory-model-and-reordering/

3. 我不知道您的數據大小，但我覺得在這種情況下使用Message Queue（MQ）解決方案仍然會更好。 使用文件IO是一個相對較慢的操作，可能會降低系統速度。

Answer 3

在我的一個項目上使用基於文件交換的方法。 它基於在進程完成時重命名文件擴展名，以便其他進程可以通過文件名表達式檢查來檢索它。

1. FTP進程下載文件並將其名稱命名為“.downloaded”
2. 主任務處理器在目錄中搜索文件'* .downloaded'。
   在開始之前，作業更新文件名為“.processing”。
   完成后，更新為“.done”。
   如果出現錯誤，它會創建一個帶有“.error”擴展名的新補充文件，並將最后處理的行和異常跟蹤放在那里。 在重試時，如果此文件存在，則讀取它並從正確的位置繼續。
3. 定位器進程搜索“.done”並根據其配置移動到備份文件夾或刪除

這種方法在移動運營商網絡中的巨大負載下運行良好。

考慮點是對文件使用唯一名稱很重要。 因為移動文件的行為會根據操作系統而改變。
例如，當目的地中存在相同文件時，Windows會出錯，但是unix會將其刪除。